Escolar Documentos
Profissional Documentos
Cultura Documentos
Switching (MPLS)
Module Objectives
Introduction
Objectives
Timeline
Prerequisites and Follow-on
Administration
Module 0 | 2
Module 0 - Page 2
ALCATEL-LUCENT
NETWORK ROUTING SPECIALIST II
ALCATEL-LUCENT
ALCATEL-LUCENT
TRIPLE PLAY ROUTING PROFESSIONAL MOBILE ROUTING PROFESSIONAL
ALCATEL-LUCENT
SERVICE ROUTING ARCHITECT
49 DAYS / 11 COURSES / 11 WRITTEN EXAMS / 2 PRACTICAL LAB EXAMS
Module 0 | 3
3
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 0 - Page 3
Module 0 | 4
4
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 0 - Page 4
Exam Number
Exam Pre-requisites
(4A0-XXX)
4A0-100
NA
4A0-101
NA
4A0-102
NA
4A0-103
NA
4A0-104
NA
Exam Name
4A0-105
NA
4A0-106
NA
4A0-107
NA
4A0-108
NA
4A0-109
NA
4A0-110
NA
4A0-M01
NA
4A0-M02
NA
NRSII4A0
MRP4A0
ASRA4A0
100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110,
NRSII4A0
Module 0 | 5
Module 0 - Page 5
Exam Delivery
Written Exams
Delivered by Prometric
Global provider of testing services
5000+ test sites worldwide
Register at:
www.prometric.com/alcatel-lucent
Lab Exams
Module 0 | 6
Module 0 - Page 6
SRC Program
Global Reach, Flexible Delivery Options
On-site delivery at your business location anywhere in the world
Delivery from any of the following Alcatel-Lucent University locations
globally
Europe
Antwerp, Belgium
Newport, UK
Paris, France
Americas
Plano, USA
Ottawa, Canada
Mexico City, Mexico
Sao Paulo, Brazil
APAC
Shanghai, China
Sydney, Australia
Melbourne, Australia
Wellington, New Zealand
Bangalore, India
Chennai, India
Gurgaon, India
Mumbai, India
Module 0 | 7
7
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 0 - Page 7
Your Own Service Router Lab Now you can have one
Module 0 | 8
Module 0 - Page 8
Module 0 | 9
9
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 0 - Page 9
Module 0 | 10
Module 0 - Page 10
Module 0 | 11
Module 0 - Page 11
Module 0 | 12
Module 0 - Page 12
Module 0 | 13
Module 0 - Page 13
y
y
y
y
Day 3
Module 4 Resource Reservation Protocol
y Lab 4 IGP-Based RSVP LSP Establishment
Module 0 | 14
Module 0 - Page 14
5.1
5.2
5.3 5.4
5.5
y
y
y
y
y
Day 5
Module 6 Resiliency
y
y
y
y
Lab
Lab
Lab
Lab
Module 0 | 15
Module 0 - Page 15
MPLS Exam
To ensure full comprehension of the material covered in this
course, it is recommended that the student register for, and
take, the Alcatel-Lucent MPLS exam following successful
completion of this course.
Suggested Follow-on Courses
Based on the material covered in this course, it is recommended
that this course be followed with the Alcatel-Lucent Services
Architecture course.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 0 | 16
Module 0 - Page 16
Module 0 | 17
Module 0 - Page 17
Administration
Registration
Facility Information
Restrooms
Communications
Materials
Schedule
Introductions
Name and Company
Experience
Questions
Module 0 | 18
Module 0 - Page 18
www.alcatel-lucent.com/src
3FL-30635-AAAA-ZZZZA Edition 01
Module 1 Page 1
Module Objectives
Module 1 | 2
Module 1 Page 2
Module 1 Page 3
Section Objectives
Module 1 | 4
This section provides a general overview of the diverse services and applications that became available with the
establishment of MPLS tunnels, and all their related features.
Module 1 Page 4
Module 1 | 5
Multiprotocol Label Switching (MPLS) allows routers to forward traffic based on a simple label embedded in the packet
header. An MPLS router examines the label to determine the next-hop for the packet. This simplifies the forwarding
process and separates it from the routing protocol, which determines the route that traffic will take across the
network.
MPLS is a label switching technology that sets up a specific path for a sequence of packets. Each packet is identified by
a label inserted in the packet and forwarding occurs based on this label.
MPLS is independent of any routing protocol but is considered multiprotocol because it works with the Internet Protocol
(IP), Asynchronous Transport Mode (ATM), and Frame Relay (FR) network protocols.
In the case of IP networks, any IGP routing protocol may be used to establish the IGP infrastructure.
The MPLS Working Group of IETF at http://www.ietf.org/html.charters/mpls-charter.html may be used as a further
reference.
Module 1 Page 5
Module 1 | 6
Initially, engineers developed a label switching protocol to improve packet processing in IP routers. Routers did their
work in software rather than hardware, and MPLS packet switching could improve performance. Routing was considered
to be slower and more cumbersome.
Routing an IP packet requires that the device process the packet up to Open Systems Interconnect (OSI) Layer 3. The
router looks at the destination IP address in the IP header and compares it against the routing table entries, locating
the longest, or best, match. This process can be quite resource intensive, depending on the routing table size.
The MPLS Label Binding Table lookup process is simpler. The table only contains the forwarding information associated
with an exact match, rather than a longest match, so the forwarding table can be smaller than a routing table. The
nodes forward traffic using a predetermined label sent down a preselected path and replaced at each hop, so they can
decide much more quickly where to send the packets next.
Modern manufacturing and hardware advances have negated much of the speed benefits gained when using MPLS versus
routing strictly for moving IP packets. Routers now use special purpose hardware, namely Application-Specific
Integrated Circuits (ASIC), to forward IP packets in the data plane. The packet processing time differences between the
two techniques is so insignificant that this argument becomes invalid.
Module 1 Page 6
Module 1 | 7
Routing protocols cannot make use of all available network resources because of their limited mechanisms for selecting
the best path.
Routing protocols do not provide routers with any visibility into network resource utilization, and therefore the routers
do not recognize congestion on the network links, underutilized alternate paths, or idle links.
Distributing the aggregate network traffic load over all available resources becomes difficult in conventional IP routing,
and IP hyperaggregation remains a problem.
MPLS can help engineers correct hyperaggregation issues with traffic engineered label switch paths that are planned
and designed to better balance the traffic load in a hierarchical, highly reliable network infrastructure.
Module 1 Page 7
MPLS offers manageable and scalable tools that engineer the traffic
flows for better utilization of network resources.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 1 | 8
Traffic Engineering refers to the ability to optimize the use of network resources; that is, utilizing all the links and
router processes in the most efficient way as possible.
With reference to the above slide, using an IP-only network on router R3, traffic from both routers R1 and R2 will be
forwarded to router R4, based on the IGP best path (lowest cost) decision. This can cause congestion (bottleneck) issues
on the links depicted along the blue path, while the links along the red path might be underutilized, or not used at all.
IP does not have the inherent capability to tackle such issues because of its design. Equal Cost Multiple Path (ECMP) is
thus offered as a possible solution. It adjusts the IGP costs of both paths equally, so that load balancing can be
achieved. However, this would quickly prove to be a non-scalable and unmanageable approach for large networks.
Solving the problem for a certain portion of the network, or for certain sets of traffic flows, would create problems for
others.
With the RSVP-TE protocol, MPLS can offer a better and easy-to-use solution to service providers. In this example, the
network administrator can easily steer the traffic originating from router R2 over the bottom path, through router R5,
which is completely different from the IGP chosen path.
MPLS Traffic Engineering is covered in greater detail in Module 5.
Module 1 Page 8
MPLS offers a rich set of traffic protection mechanisms that surpass the
IGP convergence times.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 1 | 9
In the event of unexpected network resource failure, such as within a link or complete node, the ability of the network
to respond as quickly as possible becomes extremely important. The total amount of time it takes to reroute traffic
over other links/nodes is called convergence time.
The convergence times offered by an IP-only network depend on a number of factors but, in any case, they can be
unsatisfactory, and even unacceptable, for certain mission-critical traffic types or customers.
MPLS provides outstanding rerouting performance, with easily configurable features.
Using Fast Reroute, each router can signal a protection LSP that takes a path away from the potential point of failure in
advance. This can be the next-node or next-link along the path of the Primary LSP, as shown in the above slide.
Fast Reroute has a proven field record of providing less than 50 milliseconds of convergence times for large numbers of
LSPs after detecting failure.
In cases where end-to-end protection of primary LSPs is required, secondary LSPs can also be used. In normal
circumstances, the traffic is forwarded over the primary LSP. If the primary LSP fails, the secondary can take over.
Using the standby option on the secondary LSP further improves the convergence times after failure detection.
Fast reroute and Secondary (standby) LSP features can be used individually or in conjunction for any configured primary
LSP.
MPLS fast convergence (resiliency) features are covered in greater detail in Module 6.
Module 1 Page 9
Module 1 | 10
MPLS is mature, standards-based technology that continues to evolve in many service provider networks around the
globe.
The real advantage of MPLS is its versatile and unmatched ability to support all the aforementioned services,
applications, and solutions over a converged networking infrastructure.
Its resiliency and security features are provided by the inherent tunneling and traffic protection mechanisms covered in
this section.
Module 1 Page 10
Module 1 | 11
A Virtual Private Network (VPN) offers a private, isolated and secure connection between customer sites. Business VPN
Services are among the most important applications and are a significant source of revenue for service providers.
For the customer demanding service to connect two remote sites that require dedicated point-to-point connectivity, a
Virtual Leased Line (VLL ) or Virtual Private Wire Service VPWS) can be utilized. As the name implies, a VLL emulates a
private leased line connection over a packet-based core infrastructure. It is the simplest type of VPN to deploy with
minimal resource requirements, which is ideal for point-to-point connectivity scenarios.
From the customers perspective, the service provider network that provides the VLL service acts like an end-to-end
wire. For this reason, this type of service is also referred to as a Virtual Private Wire Service (VPWS). An industry
standard exists under the name pseudowire to allow for interoperability across different providers willing to provide
this service. In Alcatel-Lucent parlance, this is called a Pipe service.
If the User Network Interface (UNI) at both sides of the connection are Ethernet based, the service is called an ePipe.
An important benefit of MPLS is its ability to support legacy access technologies such as ATM, FR or TDM. These traffic
types can easily be transported through aPipe, fPipe and cPipe respectively, thanks to the transparent nature of the VLL
connection.
A similar service can be provided over a pure IP-network, as well by using Generic Routing Encapsulation (GRE) tunnels,
which utilize an IP header. Security concerns can further be addressed using IPSec on top of the GRE tunnels via
encryption. Although such solutions work, they bring high operational overhead and are slow and not scalable.
The advantage of MPLS is the ease of provisioning and maintenance, and of providing a scalable, highly available, and
standards-based solution.
Module 1 Page 11
Module 1 | 12
In relation to the VPN requirements presented, Virtual Private LAN Service (VPLS) enables multipoint connectivity at OSI
Layer 2 for enterprise customers.
In the above figure, a VPLS service is illustrated with three participating service routers. The service acts a bridged
Layer 2 multipoint VPN, connecting various geographically dispersed customer sites. The service provider network acts
like an Ethernet bridge or switch, from the perspective of the customer. All customer end devices connected to the
same VPLS service appear to be on the same broadcast domain.
Thus, there is also a clear demarcation of functionality and responsibility between the service provider and the
customer. The service provider simply provides Layer 2 connectivity, based on MAC address communication. With this,
the customers can maintain their routing control tasks themselves.
VPLS supports features such as VLAN trunking, double tagging (also known as Q-in-Q), VLAN translation, and several
variations of the Spanning Tree Protocol (STP) to avoid Layer 2 broadcast storms.
The Alcatel-Lucent Service Router implementation addresses possible scalability concerns by introducing the
Hierarchical VPLS (H-VPLS) and Provider Backbone Bridging (PBB) features.
Virtual Private LAN Services and related features are covered in detail in the dedicated VPLS course of the SRC
program.
Module 1 Page 12
Module 1 | 13
The multipoint connectivity needs of customers can also be addressed via the use of Layer 3 (IP) VPN Services.
Alcatel-Lucent calls this type of service a Virtual Private Routed Network (VPRN). The term peering model is also used
in the industry for such solutions, because peer relationships between the customer and provider edge routers are
necessary to exchange IP routing information.
The privacy concerns in IP-VPN services are addressed by Virtual Routing and Forwarding (VRF) instances on the service
router. Each IP-VPN customer is allocated a separate VRF, which isolates routing information and enables the use of
overlapping private IP address spaces at each customer site.
Isolation is achieved inherently in the core, thanks to the tunneling concept that uses labels.
IP-VPN services are typically offered as managed services and are usually preferred by customers willing to offload their
routing control tasks to the service provider.
Prior to MPLS, IP-VPN services could still be offered on IP-only networks through routing policies and packet filters that
achieve isolation and separation between different customers. This approach can easily become overwhelmingly
complex and administratively non-scalable or unmanageable, however, hence the extensive MPLS feature set.
Module 1 Page 13
Module 1 | 14
A Triple Play network provides IPTV, Video On-Demand, VoIP, Internet access, and other IP-based applications for
subscribers (residential home users). The Triple Play solution allows service providers to provide combined data,
Internet access, and video and voice applications to large numbers of customers.
The Triple Play reference architecture in the diagram is based on two major network elements, optimized for their
respective roles: the Broadband Service Aggregator (BSA) and the Broadband Service Router (BSR).
BSA devices have Layer 2 service capabilities that forward traffic using Layer 2 mechanisms. They also have the Quality
of Service (QoS) and packet filtering capabilities necessary to enforce higher-level policies. BSAs terminate Layer 2
access traffic, forward the traffic over MPLS tunnels, and then terminated the tunnels on the BSRs.
The BSRs are highly scalable, high throughput devices that perform routing and additional QoS and subscriber
management functions.
The connectivity between the BSAs and BSRs is provided through a secure and resilient VPLS infrastructure. The
combined security features of this model prevent unauthorized access, denial of service, and theft of service.
Broadband Service Access Network (BSAN) devices are typically Digital Subscriber Line Access Multiplexer (DSLAM)
devices, which terminate physical connections from home user devices. The BSANs connect the home users to the BSAs.
Module 1 Page 14
BGP traffic is tunneled through the core, removing the need for the
routers inside the IP/MPLS core to maintain BGP routing information.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 1 | 15
Packet forwarding in a service provider IP network is possible only if the routes to all destination prefixes are known on
each router.
In many typical deployments, BGP is used to bring external routing information from other autonomous systems to
provide connectivity to the global internet. The number of IPv4 prefixes in the global internet table has exceeded well
beyond 300,000 as of 2010 (http://bgp.potaroo.net/).
In the IP-only case, normally all the routers in the service provider domain need to contain these external routes in
their BGP tables for packet forwarding to work end-to-end. This includes even the core (P) routers, which might not
have to offer directly BGP related services on themselves, unlike the PE routers.
However, by using MPLS shortcut tunnels between the PE devices and the BGP Peering Router(s), external traffic can be
label-switched through the tunnels in a transparent fashion from the perspective of the P or core routers; hence the
term, BGP-Free Core.
For reference, Route Reflectors are commonly used to reduce the amount of internal BGP peering sessions. The same
tunneling methodology can be applied to remove the burden of keeping and processing a high number BGP routes from
core routers and relaxing the memory and CPU resources on these routers.
Module 1 Page 15
Section Summary
Module 1 | 16
Module 1 Page 16
Module 1 Page 17
Section Objectives
Module 1 | 18
This section provides an overall review of some of the fundamental principles of Multiprotocol Label Switching. An
introduction to the technology and its related terminology is also provided.
The concepts are presented in a way that allows for comparison with normal IP routing that can help highlight the
packet forwarding differences and the benefits introduced by MPLS.
The end of the section takes a glimpse into the tables maintained on MPLS enabled routers to pave the way for
following modules, in which the control plane perspective will be analyzed from a much deeper perspective.
Module 1 Page 18
Module 1 | 19
Module 1 Page 19
IP Routing Overview
Module 1 | 20
Module 1 Page 20
MPLS Terminology
iLER : Ingress Label Edge Router
eLER: Egress Label Edge Router
LSR : Label Switch Router
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 1 Page 21
Labels are pushed onto packets as they enter the service provider
network. They are swapped across the network and popped as
they leave the network.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 1 | 22
The above slide illustrates the basic data plane forwarding process of MPLS labeled packets.
A label header is a fixed length entity the router inserts into the packets as they enter the Service Provider Core
Network. The process occurs on the first router (PE) attached to the CE device and is called a Push operation.
The packet that comes in from the CE router, indicated as Data in this figure, can be any type of non-MPLS traffic,
depending on the type of service (the different service types will be presented in the next section).
The Provider (P) routers simply check the incoming label against their Label Forwarding Database to find out the
interface and outgoing label needed to forward the packet to the next-hop. The PE router at the other end of the flow
strips the incoming label and sends the packet again as unlabeled to the other CE router.
The details of the label structure and concepts, such as label stacking, are explained in Module 2.
Building the Label Forwarding Database is explained more in detail later in this section.
Module 1 Page 22
Module 1 | 23
A Label Switched Path (LSP) can be defined as a sequence of labels and label actions performed on MPLS routers to
forward data packets from point A to point B, using label switching.
A Label Switched Path always starts from an iLER and ends at an eLER. An LSP is thus an end-to-end, unidirectional path
that can carry traffic from Router A to Router B.
In the above slide, traffic flows from left-to-right. The flow of MPLS labeled packets in the other direction, that is,
right-to-left, would be represented by another LSP pointing in the reverse direction. In that case, the roles of the iLER
and eLER routers in the figure would be swapped.
The encapsulation and forwarding of packets using labels is also referred to as tunneling; as such, LSPs are often called
as tunnels.
Tunnels must be established prior to the arrival of data packets. Label negotiation and distribution protocols are used
to build the tunnels with negotiated label values. The details of these control processes and exact mechanisms of MPLS
protocols will be covered in the upcoming modules.
Module 1 Page 23
y For example: An entry in route table for 10.1.1.0/24 with nexthop address 15.15.15.15
y Two received packets with addresses 10.1.1.1 and 10.1.1.2 will
both be forwarded to the same next-hop, 15.15.15.15. In this
manner, it could be said that they both share the same FEC.
In IP-based routing, FEC lookup is done at each hop.
Module 1 | 24
Forwarding Equivalence Class (FEC) allows for the classification of packets into groups based on common criteria.
In IP networks, the most commonly used Forwarding Equivalence Class (FEC) is the packets destination IP addresses
(prefixes).
By definition, FECs can be based on other administrative criteria, such as the markings inside packets that indicate
Class of Service information.
In IP routing, packets are reclassified at each hop along their forwarding paths, according to their destination IP
addresses.
Module 1 Page 24
The FEC lookup determines the next hop LSR and the label the
source router pushes onto the packet.
The LSRs then simply perform swap operations based on the
previously determined label values.
Module 1 | 25
The tunnels are established before the data packets arrive on the ingress router. When the label associations to the
tunnels are also known, the ingress LER decides if the data packet will be forwarded via normal IP routing or via label
switching. The choice depends on the service configuration of the router associated with the incoming interface on
which the packet was received.
If label switching is to be used, the ingress LER chooses the tunnel and pushes the label onto the packet before sending
it to the next LSR.
The LSRs along the path do not need to reclassify the packets as they receive them; they merely swap the labels
according the previously determined and negotiated values.
Module 1 Page 25
Module 1 | 26
When an iLER receives a packet, it makes a decision to forward the packet via an MPLS tunnel (LSP). As indicated in the
previous slide, this depends on the definition of the service the ingress interface is associated with.
If the iLER decides to use an MPLS tunnel to forward the packet, it performs an FEC lookup in its Label Binding Table.
As the name implies, the Label Binding Table contains FECs received from other routers and their label associations.
In this example, and throughout this course, the FEC corresponds to an IP prefix (an IP address plus a subnet mask) that
exists on a router.
In the figure above, FEC x belongs to router R5, which is why we have LSP 1 pointing to, or terminating on, router R5.
FEC y belongs to router R6; therefore, the final destination for LSP 2 is router R6.
Through the lookup operation, the iLER finds out that the packet needs to be forwarded through LSP 1, thus a label with
a value of Label1 is pushed onto the packet and sent to router R1, which is the next-hop LSR. The rest of the story is
as explained in previous slides.
The exchange of label bindings and the process of building the binding tables are summarized in the following slides.
Module 1 Page 26
Module 1 | 27
Every router consists of a Control Plane and a Data Plane. Data packet processing and forwarding take place on the Data
Plane. The Control Plane is like the command center of the router; communication with other routers via protocols and
maintenance functions inside the router takes place here. The Control Plane, therefore, always needs to be one step
ahead of the Data Plane.
The two functions are usually divided among different hardware components within the system. On Alcatel-Lucent 7750
Service Routers, the hardware component that performs the control plane functions is called the Control Processor
Module, or CPM, and the component that performs the data packet processing and forwarding functions is called the Input
Output Module, or IOM.
When a routing protocol is enabled on the routers of a network, a series of actions is initiated. In this and the following
slides, the information exchange between a single router pair is briefly discussed. It is then easy to extend these principles
to any number of devices in the network.
First, with the more modern link state protocols (OSPF and IS-IS), an adjacency relationship is established between the
routers. If the two routers agree on the parameters, they exchange routing updates with each other to synchronize their
topology databases and build their Routing Information Base (RIB).
In this course, only the link-state protocols are considered (OSPF and IS-IS), since these are the only choices in todays
Service Provider Networks.
The SRC AIRP course examines the Interior Routing Protocols in much greater detail.
Module 1 Page 27
Based on their protocol metrics, the CPM chooses the best routes
from the RIB and writes them into the Route Table.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 1 | 28
Inside the RIB, various next-hop alternatives to certain destinations might exist, depending on the link and node
redundancy in the network. The responsibility of the router is to choose the best paths to all the given destinations. In
the case of link protocols, the Shortest Path First, or SPF, algorithm performs this function.
The SPF algorithm uses metrics to calculate the best path. In link-state protocols, metric is defined as a function of the
physical link bandwidth. The higher the bandwidth, the lower the metric, and the lower the cost of getting to
destinations via that link.
The router places the SPF chosen routes in the Route Table.
Module 1 Page 28
Module 1 | 29
The Route Table thus contains the best (lowest cost) paths to all possible destination prefixes. To be able to perform
data packet forwarding functions, this information needs to be transferred to all the data plane components. The
database that is maintained on the data plane for this purpose is called the FIB (Forwarding Information Base).
The FIB is virtually an image of the Route Table that is calculated from the entries in the RIB of the control plane. Since
the FIB exists on the data plane, it does not need the extra information related to the control plane. In this manner, we
can loosely think of it as a lightened version of the Route Table.
On Alcatel-Lucent 7750 Service Routers, identical copies of the routers FIB exists on every operational IOM. Dedicated
internal processes exist to keep these databases synchronized and up-to-date.
The command to display the route table entries on the 7750 SR is show router route-table.
The command to display the forwarding table entries on a certain IOM card that is installed in slot number <x> is show
router fib <x>.
Module 1 Page 29
Module 1 | 30
Once the Forwarding Information Base (FIB) is populated, it is used to forward native (unlabeled) IP packets on the
router.
(The detailed data packet forwarding process was explained on Pages 6 and 7.)
Module 1 Page 30
MPLS Protocols Exchange label bindings for their FECs and build the
LIB (Label Information Base).
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 1 | 31
An IGP routing protocol in the network is a mandatory prerequisite to making the core network MPLS-capable. This
brings several additional capabilities and applications, the most important of which will be covered in the next section.
When an operator starts the MPLS label signaling protocol on the routers, the routers establish protocol sessions first.
The routing information present in the route tables allow the routers to create these sessions.
After sessions are established, routers exchange label bindings for FECs (destination IP prefixes) that are known to
them. The information that is sent and received is stored in a database that is called the Label Information Base, or LIB.
When this process is completed on the end-to-end path of an LSP (tunnel), label forwarding can take place.
The details of this process depend on the MPLS label signaling protocol that is used, which will be covered later in the
course.
Module 1 Page 31
Module 1 | 32
Just as a FIB is required for native IP traffic, a Label Forwarding Information Base (LFIB) needs to be stored on the data
plane for forwarding label switched packets.
A selection process might be performed on the LIB when constructing the LFIB. Thus, the LIB might contain some
redundant entries, those are not actually used on the data plane (LFIB) at a given time. This depends on the actual
MPLS label distribution protocol implementation, either Label Distribution Protocol (LDP) or Resource Reservation
Protocol with Traffic Engineering extensions (RSVP-TE), the details of which are covered in their individual sections.
Module 1 Page 32
A label is pushed onto the packet at the iLER and label swapping takes
place at the LSR, using the LFIB in the Data Plane.
Module 1 | 33
When an iLER receives a packet, it makes a decision to forward the packet via an MPLS tunnel (LSP). As indicated in the
previous slide, this depends on the definition of the service with which the ingress interface is associated.
If the iLER decides to use an MPLS tunnel to forward the packet, it will perform an FEC lookup in its LFIB. This process
will allow the packet to be encapsulated with a label and forwarded to the next-hop LSR.
For the sake of simplicity, a single label is being used to illustrate the basic concepts of MPLS label switching. In reality,
however, more than one label is often imposed onto the data packet, depending on the type of service or application.
This is called a label stack, which will be explained in Module 2.
The LSR then swaps the label with another, again consulting the LFIB stored locally on itself.
In some exceptional cases, the LSR might impose a further label onto the incoming stack in addition to the swap
operation. We will see an example of this in Module 6.
Module 1 Page 33
The label of the incoming packet from the LSR is popped at the eLER
using the LFIB in the Data Plane.
Module 1 | 34
Module 1 Page 34
Section Summary
Module 1 | 35
Module 1 Page 35
Module Summary
Module 1 | 36
Module 1 Page 36
Module 1 | 37
Module 1 Page 37
Module 1 | 38
Module 1 Page 38
Module 1 | 39
Module 1 Page 39
Learning Assessment
Module 1 | 40
1. The router at the beginning of an LSP is the ingress Label Edge Router (iLER).
2. A router in the MPLS domain that resides between the ingress and egress routers is called a Label Switch Router
(LSR).
3. The router at the end of an LSP is the egress Label Edge Router (eLER).
4. Define the three MPLS label operations.
PUSH An MPLS header is inserted into an IP packet
SWAP An existing MPLS header is exchanged for a new MPLS header
POP An MPLS header is removed from an IP packet
5. Define an MPLS Forwarding Equivalence Class (FEC).
An MPLS FEC is a group of packets forwarded in the same manner, over the same path, and with the same
forwarding treatment.
6. What information is contained in the LFIB?
The active labels matching the best path to the destination FEC.
7. An iLER and an eLER perform what forwarding operations on a packet?
Switching and routing switching a labelled packet and routing an unlabeled packet.
Module 1 Page 40
www.alcatel-lucent.com
3FL-30635-AAAA-ZZZZA Edition 01
Module 2 Page 1
Module Objectives
Module 2 |
Module 2 Page 2
Module 2 Page 3
Section Objectives
Explain pipe vs. uniform mode operation with respect to TTL, EXP,
and the impact to a label stack.
Explain frame vs. cell mode label implementation.
Module 2 |
This section explains the key elements related to forwarding of MPLS data packets.
MPLS label stacking is explained first, along with the justification for the need of a stack in the example of VPN
services.
Then, several fields inside the MPLS header (label value, Experimental, Bottom of Stack and Time to Live) are
introduced.
The actual use of these fields, as influenced by the mode of implementation (pipe vs. uniform mode), is explained in
step-by-step detail.
The Alcatel-Lucent (ALU) SR OS mode of implementation for processing these fields is also considered.
Finally, the two encoding options for the MPLS label are explained, frame mode v. cell mode, together with ALU SR OS
implemented frame mode of operation.
Module 2 Page 4
Module 2 |
MPLS headers are inserted between the Layer 2 of the network interface and the encapsulated MPLS Payload.
As explained in the previous module, MPLS initially transported IP packets to their destination FEC with label
encapsulation, providing higher network performance. As such, MPLS is also often known as a Layer 2.5 protocol, since
the label is inserted as a shim between the Layer 2 and Layer 3 headers.
Today, MPLS also supports VPN services as well as IGP and BGP tunnels, extending its use. An MPLS Payload can consists
of a variety of protocols and services, so in this course we generically label the green payload field as Data.
A label stack can be formed by encapsulating labels with other labels, each layer providing a specific function on the
network. For example, the router places a service label on the customers payload to identify the VPN to which it
belongs. Then, to move this labeled payload through the MPLS domain, the same router adds to the stack top a
transport label. If the operator runs Fast Reroute, discussed in Module 6, a router may add a bypass tunnel label to the
stack. The SR OS supports up to six stacked labels.
Stacked labels support a wide range of MPLS-based services, including VPLS, VPRN, MPLS Fast-Reroute, trace, ping, or
Traffic Engineering applications.
Technically, a packet can have any number of labels in it, depending on the number of applications being used. The
maximum number of labels that can be carried is governed by the physical interfaces maximum packet size as well as
the routers implementation of the MPLS protocols.
Module 2 Page 5
Module 2 |
The service provider IP/MPLS network supports all customer services - including scalable and standards based VPN
solutions - over a consolidated, shared backbone.
The above figure shows the logical service construct for simple point-to-point connectivity services. In this model, only
the edge (PE) routers are service aware. For each VPN customer, service instances are configured on all the
participating PE routers.
A service instance is a virtual software entity in the service router. Different service instances provide isolation
between different customers, which provides inherent security and the ability to apply local, customized settings for
each customer. Different logical service instances also allow for a very granular and scalable allocation of resources
across different customers.
Referring again to the figure above, the separate logical service tunnels connect the service instances that belong to
the same customer on both PE routers.
The MPLS transport tunnel (depicted in red) can multiplex and transport several service tunnels. The intermediate (P)
routers are only aware of the transport tunnel. The transport tunnel encapsulates (hides) the service tunnels from the P
routers. Because the P routers have no visibility over the services instances or the service tunnels connecting these
instances, they need only look at the outermost label to make their forwarding decisions. This improves both network
performance and scalability.
A more detailed discussion on the Alcatel-Lucent service model offered in the SRC ASA (Alcatel-Lucent Service
Architecture) course. The important point to understand here is the concept of tunneling and label stacking.
Module 2 Page 6
Module 2 |
This diagram assumes that the routers have already signaled the tunnels and their associated label values prior to the
arrival of data traffic at the iLER. We discuss these MPLS control plane fundamentals in the next module.
Looking at the left side of the figure above, the ingress PE (router R1) processes each customers data traffic into a
dedicated service. From there, router R1 delivers the data into their corresponding service tunnels. Router R1 pushes a
separate, previously signaled service label on top of each packet. Router R1 pushes onto the appropriate data packets
service label S1 for Customer A and service label S2 for Customer B.
The same edge-to-edge transport tunnel forwards the labeled packets to the core. Router R1 pushes transport label T1
onto the label stack and sends the twice-labeled packet towards router R2.
As an LSR, router R2 processes only the top label in the stack. Router R2 swaps transport label T1 with transport label
T2 and sends the packet on to router R3. Router R2 leaves the remaining parts of the packet, service label X and the
encapsulated customer data, untouched.
When the egress PE router R3 receives the packet, it processes the transport label T2 first, popping it from the top of
the stack.
Router R3 needs the second label so that it can select the appropriate service instance to which it will send the data
packet. Since router R3 forwarded the service label S1 to router R1, router R3 knows the data belongs to Service 1 and
Customer A. Similarly, if the router R3 receives the packet with a service label S2, the data belongs to Customer Bs
Service 2.
Module 2 Page 7
Module 2 |
Module 2 Page 8
Module 2 |
The Layer 3 (IP) VPN service solution is Virtual Private Routed Network (VPRN).
In this model, the service instances maintain isolated routing tables and decide on a per service basis how to forward
the packets to their destinations. The PE routers form peer relationships with the CE routers inside the respective
service instances.
Again, assuming Ethernet data link connections between all routers:
(*) The Layer 2 header sent from CE1 to router R1 has a source MAC address of the CE1, and a destination MAC address
of the PE1 service interface. From the customers perspective, PE1 is the next-hop to the destination network, CE2.
Router R1, the ingress PE router, removes the Layer 2 header, processes the IP packet, and forwards only the IP header
and payload, encapsulated within two MPLS headers.
(**) Router R1 encapsulates the MPLS packet with the egress service provider interface Layer 2 header. The source MAC
address is that of router R1 and the destination MAC address is that of router R2.
(***) The egress LER (router R3) removes the service headers and processes the packet as any IP packet, finding a route
in the services IGP routing table, building a new Layer 2 header and forwarding the packet to CE2. The source MAC
address is that of the service interface on router R3 and the destination MAC is that of the CE2 interface.
Module 2 Page 9
Name
Size (bits)
Purpose
Label
MPLS Label
20
EXP*
Experimental
Bottom of Stack
TTL
Time to Live
Module 2 |
10
Each MPLS header in the MPLS stack includes the following four fields:
Label (20 bits): The most significant 20 bits in the MPLS header is the label, which contains the value information.
Labels can be given values ranging from 0 to 1,048,575. The next slide shows the allocation of this large range into
different pools that are used for various purposes or applications.
EXP (3 bits): The next 3 bits are experimental bits. They are called this because when the MPLS protocol was first
introduced as a standard, there was no clear view on how they would be used. These bits are now used solely for
Quality of Service marking in all the implementations. RFC 5462 renames this filed as Traffic Class. Module 5 discusses
this fields use.
Abstract from RFC 5462: EXP Field Renamed to Traffic Class Field
The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This
includes a three-bit field called the EXP field. The exact use of this field was not defined by these documents, except
to state that it was to be reserved for experimental use.
Although the intended use of the EXP field was as a Class of Service (CoS) field, it was not named a CoS field by
these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a
number of standards documents define its usage as a CoS field.
To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this
field. This document changes the name of the field to the Traffic Class field (TC field). In doing so, it also updates
documents that define the current use of the EXP field.
S (1bit): The S bit indicates the bottom of stack. In a stack of multiple labels, the label at the bottom of the stack has
an S bit value of 1, while all others are set to 0.
TTL (3 bits): The Time To Live (TTL) field inside the MPLS header functions like the TLL field inside the IP header. The
TTL value is decremented at each LSR hop to prevent packets from getting stuck in infinite forwarding loops. In the
event of such a loop, the TTL value eventually runs down to 0 and the packet is discarded.
Module 2 Page 10
Field
0-15
16 31
32 1, 023
1, 024 2, 047
Module 2 |
11
20 bits are allocated for the Label Value in the MPLS Header.
The decimal value range that can be achieved with 20 bits is from 0 to 1,048,575. This entire range is further divided
into several sub-ranges on service routers, as shown in the above slide.
The label ranges are fixed in the SR OS code, and are not configurable.
Note the label values between 0 and 15. RFC 3032 reserves this range for special applications.
A basic overview of the MPLS control plane processes is needed to better understand the use of these labels; as such, it
will be covered at the end of the next section.
Module 2 Page 11
Label Values
Module 2 |
12
The MPLS Experimental bits are used to carry the Class of Service information of the transported data traffic over the
path of an LSP. This information, inside the label header, allows LSRs to apply different Quality of Service treatments
to various types of MPLS encapsulated traffic (a full discussion of Quality of Service principles and techniques is part of
the SRC QoS (Quality of Service) course).
In the following slides, we will examine the processing of the EXP field based on the mode of implementation defined in
the standard.
Module 2 Page 12
At iLER, the EXP fields of all MPLS labels are set to the same value,
using administrative configuration.
The DSCP value inside the customer packet header is preserved.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 2 |
13
Pipe mode is implemented in the service routers for the processing of Experimental bits.
The customer router may mark the Differentiated Services Code Point (DSCP) field of the IP header to indicate the class
of service for the type of traffic it is sending. The ingress LER router may use this information to do the initial
classification and prioritization of the customer packet, but this value has no influence in determining the EXP field of
the tunnel header(s).
The EXP fields inside the MPLS tunnel headers are set to a specific value (X) via explicit administrative configuration.
Remember that only the top (transport) header is significant for processing at the LSR. Nonetheless, in the service
router implementation, all the tunnel headers are set to the same EXP value. This is mainly to support certain intervendor compatibility scenarios, including a special feature called Penultimate Hop Popping, which is covered at the end
of the next section.
By default, the EXP settings are not altered by the LSRs, and this is usually the desired behavior to maintain a
consistent end-to-end QoS implementation. However, if there is a requirement to change the EXP markings on an LSR,
the service router also has the necessary configuration tools to do so.
Again by default, the DSCP value inside the customer packet is preserved.
For the sake of simplicity, we assume an IP forwarded datagram here (typically for a Layer 3 service), but the same
principles hold true also for Layer 2 services.
Module 2 Page 13
At iLER, the first 3 bits of the DSCP field inside the customer packet
are copied to the EXP field of MPLS header.
The DSCP value inside the customer packet is preserved.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 2 |
14
The above figure provides a step-by-step summary of EXP processing across an LSP in uniform mode implementation.
It is important to note that the service router implementation only supports the pipe mode and, at the time of this
publication, no other configuration option exists to make it operate.
Again for simplicity, we consider IP forwarding and only one MPLS label is shown. In principle, however, more can
certainly exist in the label stack. What happens to the EXP fields of those other labels would vary from vendor to
vendor.
In the uniform mode implementation, the ingress LER automatically copies the first three most significant bits of the
DSCP field inside the customer IP header onto the EXP field of the outgoing MPLS packet.
At the egress LER, the EXP bits may or may not be copied back into the DSCP field of the customer packet; it depends
on the vendors and their specific implementation or configuration. Usually, however, this value would be untouched.
Module 2 Page 14
Module 2 |
15
A packet might contain various MPLS label headers, forming a label stack.
The S (bottom of stack) bit is only one bit in length and set to 1 at the bottom header to indicate the end of the stack.
This bottom header resides closest to the customer payload; the remaining headers, with the stack bit set to 0, serve to
transport the payload to the tail end PE routers.
Module 2 Page 15
The 8-bit MPLS Time to Live (TTL) Field functions similarly to the IP
TTL field.
A packet with a TTL of 0 is not transmitted to the next-hop.
In most cases, only the TTL field inside the top label is significant
in processing.
There are two approaches to MPLS TLL Handling:
y Pipe Mode
y Uniform Mode
The Alcatel-Lucent SR OS only implements Pipe Mode.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 2 |
16
Module 2 Page 16
Module 2 |
17
The figure above explains the end-to-end processing of the TTL headers inside the MPLS and IP headers.
At the ingress LER, the IP TTL of the customer packet is untouched because this is a Layer 2 service and no processing is
done on the IP header. The customer frame is encapsulated within 2 labels: the Transport and the Service labels.
The ingress LER sets the TTL field of both MPLS labels is set to 255 by default.
Recall that only the transport label is significant for processing at the LSR. Nonetheless, the service label is also given a
TTL value. This is mainly to support certain inter-vendor compatibility scenarios, including a special feature called
Penultimate Hop Popping. This feature is covered at the end of the next section.
While performing the swap operation on the transport label, router R2 decrements the TTL of only the top label by 1.
All other TTL values remain intact, as they are transparent to the LSR.
Again, the ingress LER does not touch the TTL of the customer packet because no processing is done on the IP header
for a Layer 2 service.
Module 2 Page 17
Module 2 |
18
Unlike the previous scenario, on the above slide, the ingress LER decrements the TTL of the incoming customer packet
by 1. This is because the packet belongs to a Layer 3 service, and the router processes the IP header.
At ingress LER, the TTL of the transport label is set to 255. The TTL of the service label, however, is set to the
decremented IP TTL of the customer packet (in this case, 4).
While performing the swap operation on the transport label, router R2 decrements the TTL of only the top label by 1.
All other TTL values remain intact since they are transparent to the LSR.
The egress LER (router R3) also decrements the IP TTL of the customer packet by 1 before sending it to CE2.
Module 2 Page 18
Module 2 |
19
The SR OS only supports pipe mode for TTL processing in VPN services. At the time of this publication, the router cannot
operate in uniform mode.
Again for the sake of simplicity, we only consider IP packet forwarding and only one MPLS label is shown. In principle,
however, more labels can exist in the label stack. What happens to the TTL fields of those other labels would vary from
vendor to vendor and depend their specific modes of configuration.
In uniform mode, the ingress LER decrements the IP TTL of the customer packet by 1 and also copies this value to the
MPLS header (4).
While performing the swap operation on the transport label, router R2 decrements the TTL of only the top label by 1.
All other TTL values remain intact because they are transparent to the LSR.
The egress LER (router R3) copies the TTL of the MPLS header to the TTL of the IP header inside the customer packet
before sending it to CE2.
Module 2 Page 19
Module 2 |
20
The above slide illustrates the two types of MPLS label implementations.
The MPLS label values may be carried in an MPLS specific Shim header or in a technology specific Layer 2 header, as is
the case in ATM or Frame Relay. With ATM, the VPI/VCI field in the cell header is used as the MPLS label. With Frame
Relay, the DLCI is used.
The MPLS encoding technique of implementing a label in the existing Layer 2 header is sometimes referred to as cell
mode MPLS, and is not supported by Alcatel-Lucent Service Routers.
Module 2 Page 20
Section Summary
Label Value
EXP Field
S (Bottom of Stack) Field
TTL Field
Module 2 |
21
Module 2 Page 21
Module 2 Page 22
Section Objectives
Module 2 |
23
In this section, we will take a behind the scenes look at MPLS operations, which includes the control plane processes
that run continuously in the background to keep the network operational and optimized.
The section starts by introducing the requirement for control plane processes, namely the routing and label signaling
protocols enabled on the routers.
To understand the various implementation options offered to protocol and equipment vendors by the MPLS RFC 3031,
we will discuss the following modes:
Label Distribution: Downstream Unsolicited and Downstream On Demand
Label Control: Ordered and Independent
Label Retention: Conservative and Liberal
The concepts are explained from a generic point of view as far as possible because the actual details of implementation
might differ from one protocol to the next.
The following modules are dedicated to the exact mechanisms, based on each MPLS signaling protocol, LDP, and RSVPTE covered in this course.
Finally, the control and data plane perspectives of using MPLS reserved labels in the range of 0 -15 will be explained at
the end of the section.
Module 2 Page 23
Module 2 |
24
Module 2 Page 24
Module 2 |
25
Module 2 Page 25
The FECs IP prefixes are exchanged and the other routers tunnel
destinations are known, thanks to IGP.
A signaling protocol is needed to negotiate the MPLS labels and
establish the tunnels.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 2 |
26
The Interior Gateway (Routing) Protocol is responsible for distributing the reachability information throughout the
network and ensuring that paths are re-optimized after certain network failure events.
To be able to establish the MPLS LSPs in the network and enable label forwarding of packets, a common protocol needs
to be enabled on all participating routers.
This protocol will define the set of rules and procedures for how the routers exchange the labels and agree on their
meanings.
At this point, RFC 3031 that sets the ground rules for the MPLS Architecture (in capital letters):
THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL DISTRIBUTION PROTOCOL.
A number of protocols have been standardized for this purpose.
In the following pages, we will discuss some of the main design principles that a label distribution (signaling) protocol
must meet.
Module 2 Page 26
Module 2 |
27
Before going further to explain the control plane perspective of MPLS Label signaling protocols, we will describe two
terms that will be used in several upcoming discussions: Upstream and Downstream.
As with many other concepts in MPLS, the definition of these terms depends on the direction of the data traffic flow
under consideration. Throughout this course, the assumed data traffic flow is left to right (in almost any case, traffic
flows both ways; but, for the sake of simplicity, only one direction is taken into account here).
Therefore, the customer router on the left becomes the source and the router on the right becomes the destination of
data traffic.
Hence, the definition of an upstream router is a router that is closer to the source of a data packet, relative to another
router. Hence, router R1 is an upstream router for router R2, and router R2 is an upstream router for router R3.
The definition of a downstream router is a router that is farther from the source, or closer to the destination, of a data
packet, relative to another router. Thus, router R2 is a downstream router for router R1, and router R3 is a downstream
router for router R2.
Data traffic flows in the downstream direction, from an upstream router to a downstream router.
Control plane processes reverse this order, as we will explain the in the following slides.
Module 2 Page 27
RFC 3031 does not assume the use of a single signaling protocol
and offers various implementation alternatives that control label
distribution and maintenance.
y Downstream on Demand
Module 2 |
28
If MPLS forwarding wants to be used in the network, the routers must first generate and advertise label bindings for
their selected FECs. This populates the label forwarding tables and defines the paths of Label Switched Paths in a
consistent manner. A common dynamic MPLS signaling protocol is enabled on all participating routers for this purpose.
However, RFC 3031, which defines the Multiprotocol Label Switching Architecture, does not assume the use of a single
signaling protocol. In addition, various implementation alternatives are offered in the RFC that describe the ways to
distribute and retain FEC label bindings.
Therefore, IP/MPLS router vendors must comply to the principles dictated in this RFC when implementing one or more
of the standardized protocols into their equipment.
Network operators, in turn, need to know the intrinsic characteristics of all implementations in order to decide which
to deploy in their network. This knowledge might become more valuable when operating in a multi-vendor environment,
where different vendors might use different implementation modes for the same protocol.
In the following pages, the distribution and control and retention modes are explained from a general perspective.
The actual details of MPLS signaling protocols in the Alcatel-Lucent Service Router portfolio will be covered in greater
detail in later modules.
Module 2 Page 28
The two modes that define the process to distribute label bindings
for FECs in an MPLS enabled network are:
y Downstream Unsolicited
Module 2 |
29
For simplicity, only router R3 is used to explain the different label distribution mechanisms. Here, router R3 is the
downstream router for FEC Z, which is a local IP prefix on R3. To put it in another way, router R3 is the egress for data
traffic that is destined to FEC Z.
The two label distribution methods can be described as follows:
Downstream Unsolicited (DU) mode - a router operates distributes a label binding to its MPLS neighbors without
first being asked. In other words, if the router decides to advertise a label binding for a particular FEC, it does so
regardless of whether any other router needs that label or not.
Downstream on Demand (DoD) mode - a router operates distributes a label binding to another router only if that
router explicitly requests it.
Module 2 Page 29
Module 2 |
30
Router R3 is operating in Downstream Unsolicited Mode. It has also formed a peering relationship with router R2, using a
common label distribution protocol.
Router R3 decides to advertise a label binding for its FEC, Z. It generates a binding with a label value of 100 and
allocates this locally in its label binding table, inside the memory.
Router R3 advertises this label binding right away, without waiting for an explicit request from its neighbors.
Router R2 receives the label binding from router R3 and records it. Notice that the control plane operates in opposite
direction to the data plane. This means that, in the data plane, router R2 now knows that it needs to send MPLS packets
with a label of 100 to router R3, for FEC Z.
Router R2 notices that it also has an upstream neighbor (router R1), which means that router R2 can also be an LSR for
data packets coming from router R1. For this purpose, it generates a local binding with a label of 200, allocates it in
the table, and advertises it to router R1.
Router R2 now has another label action: besides pushing labels onto unlabeled packets originating on R2 and targeting
FEC Z, router R2 swaps label 200 with label 100 when transporting labeled packets from R1 to FEC Z.
Finally, router R1 receives the label binding from router R2 and chooses the label action: to push data packets with a
label of 200 and send them to router R2.
NOTE: Downstream Unsolicited mode is used by the LDP protocol; its actual implementation will be explained in more
detail in Module 3.
Module 2 Page 30
Module 2 |
31
Router R3 is in Downstream on Demand mode, so it has not yet generated a label binding for its FEC Z.
Router R1 decides that it needs a label binding for FEC Z, since it needs to establish a tunnel going in that direction.
Router R1 sends a label request message to its downstream neighbor, router R2, which then delivers this to router R3,
the owner of the FEC.
It is now up to router R3 to respond to this request.
Module 2 Page 31
Module 2 |
32
Router R3 receives a request from router R1 to advertise a label binding for its FEC Z.
(From this point, the process closely resembles the steps for Downstream Unsolicited Mode.)
Router R3 generates a label binding and advertises it to router R2, which then forwards this to router R1, the requester
of the label binding.
Once router R1 receives the label binding, all downstream routers along the LSP path also have their labels in place. At
this point, the LSP (tunnel) is established (shown on the next slide).
NOTE: Downstream on Demand mode is used by the RSVP-TE protocol; its actual implementation will be further
examined in Module 4.
Module 2 Page 32
Label Forwarding Information Base (LFIB) tables are populated and the
LSP gets established.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 2 |
33
As a result of the label binding advertised from the egress router R3, and forwarded by router R2, the label connection
is now complete and the LSP is established from router R1 towards the direction of router R3. The routers build a Label
Forwarding Information Base (LFIB) containing the labels associated with the best IGP or constrained path to the
destination.
Data forwarding can now take place with the negotiated labels.
Module 2 Page 33
The two modes that define the order in which nodes create and
advertise FEC label bindings in an MPLS enabled network are:
Module 2 |
34
RFC 3031 specifies two label distribution modes, Ordered Control and Independent Control, that define the label
binding advertisement order of operation for LSP setup.
When a router operates in Ordered Control label distribution mode, it only distributes a label for a FEC for which it is
the egress LER for that FEC or it has already received from its next-hop a label binding for that FEC.
When a router operates in Independent Control label distribution mode, it distributes labels for its known FECs to its
upstream routers, regardless of whether is has received a label from the downstream routers that actually own the
FECs. This corresponds to the way that conventional IP datagram routing works; each node makes an independent
decision with regards to how to treat each packet, and relies on the routing algorithm to converge rapidly so that each
datagram can be correctly delivered.
To ensure that traffic in an FEC follows a path with a specified set of properties (for example, that the traffic does not
traverse any node twice, or that a specified amount of resources are available to the traffic), Ordered Control must be
used. With Independent Control, LSRs may begin label switching traffic in the FEC before the LSP is completely set up,
which can cause traffic in the FEC to follow a path that does not have the specified set of properties.
Therefore, Ordered Control label distribution mode is used for both transport protocols LDP and RSVP-TE on AlcatelLucent Service Routers. However, it should be noted that Ordered Control and Independent Control modes are fully
interoperable.
Module 2 Page 34
Ordered Control
Independent Control
Module 2 |
35
In the above example, router R2 already has an entry for FEC Z in its IP Forwarding Table, with a next-hop of router R3.
If router R2 is operating in Ordered Control mode, it will wait for its downstream neighbor, router R3, to advertise a
label for FEC Z first. When it receives the label binding from router R3, router R2 will further advertise it to its
upstream neighbor, router R1. This ensures a loop-free network where routers only advertise labels for FECs associated
with valid routes.
If router R2 is operating in Independent Control mode, it will not wait for router R3 to advertise the label binding; it
will make an independent decision to advertise a label binding for FEC Z to its upstream neighbor, router R1. This
speeds MPLS convergence but risks loops in the instance where the advertising router does not have a valid route to the
destination FEC.
Module 2 Page 35
Module 2 |
36
RFC 3031 specifies two retention modes, Liberal and Conservative, that define methods of retaining the label bindings
received from downstream neighbors.
In Liberal label retention mode, a router stores all the labels it receives from other routers in the LIB.
In Conservative label retention mode, a router validates the labels received from other routers and only stores the
valid labels in its label database.
Module 2 Page 36
The two modes that define the way routers maintain the received
label bindings in their tables are:
y Conservative
y Liberal
Module 2 |
37
In the above example, router R1 has received a label binding for FEC Z but has decided that it does not need the label
nor the tunnel to router R3.
The two scenarios illustrated summarize how router R1 will react in either of the retention mode implementations.
There are various reasons for choosing an implementation, which depend on the protocol and scenario being
considered. In general:
Liberal label retention mode allows for quicker adaptation to routing changes, but consumes more memory
resources
Conservative label retention mode requires an LSR to maintain fewer labels, making it less resource intensive but
possibly slower to react to routing changes.
NOTE: LDP uses liberal retention and is covered in Module 3. RSVP-TE uses conservative retention and is covered in
Module 4.
Module 2 Page 37
Protocol
Distribution Mode
Control Mode
LDP
Downstream Unsolicited
Ordered
RSVP
Downstream on Demand
Ordered
Module 2 |
38
Retention Mode
Liberal
Conservative
The matrix shown above summarizes the combinations of MPLS label signaling modes and label retention modes.
Most implementations use one of the following combinations:
Conservative Label Retention with Downstream On Demand
Liberal Label Retention with Downstream Unsolicited
Module 2 Page 38
SR OS
Module 2 |
39
The concept of label space is useful for discussing the assignment and distribution of labels. There are two types of
label spaces: per platform and per interface.
Per platform label space assigns a single label per FEC per device, or platform, used by all the devices interfaces.
Per interface label space assigns a unique label to each FEC per interface, usually based on interface specific resources,
such as Frame Relay DLCI or ATM VPI/VCI.
Per platform label space uses fewer label resources than per interface. With per platform labels, the same label may be
used to forward a packet from an LSR, regardless of which physical port is used to forward that packet. This is common
in the Ethernet scenario.
The Alcatel-Lucent Service Routers implement per platform label space.
Module 2 Page 39
SR OS
Module 2 |
40
LDP creates IGP-based LSPs. Label exchange and signaling creates the LSP paths, which are determined by the IGP
algorithm in use, typically a shortest path algorithm. The IGP route selection determines the best path the LSP uses for
that FEC. Each downstream router also independently chooses the label it will use to forward labeled packets to the
destination, just as though the routers were forwarding the traffic strictly at Layer 3.
LDP provides no redundancy, no traffic protection mechanisms beyond multiple possible IGP paths and ECMP. One could
consider LDP best effort forwarding, completely dependent on the IGP.
RSVP-TE, oh the other hand, establishes LSP tunnels that enable the allocation of resources along the defined path,
which could be simply the IGP chosen path, or a set of strictly defined downstream routers. RSVP-TE allows per LSP
path bandwidth allocation, allowing the head end (iLER) to choose the path that meets the specified bandwidth
requirement.
RSVP-TE also supports LSP establishment based on the IGP, using a constraint based algorithm such as CSPF (constraintbased Shortest Path First), or based on explicitly defined paths. IGPs require additional protocol extensions to allow
CSPF to be implemented.
Finally, RSVP-TE includes a rich set of protection mechanisms, namely secondary path and Fast Reroute protection, that
surpass the convergence times offered by IGP.
Module 2 Page 40
Module 2 |
41
Beyond LDP and RSVP-TE, SR OS routers use other MPLS label signaling protocols, which are usually configured and used
when implementing MPLS-based services. Their role is to signal the inner (service) label of the MPLS label stack, thus
they serve a different purpose from LDP or RSVP-TE.
Targeted LDP (T-LDP)
Targeted LDP is used in the implementation of services across an MPLS network. It signals the label that identifies the
particular service, from the eLER to the iLER, such as an ePipe or VPLS. T-LDP is discussed in the SRC Alcatel-Lucent
Service Architecture (ASA) course.
Multiprotocol BGP (MP-BGP)
RFC 4364 defines the Multiprotocol extensions to BGP (MP-BGP) as enhancements to the BGP protocol that supports
MPLS signaling for Layer 3 VPNs. Multiprotocol extensions to BGP (MP-BGP) are discussed in the SRC VPRN (Virtual
Private Routed Networks) course.
Module 2 Page 41
Label Usage
Router Alert
Implicit Null
4-15
Module 2 |
42
Label values 0 15 are reserved for use in special applications. These applications are:
Value of 0 represents IPv4 Explicit NULL label
Value of 1 represents Router Alert Label and cannot be at the bottom of the stack
Value of 2 represents IPv6 Explicit NULL label
Value of 3 represents Implicit NULL label
Values 4 15 are reserved for future use
The use of label values 0 3 will be explained in the following pages, although not in sequential order.
NOTE: RFC 3032 specifies that the IPv4 and IPv6 Explicit Null label values have to be at the bottom of the stack. This
restriction has since been removed, as described in RFC 4182.
Module 2 Page 42
Label Value
Module 2 |
43
The above slide illustrates the normal mode of operation for an LSP that starts on router R1 and ends on router R3.
Router R3 normally receives packets from router R2 with a label of 100 for FEC Z.
Router R3 pops the transport label 100 and sends the original data to its destination.
Module 2 Page 43
On router R3, the result of the label lookup process for packets
destined to FEC Z is always a pop action.
If router R3 wants to save some processing resources, it can
request the penultimate router (router R2) to send the packets
with no transport label.
Router R3 expresses this desire by advertising a label binding for
FEC Z with a value of 3.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 2 |
44
Continuing the scenario from the previous page, router R3 can save some CPU processing resources if it does not have to
perform a lookup in its label binding database for FEC Z. Therefore, in this situation it is preferable for router R3 if
router R2 sends packets for FEC Z without labels.
Router R3 signals this request to router R2 by advertising a label binding for its FEC Z, with a label value of 3. This is
called an implicit null request (keep in mind that this is a control message regarding a control plane process).
Router R2 records this label in its label binding table.
On the next page, we see the implication of the implicit null advertisement on the data plane.
Module 2 Page 44
The penultimate hop (router R2), honors the request of router R3 and
pops the transport label.
Although the egress label value is displayed as 3, this value can never
exist in an MPLS label of a data packet.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 2 |
45
As seen in the figure above, router R2 now has an egress label of 3 for FEC Z.
However, router R2 will not swap the incoming data packets with a label value of 3, as label value 3 can never appear
in the encapsulation header. Instead, router R2 forward the unlabeled packet to router R3. Router R3 still acts as the
LER for that tunnel.
Router R3 is the last hop for this FEC, which makes router R2 the penultimate (the second to last) router. Router R2
now pops the label, thus this behavior is referred to as Penultimate Hop Popping (PHP)
NOTE: The penultimate hop only pops the transport label. It leaves other labels (for example, service labels) in the
stack so that router R3 can still perform service selection based on the service label value.
The primary benefit to using PHP is that it enables a single lookup on the eLER, potentially optimizing the routers
performance. However, any additional information carried in the MPLS header, such as QoS parameters in the EXP bits,
is lost over the last link between the penultimate router and the eLER, and, as a result, the packet may not receive its
proper QoS treatment at the eLER.
Module 2 Page 45
Module 2 |
46
Alcatel-Lucent Service Routers have always had implicit null support as a penultimate hop. That is, if any last hop
router advertises an implicit null, the Service Router understands and honors this request. On the data plane, it pops
the transport label, instead of swapping it, before sending the packet.
The implicit null feature was introduced for deployment scenarios where small-scale Service Router products, such as
the Alcatel-Lucent 7705 SAR (Service Aggregation Router), are used as egress nodes.
The SR OS supports implicit null signaling on both LDP and RSVP-TE protocols.
Configuration required for LDP: configure router ldp implicit-null-label
Configuration required for RSVP-TE: configure router rsvp implicit-null-label
NOTE: If the RSVP-TE process is already running, you must administratively shut down the RSVP process to enable
implicit null label generation. Of course, this can be service effecting.
The configuration steps required then are:
configure router rsvp shutdown
configure router rsvp implicit-null-label
configure router rsvp no shutdown
Module 2 Page 46
SR OS
Router R3 still wants to save some CPU resources, but needs the
QoS information included in the EXP bits.
Router R3 sends to router R2 a label value of 0 (2 for IPv6).
Router R3 pops the label directly without doing a label lookup;
router R3 records the EXP bit value for QoS processing.
Module 2 |
47
The label generated by the egress LER may be the MPLS label value of 0 (zero), known as the IPv4 Explicit Null.
The Explicit Null label solves the issue of PHP, in which the QoS of the packet was lost. The penultimate router
forwards the Explicit Null label with the packet, so the packet retains the EXP value. The eLER can thus treat the
packet based on its EXP value before it pops the Explicit Null label.
Module 2 Page 47
The penultimate hop (router R2), honors the request of router R3 and
sends the packet with a label value of 0.
Router R3 immediately pops the label when it sees a value of 0.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 2 |
48
If the eLER advertises the label value of 0 to the penultimate LSR, the eLER will receive packets for the FEC containing
an outer MPLS label of 0 from the penultimate LSR.
The MPLS label value of 0 instructs the receiving device, in this case the eLER, to pop the outer label. The next header
in the packet is then inspected and a second lookup is performed at the eLER on that header.
The second header could be another MPLS header, in the case of a multiple label stack, or the IP packet header.
The SR OS has always supported explicit null processing as the penultimate router, although SR routers do not generate
the explicit null label.
Module 2 Page 48
Module 2 |
49
Module 2 Page 49
Module 2 |
50
The Router Alert label is used in certain OAM (Operational, Administration, Maintenance) applications.
Service Routers contain a diverse set of OAM features that test and monitor various aspects of service and network
health.
Some of these OAM commands require the use of a special label, namely the Router Alert Label (such as MAC-ping and
SDP-ping). The actual use of these commands is covered in SRC ASA and VPLS courses.
From an MPLS perspective, the router sending these OAM commands inserts an additional Router Alert label with a value
of 1.
When the receiving router processes (decapsulates) the MPLS headers on the data plane, it realizes that the underlying
data packet must be passed internally to the control plane, instead of forwarded on another physical interface. As a
result, the OAM message gets processed by the Control Module and necessary actions are taken.
Module 2 Page 50
Section Summary
Module 2 |
51
MPLS supports two label distribution modes, Downsteam Unsolicated and Downstream on Demand
MPLS supports two label distribution control modes, Ordered Control and Independent Control
MPLS supports two label retention modes, Liberal Label Retention and Conservative Label Retention
MPLS supports two label space implementation modes, Frame Mode and Cell Mode
SR OS routers use LDP and RSVP-TE for tunnel labels, and T-LDP and MP-BGP for service labels
Label values 0-15 are reserved for special use, such as implict null (3), explicit null (0), and router alert (1)
SR OS routers support implicit and explicit null label processing, and can generate implicit null labels via LDP and
RSVP-TE
Module 2 Page 51
Module Summary
Module 2 |
52
Module 2 Page 52
Multiprotocol
Alcatel-Lucent
Label Switching
Multiprotocol Label Switching v2.1
Module 2 |
53
Module 2 Page 53
Using Ordered Control, an LSR distributes label mappings only for the
FECs for which it has already received a label mapping for the FEC
next-hop.
An LSR distributes label mappings independently of other LSRs using
Independent Control mode.
Label retention may either be Liberal or Conservative.
Liberal Label Retention mode allows an LSR to retain all labels it has
received from all peers in memory.
Conservative Label Retention mode allows an LSR to retain only the
received labels that are being used.
Per platform label space is used for interfaces that can share the
same labels.
Per interface label space is used for interfaces that use interface
resources for labels such as ATM or Frame Relay.
Multiprotocol
Alcatel-Lucent
Label Switching
Multiprotocol Label Switching v2.1
Module 2 |
54
Module 2 Page 54
Multiprotocol
Alcatel-Lucent
Label Switching
Multiprotocol Label Switching v2.1
Module 2 |
55
The explicit null label tells the eLER not to look up the label, but to
pop it on ingress.
The router alert label tells the recipient to pass the packet to the
control plane.
Module 2 Page 55
Learning Assessment
Module 2 |
56
Module 2 Page 56
7.
Module 2 |
57
True or False: The SR OS LDP implementation uses Downstream on Demand label distribution, ordered control,
and liberal label retention.
False.
8.
True or False: The SR OS RSVP-TE implementation uses Downstream on Demand label distribution, ordered
control, and Conservative label retention.
True.
9.
MPLS routers depend on what protocol to distribute the reachability information the routers use to generate LFIB
entries?
The IGP.
10. What label distribution method requires that the iLER request and wait to receive a label from the next-hop
before forwarding data downstream?
DoD.
11. Which control mode ensures a loop-free LSP path?
Ordered control
Module 2 Page 57
Module 2 |
58
12. LDP implements liberal label retention mode to speed network convergence in what way?
Populate the LFIB with new labels to represent the IGP lowest cost path to destination.
13. Which label space, implemented by the SR OS routers, conserves label resources?
Per platform.
14. What is a primary difference between LDP and RSVP-TE signaled LSPs?
RSVP builds IGP-based tunnels only, while RSVP-TE allows constraint-based tunnels.
15. SR OS routers support PHP in what way(s)?
They both accept and generate implicit null labels.
16. What special use label tells the next-hop router to process the received packet in the control plane?
The router alert label tells the receiving router to pass the packet to the control plane.
Module 2 Page 58
www.alcatel-lucent.com
3FL-30635-AAAA-ZZZZA Edition 01
Module 3 Page 1
Module Objectives
Module 3 |
Module 3 Page 2
Module 3 Page 3
Section Objectives
Investigate the label distribution process for Link LDP and explain
how the label databases are populated.
Module 3 |
This section provides a detailed explanation of how routers establish and maintain LDP sessions and how they exchange
labels over these established sessions.
LDP enabled routers maintain two label databases one in the control plane and one in the data plane. Section 1
describes how the routers populate these databases as well as the IGP interaction for the process.
Both the theoretical and practical details of the subject matter are examined, to provide a method to relate the two
perspectives to each other.
Module 3 Page 4
Module 3 |
RFC 3036 defines LDP as an MPLS label distribution protocol. Routers running the LDP protocol establish LDP sessions
with other LDP routers. The LDP sessions allow them to exchange of label/FEC binding (mapping) information.
To support MPLS label switching, routers must distribute labels for the FECs (IP prefixes) listed in the FIB (route table).
Though multiple interior routing protocols exist, (RIP, OSPF, IS-IS, and so on), modifying each routing protocol to
support label distribution became too difficult. Therefore, Label Distribution Protocol (LDP) was introduced to carry
label binding information for FECs, regardless of the routing protocol used in the network.
The LDP protocol in the Alcatel-Lucent 7750 product family is used for:
Establishing Transport Tunnel LSPs.
Establishing Targeted LDP sessions between directly or indirectly connected peers.
Providing shortcut tunnels to label switch native IP traffic (explained later in Module 5).
Module 3 Page 5
Module 3 |
The service provider IP/MPLS network supports all customer services - including scalable and standards based VPN
solutions - over a consolidated, shared backbone.
For example, the above slide illustrates how MPLS tunnels might be used to support the logical service construct for
simple point-to-point connectivity services. Only the edge (PE) routers know the services exist; service instances are
configured on all the participating PE routers for each VPN customer. Hence, a single set of MPLS transport tunnels can
carry traffic for hundreds of point-to-point service instances. The transport tunnels do not care what they transport,
for to them the service traffic becomes just another payload.
A service instance is a virtual software entity in the service router. Different service instances provide isolation
between different customers, which provides inherent security and the ability to apply local customized settings for
each customer. Different logical service instances also allow for an especially granular and scalable allocation of
resources across customers.
A more detailed discussion on the Alcatel-Lucent service model is included in the SRC ASA (Alcatel-Lucent Service
Architecture) course. The important point to understand here is the concept of tunneling and label stacking.
Module 3 Page 6
Link LDP sessions are created between all directly adjacent LDP
routers.
Routers exchange label bindings with each other over LDP sessions.
This creates a full-mesh of transport tunnels in the network.
It relies on IGP for operation and convergence.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 3 |
Link LDP requires all participating routers to establish peering relationships and sessions between each other. After the
sessions are established, routers exchange label bindings with each other for their selected FECs. The routers maintain
the sessions by exchanging periodic keepalive messages.
Label exchange occurs in a flooding manner, much like how IGP topology information is distributed throughout the
network. The routers perform a selection process on the received labels to decide which next-hop router and label will
be used to reach all the other Label Switching Routers. This way, logical entities called Label Switched Paths (LSPs) or
tunnels will be created in a full-mesh fashion between every possible source and destination router pair in the LDP
network.
LDP relies on the underlying Interior Gateway Protocol (IGP) to establish the sessions, obtain FEC information, and
maintain the tunnels.
Failure recovery times also depend on the performance of the IGP convergence times, but this will be discussed later in
Module 6.
Module 3 Page 7
Module 3 |
In the first process, LDP enabled routers discover each other via Hello messages, using a process similar to OSPF.
The routers send hello messages on all the LDP enabled network links, targeting the multicast address 2240.0.2 and the
well-known UDP port 646. After the routers successfully discover and acknowledge each other, they send periodic hello
messages to keep the adjacency alive.
When the discovery phase is complete, a single LDP session is established between each router pair, regardless of how
many parallel network links may exist between the two.
The primary objective of LDP is to distribute labels by distributing label mapping messages over the established
sessions.
If the FEC for which a label was distributed becomes unavailable, the egress router for the FEC will direct its peers to
clear their label associations by issuing label withdraw messages. Label withdraw messages are acknowledged by the
receiving routers via label release messages (this process is explained in further detail in Section 2).
If errors are encountered at any point during the peering session, routers will inform each other via notification
messages.
Module 3 Page 8
Module 3 |
Module 3 Page 9
Module 3 |
10
The above diagram explains the main principles of LDP operation that are used throughout this module.
System IP interfaces are created on the Service Routers by default and are crucial to the operation of the routers in
various contexts.
Unique addresses need to be assigned to the system IP addresses to maintain proper operation.
A prefix length of 32 is assigned to system IP interfaces, which implies a single host; the host is the router itself in this
case.
Module 3 Page 10
A:R4>config>router#
-------------------------------interface "toR6"
address 10.4.6.4/24
port 1/1/4
exit
A:R4>config>router>ldp#
-------------------------------interface-parameters
interface "toR6"
exit
exit
A:R6>config>router#
-------------------------------interface "toR4"
address 10.4.6.6/24
port 1/1/4
exit
IP Interface
Configuration
A:R6>config>router>ldp#
-------------------------------interface-parameters
interface "toR4"
exit
exit
Link LDP
Configuration
Module 3 |
11
When a router is configured from scratch, some basic hardware provisioning is necessary to initialize several data plane
components. It involves the following:
Provisioning Input Output Modules (IOMs) with the correct card type.
Provisioning Media Dependent Adapters (MDAs) with the correct MDA type.
Enabling network ports (they are shutdown by default).
When the hardware is provisioned, IP interfaces are configured on the network. It is a good idea to use the ping tool
after this step, to verify IP reachability to the neighboring device.
Link LDP is enabled in the configure router ldp context, and then under the interface-parameters subcontext. All the network interfaces that will take part in the LDP domain must be added into this sub-context.
When LDP is enabled, a series of processes are triggered, which take place via the exchange of several LDP packet
types. In the end, an LDP session is created between all adjacent routers and label distribution can occur.
These processes are explained by a single router pair, routers R4 and R6, in the reference topology.
The same sequence of events occurs on every other router pair in the network.
Module 3 Page 11
A:R4>config>router#
-------------------------------interface system"
address 10.10.10.4/32
exit
System
IP Interface
Configuration
A:R6>config>router#
-------------------------------interface system"
address 10.10.10.6/32
exit
Module 3 |
12
At this point, the LDP routers do not even attempt to initiate the LDP neighbor discovery process because the system IP
addresses are not configured on both. The LDP operational status remains down, with the status code indicating that
the System IP interface is down. This error message can be the result of an address that is not configured, or a system
interface that is administratively disabled (with a shutdown command).
It is sufficient to specify an IP address with a /32 prefix length to enable the system IP address, but the administrator
must ensure that each router uses a unique system IP address in the network.
If any two adjacent routers in the network have overlapping system IP addresses, they will be unable to establish any
form of peering (IGP or LDP). When non-adjacent routers have the same system IP addresses, strange routing problems
occur in the network that could be difficult to troubleshoot.
Module 3 Page 12
Module 3 |
13
After LDP is enabled on the previously created IP interfaces, and unique system IP addresses are assigned on both
routers, the routers start exchanging packets that relate to a series of processes.
The first of these processes is peer discovery. Once LDP is enabled on an interface, the router sends out an LDP Hello
packet to find out about its neighbor(s) on that link segment. This process is very similar to link-state IGP protocols
(OSPF and IS-IS).
LDP Hello messages are sent to the reserved all-routers multicast address 224.0.0.2. This is to ensure that, if several
routers are attached to the same broadcast segment, all will receive the hello message, and process it if they also have
LDP enabled on their interfaces.
When routers receive a hello response, they identify the router in the source of the hello message as a Link LDP peer
and mark the network interface as an active Link LDP adjacency.
LDP Hello messages are sent over the transport layer protocol UDP with the designated destination port number 646.
A number of parameters is included in the hello messages. The most important of these are indicated in bold in the
above figure and are explained in the following slides.
Module 3 Page 13
Module 3 |
14
Module 3 Page 14
LDP Identifier
The first four octets identify the LSR and must be a globally unique
value.
Typically, the system IP address is assigned as the LSR-ID.
The last two octets identify a specific label space within the LSR.
For platform wide label spaces, the last two octets of the LDP
Identifier are always set to zero.
Example: 10.10.10.4:0
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 3 |
15
An LDP identifier is a six octet quantity used to identify an LSR label space.
The first four octets identify the LSR and must be globally unique values, such as a 32 bit router ID assigned to the LSR.
The last two octets identify a specific label space within the LSR and are always set to zero for platform wide label
spaces.
Alcatel-Lucent Service Routers use platform wide label spaces; therefore, the last two octets are always set to zero in
the LDP identifiers.
When an LSR uses LDP to advertise more than one label space to another LSR, it uses a separate LDP session for each
label space. This is referred to as per interface label space and, in this situation, the last two octets of the LDP
identifier for per interface label spaces are not zero.
For example, when an LSR has two links to a peer and both are ATM and use per interface labels, it advertises more
than one label space to the peer and, hence, uses more than one LDP identifier, in the range 4000-5000.
Another example of when an LSR would use multiple LDP identifiers is when the LSR has two links to the same LSR peer,
one of which is Ethernet, which uses per platform labels, and the other of which is ATM or Frame Relay, which uses per
interface labels.
Module 3 Page 15
Module 3 |
16
When there is physical link failure, lower layer detection mechanisms usually warn upper layer protocols about the
problem to prompt them to converge again. To cover corner-case situations, where failures go undetected by the lower
layer mechanisms, the periodic hello exchange mechanism is deployed in LDP.
After the routers complete the discovery process, they continue to send out hello messages to their neighbors at predefined intervals. The router expects to hear an LDP hello message from its neighbor within the specified hello timeout
period. You can configure the LDP hello timeout either globally or per interface. The default hello timeout is 15 secs.
The hello factor determines how many hello messages the router sends in the timeout period. You may also configure
the hello factor either globally or per interface. The default hello factor is 3 messages/timeout period. Divide the
timeout by the factor value, and you get the interval between hello messages.
For example: Hello interval (time between hellos) = Hello timeout hello factor = 15 3 =5. By default, the routers
send one hello over 5 seconds. Note that you cannot configure the hello interval, but knowing this value helps you
determine how often you should observe the routers exchange hello message.
If the routers have multiple interfaces, they send a separate set of hello messages on each of the links.
Module 3 Page 16
A:R1>config>router>ldp#
-------------------------------interface-parameters
hello 15 3
interface "toR2
exit
interface "toR3
exit
interface "toR4
hello 45 3
exit
17
When configured directly under the interface-parameters subcontext, the hello parameters apply to all the network
interfaces configured for LDP.
To override the global settings, individual settings can be applied per interface.
Hello parameters are configured in the following format:
*A:R1>config>router>ldp>if-params# hello
- hello <timeout> <factor>
- no hello
<timeout>
: [3..65535]
<factor>
: [1..255]
The no form of this command restores the default settings: Timeout = 15, and Factor = 3.
In the above slide, and with the displayed settings, router R1 sends hello messages to neighbors routers R2 and R3 at 5
second intervals.
With the override settings at interface level, hello messages are sent to router R4 at 15 second intervals.
Module 3 Page 17
Module 3 |
18
Each router specifies the locally configured hello timeout period in the hello message that they send to the peer.
The hello timeout values do not need to match on both routers for the discovery process to succeed. A silent
negotiation takes place, in which the routers set the operational timeout period to the lower of the received or
advertised values. This determines the hello sending interval, according to the hello factor.
Hello Interval is set to the operational hello timeout value divided by the locally configured factor.
Module 3 Page 18
Module 3 |
19
The status of the discovery process relevant to all the configured LDP peerings can be verified with the show router
ldp discovery command.
Local and Peer Addr are actually the system IP addresses of each router, as advertised in the LSR-ID portion of the
LDP identifier included in the hello messages.
The possible values for AdjType are Link and Targeted. In this case, only a link LDP adjacency exists between the
two routers.
The State is Estab (a truncated form of Established). This indicates that the two routers have successfully passed
the initial discovery stage and are ready to create a session.
If the detail keyword is appended to the command, more details are displayed relating to the adjacency.
The Hold Time Remaining is reset to 15 (by default) every time a hello message is received from the peer.
The Hello Mesg Recv and Sent show the number of messages received and sent during the uptime of the adjacency.
Local and Remote IP Address refer to the directly connected IP interface at each side of the connection.
The output also shows the locally configured hello timeout and the timeout value that was received from the directly
connected peer. As mentioned before, the operational timeout value is set to the lower of these two values - 15 in this
case.
Routers also include a sequence number in the hello messages. This is a 4-byte unsigned configuration number that
indicates the configuration state of the sending router. It is used by the receiving router to detect configuration
changes on the sending router. The sending router increments the configuration sequence number whenever there is a
configuration change (such as the hello timeout).
Module 3 Page 19
Module 3 |
20
After an adjacency is established between the two LDP routers, using UDP Hello messages, an LDP session is required for
the reliable exchange of label advertisement messages.
Initially, the routers set up a TCP connection over which the LDP session runs. Like any other TCP application, LDP takes
advantage of TCP reliability mechanisms, such as sequence number tracking, acknowledgment, and retransmission, to
ensure that all messages are sent and received correctly by both peers.
In a TCP session, one side (the router with the higher transport address) always assumes the active role and initiates the
TCP connection with its LDP neighbor. LDP uses TCP well-know port number 646.
The routers first need to decide which will be active and start the session establishment process. Another parameter to
determine is the address to use to establish the session on both sides. Both of these concerns are addressed by the
transport address, which is included in the LDP hello messages. A router chooses between the directly connected IP
address or the system IP address to use as a transport address.
The decision depends on two inter-related implementation options, the chosen label space and label implementation.
Module 3 Page 20
Module 3 |
21
Recall the two types of label spaces and frame/cell mode interface implementations that were introduced in Module 2.
If a router pair has 2 frame mode interfaces, as in the example above, the same set of labels are advertised for the
specified FECs on both interfaces. The label values are picked from a global reserve of labels, identified as per-platform
label space. The routers maintain only one LDP session across the two interfaces.
However, if the router pair has 2 cell-mode interfaces, as with ATM or Frame Relay connections, the router needs to
advertise separate labels on each interface. Each label binding is relevant for each interface in the cell mode of
operation. In this case, 2 separate LDP sessions will be required between the 2 routers, as shown on the right.
Another scenario, not shown in the figure above, is a router pair with a frame mode and a cell mode interface between
each other. Again, two sessions will be established between the routers.
Module 3 Page 21
Module 3 |
22
Only frame mode interfaces and per-platform label space are implemented on Alcatel-Lucent Service Routers.
As such, in the case of multiple interfaces between 2 routers, a single LDP session needs to be established to be able to
advertise a single set of labels for the selected FECs of each router.
This necessitates the use of a single, unique address as the transport address to be advertised inside the LDP Hello
messages in the discovery phase.
System IP addresses need to be unique to each router; for this reason, the system IP address is used as the transport
address by default on Alcatel-Lucent Service Routers.
Module 3 Page 22
A:R1>config>router>ldp#
-------------------------------interface-parameters
transport-address system
interface "toR2
exit
interface "toR3
exit
interface "toR4
transport address interface
exit
Module 3 |
23
Although the transport address is set as the system IP address by default on the Service Router, if there is a
requirement to interoperate with another vendor router, it is possible to configure the router to use the directly
connected interface address as the transport address.
In the example above, the transport address of 10.10.10.1 is advertised to routers R2 and R3. This is the global setting
directly under the interface parameters LDP sub-context. It is the default setting and can be displayed by typing info
detail in the configure router ldp context.
An administrator can override this setting on a per interface basis, as shown in the diagram.
NOTE: The default global setting can also be modified to interface, which will apply to all the configured network
interfaces in the LDP context.
Module 3 Page 23
Module 3 |
24
The show router ldp session command provides information about the status of the LDP session.
At this stage, the output displays the state of the session as Nonexistent. This implies that a session has not been
attempted by the router.
This can be the result of a lack of the system IP address of the peer in the IP routing (forwarding) table that is specified
in the transport address portion of the LDP hello message.
An Interior Gateway Protocol needs to be configured between the 2 routers to advertise the system IP addresses and
other relevant routing information.
NOTE (1): Configuring an IGP is, in fact, a common practice, even before starting to configure LDP. Here, it is
mentioned at this step to illustrate the possible root cause of such errors.
NOTE (2): Static-routing can also be used to populate the routing table with the system IP addresses of the peers.
Except in very specific cases, however, it is not used in practice.
Module 3 Page 24
A:R4>config>router>ospf#
-------------------------------area 0.0.0.0
interface system
exit
interface toR6
interface-type p2p*
exit
OSPF
Configuration
OSPF
A:R6>config>router>ospf#
-------------------------------area 0.0.0.0
interface system
exit
interface toR4
interface-type p2p*
exit
Module 3 |
25
OSPF
An IGP is configured to exchange routing information between the 2 routers. This is necessary to inform each router
about the system IP address (transport address) of the peer. After the session is established, IGP will again be required
to distribute IP prefix (FEC) information across the network.
The relevant OSPF configurations are shown in the figure above. A single (backbone) area is used in the network with an
area-ID of 0.0.0.0 (when configuring, it is sufficient to type only a single zero to represent this ID).
It is important to remember to add the system interfaces in the OSPF configuration, as this is necessary to advertise the
system IP addresses. As a result, the system IP address of the peer is added to the routing and forwarding table of each
router, along with other possible prefixes advertised by the peer.
For the sake of clarity, only the system IP addresses are shown in the figure.
Now that the system IP addresses are known, the routers can begin the LDP session establishment process (described on
the next page).
interface-type p2p*: The actual command used here is interface-type point-to-point. The default setting for
the interface-type is broadcast, which is actually intended for multi-access segments (that is, multiple routers
attached to a common Layer-2 segment). Initial convergence on broadcast segments take more than 40 seconds because
of Designated Router election. It is therefore recommended practice to use the point-to-point setting for directly
connected segments on which only 2 routers exist.
Module 3 Page 25
Enabling IGP
The router with the higher transport address (router R6) initiates
the LDP session to TCP destination port 646 of the neighbor.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 3 |
26
Module 3 Page 26
Module 3 |
27
The status of the session establishment process related to the configured LDP peerings can be verified with the show
router ldp session command.
The State needs to be Established for an operational LDP session to exist between the routers.
The possible values for the Adjacency type are Link and Targeted. In this case, only a link LDP adjacency exists
between the two routers.
If the detail keyword is appended to the command, more details relating to the session are displayed.
The remaining Holdtime is reset to 30 (by default) every time a keepalive message is received from the peer.
The command also displays the total number of session messages received and sent during the uptime of the
session, in this case 20 sent and 21 received.
Local and Remote IP addresses refer to the configured system IP addresses.
The local TCP port is 646, which means this router has assumed the passive role in the session. The active side
(router R6) has chosen a port number of 50309 (explained on the previous page).
The output also shows the locally configured keepalive timeout and the timeout value received from the peer, both
30 seconds.
With the session established, the peers can initiate the label generation and distribution process. The label
distribution mode is indicated as DU, which refers to Downstream Unsolicited, the default mode of operation for
LDP running Service Routers.
Module 3 Page 27
Module 3 |
28
When there is physical link failure, lower layer detection mechanisms usually warn upper layer protocols about the
problem to prompt them to reconverge. To cover corner-case situations, where failures go undetected by lower layer
mechanisms, the periodic keepalive exchange mechanism is deployed in LDP.
After the session is established, the routers continue to send keepalive messages towards the neighbor at pre-defined
intervals. A router expects to hear an LDP keepalive message from the neighbor within the specified keepalive timeout
period.
Keepalive Timeout = Keepalive Interval x specified Hello Factor.
The keepalive factor provides a measure of how many keepalive message intervals should elapse before declaring the
peer down.
Module 3 Page 28
A:R1>config>router>ldp#
-------------------------------interface-parameters
keepalive 30 3
interface "toR2
exit
interface "toR3
exit
interface "toR4
keepalive 90 3
exit
(global setting)
Timeout = 30 seconds & Factor = 3
(Keepalive Interval = 303 = 10 seconds)
29
When configured directly under the interface-parameters subcontext, the keepalive parameters apply to all the
network interfaces configured for LDP.
To override the global settings, individual settings can be applied per each interface.
Keepalive parameters are configured in this format:
*A:R1>config>router>ldp>if-params# keepalive
- keepalive <timeout> <factor>
- no hello
<timeout>
: [3..65535]
<factor>
: [1..255]
The no form of this command restores the default settings: Timeout = 30, and Factor = 3.
A Keepalive Timeout of 30 divided by a Factor of 3 equal a Keepalive Interval of 10
In the figure above, and with the displayed settings, router R1 sends keepalive messages to neighbors routers R2 and R3
at 10 second intervals.
With the override settings at interface level, keepalive messages are sent to router R4 at 30 second intervals.
Module 3 Page 29
Module 3 |
30
Each router specifies the locally configured keepalive timeout period in the Init message that they send to the peer.
The keepalive timeout values do not need to match on both routers for the session to be established. A silent
negotiation takes place, in which routers set the operational timeout period to the lower of either the received or
advertised values. This determines the keepalive sending interval, according to the keepalive factor.
Keepalive Interval will be set to the operational keepalive timeout value divided by the locally configured factor.
Module 3 Page 30
Module 3 |
31
Link LDP sessions are created between each router pair in the network, as described on the previous pages.
Now label bindings for selected FECs can be exchanged on the established LDP sessions. In this case, an FEC is nothing
but an IP prefix in the routing table.
In an IP/MPLS service network, transport tunnels are only required to carry VPN service traffic between the routers.
Thus, the routers only need to know how to reach other routers, using a certain label. For this purpose, it is sufficient
to distribute labels for the system IP addresses of the routers only.
Recall that the system IP interface is a loopback interface by default, and should be reachable as long as the router is
operational. Even if a physical interface goes down, other routers should be able to reach the system interface of the
router via another interface. This provides resiliency in routing.
Each router generates a label binding for its own system IP address only and distributes this information to its directly
connected peers, with which active LDP sessions exist. Upon receipt of this message, each receiving router generates its
own label binding for the prefix and forwards the information in the network.
This way, label bindings are distributed in a flooding fashion, much like IGP. LDP has embedded mechanisms to prevent
possible indefinite loops during this process.
As a result, each router will have a label binding for the system IP address of every other router in the network. The
sequence of labels and label actions, starting from an ingress data point to an egress data point, is logically represented
by an LSP, or a (transport) tunnel.
Module 3 Page 31
Module 3 |
32
Module 3 Page 32
===============================================================================
LDP Parameters (LSR ID 10.10.10.4)
===============================================================================
------------------------------------------------------------------------------Interface Parameters
------------------------------------------------------------------------------Keepalive Timeout : 15 sec
Keepalive Factor : 3
Hold Time
: 15 sec
Hello Factor
: 3
Propagate Policy
: system
Transport Address : system
Deaggregate FECs
: False
Route Preference : 9
Label Distribution : downstreamUnsolicited Label Retention
: liberal
Control Mode
: ordered
Loop Detection
: none
-------------------------------------------------------------------------------
Module 3 |
33
The default implementation parameters used by the ALU Service Routers can be displayed with the show router ldp
parameters command.
Note the parameters depicted in bold. These are router defaults and cannot be modified.
Downstream Unsolicited label distribution mode
Labels are distributed to all LDP peers with active LDP sessions.
Ordered Control Mode
An LDP router generates and distributes a label for its own prefixes only (by default, the System IP address
only).
Upon receipt of a label mapping from a downstream peer, an LDP router generates its own label mapping for
that IP prefix and distributes it to other peers (if any).
Liberal Label Retention
An LDP router keeps all the labels it has received from peers in the control plane.
In the data plane, only one label is used as the active label for a given IP prefix.
Module 3 Page 33
Module 3 |
34
Module 3 Page 34
Module 3 |
35
Prefix 10.10.10.6/32 is configured as a system IP address on router R6; in other words, router R6 is the egress for prefix
10.10.10.6/32. Therefore, router R6 must initiate the entire label distribution process for its own system IP address.
For this purpose, router R6 picks an available label from the range allocated by MPLS protocols for dynamical
assignment (32768 - 131071) and associates it with prefix 10.10.10.6/32; that is, it generates a label binding for prefix
10.10.10.6/32. Label 131071 is locally reserved for prefix 10.10.10.6/32 on router R6 for use by LDP. No other prefix
can be assigned to this label, and no other dynamic protocol can use this label on router R6.
Router R6 sends out a label mapping message to both routers R4 and R5 to inform the peers of this label binding. The
destination IP address of the label mapping message is either 10.10.10.4 or 10.10.10.5.
Recall that LDP uses platform wide label space implementation on the Service Routers; therefore, the same label
(131071) is distributed to both neighbors.
LDP operates in Downstream Unsolicited mode; therefore, router R6 does not need to receive requests from its
neighbors to distribute the label binding. If there is an active session, the generated label binding is distributed towards
the other peer right away. Router R6 chooses the label that it wishes its peers to use when forwarding data to R6.
Module 3 Page 35
Peer: The LDP peers address to which this router sent or from
which it received a label for this FEC. In this example, these are
peers to which R6 sent a label.
Ingress Label: Locally generated and distributed label value.
Egress Label: The label value received from the peer. R6 is the
egress LER for prefix 10.10.10.6/32, so it is not applicable in this
case.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 3 |
36
Label generation and distribution is a control plane process that needs to take place before data packets can be
delivered.
Therefore, the generated label for prefix 10.10.10.6/32 is stored in a table or database that is called the Label
Information Base (LIB).
A router maintains entries in the LIB for every prefix for which it has generated and distributed a label binding, as well
as label bindings it has received for those prefixes. Since a router can have multiple directly connected peers, there can
be multiple entries per prefix for each peer.
The label that is locally generated and distributed to a peer is indicated in the IngLbl (Ingress Label) column. Recall that
the control plane and data plane functions operate in the opposite direction to each other. If router A needs to forward
a labeled packet to router B, router A first needs a label. Router B sends the label upstream to router A, so that router
A can forward labeled packets downstream to router B.
Router R6 distributes a label of 131071 to its neighbor, which signals that it wishes to receive the (ingress) labeled data
packets destined to its system IP address with that label.
The EgrLbl (Egress Label), EgrIntf (Egress Interface) and EgrNextHop (Egress Next-Hop) fields are empty; therefore, the
ingress labeled data packets for this prefix have no outgoing transport (outer) labels. This is an indication that router R6
terminates LSPs targeting its FEC 10.10./10.6/32, removing (popping) in the data plane the label 131071 from ingress
packets. Router R6 is where the LSP (Transport Tunnel) to 10.10.10.6/32 terminates or ends.
Module 3 Page 36
The router checks the next-hop information for the given prefix in
the IP Forwarding Information Base (FIB).
This determines which label binding entry in the LIB will be written
into the LFIB, in case of multiple options.
LFIB is used to label switch the data packets.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 3 |
37
In Module 2 we explained that, internally, every router has separate control plane and data plane functionalities. The
figure above provides a high level of view of the consistent interaction between the control and data planes from the
perspective of LDP operation.
All the dynamic routing and signaling protocol operations occur in the control plane. As a prerequisite, the Routing
Information Base (RIB), which serves as a database to store all the routing protocol entries, has already been populated.
The best routes are chosen from this database of possible alternatives and written into the Route Table. Finally, a copy
of this route table is installed in the data plane, in the form of a Forwarding Information Base (FIB).
Once the operator enables LDP on the router and/or interfaces, the routers form LDB adjacencies. The Label
Information Base (LIB) contains all the label bindings that have been sent to or received from the active peers.
Recalling that LDP operates in Downstream Unsolicited mode, this implies a flooding behavior similar to IGP. Therefore,
there are multiple options (multiple egress labels and next-hop routers) to reach certain destination prefixes. Again, the
best of the possible options needs to be chosen and indicated in the data plane as the active label binding to label
switch the packets.
As mentioned earlier, LDP has a strong reliance on IGP in this context. This means that LDP will use the IGP active nexthop to determine which label it will use to forward traffic for a particular FEC.
The Forwarding Information Base (FIB) contains the active IP next-hop information. The router checks the FIB,
determines the active next-hop, and installs the label that has been received from that active next-hop in the Label
Forwarding Information Base (LFIB).
This will become more evident as we move through the case study and track the label distribution process.
Module 3 Page 37
(LIB)
(FIB)
(LFIB)
Module 3 |
38
Router R6 has not received any label bindings for 10.10.10.6/32 from its neighbors, indicated by the fact that the
egress label, interface, and next-hop fields are empty in the show router ldp bindings command output that
displays the LIB.
This is expected, because router R6 is the egress LER for LSPs, targeting its own system IP address. The single FIB entry,
showing router R6s system interface as the LOCAL next-hop also indicates the target prefix resides on router R6.
NOTE: The command to display the FIB on the ALU Service Routers is show router fib X. X is the IOM (Input Output
Module) hardware slot number on the chassis. In theory, all installed IOMs have the same copy of the FIB.
Appending the active keyword to the show router ldp bindings command shows the labels that are actively
used, and the corresponding label actions on the data plane. This is the Label Forwarding Information Base (LFIB). In the
example, the entry says that if the router receives data packets labeled data packets with transport (outer) labels of
131071, it will POP the label and analyze the next encapsulation header.
Both the FIB and LFIB are uniform throughout the entire data plane. Regardless of which data plane component (IOM)
the packets travel through, they are subject to the same treatment.
Module 3 Page 38
Module 3 |
39
1. Router R6 sends a label mapping message to routers R4 and R5. (Only router R4 is considered here, for the sake of
clarity.)
Upon receipt of the message, router R4 receives the label binding for prefix 10.10.10.10.6/32 and writes it into its LIB,
as an egress label towards router R6.
2, 3. Seeing that there are other active LDP peers present, router R4 generates its own label binding for 10.10.10.6/32
and distributes it to routers R2 and R5. The destination IP of the label mapping message here is either 10.10.10.2
(router R2) or 10.10.10.5 (router R5).
Module 3 Page 39
R6
R2 and R5
Module 3 |
40
The slide shows router R4s LIB, where it has received from router R6 a label binding for prefix 10.10.10.6/32, and has
distributed its own label binding to the other peers, routers R2 and R5. For this particular FEC, router R4 now has 3 LIB
entries.
The first 2 rows of the LIB display the label generated by router R4 and advertised to both peers, routers R2 and R5. It
is an ingress label because this is the label that router R4 expects to receive in the data plane, if the neighbors choose
router R4 as the next-hop to reach router R6.
The third row indicates the label binding received from router R6, the owner of the prefix. It is an Egress Label because
this is the label used when sending labeled packets to router R6 in the data plane. The physical egress interface and the
resolved next-hop IP address are also included in the output for this entry.
However, this is not the complete picture on router R6. The label distribution case study is continued on the next
pages.
Module 3 Page 40
Module 3 |
41
In a redundant network, a router may receive multiple label mapping messages from several peers for the same prefix.
Label mapping messages are propagated through the network in a flooding fashion and, as a result, router R4 receives a
label binding for prefix 10.10.10.6/32 from routers R2 and R5.
Module 3 Page 41
The label mappings received from routes R2 and R5 are also written
into the LIB in the EgrLbl (Egress Label) column.
This is a consequence of using Liberal Label Retention (all label
bindings are kept in the LIB).
Router R4 has chosen router R6 as the active next-hop for
10.10.10.6/32; therefore, only the entry for router R6 has an
associated Egress Interface and Egress Next-Hop IP address.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 3 |
42
In this slide, router R4 has now received a label binding for prefix 10.10.10.6/32 from routers R2 and R5. Notice that
the EgrLbl field now shows these received labels; compare the above slides Egress entries with the previous slides
router R4 LIB snapshot.
As described earlier, an egress label indicates that the router can potentially use the peer that advertised the label as a
next-hop to send labeled data packets. Also, recall that all label bindings are kept in the LIB when using Liberal Label
Retention mode, which allows for faster path transition in network link failures.
However, only a single egress label and a single egress interface are required to label switch the packets in the data
plane. This implies that the router needs to make a local selection from among the alternatives that are present in the
LIB, and install the chosen entry in the LFIB.
The above output illustrates the outcome of this selection process. Only the entry for router R6 has a physical egress
interface as well as a resolved next-hop IP address, which indicates that label 131071 and port 1/1/4 will be used when
sending labeled packets for prefix 10.10.10.6/32. The details of this selection process regarding the LIB, FIB and LFIB
interaction are explained on the next page.
NOTE: An exception to the one egress label and one egress interface per prefix rule arises if Equal Cost Multiple Path
(ECMP) is enabled on the router. ECMP is discussed in the next section.
Module 3 Page 42
Module 3 |
43
To sum up:
Router R4 receives a label binding for prefix 10.10.10.6/32 from router R6 (131071 in the egress column).
Router R4 generates its own label binding for the same prefix and distributes to routers R2 and R5 (131070 in the
ingress column for both entries).
Router R4 receives additional label bindings for prefix 10.10.10.6/32 back from routers R2 and R5 (131068 and
131069 in the egress column).
On the data plane, regardless of the interface, the packet is received. Router R4 expects to receive the same label from
its peers for prefix 10.10.10.6/32 (Ingress Label 131070).
An egress label and egress interface must be chosen from among the three options. Router R4 checks the FIB to identify
the IP next-hop for prefix 10.10.10.6/32.
The IP next-hop is router R6, so router R4 installs the label received from router R6 as the active egress label and
displays the associated egress physical interface and next-hop IP address that will be used in data forwarding.
As indicated earlier, redundant entries in the LIB help to increase failure recovery times. For example, if the interface
between routers R4 and R6 goes down, router R4 can place in its LFIB the label it received from router R5, sending the
traffic instead to router R5 immediately after IGP convergence. More aspects of LDP and network convergence are
covered in Module 6 Resiliency.
NOTE: Router R4 also has a Push entry for prefix 10.10.10.6/32 in the LFIB, for cases where it is the ingress LER for
data traffic. This is not discussed here for the sake of a more straightforward example, and because the case study
focuses on where router R1 is the ingress, and router R6 is the egress, LER specifically.
Module 3 Page 43
Module 3 |
44
Eventually router R1, which has the ingress LER role in this case study, receives two label bindings for prefix
10.10.10.6/32 from both of its peers. Router R1 writes both of these entries in the LIB.
Router R1 needs to select a next-hop router and label to install in the LFIB for data forwarding. This is explained on the
next page.
Module 3 Page 44
Module 3 |
45
Module 3 Page 45
Module 3 |
46
After the label distribution is completed in the control plane, data traffic can be label switched using the constructed
label forwarding entries in the LFIB. This is actually a return to the data plane forwarding process presented in Modules
1 and 2, with LDP specific information.
Router R1 is the ingress LER for this case study. Therefore, the incoming data packets are labeled with an MPLS label
value of 131068 and forwarded on physical interface (port) 1/1/4 to next-hop 10.1.2.2 (router R2). This implies a
Push operation on router R1.
NOTE: There are two reasons why router R1 would choose to label switch the incoming data traffic with labels
negotiated by LDP, as opposed to using native IP forwarding. The first is that the ingress LER interface on which the
data traffic arrives is configured as an access interface, part of a VPN service provisioned on router R1. The VPN service
is then configured to use an LDP transport tunnel to get the packets across the network. The other reason is that MPLS
forwarding for IP traffic, also known as an LDP-shortcut feature, has been enabled on router R1.
The details of Alcatel-Lucent service implementation is covered in the SRC Services Architecture course.
The LDP-shortcut feature is covered in Module 5 of this course.
Module 3 Page 46
Module 3 |
47
The data traffic arriving from router R1 with an ingress label of 131068 is swapped on router R2 and transmitted with an
egress label of 131070 towards router R4. The LDP Label Forwarding Information Base (LFIB) is consulted, as seen in the
figure above, for this operation.
Module 3 Page 47
Module 3 |
48
The data traffic arriving from router R2 with an ingress label of 131070 is swapped on router R4 and transmitted with an
egress label of 131071 towards router R6. The LDP Label Forwarding Information Base (LFIB) is consulted, as seen in the
figure above, for this operation.
Module 3 Page 48
Module 3 |
49
The data traffic arriving from router R4 with an ingress label of 131071 is popped on router R6.
The label that is popped is a transport (outer) label. Router R6 processes the remaining labels, if there are any, and
forwards the original data packet towards its destination, without any labels.
Module 3 Page 49
Router R1 has generated and advertised label 131066 to routers R2 and R3.
The entry for router R2 is marked as N (Not In Use), because router R2 is currently
the IGP next-hop for 10.10.10.6/32 (it cannot be an upstream neighbor).
The entry for router R3 is marked as U (In Use), because router R3 can become an
upstream neighbor if an IGP topology change affects it.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 3 |
50
The above slide illustrates the full LIB on router R1. Again, prefix 10.10.10.6/32 is used as an example.
As described earlier, as a result of the flooding behavior of LDP, routers distribute labels to all other peers, whether
they are on the IGP best path or not.
However, if a peer is on the IGP best path to reach a certain prefix, the label distributed to that peer is marked with an
N, indicating that the label is not in use. This means that the label is not activated because the peer is a downstream
router at the moment, and thus cannot be an upstream router at the same time.
This is the case shown in the figure above. Router R1 is using router R2 as the IGP next-hop to reach 10.10.10.6/32; that
is, router R2 is a downstream router to router R1. This means that router R2 is currently closer to the destination than
router R1. Under these topological constraints, router R2 will not attempt to use router R1 as a downstream router.
Hence, the label advertised to router R2 is marked with N Not In Use.
Why does router R1 advertise the label to router R2 if it will not be used? To speed up convergence and decrease
service downtime by reducing the amount of flooding required during a link failure that causes a topology change. If,
for example, router R2 lost all of its links, except the link between routers R1 and R2, it would have no choice but to go
through router R1 to reach router R6. In that case, router R2 would start using the label received from router R1
(131066) to send data traffic right away. (The symbol on router R1 would change to U then).
On the contrary, router R3 is not on the IGP best path to reach 10.10.10.6/32, so router R3 may use the label received
from router R1 at any given time. A possible scenario is explained on the next two pages.
Module 3 Page 50
Router R1 has also installed an entry with a swap action for when it
becomes a downstream router for any peer.
If a peer sets router R1 as the IGP next-hop, having this label
readily available in the LFIB will save time.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 3 |
51
The case study presented uses router R1 as the ingress LER for data traffic.
However, a peer may have to use router R1 as a downstream router when sending the traffic. In such a scenario, router
R1 already has a label distributed to its peers (131066), and a label action associated with it. An example is presented
on the next page, wherein router R1 becomes a downstream router for its peer and performs a label swap action.
After IGP convergence takes place, routers can immediately resume label switching the data traffic, without waiting for
label negotiation.
More information on IGP and MPLS convergence is covered in Module 6 of this course.
Module 3 Page 51
Module 3 |
52
When router R3 is the ingress LER for data traffic destined to router R6:
The traffic path is router R3-R5-R6, when all links are operational, and assuming all link costs are equal.
If the link router R3-R5 fails, the traffic path is routers R3-R2-R4-R6.
If the R3-R2 link also fails, router R3 would have no option but to use the path shown above. Router R1 thus becomes a
downstream router for router R3, performing a label swap action.
After IGP convergence, router R3 starts pushing the label 131066, which is already available in the LIB. This is again a
result and an advantage of using liberal label retention.
Module 3 Page 52
Module 3 |
53
To sum up, when LDP is enabled in the network, all routers generate a label binding for their own system IP address and
distribute to their peers by default. The distribution mode is downstream unsolicited, so a router does not need to wait
for an additional trigger, nor request the label mapping message from its peers.
The labels are flooded throughout the network and, eventually, all the routers have a Label Switched Path (transport
tunnel) to reach all the other routers. A full-mesh of tunnels is created.
In the example above, the show router tunnel-table command output displays the tunnels made available on
router R1, via LDP label negotiation. Assuming router R1 is always the ingress Label Edge Router, an LDP-made tunnel
exists towards all the other routers, represented by their system IP addresses. (The figure only shows the tunnels
initiated on router R1, for the sake of clarity.)
When using LDP, a router does not have an end-to-end view of a tunnel. As indicated with the LIB and LFIB outputs
earlier, an LDP router only knows the egress label and the next-hop router to reach the tunnel destination. The
consistent sequence of labels and their associated label actions from an ingress to an egress point constitute the tunnel.
When using LDP signaled transport tunnels, an LSP is merely a logical construct, not an actual end-to-end tunnel.
NOTE: The Pref (Preference) value is assigned internally by the router. For LDP based tunnels, this value is always set
to 9. For RSVP-TE based tunnels, it is set to 7. There is no configuration parameter to change this value and it is only
used in specific cases. For example, in a Layer 3 VPN (VPRN) service, multiple tunnel options exist to reach a certain
destination. If the router has to choose between tunnels offered by different protocols (LDP or RSVP-TE), it uses the
preference value. As with the IGP, the router prefers the lower numeric value over the higher.
Module 3 Page 53
Module 3 |
54
The show router tunnel-table command output above displays the tunnels available on router R4, assuming that
router R4 is the ingress point of those tunnels.
A similar view would be present on all the other routers, hence the full-mesh of LDP tunnels.
Note that the metric values in the tunnel table output correspond to the IGP metric value, which is yet another
indication of strong LDP-IGP dependence. Tunnels created by LDP label negotiation strictly follow the IGP determined
paths.
Module 3 Page 54
Module 3 |
55
The MPLS lsp-ping command is a commonly used troubleshooting tool and is part of the general OAM (Operational,
Administrational and Maintenance) toolkit provided to network operators.
The router where the command is executed is the ingress of the LDP tunnel. The router that owns the prefix specified
in the command is the egress of the LDP tunnel.
The LSP-Ping utility performs a unidirectional test; it checks the MPLS tunnel in a single direction only from the ingress
to the egress router. If the tunnel needs to be tested in the opposite direction as well, the command must be run on the
egress router, with the roles swapped.
The above slide illustrates the use of LSP-Ping facility.
It is important to specify the prefix keyword, otherwise the following warning message is displayed:
Send failed. The lsp-name does not exist.
This is because an LSP created via LDP does not have any name, and is represented by the destination prefix (FEC).
(Note: With RSVP-TE signaling, a name is given to LSPs, which is specified when using the lsp-ping command).
By default, the command sends a single request packet. It is also possible to send more test packets, as shown in the
following example:
*A:R1# oam lsp-ping "to_R6" send-count 3
LSP-PING to_R6: 92 bytes MPLS payload
Seq=1, send from intf toR2, reply from 10.10.10.6
udp-data-len=32 ttl=255 rtt=3.31ms rc=3 (EgressRtr)
Seq=2, send from intf toR2, reply from 10.10.10.6
udp-data-len=32 ttl=255 rtt=3.19ms rc=3 (EgressRtr)
Seq=3, send from intf toR2, reply from 10.10.10.6
udp-data-len=32 ttl=255 rtt=3.20ms rc=3 (EgressRtr)
Module 3 Page 55
---- LSP 10.10.10.6/32 PING Statistics ---1 packets sent, 1 packets received, 0.00% packet loss
round-trip min = 3.59ms, avg = 3.59ms, max = 3.59ms, stddev = 0.000ms
MPLS Echo Request packets are sent labeled (within the MPLS
tunnel).
Module 3 |
56
The LSP-Ping command uses MPLS Echo Request and MPLS Echo Reply packets.
The MPLS Echo Request packets are sent encapsulated within the MPLS labels that are signaled for the target prefix.
The TTL value in the outgoing packet is set to 255.
In the figure above, the MPLS Echo Request is forwarded all the way down to router R6, the egress router of prefix
10.10.10.6/32.
The MPLS Echo Request messages are sent over UDP with a destination port of 3503, and a source port value that router
R1 chooses arbitrarily.
The Echo Request message contains the target FEC (prefix) value that the egress router needs to check.
Module 3 Page 56
Module 3 |
57
Module 3 Page 57
rtt=1.63ms rc=8(DSRtrMatchLabel)
rtt=3.19ms rc=8(DSRtrMatchLabel)
rtt=3.80ms rc=3(EgressRtr)
Module 3 |
58
The LSP-Traceroute utility also uses MPLS echo request and reply messages.
LSP-traceroute gathers hop information through the path of an LSP. The command is implemented using a special
solution involving the MPLS TTL values. This solution is explained in detail in the following slides.
Separate MPLS Echo Request messages are sent per downstream router.
Upon receipt of the MPLS echo request message, each downstream router checks the prefix in their label database and
responds accordingly.
The keyword rc in the command output above is the Return Code, as specified in RFC 4379.
There are 14 return codes defined in the RFC (values 0-13) that can indicate problem conditions, their root causes, or
proper operation.
LSP-traceroute facility is illustrated above. Two LSRs, routers R2 and R4, have returned a code of 8 (DSRtrMatchLabel),
meaning that they were able to find a downstream label mapping for the incoming label. On the last line, router R6 has
included a return code of 3 (EgressRtr), which means that it has found out that it is the egress point for this prefix (a
label pop action in its LFIB).
All of the above point to a proper, error-free LSP operation.
Module 3 Page 58
1
2
3
Module 3 |
59
The LSP-Traceroute utility tests all the downstream routers to gather hop information along the path of an LSP by
sending separate MPLS Echo Request packets to each downstream router.
The TTL value of the outgoing packet is set to 1 in the first Echo Request packet that is sent out from router R1.
Router R2 receives the packet and decrements the TTL to 0. It then processes the rest of the packets contents in the
control plane.
Module 3 Page 59
Module 3 |
60
Router R2 analyzes the Echo Request packet and checks the specified FEC in its label database. It finds an egress
(downstream) label mapping for prefix 10.10.10.6/32, which means that it is a transit router for the prefix.
Router R2 indicates this by setting the return code to 8 (DSRtrMatchLabel) in the MPLS Echo Reply packet that is
returned.
The Echo Reply packet is unlabeled and IP routed, as in the case of LSP-Ping.
Router R2 is not the egress router for prefix 10.10.10.6/32, so the LSP-Trace operation needs to continue.
Module 3 Page 60
Module 3 |
61
The MPLS TTL value is set to 2 in the next Echo Request packet.
Router R4 receives the packet and decrements the TTL to 0. Router R4 then processes the rest of the packets contents
in the control plane.
Router R4 analyzes the Echo Request packet and checks the mentioned FEC in its label database. It finds an egress
(downstream) label mapping for prefix 10.10.10.6/32, which means it is a transit router for the prefix.
Router R4 indicates this by setting the return code to 8 (DSRtrMatchLabel) in the MPLS Echo Reply packet that is
returned.
The Echo Reply packet is unlabeled and IP routed, as in the case of LSP-Ping.
Router R4 is not the egress router for prefix 10.10.10.6/32, so the LSP-Trace operation needs to continue.
Module 3 Page 61
Module 3 |
62
The MPLS TTL value is set to 3 in the next Echo Request packet.
Router R6 receives the packet and decrements the TTL to 0. Router R6 processes the rest of the packets contents in
the control plane.
Router R6 analyzes the Echo Request packet and checks the specified FEC in its label database. It does not find any
egress (downstream) label mapping for prefix 10.10.10.6/32, which means it is the egress router for the prefix.
Router R6 indicates this by setting the return code to 3 (EgressRtr) in the MPLS Echo Reply packet that is returned.
The Echo Reply packet is unlabeled and IP routed, as in the case of LSP-Ping.
Router R6 is the egress router for the prefix, so the LSP-Trace operation stops.
Module 3 Page 62
Section Summary
Module 3 |
63
To sum up:
LDP Hello messages are exchanged between all directly connected and LDP enabled router pairs.
LDP Hello messages are sent over UDP port 646.
An LDP identifier is included in all the LDP messages.
An LDP-ID is a 6-byte field that identifies both the router and its label space uniquely in the LDP domain.
An LDP-ID consists of an LSR-ID (4 bytes) and a label space ID (2 bytes).
The LSR-ID is set to the system IP address, and the label space ID is set to 0 on the ALU Service Routers (per
platform label space).
The lower value for the hello timeout indicated in the hello messages is used by both peers.
Routers continue exchanging periodic hello messages after a successful discovery.
The router with the higher transport address initiates the LDP session to TCP port 646 of the peer by sending an LDP
Init message.
The lower value for the keepalive timeout indicated in the Init messages is used by both peers.
Routers continue to exchange periodic keepalive messages after a successful session establishment.
Labels are distributed in downstream unsolicited mode only for the system IP addresses in ordered control mode.
All received labels are kept in the Label Information Base (LIB) in liberal label retention mode.
The label received from the active IGP next-hop is used as the active label in the Label Forwarding Information
Base (LFIB) for data plane switching.
The path of a packet label switched through an LDP based tunnel to a certain destination is identical to the path of
a packet that is routed to that same destination via IGP decisions.
The OAM LSP-Ping and LSP-Traceroute commands are implemented using MPLS echo request and reply messages.
LSP-pings verifies the reachability of the destination prefix.
LSP-traceroute provides intermediate hop information.
Module 3 Page 63
Module 3 Page 64
Section Objectives
Module 3 |
65
The fundamental principles of Link LDP operation were presented in the previous section.
In this section, additional topics related to LDP will be covered, including:
How to achieve MPLS traffic load balancing, using ECMP.
How to distribute label bindings for prefixes other than the system IP address, using export policies.
How to control the way label bindings are received from peers, using import policies.
How to resolve specific prefix FECs when a more general aggregate prefix is used in a multi-area IGP deployment.
How routers maintain the LIB and LFIB with additional label management actions; label withdraw and release
messages.
How to enable and configure targeted LDP sessions.
How to enable LDP authentication to harden the network security.
Module 3 Page 65
2 Paths are available from router R1 to router R6, with equal costs.
The IGP Shortest Path First (SPF) algorithm normally uses a tiebreaker rule to choose either router R2 or router R3 as next-hop (on
the ALU Service Router, this is the lowest next-hop IP address).
The LDP Tunnel to router R6 is also established on the IGP best path.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 3 |
66
Redundant paths can exist in the network between any traffic source and destination point.
When the total IGP cost to get from a particular source to a particular destination is the same for different paths, the
paths are referred to as Equal-Cost Multi-Path (ECMP).
In the example above, router R1 has 2 ECMP routes to reach router R6, with a path cost of 300.
The standard Shortest Path First (SPF) implementation dictates the selection of a single path to a destination.
Therefore, a tie-breaker rule is used in the case of multiple paths sharing the same total cost value.
On the ALU Service Routers, the tie-breaker rules state that the path with the lowest next-hop, directly connected
interface address be used as the active path on the data plane.
The LDP next-hop is also set to the selected IGP next-hop as a result of IGP dependence (explained in the previous
section).
Module 3 Page 66
Module 3 |
67
The above slide illustrates the state of the LIB, FIB, and the LFIB tables without ECMP enabled on router R1. This is the
situation described in the previous section.
Router R2 is the IGP next-hop, as illustrated in the FIB, and the label from router R2 is used as the active egress label in
the LFIB.
Module 3 Page 67
Module 3 |
68
The figure above again illustrates the data forwarding path from router R1 to router R6 without ECMP enabled on router
R1.
Router R2 is the active IGP and LDP next-hop, and the traffic is being switched with the previously negotiated label
values on the path R1-R2-R4-R6. Assuming that there is 100 Mbps ingress data traffic, all this traffic travels over this
path.
The path R1-R3-R5-R6 is not currently utilized, even though all of the links on the path are physically available. From
the service providers perspective, this might be an inefficient or non-optimal use of network resources, which can have
negative implications concerning the return value of infrastructure investments and congestion control.
Module 3 Page 68
Enabling ECMP
Module 3 |
69
ECMP can be enabled to optimize the use of network resources in such scenarios.
When enabled, ECMP is applicable for all active IGP protocols (OSPF, IS-IS, RIP) as well as LDP.
(As a result of its limitations, RIP is not used in todays IP/MPLS networks. It is mentioned only for the sake of
completeness.)
The candidate paths, however, must be identical to be used for ECMP; they must have the same cost values as well as
the same preference values. Since the costs must be equal, all the ECMP routes must be offered by the same IGP
protocol.
By default, OSPF has a protocol preference of 10 and IS-IS has a preference of 15 (for Level-1 routes) and 18 (for Level-2
routes). It is possible to modify the default preference values, if required.
The route with the lower preference value is preferred.
NOTE: If OSPF and IS-IS are running at the same time, provide a common route, and are both configured to use the
same preference value by the administrator, the router chooses the OSPF route over the IS-IS based route, according to
the current Service Router implementation.
When ECMP is active, multiple next-hops can be installed in the FIB for IP Forwarding. As a result, LDP installs multiple
entries in the LFIB corresponding to the IP next-hops.
An example of the LIB, FIB, and LFIB tables is presented on the following slide.
Module 3 Page 69
<max-ecmp-routes>
Module 3 |
70
When ECMP is enabled, the FIB contains 2 entries for prefix 10.10.10.6/32 with both routers R2 and R3 set as active IP
next-hops.
As with the FIB, 2 entries are present in the LFIB with Push actions, as displayed in the show router ldp
bindings active command output.
Module 3 Page 70
Since the routers use liberal label retention, router R1s LIB already
contains two labels, one each received from routers R2 and R3.
When ECMP is enabled, router R1 installs two forwarding entries in
the FIB and the LFIB.
An internal hashing algorithm distributes the traffic flows across the
two links in a load balancing fashion.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 3 |
71
After ECMP is enabled, router R1s LFIB contains 2 active egress labels to reach router R6, received from routers R2 and
R3. Router R1 can now distribute the incoming traffic flows over the 2 active links by encapsulating every flow with a
label received from either router R2 or router R3.
Traffic flow can be loosely defined as the data activity between a source and destination pair. Several criteria can be
used to define the source and destination, depending on the application and point of reference.
Traffic arriving at an ingress LER might be:
Traffic from an IP source address to an IP destination address.
Traffic from an IP source and TCP/UDP source port to an IP address and TCP/UDP destination port.
For traffic arriving at an LSR:
Traffic coming in on a port with certain MPLS label stack values.
An internal hashing algorithm, on a per-flow basis, chooses the link on which the iLER will forward incoming data
traffic. This depends on the MPLS configuration as well as the type of traffic and certain flow characteristics, as
mentioned above.
NOTE: SR OS does not implement per-packet load balancing. Sending packets from the same flow over different links
can cause sequencing problems at the eLER, since the links can experience different delay characteristics. In this case,
packets arrive out of order, causing delay, jitter, and packet loss.
Module 3 Page 71
Module 3 |
72
Module 3 Page 72
Module 3 |
73
Recall that a router generates and distributes a label binding for its system IP address only.
However, if desired, it is possible for the router to generate and distribute a label for its local prefixes.
A local prefix is a prefix that is owned by the router itself, an interface that is configured directly on the router
under consideration. It can be an interface directly connected to another router, or an interface that is set to operate
in loopback mode, much like the system interface, which is the default loopback interface.
Additional local prefixes are distributed by configuring and applying an export policy for LDP, a process that is
explained in the following pages.
Module 3 Page 73
Module 3 |
74
The configuration snapshots above illustrate how to configure and verify new loopback interfaces.
An interface needs to have either a physical port or the loopback keyword specified, as well as an IP address/prefix
length, to become operational.
Interfaces that are configured to establish IP connectivity to other routers/systems have a physical port configured for
them.
Interfaces that are not used to connect to other routers/systems, but that are required to remain IP interfaces that are
up and reachable as long as the router itself is functional, are called loopback interfaces. Loopback interfaces are
configured with the loopback keyword.
The only exception to the rule is the system IP address, which is the default loopback interface, as was explained in the
first section. The system IP address only needs a configured IP address to become operational. The loopback keyword is
not required and is implied for the system interface.
NOTE: The example here illustrates the distribution of labels for loopback interface IP prefixes, but the same procedure
can be applied to non-loopback, directly connected interfaces as well.
Module 3 Page 74
A:R6>config>router#
-------------------------------interface LP1"
address 192.168.6.1/32
loopback
exit
interface LP2"
address 192.168.6.2/32
loopback
exit
Module 3 |
75
Policies are administrative entities or templates that allow the administrator to impose additional controls over the way
the router functionalities or protocols operate. Policies are often used to override the default behavior of certain
protocols and perform additional tasks.
An example policy configuration is shown above. On the Alcatel-Lucent Service Routers, all of the policy-related
configurations are done in the configure router policy-options CLI context, regardless of which protocol or
feature the policy needs.
In the policy-options context, the operator first issues the begin command to enter policy edit mode; this opens the
policy editing application enabling policy modifications. Any new or existing changes become effective only upon once
the operator issues a commit command, ending the editing session and saving the changes.
A policy is defined with the policy-statement command, followed by the choice of an arbitrary name. The policy
names, however, are restricted to a maximum of 32 characters. If the name contains space characters, you must
enclose the entire name with double quotation marks (" ").
A policy can contain multiple entries that specify match conditions, and the action to be executed in case of a
match. These conditions can differ, depending on the protocol on which the policy will be applied and the purpose of
the policy. The entries are sequenced, meaning they are given numbers ranging from 1 to 4,294,967,295. In turn,
entries are evaluated in sequential order, starting from the lowest numerical value.
In terms of the given example, the purpose of the policy is to generate and distribute label bindings for the newly
created loopback addresses that override the default behavior of LDP, which only works for the system IP address.
To accomplish this, a prefix list that contains the statement 192.168.6.0/24 longer is created and arbitrarily
named (loopbacks in this example). The longer keyword provides for a more general statement, saving the operator
from having to specify the prefixes individually, as prefix 192.168.6.1/32 exact and prefix 192.168.6.2/32 exact.
If high-precision is required for prefixes to advertise in the subnet, the latter statements may be preferred. If even
lower-precision is required, the from protocol direct statement can be used to redistribute all the directly connected
(local) prefixes.
It is important to remember that a policy needs to be applied under the relevant protocol to become functional.
Module 3 Page 75
*A:R6>config>router>policy-options#
---------------------------------------------3 prefix-list "loopbacks"
prefix 192.168.6.0/24 longer
exit
1 policy-statement "LDP_export"
entry 10
from
prefix-list "loopbacks"
2
exit
5 action accept
exit
exit
exit
----------------------------------------------
Module 3 |
76
The SR OS executes the label distribution policy, used for distributing labels for the additionally configured loopback
interfaces, as follows:
NOTE: We assume that loopback interfaces are already configured and the policy has been applied under the LDP
context.
1.
The router begins the policy execution process with the lowest numbered entry, number 10.
2.
Entry 10 includes a from statement. This indicates that the router will process a match on the contents of the
prefix-list called loopbacks.
3.
The router evaluates prefix-list loopbacks. This list states that any available prefix within the 192.168.6.0/24
subnet is a valid match condition.
4.
The router then scans the forwarding table entries locate the any matching prefixes. In this instance, the router
finds two matches with prefixes 192.168.6.1/32 and 192.168.6.2/32. These belong to the configured loopback
interfaces.
The router will only match on prefixes actively available in the FIB. For example, if a loopback interface is
administratively shutdown, the route table manager (RTM) does not include this prefix in the FIB. The router will
not match on the inactive prefix.
5.
The router checks the policys action statement in the policy to determine what action will be performed on
the matched prefixes. This example sets the action to accept, which means generate label bindings for valid
matches and distribute the labels to all active LDP peers.
6.
A LIB check shows the desired outcome: For prefix 192.168.6.1/32, router R6 generates label 131065 and
distributes it to both routers R4 and R5. Similarly, for prefix 192.168.6.2/32, router R6 generates label 131064
and distributes that label to both peers.
NOTE: The peers will signal labels back to router R6 for these same prefixes. In this example, we gray out the
Egress Label column for the sake of clarity.
7.
There are no more entries to be executed in the policy, so the process can be concluded.
Module 3 Page 76
ALU Service Routers accept all label bindings received from peers,
by default.
An import policy can be used to reject certain label bindings upon
receipt.
In practice, the router still keeps the received labels, but does not
generate and distribute its own bindings to other peers.
Module 3 |
77
On the receiving end, the default behavior of Alcatel-Lucent Service Routers is to accept all label bindings received
from peers. The receiving router, in turn, generates its own label bindings for the prefixes and forwards them to other
peers.
It is possible, however, to use an import policy to prevent a selection, or all, of the received label bindings from being
further processed by the router, for administrative reasons. An example of these reasons is to prevent potential label
flooding when interoperating with a router under a different administration.
As illustrated in the following pages, the router still stores the received label bindings from the peers in the LIB, but
does not install them in the LFIB or propagate the message any further.
Module 3 Page 77
Module 3 |
78
Module 3 Page 78
After applying the import policy, all forwarding entries, except the
system IP address of router R4 itself, are removed from the LFIB,.
The entry for 10.10.10.4/32 is not a received, but a locally
generated label binding; therefore, it remains.
Module 3 |
79
The impact of the import policy is even more evident in the LFIB output.
All the forwarding entries have disappeared, except the one for the system IP address for router R4 itself.
Router R4 will only accept traffic arriving on an LDP tunnel on which its system interface IP is the target FEC, looking
for the ingress label 131071.
Module 3 Page 79
Module 3 |
80
In the example above, the router no longer can forward traffic to the prefix 192.168.6.1/32, a prefix for which it had
earlier distributed a label binding via an LDP export policy. Any condition which would cause a router to remove a
prefix from its FIB would cause the withdrawal message, such as a failed link or shut down interface. Additionally,
removing an applied export policy from the LDP context can cause a router to send a label withdraw message to its
peer(s). A Label Release message is sent in this case by the receiving peer, which acknowledges the receipt and
withdrawal of the label.
The label for a given FEC may be withdrawn, and as a result invalidated, if:
An MTU change on the interface causes a router to withdrawal the previously assigned label and re-signal the FEC
with the new MTU.
A network change, such as a failed interface, causes the router to remove a FEC from its FIB. The router had
previously generated and advertised a label for this FEC.
The router is configured to stop generating labels for specified FECs (for example, the removal of the export
policy).
A service manager command is issued to clear the labels, the labels are withdrawn, and new label mappings are
issued (for example, clear router ldp instance).
An LDP Label Release message may be generated if:
The LSR receives a label withdraw message from a peer.
The LSR operates in Conservative label retention mode, and receives a label from a peer that is not the next-hop
router for the FEC.
The LSR operates in Conservative label retention mode, and the peer from whom it received the label for a FEC is
no longer the next-hop router for that FEC (for example, the result of a network failure or topological change).
There is no more memory to store a received label and the label is released.
Module 3 Page 80
A:R6>config>router>ospf#
-------------------------------area 0.0.0.1
interface system
exit
interface toR4
exit
interface LP1
exit
interface LP2
exit
exit
A:R4>config>router>ospf#
-------------------------------area 0.0.0.0
interface system
exit
interface toR2
exit
area 0.0.0.1
area-range 192.168.6.0/24
interface toR6
exit
Module 3 |
81
A large IGP domain can be split into several areas to increase scalability.
To further benefit from the area design, route aggregation (summarization) can be enabled on the Area Border Routers
(ABR) to reduce the number of prefixes that are advertised and stored by the routers.
In the above example, router R4 is an OSPF Area Border Router that connects Area 0 and Area 1.
Router R6 advertises both of its prefixes 192.168.6.1/32 and 192.168.6.2/32 to router R4 via OSPF.
Route summarization occurs on router R4, and router R4 advertises a single aggregate prefix 192.168.6.0/24, as a result
of the area-range command.
Router R6 distributes 2 separate label bindings for its prefixes 192.168.6.1/32 and 192.168.6.2/32 to router R4. Router
R4 generates its own label bindings for these prefixes and again distributes 2 separate label bindings to router R2.
NOTE: In practice, Area 1 can contain many routers advertising specific prefixes within the aggregated 192.168.6.0/24
network, or even a larger network or networks. In such a case, aggregation would be beneficial to database and route
table optimization.
Module 3 Page 81
Module 3 |
82
Router R2 has received a single aggregate prefix of 192.168.6.0/24 via OSPF, as indicated in the FIB output.
Router R2 has also received 2 separate label bindings for prefixes 192.168.6.1/32 and 192.168.6.2/32, as indicated in
the LFIB output (show router ldp bindings).
To be able to resolve these LDP prefixes and install forwarding entries in the LFIB, router R2 looks for an exact match
for both of the prefixes in the FIB, by default.
Exact matches for the /32 prefixes do not exist in the FIB, so no entries are installed in the LFIB (show router ldp
bindings active). A possible solution to this problem is introduced in the next page.
Module 3 Page 82
Module 3 |
83
The configure router ldp aggregate-prefix-match command can be used to allow the router to resolve the
specific LDP advertised prefixes to the FIBs aggregate prefix entry.
As illustrated above, the label forwarding entries are installed into the LFIB of router R2.
This is a useful feature in very large, hierarchical network deployments where route aggregation is required.
Module 3 Page 83
Module 3 |
84
Module 3 Page 84
Module 3 |
85
Module 1 explained that an IP/MPLS network can be used to consolidate various types of services and applications. An
important portion of these applications is MPLS-enabled business VPN services. With MPLS VPN services, enterprise
customers may interconnect their various sites over the common service provider infrastructure, while enjoying the full
benefits of the MPLS technology, like security, privacy, cost-efficiency, and high reliability. The service instances that
belong to the same customer are virtually interconnected by separate service tunnels. This provides isolation between
the traffic from different customers.
SR OS routers use two LDP versions, Link LDP and Targeted LDP (T-LDP). We use Link LDP to establish transport tunnels
in the network that label switch traffic through the core, in a manner that is transparent to the core routers.
Alternately, we use T-LDP to signal service labels and establish service tunnels for Layer 2 VPN services, such as VLL and
VPLS.
Service tunnels tunnel VPN traffic through the MPLS core from PE router to PE router; these service tunnels depend on
MPLS transport tunnels for reliable, edge-to-edge traffic transport. To improve scalability in the core and provide data
transparency for P or MPLS core routers, service tunnels are carried inside the same transport tunnels. The edge routers
use T-LDP to signal service labels associated with the service tunnels, and the PE routers use these service labels to
identify a particular VPNs traffic.
The MPLS VPN solution implements a 2-label stack; the outer label is the transport label and the inner label is the
service label. The Label Switching Routers (LSR) only process the outer labels and are not service-aware. The service
labels are inserted by the ingress LER and used by the egress LER to demultiplex the traffic coming in on different
service tunnels and direct them to their respective service instances. These stacked labels allow the PE routers to
aggregate traffic for multiple VPN services in a single set of MPLS transport tunnels .
Module 3 Page 85
Module 3 |
86
Link LDP and T-LDP have specific purposes; Link LDP forms adjacencies between directly connected peers, supporting
hop-by-hop transport tunnels, where T-LDP forms adjacencies between indirectly connected peers, such as when
multiple P routers separate the two PE routers. Link LDP signals tunnel labels; T-LDP signals service labels.
Additionally, a VPN does not have to use Link LDP tunnels, as it can be configured to use RSVP-TE based transport
tunnels, as well. T-LDP may run without LDP enabled on the individual interfaces.
For a Layer 2 VPN service, the following combinations are possible when implementing the service:
Transport Tunnel LDP and Service Tunnel Targeted-LDP
Transport Tunnel RSVP-TE and Service Tunnel Targeted-LDP
Transport Tunnel LDP and Service Tunnel Static via static label configuration
Transport Tunnel RSVP-TE and Service Tunnel Static via static label configuration
For a Layer 3 (IP) VPN Service, the service labels are signaled via the MP-BGP (Multi-Protocol Border Gateway Protocol).
Targeted LDP is not utilized in pure Layer 3 VPN service environments.
NOTE: Transport Tunnels can also be established via Static LSP configurations. Static configurations are not covered in
this course; they are not preferred solutions because of their lack of reliability, scalability, and the administrative
complexity involved.
The primary purpose of Targeted LDP is to signal service labels for Layer 2 services. Services are configured on PE
routers, which are typically located at the edges or on the boundaries of the IP/MPLS network. For this reason,
Targeted LDP is designed to be able to also run between non-directly connected routers, unlike Link LDP.
Module 3 Page 86
Module 3 |
87
Module 3 Page 87
Module 3 |
88
Protocols are enabled on the service router by enabling contexts that activate the internal processes needed to run
the protocols.
The command configure router ldp enables the routers LDP processes, both Link LDP and T-LDP. You can verify
this with the show router status command, as shown above.
At this point, only the LDP process is enabled on the local router; no peer relationships exist. The required peer
configurations are explained on the following pages.
NOTE: In the SR OS CLI, the terms LDP and MPLS represent separate contexts, not protocols; in fact MPLS is not a
protocol at all. While LDP is an MPLS label signaling protocol, enabling LDP will not enable features configured under
the MPLS context; the MPLS context relies on the RSVP context, another MPLS signaling protocol.
Nonetheless, LDP does enable MPLS functionality configured under the LDP context, such as T-LDP. LDP configuration
occurs inside the configure router ldp context. Sections 4, 5, and 6 clarify the differences between the LDP and
the MPLS and RSVP contexts.
In short, the use of the LDP and MPLS contexts are independent of each other. LDP can operate without the MPLS
context enabled.
Module 3 Page 88
*A:R4>config>router>ldp#
---------------------------------------------interface-parameters
interface "toR6"
Link LDP sub-context
exit
exit
targeted-session
disable-targeted-session
Targeted LDP sub-context
exit
----------------------------------------------
With the configuration above, Link LDP is still active. Only the
targeted sessions are disabled.
The default is: no disable-targeted-session (targeted sessions are
enabled when LDP is enabled).
Module 3 |
89
Two separate sub-contexts are available within the main configure router ldp context for Link LDP and Targeted
LDP configurations.
The interface-parameters sub-context carries out Link LDP configurations, as was explained in Section 1 of this module.
Configure T-LDP under the targeted-session sub-context.
If you wish to completely disable targeted sessions on a router while maintaining Link LDP functionality, the disabletargeted-session command may be used. You might disable targeted sessions if building Layer 3 VPNs or statically
assigning service labels. L3 VPNs signal service labels using MP-BGP, while statically assigned service labels can be used
for mirror services.
The default mode of this command is no disable-targeted-session, which means that targeted session are
enabled, as can be verified by the info detail command output.
Module 3 Page 89
*A:R1>config>router>ldp#
---------------------------------------------interface-parameters
interface "toR6"
exit
exit
targeted-session
peer 10.10.10.6
exit
exit
----------------------------------------------
Both sides of the T-LDP peering must be configured properly for the
session to be established.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 3 |
90
Upon enabling the LDP context, no targeted sessions exist by default on the router.
On the Alcatel-Lucent Service Routers, there are 2 ways that a Targeted LDP session may be created:
1. The automatic method: This requires no explicit peer configuration. If in the configure service sdp context
you configure a Service Distribution Path (SDP) to use the default T-LDP signaling, the router first determines
whether a T-LDP session to the specified peer in the SDP configuration already exists. If it exists, another session
will not be attempted, since a single session between the two routers is sufficient. If a T-LDP session does not
exist, the router will automatically attempt to establish one to the specified peer.
NOTE: The implementation and configuration details of SDPs is beyond the scope of this course. Interested readers
may refer to the SRC Services Architecture course, or the Service Router product manuals and configuration notes
dedicated to services, for more information.
2. The manual method: Peers can also be specified with their system IP addresses via explicit configuration, as seen in
the example above. Both sides of the peering must configured to be able to bring up the T-LDP session.
Among the reasons why the network operator might want to use the manual, instead of the automatic, method are:
The operator may want to modify the session parameters (such as hello or keepalive timeout) from the default
values (see the example on the next page).
The operator may want to avoid peering with certain routers, probably those under a different administration (see
the example on the next page).
The targeted LDP session might be required for a special feature called LDP over RSVP-TE (discussed in Module 5 of
this course).
The targeted LDP session might have to be manually specified for interoperability reasons, if required by another
router vendor.
Module 3 Page 90
(global settings)
UDP Hello Timeout & Factor
TCP Session Keepalive
Timeout & Factor
Module 3 |
91
As discussed on the previous page, an operator might want to modify the session parameters for a peer from the default
values.
In the example above, the default timeout and factor values for hello and keepalive messages apply to all peers,
regardless of whether they were created using the automatic or the manual method.
Different hello and keepalive parameters are required for peer 10.10.10.6. This is why the peer is explicitly specified
with the override settings.
The operator wants to avoid Targeted LDP peering with the address 10.10.10.5. For this reason, the peer is explicitly
specified and administratively shutdown to avoid a T-LDP session from being established.
Module 3 Page 91
*A:R1>config>router>ldp#
-------------------------------------------interface-parameters
.........
exit
targeted-session
hello 45 3
keepalive 40 4
peer 10.10.10.6
hello 15 3
keepalive 30 3
exit
peer 10.10.10.5
shutdown
exit
exit
--------------------------------------------
Module 3 |
92
The CLI output above illustrates some of the several show commands that can be used to access information regarding
targeted sessions.
The show router ldp peer command output displays information per each targeted peer along with its hello and
keepalive parameters. If a peer is set to operate in passive mode, it will only accept incoming session requests, and will
not assume an active role. The No keyword in the Auto created column indicates that the peer has been manually
defined.
Note that the peer status can be Up, even if the session is not. This just indicates that a peer has been configured, and
that the router is at least trying to bring up the session with the other peer (if it is not configured in passive mode). Both
peers need to be configured properly for the session to be established.
The show router ldp session command output displays the status of the LDP peers.
The keyword established indicates the session is currently up and running at the moment.
If only a Link LDP session is established with a peer, the link adjacency type is displayed as Link
If only a Targeted LDP session is established with a peer, the link adjacency type is displayed as Targeted.
If both Link LDP and Targeted LDP sessions are established with a peer at the same time, the link adjacency is
displayed as Both.
The show router ldp status command output displays the general statistics regarding the LDP process.
Active Adjacencies indicates successfully discovered Link LDP and Targeted LDP peers (via Hello messages).
Active Sessions indicates successfully established Link LDP and Targeted LDP sessions (via Init and Keepalive
messages).
Active Interfaces indicates the number of core interfaces on which Link LDP is enabled.
Active Peers indicates the number of active Targeted LDP peers that are provisioned via either manual or automatic
methods.
Again, note that a session does not need to be established for a peer to be listed.
Module 3 Page 92
LDP Authentication
*A:R2>config>router>ldp#
---------------------------------------peer-parameters
peer 10.10.10.1
authentication-key Secret
exit
exit
Module 3 |
93
LDP sessions are established over the TCP transport layer. A malicious user may try to attack these sessions by sending
spoofed TCP segments. Message Digest 5 (MD5) authentication can guard against such attacks.
When enabled, the MD5 authentication algorithm adds a signature to each TCP segment, also known as an MD5 digest.
The MD5 password (Secret in the above example) is used to calculate a unique MD5 digest for each TCP segment and
is never transmitted to the other end in clear text format. The receiving end verifies the MD5 digest by using its locally
configured MD5 password. If the verification is not successful, the received TCP segment is dropped.
The configured authentication key is also not displayed in clear text form in the configuration outputs.
It rather appears in hashed format, as seen in the example below:
*A:R1>config>router>ldp# info
---------------------------------------------peer-parameters
peer 10.10.10.2
authentication-key "7ZooHlzw8OE8Hs6IKYJ1kiES27LcfN23" hash2
exit
exit
Module 3 Page 93
*A:R1>config>router>ldp#
---------------------------------------peer-parameters
peer 10.10.10.2
authentication-key Secret
exit
exit
Function
Signals errors and other events
0x0100
Hello
0x0200
Initialization
0x0201
KeepAlive
0x0300
Address
0x0301
Address Withdraw
0x0400
Label Mapping
0x0401
Label Request
0x0402
Label Withdraw
Requests the peer remove from its LIB a previously signaled label
0x0403
Label Release
Signals the peer that the LSR no longer needs specific FEC-label
mappings previously requested of and/or advertised by the peer
0x0404
0x3E00 0x3EFF
Vendor Private
0x3F00 0x3FFF
Experimental
Module 3 |
94
Type
0x0001
The table above provides a list of all the supported LDP messages.
Module 3 Page 94
Section Summary
Module 3 |
95
To sum up:
The FIB can contain multiple IP forwarding entries when ECMP is enabled.
The LFIB can be populated with multiple MPLS forwarding entries when ECMP is enabled.
An internal load balancing algorithm distributes the incoming data traffic flows over multiple available links.
Label bindings for additional prefixes can be distributed by configuring and applying an LDP export policy.
An LDP import policy can be used to prevent label bindings for a selection, or all, of the received prefixes from
being installed into the LFIB, or from being further distributed to other peers.
In a multi-area IGP deployment, route summarization can occur at area boundaries, causing an aggregate prefix or
prefixes to be advertised into other areas. By default, a specific prefix advertised by LDP cannot be resolved and
installed in the LFIB, unless an exact match prefix is available in the FIB. The aggregate-match-prefix feature helps
to override this limiting rule.
A router can issue a label withdraw message, to instruct its peers to delete a label binding for a prefix that is no
longer available.
Upon receipt of a label withdraw message, the peer responds with a label release message to confirm the label
delete action.
Targeted LDP is used to signal service labels for Layer 2 VPN services, such VLL and VPLS.
Targeted LDP sessions can be established between non-directly connected peers, unlike Link LDP.
Targeted LDP sessions are established similarly to Link LDP, except that the discovery (UDP Hello) messages are
sent in unicast, as opposed to multicast.
Authentication can be enabled on LDP sessions to harden the network security and guard against potential TCP
spoofing attacks.
Module 3 Page 95
Module Summary
The SR OS uses link LDP for transport tunnel and targeted LDP (TLDP) for service tunnel establishment.
LDP establishes tunnel LSPs with directly attached neighbors or
Targeted LDP sessions between non-directly connected peers.
LDP uses four processes to set up and maintain an LDP session:
Peer discovery Hello messages
Session establishment and management
Label management Advertise and withdraw labels
Notification Error alerts
1.
2.
3.
4.
Module 3 |
96
Module 3 Page 96
Module 3 |
97
Module 3 Page 97
Module 3 |
98
Module 3 Page 98
Module 3 |
99
Module 3 Page 99
Learning Assessment
Module 3 |
100
4. What is the port number used for UDP based LDP messages?
12. Which address determines the router that initiates the LDP
session?
13. True or False: An LDP router populates its LFIB by first checking
the RIB and then choosing the label from the FIB.
14. What must you enable on the router to allow it to populate its
LFIB with multiple labels per FEC?
15. By default, which peer generated LDP labels does an SR OS router
reject?
Alcatel-Lucent Multiprotocol Label Switching v2.1
9.
Module 3 |
101
10. Routers forward link LDP Hello messages to which reserved, all-routers address?
Link LDP Hellos target the all routers multicast address 224.0.0.2.
11. To create an LDP session, peer routers must have an IGP route to which of the others addresses?
transport address
12. Which address determines the router that initiates the LDP session?
The router with the highest transport address initiates the LDP session.
13. True or False: An LDP router populates its LFIB by first checking the RIB and choosing the correct label from the
FIB.
True
14. What must you enable on a router to allows it to populate its LFIB with multiple labels per FEC?
ECMP
15. By default, what peer generated LDP labels does an SR OS router reject?
SR OS routers accept all label bindings from their peers, by default.
11. In order to create an LDP session, peer routers must have an IGP
route to which of the others addresses?
www.alcatel-lucent.com
3FL-30635-AAAA-ZZZZA Edition 01
Module 4 Page 1
Module Objectives
Module 4 |
Module 4 Page 2
Module 4 Page 3
Section Objectives
Module 4 |
This section briefly examines the Resource Reservation Protocol, which was available before the introduction of MPLS.
The modifications, or extensions, made to RSVP to tailor it for MPLS traffic engineering purposes are then briefly
discussed.
The main purpose of the section, however, is to explain the primary components, as well as the general process, of
establishing LSPs, using the RSVP-TE protocol.
An RSVP-TE based LSP requires session states that are maintained in all of the participating routers on the path of an
LSP. The establishment and periodic maintenance of these sessions, using heartbeat messages, is examined step-by-step
in a simple case study.
The messages used by RSVP to signal, maintain, and clear (tear down) LSPs, or to signal certain error conditions, are
also introduced with case study examples.
Finally, the use of the LSP-Ping and LSP-Trace OAM commands for RSVP-TE based tunnels are presented at the end of
the section.
Module 4 Page 4
Module 4 |
Originally, the Resource Reservation Protocol (RSVP) was developed as a network control protocol that a host would use
to request specific qualities of service from the network for particular application data streams or flows. In addition,
RSVP has also been used by routers to deliver quality of service (QoS) requests to all nodes along the paths of the flows,
and to establish and maintain a state that provides the requested service. RSVP requests usually result in the
reservation of resources in each node along the data path. When used with MPLS, RSVP leverages this mechanism to set
up traffic engineered LSPs.
RSVP requests resources for simplex flows but only in one direction (unidirectional). Therefore, RSVP treats a sender as
logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the
same time. Duplex flows require two LSPs, to carry traffic in each direction.
RSVP is not a routing protocol. It operates with unicast and multicast routing protocols that determine where packets
are forwarded. RSVP consults local routing tables to relay its messages.
Module 4 Page 5
Module 4 |
The RSVP protocol has since been extended to support the traffic engineering requirements in MPLS based networks.
RSVP-TE brings major benefits to MPLS networks. They:
Provide access to detailed and customized path information to signal LSPs, which can be completely different from
IGP best path decisions.
Facilitate the use of additional administratively defined attributes for links that enable more complex dynamic
path calculations, to increase resiliency and resource efficiency. This is an improvement to IGP shortest path
calculations, which are restricted by their use of a single parameter or metric, called the link cost, for Link-State
Protocols.
Provide access to preferred features, such as secondary path or Fast Reroute protection, which help to improve the
convergence times offered by standard routing protocols.
Take resource reservation information into account during the LSP establishment process, which ensures that LSPs
only traverse routers that have sufficient resources available. This is called Connection Admission Control (CAC).
Using CAC allows operators to prevent resource overbooking.
Module 4 Page 6
Module 4 |
The RSVP-TE LSP establishment process is significantly different from the LDP process that was covered in Module 3.
LDP uses a Downstream Unsolicited mode of distribution, with Liberal Label Retention. When LDP is enabled in the
network, labels are advertised for the system IP address of all MPLS routers, by default; an additional trigger is not
necessary. As a result of label flooding in the network, eventually a full mesh of LDP based tunnels are established in
the network. While obviously simple to configure and maintain, LDP is limited by its lack of traffic engineering
capability and its heavy dependence on IGP, in terms of convergence.
RSVP-TE uses a Downstream on Demand (DoD) mode of label distribution. The demand for labels is triggered when an
ingress router sends a PATH message in the downstream direction, towards the egress router. The allocation of labels
follows a hierarchical order; that is, labels are allocated in an orderly fashion, starting from the egress router and
progressing hop-by-hop towards the ingress router in the upstream direction. This is achieved by the propagation of a
RESV (Reservation) message, which travels in the opposite direction to the corresponding PATH message.
In the original RSVP protocol (RFC 2205), a session is defined as a dataflow with a particular destination IP address, IP
protocol ID, and optionally, the destination port ID. RSVP with Traffic Extensions (RSVP-TE) is used to signal end-to-end
MPLS LSPs. Therefore, the concept of an RSVP session is made more general. When using RSVP-TE, an RSVP session is a
connection that contains the mapping of an ingress label and an egress label that belong to the same LSP. This
connection is analogous to the cross-connect concept of an ATM PVC.
Module 4 Page 7
Ordered Control
y Label distribution process follows a hierarchical order.
Module 4 |
The above figure illustrates an RSVP LSP path. The ingress label edge router (iLER) transmits an RSVP path message
(path: 10.10.10.6) downstream to the egress label edge router (eLER). The path message contains a LABEL_REQUEST
object, which asks intermediate LSRs and the eLER to provide a label binding for the path.
The signaling protocol model uses downstream-on-demand label distribution. A request to bind labels to a specific LSP
tunnel is initiated by an ingress node through the RSVP Path message. For this purpose, the RSVP Path message is
augmented with a LABEL_REQUEST object.
Module 4 Page 8
RESV messages are sent in the upstream direction and labels are
allocated at each hop.
When router R1 receives the RESV message from its downstream
neighbor, it brings up the LSP.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 4 |
Module 4 Page 9
Module 4 |
10
The logical sequence of actions to configure and signal RSVP-TE based LSPs is presented above.
The basic provisioning of related hardware components, such as the Input-Output Modules (IOMs), Media Dependent
Adapters (MDAs), and the physical ports, must be accomplished before proceeding to any other tasks on the AlcatelLucent Service Routers. Please refer to Alcatel-Lucent Configuration and Hardware manuals for more information.
The remaining steps necessary to complete the prerequisites to configure RSVP-TE based LSPs are outlined above and
explained in more detail in the following pages.
Module 4 Page 10
Module 4 |
11
The above diagram will be used to explain the main principles of RSVP-TE operation throughout this module.
System IP interfaces are created on the Service Routers by default and are crucial to the operation of the router in
various contexts.
Unique addresses need to be assigned to the system IP addresses to maintain proper operation.
The system IP interfaces use a prefix length of 32. This mask value implies a single host, where the host is the router
itself.
Module 4 Page 11
A:R1>config>router#
-------------------------------interface "toR2"
address 10.1.2.1/24
port 1/1/4
exit
interface "toR3"
address 10.1.3.1/24
port 1/1/3
exit
interface system
address 10.10.10.1/32
exit
A:R1>config>router>ospf#
-------------------------------area 0.0.0.0
interface system
exit
interface toR2
interface-type p2p*
exit
interface toR3
interface-type p2p*
exit
Module 4 |
12
The configuration of the core IP interfaces and the system interface is seen in the top CLI capture in the above slide.
Router R1 is used as an example.
The system interface is the default loopback interface; that is, an entity that remains up as long as the router is
operational. The system interface is not bound to any physical interfaces so it can be reached through any of the
routers physical interfaces.
Recall that RSVP-TE is not a routing protocol; it needs an Interior Gateway protocol to distribute the network
reachability information. OSPF and IS-IS are the major protocols used in contemporary IP/MPLS networks.
The configuration of OSPF is seen in the bottom CLI capture. A single backbone area (Area 0) is being used. It is
important to include the system interface in the OSPF configuration, so that other routers are able to reach the
interface.
interface-type p2p*: The actual command used is interface-type point-to-point. The default setting for the
interface-type is broadcast, which is actually intended for multi-access segments (that is, multiple routers attached
to a common Layer-2 segment). Initial convergence on broadcast segments take more than 40 seconds, due to
Designated Router election. Thus, it is recommended practice to use the point-to-point setting for directly connected
segments on which only 2 routers exist.
Module 4 Page 12
A:R1>config>router>rsvp# info
-------------------------------interface "system"
exit
interface "toR2"
exit
interface "toR3"
exit
Automatically added
Manually added
(Display config)
Automatically added
Module 4 |
13
Two contexts are used to configure and signal RSVP-TE based LSPs on the ALU Service Routers MPLS and RSVP.
Most LSP related configuration tasks occur from within the MPLS context. Operators create the path definitions and LSPs
and enable or disable features that effect the LSPs operation.
LSPs cannot be established unless MPLS is enabled and properly configured.
Interfaces can only be added into and removed from the MPLS context.
The RSVP context is mainly used to modify the parameters, or enable certain features, that are related to the actual
signaling of LSPs.
The contexts are internally connected to each other in several ways. If you add an interface into the MPLS context, it is
also automatically added into the RSVP context as well. If you remove an interface from the MPLS, it is also removed
automatically from the RSVP context.
The system interface is automatically added to both contexts, since it is usually crucial to the operation of RSVP-TE
based LSPs.
Module 4 Page 13
A:R1>config>router>mpls#
-------------------------------interface "system"
exit
interface "toR2"
exit
interface "toR3"
exit
Module 4 |
14
As of SR OS Software Release 7.0, both MPLS and RSVP contexts are initially disabled by default.
Before making any LSP configurations, it is a good idea to do a sanity check to ensure that the required protocols are up
and running. This can easily be done by using the show router status command, as displayed above.
Both contexts need to be enabled separately by issuing an administrative no shutdown.
The result of this action can be verified by executing the show router status command again. The bottom CLI
capture in the above slide illustrates that both contexts are now both administratively and operationally Up.
For proper operation, similar procedures defined on this and the previous pages must be performed on all the core
routers before attempting to configure LSPs.
Module 4 Page 14
Module 4 |
15
RSVP-TE LSP introduces the concept of LSP-Path, which is among the advanced traffic protection mechanisms.
The following (rough) definitions can be made for LSP and LSP-Path, in relation to RSVP-TE.
In practical terms, LSP is a logical entity that only exists in the ingress router of a Label Switched Path. LSP represents
the MPLS reachability from an ingress router to an egress router.
LSP-Path is a logical entity that is defined in the ingress router and represents an MPLS label connection that can reach
the egress router of the Label Switched Path. An established LSP-Path consists of a series of RSVP sessions in all the
routers along the LSP-Path.
One LSP can have more than one LSP-Path for redundancy or backup purposes.
An LSP-Path can also be used a primary path, which is usually the preferred path to actively carry data traffic over the
LSP. Optionally, up to 7 secondary paths can be defined within an LSP to provide backup solutions, in case the primary,
or other secondary, paths fail.
Not included in the figure above, an LSP can also have Fast Reroute detour or bypass tunnels to recover traffic in the
fastest way possible, in case of link failures.
Secondary and Fast Reroute protection mechanisms will be covered in greater detail in Module 6.
Module 4 Page 15
Module 4 |
16
The main features of configuring RSVP-TE based LSPs are presented above.
An LSP needs at least one path definition to be signaled using RSVP.
The introduction mentioned that one of the major benefits that RSVP-TE is the ability to administratively define the
path of an LSP. Here, the term path is used merely in the sense of a series of routers (that are called as hops in
RSVP terminology) defined in a configuration.
To give ultimate flexibility to network operators, the hops that an LSP must traverse can be defined in a variety of
ways. Hops can be explicitly defined as either loose or strict, if higher administrative control is desired, and
even more constraints can be imposed to calculate the path of an LSP. These techniques will be discussed in Module 5.
In this module, only an empty path list with no specific hops will be used to facilitate the primary objective of the
module: understanding the RSVP-TE LSP and session establishment/maintenance processes.
Path definitions can be seen as templates or passive components. They are only put into use when applied under an
LSP, either as a primary or secondary LSP-Path. A path definition can be used multiple times within the same LSP, or
within different LSPs if it is suitable to do so.
A case study example is presented in the following pages to better illustrate these concepts.
Module 4 Page 16
no shutdown
exit
lsp "to_R6"
to 10.10.10.6
exit
no shutdown
primary "empty_list"
exit
Module 4 |
17
Module 4 Page 17
A:R1>config>router>mpls#
-------------------------------path "empty_list"
Internet Protocol:
Source: 10.10.10.1
Dest. : 10.10.10.6
<EXPLICIT ROUTE>
............
Module 4 |
18
When the configuration on the previous page is complete and the LSP is enabled, the ingress router attempts to signal
the LSP-Path by sending out an RSVP Path message. This is the request message that was presented in the protocol
introduction. It travels downstream towards the egress router to trigger label allocations.
An RSVP Path message is encapsulated in an IP header. The source IP address is typically the configured system IP
address of the ingress router. The destination IP address is taken from the to portion of the LSP configuration. In our
example, this is the system IP address of the egress router.
As seen above, the Path message uses end-to-end addressing. Even if the Path traverses multiple intermediate hops, the
intended recipient is the router that is at the end of the tunnel. As a result of this addressing scheme, the intermediate
routers would normally be tempted to simply pass the message on, without analyzing the rest of its contents.
Therefore, they would normally forward the packet to their IGP next-hop, without decapsulating the RSVP header and
processing its contents.
According to the implementation of RSVP-TE LSP signaling (that will be presented step-by-step in the following pages),
all the intermediate routers are also required to process the RSVP message contents. To ensure this, the Router Alert
option is set in the IP header; this instructs all receiving routers to decapsulate and process the RSVP message in their
control plane and take any necessary action.
The information relevant to the signaling of an LSP is contained within several information blocks, referred to as
objects in official RSVP parlance. Some of these objects will be presented in this and the ensuing modules of this
course.
For a full description of RSVP objects, please refer to RFC 3209.
Module 4 Page 18
<SESSION>
If the RSVP message does not list any hops, the IGP forwarding table is
used to forward the PATH message at each router.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 4 |
19
If explicit hops are defined in the path definition, they are included in the RSVP message as sequential hops. The
routers consult this list of hops to determine to which next-hop they should forward the PATH message. (This will be
discussed in the next module).
An empty path definition was used in the LSP Path definition that was presented in the previous pages. Hence, the
primary path definition does have any explicitly defined hops.
In this case, the router reverts to default IGP decisions. That is, it looks up the destination IP address specified in the IP
header of the Path message (which is taken from the to field of the LSP configuration) and determines the next-hop.
In the example above, router R2 is the IGP chosen next-hop to reach prefix 10.10.10.6/32 of router R6; therefore, the
message gets forwarded to router R2.
Module 4 Page 19
Router R1 creates the PATH message and a Path State Block (PSB).
Router R1 stores the PATH message in the PSB and forwards the message to
the next-hop.
The HOP object contains router R1s egress interface IP address.
The LABEL REQUEST object indicates that router R1 expects a label.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 4 |
20
For the sake of clarity, only two of the many objects inside the RSVP PATH message are displayed in the figure above.
The HOP object contains the egress IP address of the interface on router R1, on which the PATH message is forwarded.
This address is used by router R2 when forwarding the RESV message back to router R1, at a later stage.
The LABEL REQUEST object is an indicator that router R1 is asking for a label from router R2 to establish the LSP.
However, because of the Ordered Control mode of implementation, and because router R2 is not the egress router for
the LSP, router R1 will wait for its own downstream neighbor (router R4) to distribute a label first. It therefore needs to
pass the PATH message to router R4 (described on the following page).
Router R1 creates a Path State Block (PSB) right after sending the Path message to router R2. The Path State Block
stores all the details of the Path message that is sent to router R2. This is required because router R2 needs to identify
which LSP the message is intended for when it receives the RESV (reservation) message later. The router matches values
in the previously sent PATH message and the newly received RESV message in order to associate them to the LSP.
PSB is combined with RSB (Reservation State Block, presented in the following slides) to make up a session that belongs
to the LSP. The session will need to be refreshed at certain intervals. The PSB (and the RSB) also stores timers to
perform the refresh function.
Module 4 Page 20
Router R2:
Receives the PATH message.
Creates the PSB.
Stores the PATH message in the PSB.
Looks up the destination in FIB.
Regenerates and forwards the PATH message.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 4 |
21
The sequence of events that take place on router R2 are illustrated above.
Upon receipt of the PATH message, router R2 creates its own Path State Block (PSB). The PSB stores all the contents of
the PATH message, but we show only the HOP object for the sake of clarity. 10.1.2.1 is router R1s (the upstream
routers) egress interface IP address, on which the PATH message was sent. Router R2 will use this information later.
Router R2 realizes that there are no explicitly defined hops in the RSVP message. As a result, router R2 reverts to the
default mechanism in forwarding the PATH message; that is, it looks up the destination IP address in the FIB.
Router R4 is listed as the next-hop for prefix 10.10.10.6/32, therefore router R2 forwards the PATH message to router
R4.
In the outgoing PATH message, the HOP object is set to router R2s outgoing interface IP address, 10.2.4.2.
The process of forwarding the PATH message is similar for router R4.
Module 4 Page 21
Module 4 |
22
In the figure above, the complete end-to-end forwarding of the PATH message from the ingress router (R1) towards the
egress router (R6) is displayed.
PSBs are created on all the routers that receive and process the PATH message.
Eventually, the PATH message reaches router R6, at which point the propagation of the PATH message stops.
Router R6 owns the destination IP address specified in the PATH message. It is also the egress router for the LSP and
now needs to respond to the request of the ingress router (R1) with a reservation message.
Module 4 Page 22
Module 4 |
23
Router R6 has received a PATH message to have labels allocated to signal an LSP that was initiated by router R1.
Router R6 checks its dynamic label-range (32,768 131,071) and allocates a label that has not yet been reserved by any
signaling protocol. In the example above, the label that router R6 locally allocates for the LSP request by router R1 is
131,067. This label value is indicated in the LABEL object of the RESV message that is sent to router R4.
Unlike the PATH message, which uses end-to-end addressing, the RESV message uses hop-by-hop addressing. That is,
router R6 does not perform a FIB lookup to determine where the RESV message should be forwarded; rather, it uses
previously received information.
To find out which upstream neighbors directly connected IP address should be used as the destination IP address of the
RESV message, router R6 checks the HOP object inside the PSB that was created when the PATH message was received.
The HOP object in the PSB contains the address 10.4.6.4, which is the interface IP address of router R4. This is why the
RESV message is sent to router R4.
The corresponding source IP address for router R6 is 10.4.6.6, as seen above. The HOP object of the RESV message sent
to router R4 is set to the egress interface IP address of the sending router, router R6.
Note: The RESV message actually contains more objects (information blocks), which are omitted here for clarity. Other
objects will be introduced in the following modules.
Module 4 Page 23
Module 4 |
24
A Reservation State Block (RSB) is created on router R6 once a label is allocated for the LSP and the RESV message sent.
The RSB basically stores the original RESV message sent to the upstream neighbor.
When a PSB and RSB are both present on a router, an RSVP session is created for the LSP to store the necessary LSP
parameters. The R6 RSVP session represents the LSP that was originally created on router R1.
Router R6 has an ingress label and no egress label, since it is the egress router for the LSP. As a result, router R6 has an
RSVP session with type terminate for the LSP. In other words, router R6 is where the LSP terminates, or ends.
Within the data plane context, router R6 expects labeled packets from router R4 with a label of 131,067. Upon receipt
of such packets, router R6 will Pop their labels and process the rest of the packets contents.
Note: Unlike LDP, router R6 advertises the label to router R4 only, and not to both neighbors.
Module 4 Page 24
Module 4 |
25
When router R4 receives the RESV message, it immediately creates the Reservation State Block to track the state of the
reservation in the future.
Recall that an RSVP session is created for an LSP when both a PSB and RSB are present on router R6. This session type is
transit, since router R4 is a Label-Switch router for the LSP and performs a swap operation. The associated ingress and
egress label values for this example are shown above.
Router R4 updates its contents and thus builds a new RESV message. The destination address used in the RESV message
is taken from the HOP object of the previously created PSB.
The HOP object of the RESV Message is set to the sending routers (R4s) egress interface IP address, which is 10.2.4.4.
Label 131,064 is reserved and advertised by router R4.
Module 4 Page 25
Module 4 |
26
Module 4 Page 26
The above commands display the LSP status and details on router R1.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 4 |
27
Since the LSP is only configured on the ingress router (the rest is dynamic RSVP signaling), the show router mpls
lsp command can only be used on the ingress router of the LSP. The command output indicates that router R1 is the
router where the LSP originates. (It is possible to view the status of the LSP on the routers by specifying additional
keywords, as will be presented in the following pages.)
The most significant parameters are the LSP-Name and destination IP address (as specified in the to field of the LSP
configuration). Fastfail Config refers to the Fast Reroute feature, explained in Module 6, which is not yet enabled.
The LSP is both administratively and operationally up.
More extensive information is displayed with the show router mpls lsp lsp-name path detail command.
LSP to_R6 has only one primary path, which is named empty_path because it does not have any specific explicit
hops defined. Router R1 is an ingress router for the LSP, hence it only has an egress interface label associated. The
Path Up or Path Down timers are useful in troubleshooting problems with an LSP. These fields can reveal if and
when a path state transition has occurred.
Note: The detail output contains much more information than is displayed above, but is omitted for clarity reasons.
Module 4 Page 27
LSP ID: Each LSP-Path (primary or secondary) have its own LSP ID.
Session Name: Format is LSP-Name :: Path-Name
Tunnel ID, LSP ID, and Session Name are used to identify a unique
RSVP session that belongs to a signaled LSP on all routers.
Tunnel ID and LSP ID are internally assigned by the originating router
(not configurable).
Session Name is taken from the LSP configuration.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 4 |
28
An RSVP session is established on all the routers along the path of an LSP. To uniquely identify an RSVP session among
other sessions, certain parameters are used.
Tunnel ID is an integer internally assigned to an LSP by the originating router. All the signaled LSP-Paths of an LSP share
the same Tunnel ID. This includes the primary path and all the signaled secondary paths.
To distinguish between the different LSP-Paths of an LSP, the LSP ID is used.
Neither the Tunnel ID nor the LSP ID is administratively configurable.
The RSVP session name is inherited from the LSP-Name and Path-Name configuration on the originating router, as shown
in the example above. Since the different paths of an LSP must have different path names, their RSVP session names are
also different.
If a primary path has one-to-one Fast Reroute protection, its detours have the same Tunnel ID and LSP ID as the primary
path. They are distinguished from the primary path, and from each other, by their different session names. This will be
explained further in Module 6.
RSVP Sessions need to be periodically refreshed to keep the LSP operational.
Module 4 Page 28
Tunnel ID: Shared by all LSP-Paths that belong to the same LSP.
The above commands display the transit LSP status and details on
router R2.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 4 |
29
On a transit router, which is responsible for performing a swap action for the LSP in the data plane, the previously
presented commands should be used together with the transit keyword.
The show router mpls lsp transit detail command output displays the ingress and egress labels and interface
information, and other relevant details regarding the LSP, all of which are not displayed here.
Module 4 Page 29
: 247
: 244
Path Sent
Resv Sent
: 246
: 238
The above command displays the transit RSVP session status and
details on router R2.
Module 4 |
30
The transit RSVP session status can be displayed with the show router rsvp session transit detail command.
The command output also displays the total count of all the received Path and Resv messages.
A low number of messages can indicate that the session has a relatively lower uptime.
Module 4 Page 30
The above commands display the LSP status and details that
terminate on router R6.
Module 4 |
31
The command outputs above displays the LSP related information on the terminating router, where the LSP ends.
Note that router R6 only has an associated ingress label and interface, as it is the egress router for the LSP.
Module 4 Page 31
: 254
: 0
Path Sent
Resv Sent
: 0
: 254
The above command displays the RSVP session status and details
that terminates on router R6.
Module 4 |
32
The show router rsvp session terminate command lists only the RSVP sessions with type Terminate on the
router.
If more information is required, the detail keyword can be specified, as seen in the example above.
Note that, because router R6 is the egress router, it only receives PATH messages and sends RESV messages for the LSP.
Module 4 Page 32
Module 4 |
33
RSVP message types other than PATH and RESV messages are presented above.
These different message types are examined later in the module.
Module 4 Page 33
Module 4 |
34
For any number of administrative reasons, the operator might want to bring down the LSP. This is done by issuing a
shutdown command in the LSP configuration of the ingress router. If an LSP, or a specific LSP-Path, is no longer
needed, it should be removed from the network to release the resources. This is how Conservative Label Retention
works.
As discussed earlier, the routers along the path of an RSVP-TE LSP store not only labels, but also session state
information. When it wishes to tear down an LSP and release its resource, the ingress router sends out a PATH Tear
message, which travels all the way downstream towards the egress router. When a router receives a PATH Tear, it
clears the corresponding RSVP session and the related state blocks to release the sessions resources.
Module 4 Page 34
Module 4 |
35
If a transit or egress router detects a fatal error condition that impacts an LSP, it immediately sends out an RESV Tear
message to instruct all its upstream neighbors to clear their RSVP sessions associated with that LSP.
This way, all the routers are informed about the problem and, since the LSP is torn down, data traffic is not blindly
forwarded downstream. Tear messages ensure traffic is not black-holed at the point of failure.
In the example above, the link between routers R4 and R6 fails. Router R6 clears its session and, since it has no other
downstream neighbors to notify, it does not need to take any further action.
Router R4, however, is a transit router for the LSP and sends out an RESV Tear message in the upstream direction,
instructing all the other routers to clear their sessions.
The ingress routers (R1) response to LSP failure will be discussed in the following modules.
Module 4 Page 35
Module 4 |
36
: to_R6
From
: 10.10.10.1
To
: 10.10.10.6
Adm State
: Up
Oper State
: Down
Path Name
: empty_list
Path Type
: Primary
Path Admin
: Up
Path Oper
: Down
......................
.......................
NOTE: PATH Error messages are also used in the Fast Reroute implementation, which is covered in Module 6 of this
course.
Module 4 Page 36
Module 4 |
37
Normally, an MPLS router runs a sanity check before forwarding the PATH message to the next downstream hop. It
determines whether the destination next-hop is reachable and, when using RSVP bandwidth reservations, if there are
enough resources available.
In the figure above, router R2 performs this check and forwards the PATH message. However, as a result of a
reservation state change or any resource allocation problem, router R2 might not be able to forward the RESV message
upstream. In this case, router R2 sends back a RESV Error message downstream, which is in the opposite direction of
RESV message propagation.
Note that the RESV Error message, much like the PATH Error message, is only informational. It does not affect the
session state on the routers. For this reason, when the egress router (R6) receives the RESV error message, it sends a
RESV Tear message upstream to clear the RSVP sessions that belong to the LSP on all routers.
Module 4 Page 37
Module 4 |
38
After the LSP-Path has been established, it must be refreshed periodically to maintain its operational state. As a softstate protocol, RSVP requires a constant refresh of all the RSVP sessions. This is done by using the same PATH and RESV
messages that were initially used to establish the sessions. If certain refresh messages are not received as expected, the
RSVP sessions expire and are cleared to release the occupied resources.
It is important to note that the RSVP state is refreshed at every hop by the PATH and RESV messages generated between
the directly adjacent routers. For each router, in every PATH state, the router generates a PATH message to the nexthop downstream router at every refresh interval. For each router, every time a PATH message is received for a session,
the Path State Block is refreshed and the expiration timer is reset.
In the upstream direction, the RESV message is generated to refresh the Reservation State Block of the RSVP session in
the same manner.
Recall that both the Path State Block and the Reservation State Block need to be actively present for an RSVP session to
stay operational.
Module 4 Page 38
Module 4 |
39
Module 4 Page 39
: [1..65535]
*A:R1>config>router>rsvp# keep-multiplier ?
- keep-multiplier <number>
- no keep-multiplier
: [1..255]
Module 4 |
40
The RSVP refresh time configuration on a router determines how frequently refresh messages are sent out of the router.
The refresh time can be locally configured on each router and the refresh timer should be configured consistently on all
the routers to avoid strange timeout issues.
The default value for sending out PATH and RESV refresh messages is 30 seconds.
To keep CLI results simple, the ALU Service Router CLI info command does not display default values. However, the
info detail command output also displays the default values of configuration parameters that are not visible in the
info output.
In addition to sending out refresh messages, a router also expects to receive constant refresh messages from its RSVP
neighbors, to be able to keep sessions active. If a router does not receive any refresh messages within a certain
interval, the sessions time out and the router sends out the appropriate Tear messages, as discussed in the previous
page. The keep-multiplier parameter governs the timeout interval. The keep-multiplier roughly determines how many
missed messages a router can tolerate before declaring a session down.
Section 2 of this module explains the optimizations done on these timers.
The no refresh-interval and no keep-multiplier commands may be used to quickly restore the default values,
if they had been modified.
Module 4 Page 40
<number>
10.10.10.2
10.10.10.4
10.10.10.6
rtt=1.57ms rc=8(DSRtrMatchLabel)
rtt=2.24ms rc=8(DSRtrMatchLabel)
rtt=3.13ms rc=3(EgressRtr)
Module 4 |
41
The operational principles of the LSP-Ping and LSP-Trace commands were explained in Module 3 (LDP) of this course.
The same functionality is used with RSVP-TE tunnels as well, with the major difference being in the syntax. The name
given to the LSP on the originating router must be specified in the commands, instead of with the prefix keyword.
Module 4 Page 41
---- LSP to_R6 PING Statistics ---1 packets sent, 1 packets received, 0.00% packet loss
round-trip min = 3.27ms, avg = 3.27ms, max = 3.27ms, stddev = 0.000ms
Section Summary
This section covered:
Introduction to RSVP-TE
LSP establishment using PATH and RESV messages
Configuration prerequisites for RSVP LSPs
RSVP sessions implementing Path State Blocks (PSBs) and
Reservation State Blocks (RSBs)
PATH Tear and RESV Tear messages used to tear down RSVP
sessions
PATH Error and RESV Error messages used to signal error
conditions
RSVP Session Refresh Process
LSP-Ping and LSP-Trace OAM commands
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 4 |
42
Resource Reservation Protocol has been used in the past to manage reservations for IP flows in the Integrated
Services Quality of Service model.
RSVP Traffic Engineering extensions support advanced MPLS signaling capabilities.
Network interfaces need to be added into the MPLS context to be able to signal RSVP-TE based LSPs.
The router automatically adds MPLS interfaces into the RSVP context.
Both MPLS and RSVP contexts are, by default, administratively disabled; they need to be individually enabled.
An LSP needs at least the egress routers destination IP address and a primary path entry.
A definition can contain explicitly defined hops that regulate the path an LSP takes.
RSVP-TE uses PATH and RESV messages to signal LSPs.
If a path definition contains hop definition, the IGP forwarding table is consulted to determine where the PATH
message will be forwarded to.
A Path State Block is created to store the sent or received PATH message.
PATH and RESV messages contain several objects that contain a range of information.
The PATH and RESV messages HOP object represents the egress interface IP address on which the router sent the
message.
To forward the RESV message back toward the ingress LER, routers use the address stored in their PSBs HOP field.
A Reservation State Block is created to store the sent or received RESV message.
When a PSB and RSB are both present, and ingress and egress labels are allocated, the router creates an RSVP session
to represent the LSP.
An RSVP session type is originate on an ingress router, transit on an intermediate router, and terminate on an
egress router, along the path of an LSP.
Sessions must be periodically refreshed to maintain their active states.
PATH Tear and RESV Tear messages are sent to tear down existing RSVP sessions.
PATH Error and RESV Error messages are sent to signal error conditions.
Module 4 Page 42
The second section of Module 4 focuses on several features and techniques that optimize failure detection times
without compromising the router performance in RSVP-TE.
Module 4 Page 43
Section Objectives
Module 4 |
44
The default session refresh time is 30 seconds in RSVP. While lowering this timer can yield better failure detection and
convergence results compared to the default, it can also negatively impact the routers processing performance.
To improve detection times without compromising the system performance, several methods have been proposed and
implemented.
The first method that will be discussed is the HELLO extension to RSVP. With this addition, directly connected RSVP
routers build neighbor relationships with each other and track the RSVP sessions running between them.
To prevent all RSVP sessions from being refreshed at the same time, one can set random refresh timers on the RSVP
sessions, as proposed in RFC 2205 Section 3.7.
The Refresh Reduction method, introduced in RFC 2961, reduces the number of refresh messages. It is also explained in
this section.
Module 4 Page 44
To maintain the LSPs state, routers periodically send PATH and RESV
refresh messages.
The global refresh time setting tells the routers when to send refresh
messages; the default refresh time is 30 seconds.
A shorter refresh time allows faster RSVP failure detection but
creates greater CPU overhead.
Module 4 |
45
Recall that the default RSVP refresh-time is 30 seconds, which applies to all RSVP sessions on the router. This means
that every 30 seconds, routers needs to exchange PATH and RESV messages to prevent RSVP sessions from timing out.
Decreasing the RSVP refresh-time may be a tempting alternative for faster detection and convergence. In a network
with a large number of LSPs and RSVP sessions, however, this might present a drawback with the number of messages
and processing involved. More messages mean the router spends more time processing these messages, which could
negatively impact the time the router spends on other processes.
NOTE: A router does not necessarily have to wait for 30 seconds to realize loss of connectivity to a neighbor. There are
now several other lower-level detection mechanisms that can notify all the higher level protocols of physical failures.
The RSVP timeout mechanism can be seen as a last resort measure, in case failures go undetected by lower-level
detection features. More aspects of failure detection and convergence are covered in Module 6
Module 4 Page 45
Module 4 |
46
As illustrated in the figure above, routers can have a huge number of RSVP sessions in a scaled network. All these RSVP
sessions require periodic refreshes to maintain their active states.
Certain criteria need to be taken into consideration when tuning the system timers. While lowering the timers can
speed up detection and convergence, it can also increase the number of state-refresh messages generated. If the timers
are increased, this drawback is alleviated, but a slower reaction to network failure and longer convergence times can
result.
Operators must balance both performance and resources for these scenarios. Several aspects of this issue are presented
later in the section.
Module 4 Page 46
Module 4 |
47
As explained on the previous page, decreasing RSVP refresh times is not always recommended because, if there are
many RSVP sessions, it can result in a large number of session-refresh messages needing to be exchanged.
The Hello Protocol was introduced to RSVP-TE to alleviate this problem. It is inherited from link-state routing protocols,
such as OSPF and IS-IS, and, with it, directly adjacent RSVP enabled routers can exchange RSVP Hello messages and
build a neighbor relationship.
Alcatel-Lucent Service Routers are enabled to exchange RSVP Hello messages, by default. In a process that is slightly
different from link-state protocols, routers begin sending Hello messages only after there is at least one active RSVP
session running on the interface. If there are no active sessions, no Hello messages are sent. However, once the Hello
mechanism is initiated, it continues to run indefinitely, even after all the active sessions go down.
The keep-multiplier value configured in the global RSVP context also applies to RSVP Hello protocol. The keepmultiplier determines how many hello messages must be missed before a router declares a neighbor down. In case of a
hello timeout, ALL the RSVP sessions running on that interface are cleared.
By default, RSVP Hello messages are sent every 3 seconds.
Module 4 Page 47
Module 4 |
48
The RSVP-TE Hello extension is configured on a per-interface basis. If two routers have more than one IP routing
interface between them, each link needs a separate Hello adjacency.
The Hello Interval is configurable in multiples of 1000 milliseconds. The default value is 3000 milliseconds, or 3 seconds.
If the Hello Interval value is changed and the default value needs to be restored, the no hello-interval command
form can be used to easily accomplish this. This is equivalent to typing hello-interval 3000 in the configuration.
It is also possible to disable sending hello messages on an interface by setting the hello-interval value to zero.
Module 4 Page 48
<milli-seconds>
Module 4 |
49
The neighbor adjacencies that are established using RSVP Hello messages can be verified with the show router rsvp
neighbor command.
The keep-multiplier in the global RSVP configuration (not per-interface) can be used to determine the Hello timeout
value, and the RSVP session timeout.
A router needs to constantly receive Hello messages from its neighbor to keep the adjacency up. A neighbor becomes
down if no Hello messages are received within the timeout interval. This is 9 seconds, by default.
Module 4 Page 49
Module 4 |
50
If a router has a large number of active RSVP sessions, refreshing all (or many) of them at the same time can cause a
sudden burst of message traffic and CPU processing. To avoid any possible side effects to this, RFC 2205 proposes a
level of randomness when sending out refresh messages for RSVP sessions.
After sending each refresh message, the interval to send the next refresh message is set to a random value in the 50%150% range of the configured refresh-time value.
The effective session refresh timeout is not a direct factor of the keep-multiplier value, to avoid any premature loss of
state. In principle, the timeout must satisfy the following condition:
Session Timeout (Keep-Multiplier + 0.5)*1.5*Refresh-Time
According to the formula above, and with the default values of the Refresh-Time (30 s.) and Keep-Multiplier (3), the
session timeout should be set to at least 157.5 seconds after each successful refresh.
Module 4 Page 50
The above command displays the Path State Block (PSB) for the
established RSVP session on a transit router.
The next Path Refresh message will be sent in 36 seconds (higher
than the configured interval of 30).
The Path Refresh timeout is reset every time a PATH message is
received.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 4 |
51
A Path State Block (PSB) is created for each RSVP session on all the participating routers, as explained in the first
section. PSB stores the original PATH message as well as the relevant timers to refresh the session.
The command output shown above displays the contents of the PSB on router R2, which is a transit LSR for the LSP in
the case study example.
The values in the Session object are To: 10.10.10.6 - 1 - 10.10.10.1, where 10.10.10.6 is the tunnel destination, 1 is
the Tunnel ID, and 10.10.10.1 is the tunnel source IP address.
The Previous Hop IP address is 10.1.2.1, as advertised by router R1 in the PATH message.
The output PSB CurrState: PRIMARYS_CONNECTED states the session is currently connected, which indicates the
session is active. The keyword PRIMARY has no relation to the LSP-Path type as primary or secondary. It is relevant to
the RSVP state machine only.
The current state of the timers related to session refresh can also be seen in the PSB output.
The configured refresh interval is 30 seconds, which is the default value.
The time left to send the next PATH refresh message can indicate the operator modified the refresh timeout mentioned
in the previous page.
The output indicates that the session will timeout if no refresh message is received within 155 seconds, which
corresponds with the formula presented on the previous page.
Module 4 Page 51
Module 4 |
52
Recall that RSVP is a soft-state protocol that requires constant PATH and RESV refresh messages on every LSP-Path that
is established. This may cause scalability issues when there are many RSVP sessions on a router. The router must handle
thousands of PATH and RESV messages, especially during a network failure. Too many incoming messages may cause a
system message queue overflow. Delay or loss of messages may cause the LSPs to go operationally down and interrupt
the data traffic. The routers CPU and memory resources may also be exhausted because of large numbers of messages
being processed.
RFC 2961 describes some RSVP-TE extensions that reduce the RSVP messaging overhead while maintaining the states of
all LSP-Paths and the ability to quickly detect message loss or network failures.
The refresh-reduction feature can be enabled on a hop-by-hop basis. Both peers must agree on the refresh-reduction
capability before the feature can be used.
The refresh-reduction feature is disabled by default. When enabled on an interface, the router includes a Message ID to
all the outgoing RSVP messages. The Message ID is an integer that easily and uniquely identifies an RSVP session.
When both sides are enabled for refresh-reduction, the individual PATH and RESV messages are replaced by a single
Summary Refresh message. The Summary Refresh message contains a list of only the Message IDs of the active sessions
between the two routers.
The refresh-reduction feature also has an option called reliable-delivery. When enabled, the first RSVP messages used
to establish the session are explicitly acknowledged to ensure that the messages are received by the other end without
problems. Summary Refresh messages are not subject to this mechanism; that is, they do not need to be acknowledged.
These steps are detailed in the following pages.
Module 4 Page 52
Module 4 |
53
When the refresh-reduction feature is enabled on a router, it starts sending all the RSVP messages (except Hello) with a
unique Message ID object.
The format of the Message ID object as defined in RFC 2961 can be seen below. The total length of the Message ID
object is 8 bytes.
The Message Identifier integer value is contained within a 4-byte field.
RSVP sessions are given Message Identifier values, starting from 1. The Message Identifier value is incremented if there
is a change in the operational or reservation state of a session. This way, the receiving router is notified when the RSVP
contents are changed.
8 bits are allocated for the Flags field. When the value of this field is set to 0x01, it means that the sending router
requests an acknowledgement for the message that it sent. This is optional, as explained in the previous page.
The Epoch field contains a value that indicates when the Message Identifier sequence has been reset. It is a random
value and only changes when the router reboots or the RSVP process is reset.
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Flags
Epoch
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Message_Identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Module 4 Page 53
Module 4 |
54
If the reliable-delivery option is enabled, the sending router requests an acknowledgment from the other party.
A timer is introduced to regulate the time to re-send the message, in case an acknowledgment is not received. This
interval is controlled by the rapid-transmit-interval setting.
The rapid-retry-limit setting determines up to how many times the message should be retransmitted if the
acknowledgment is not received.
If two peers set different capabilities, that is one node is refresh-reduction-capable bit while the other is not, the
refresh reduction capable node will still attempt to perform reliable message delivery with its peer. In this case, the
RSVP session still succeeds, but the peers exchange no acknowledgements.
The routers indicate if they are refresh reduction capable in the RSVP message header.
Module 4 Page 54
When both RSVP neighbors are enabled for Refresh Reduction, only a
Summary Refresh message is exchanged; individual PATH and RESV
(and ACK) messages are not needed to refresh each session.
The Summary Refresh message contains a list of the Message-IDs of
all the RSVP sessions running on that interface.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 4 |
55
The Refresh-Reduction feature decreases the number of refresh messages that are sent between RSVP neighbors.
When both neighbors are enabled for Refresh Reduction, and after they successfully negotiate this capability, the
routers start sending a single Summary Refresh message instead of individual PATH and RESV messages. This is a new
and more efficient way of refreshing the RSVP states of LSPs. The Summary-Refresh message uses only the Message
Identifier value received from the RSVP messages within the Message ID object. This significantly reduces the signaling
cost, since the Message Identifier is 4 bytes while the PATH message is usually a few hundred bytes per LSP-Path.
RFC 2961 states: Each Summary Refresh message MUST occupy exactly one IP datagram. If it exceeds the MTU
(Maximum Transmission Unit) of the link, the datagram is fragmented by IP and reassembled at the recipient node.
Module 4 Page 55
exit
----------------------------------------------
<hundred-milliseco*> : [1..100]
*A:R1>config>router>rsvp# rapid-retry-limit
- no rapid-retry-limit
- rapid-retry-limit <limit>
<limit>
: [1..6]
Restore default
Default: 5 (500 ms)
Restore default
Default: 3 (retries)
Module 4 |
56
The Refresh-Reduction feature must be configured on an interface basis. A router can use Summary Refresh messages
with one neighbor, and choose to not use the feature with another neighbor, depending on the neighbors capabilities.
Reliable-delivery is an optional setting that makes the sending router request acknowledgment for the individual PATH
and RESV messages that are sent. Note that when both neighbors start exchanging Summary Refresh messages,
individual PATH and RESV messages are no longer sent to refresh the sessions, so the acknowledgment mechanism is not
needed beyond that point.
The rapid-retransmit-time and the rapid-retry-limit are set under the global RSVP context, applying to all interfaces.
(The use of these commands was explained in the previous pages.)
NOTE: If the msg-pacing feature is enabled in the RSVP context, the Reliable Message Delivery feature cannot be used;
both features cannot coexist on a router. RSVP Message Pacing is a rate-limiting function that controls the burst of RSVP
messages. The below configuration snippet provides an example:
*A:R1>config>router>rsvp#info
---------------------------------------------msg-pacing
period 1000
max-burst 1000
exit
..................
---------------------------------------------The max-burst parameter defines the number of messages that can be sent out per interval. The period parameter
defines that interval in milliseconds. This sample configuration limits the RSVP message rate to 1,000 messages per
second. This feature is mutually exclusive from the reliable-delivery feature.
Module 4 Page 56
*A:R1>config>router>rsvp# rapid-retransmit-time
- no rapid-retransmit-time
- rapid-retransmit-time <hundred-milliseconds>
Module 4 |
57
The LR flag is set when the local router has the refresh-reduction feature enabled.
The LD flag is set when the local router has the reliable-delivery option enabled.
The RM flag indicates that the neighbor (remote node) supports the Message ID implementation.
The RR flag is set when the neighbor sets the Refresh-Reduction-Capable bit in its RSVP messages, as shown in the
packet capture in the previous page.
Module 4 Page 57
Module 4 |
58
Module 4 Page 58
Section Summary
Module 4 |
59
The Hello feature was introduced into the RSVP-TE protocol as an extension to monitor the health of the RSVP
interface.
The RSVP-TE Hello protocol uses Hello packets to constantly check the RSVP adjacency over the RSVP interface.
If the RSVP Hello protocol times out in an RSVP interface, all RSVP sessions running on that interface are cleared,
and the corresponding LSP is rerouted or torn down.
With the RSVP-TE Hello protocol, the RSVP sessions can have longer refresh intervals and rely on the Hello protocol
to detect RSVP adjacency failures, if they are undetected by lower-level mechanisms.
Several techniques are involved in the reduction of the RSVP session refresh overhead:
Randomizing the refresh timers to prevent all or many of the RSVP sessions from being refreshed at the
same time. This is an internal optimization and is transparent to the user.
Reliable RSVP message delivery using ACK messages.
Summarizing RSVP refresh messages to reduce overhead.
When refresh reduction is enabled, the refresh-reduction capability is negotiated between each RSVP peering interface
using Flag values inside the messages. The feature is used only if both sides can support it; otherwise, the routers ignore
the flags and Message IDs.
Module 4 Page 59
Module Summary
Module 4 |
60
Module 4 Page 60
Module 4 |
61
Module 4 Page 61
Learning Assessment
4. Where does RSVP look for find the path it uses to forward
messages?
5. Which RSVP terms describe the iLER and the eLER?
6. RSVP PATH and RESV messages flow in which directions?
7. True or False: Placing interfaces into the MPLS context
automatically enables MPLS and RSVP.
8. What hop definition combinations can an RSVP LSP path include?
Module 4 |
62
1. What are the two message types used by RSVP to establish a tunnel session?
Path Message and Resv Message
2. What label advertisement mode does RSVP-TE use?
Downstream on Demand
3. What RSVP object reduces refresh message processing by allowing the receiver to easily identify a message that
contains unchanged state information?
The message ID object reduces refresh message processing.
4. Where does RSVP look to find the path it uses to forward messages?
FIB
5. Which RSVP terms describe the iLER and the eLER?
In RSVP terminology, the iLER is the head-end router and the eLER is the tail-end router.
6. RSVP PATH and RESV messages flow in which directions?
RSVP PATH messages flow downstream, and RESV messages flow upstream.
7. True or False: Placing interfaces into the MPLS context automatically enables MPLS and RSVP.
False
8. What hop definition combinations can an RSVP LSP include?
An RSVP LSP path definition may include both loose and strict hops, or none at all.
Module 4 Page 62
9.
9.
Module 4 |
63
Module 4 Page 63
www.alcatel-lucent.com
3FL-30635-AAAA-ZZZZA Edition 01
Module 5 - Page 1
Module Objectives
Module 5 |
Module 5 - Page 2
Module 5 - Page 3
Section Objectives
Understand how these attributes are signaled via IGP (OSPF and
IS-IS TE extensions)
Discuss the operation of CSPF (Constraint-Based Shortest Path
First) algorithm.
Discuss the use of ERO (Explicit Route Object) for signaling TEbased LSP paths.
Module 5 |
This section first makes a generic introduction to MPLS Traffic Engineering concepts and methods.
Additional information that can be attributed to network links and propagated in IGP updates are presented.
The protocol extensions that have been made to both link-state protocols (OSPF and IS-IS) are shown.
The section takes a progressive approach by first presenting the high-level MPLS TE approaches and then demystifying
the real solutions in step-by-step manner.
The internal processes of the routers as to the use of the additional IGP attributes are also presented with a simplified,
cognitive approach. The modified version of the Shortest Path First (SPF) algorithm that is used for TE purposes (CSPF)
is explained in detail.
RSVP-TE takes a different approach in signaling the LSP paths calculated by CSPF than presented in Module 4. The
Explicit Route Object that ensures the CSPF calculated path messages traverse the correct desired hops is explained at
the end of the section, after the CSPF calculation procedures are understood.
Module 5 - Page 4
Module 5 |
Optimizing the network resource usage is a major concern among the operators to protect their investments and
maximize their revenues, while providing the desired level of service qualities to their customers.
To accomplish this, the operators often require certain set of tools to engineer the traffic patterns in the network to
match certain needs. If the network lacks adequate capacity planning and a flexible, future-proof design; bottlenecks
(congestion points) may easily arise resulting in packet loss and degradation in the service qualities offered to
customers.
Module 5 - Page 5
Module 5 |
As we mentioned in Module 1, MPLS can help solve hyperaggregation issues. To overcome the bottleneck, certain
solutions outside of the MPLS context may be employed, along with their shortcomings.
Placing bandwidth wherever there is a traffic requirement is called Traffic Management; this is one approach to the
hyperaggregation problem. In the network planning phase, designers must carefully assess traffic patterns to provide
proper predictions of future network usage, and the underlying transport network should reflect these pre-assessments.
However, transport circuits can be very expensive resources, and bandwidth requirements at different parts of the
network might also change over time. Therefore, network engineers must closely monitor resource requirements in the
case any expansion circuits are needed. All these factors make overall bandwidth planning a strategic task.
Another solution might be to adjust the links IGP costs to allow for load-balancing solutions, such as ECMP. The
problem with this approach, however, is that no solution can fit all possible network patterns between every source and
destination pair combinations. With the addition of new links or failure of existing ones, this solution can easily fall into
pieces.
One other technique that might be used to steer the traffic flows to desired destinations is policy-based routing. With IP
forwardings hop-by-hop nature, network designers can implement traffic control entities, called policies. At each hop,
redirecting the traffic to different hops in an attempt to equally distribute the aggregate bandwidth or to minimize
delay for time-sensitive traffic. Even in a small network, this method can quickly become unmanageable and nonscalable, requiring that the operators manually modify the policy entries each time a new demand arises. Even if the
administrator deploys special automation tools to streamline the processes, risks of configuration errors causing traffic
black-holing or loops are high.
Module 5 - Page 6
Module 5 |
When a service provider chooses MPLS along with RSVP-TE signaling, they have an abundance of Traffic Engineering
features at their disposal.
As discussed, controlling the paths of traffic flow is a difficult task using IP forwarding, because of the inherent hop-byhop nature of the protocols. RSVP-TE offers easily configured and maintained solutions by extending the capabilities of
the existing protocols and introducing new implementations around them.
Traffic engineering extensions to certain IGPs introduce enhancements to the existing routing protocols, which allow
them to carry additional link information no longer limited to IGP costs only. These extra characteristics, called link
constraints, allow the operator to automate the path determination process in a way more advanced than policy-base
routing can provide.
RSVP with Traffic Engineering, or RSVP-TE, brings a tactical Traffic Engineering approach. By allowing network
operators to reserve LSP bandwidth, for example, capacity planning can make easier traffic load distribution easier.
This approach puts the traffic where the available bandwidth is, as opposed to adding more bandwidth.
In resiliency terms, RSVP-TE allows pre-established LSP protection paths that can promptly react to network failures.
The shorter convergence times offered by these resiliency features, including secondary LSP paths and Fast Reroute
techniques, easily surpass convergence times that an IGP alone can achieve. This courses last module discusses several
TE resiliency features and MPLS protection mechanisms in great detail.
Module 5 - Page 7
Module 5 |
One RSVP-TE approach allows an administrator to specifically define the path that an LSP shall take, using RSVP-TE
strict hop path definitions.
The operator may define the entire LSP path. As an example, the operator can define the following LSP path: The LSP
shall originate on router R1, go through routers R3 and R5 and finally terminate at router R6. This manually defined
strict path may differ completely from that which the IGP might have chosen. This option gives the ultimate
administrative control in steering the traffic path.
However, this method also requires the administrator manually define all the LSP hops. In a large network with a many
LSPs, using all strict hop paths can impose a high burden on the operational personnel. Any changes, additions and
deletions require manual intervention.
A strict hop LSP path configuration is a fixed definition, requiring the LSP to go over an exact set of hops. If one of the
defined links or nodes becomes unavailable, the LSP cannot forward traffic. RSVP-TE resiliency techniques, presented in
Module 6, However, can overcome this limitation.
Module 5 - Page 8
Module 5 |
Rather than administratively defining the entire LSP path, an administrator can control an LSPs path by defining and
assigning a constraint to the LSP. Constraint-based forwarding automates the path definition processes and simplifies
administrative tasks. Well-defined algorithms are embedded into computers or machines to perform mundane,
repetitive tasks, and can support constraint-based forwarding paths.
For instance, the standard Shortest Path First (SPF) algorithm uses a constraint when calculating the routes in a network
the links cost. The cost is usually a function of the links bandwidth, and in general, the higher the links bandwidth,
the lower the cost. The routers choose the lowest cost link from themselves to the destination network as the best
path.
Using the link bandwidth as a sole path calculation constraint limits your options, however. Accordingly, network
operators may want the routers to consider other characteristics when choosing the best forwarding path, such as
bandwidth availability or path delay characteristics. Administratively defined constraints allow the network designer to
categorize certain links by these additional constraints to better streamline the path selection process.
Available constraints include those listed here:
Bandwidth reservations specifying a certain bandwidth amount the LSP requires on a specified path
Administrative groups also known as link coloring, specifying links that we either do or do not want the LSP to use
Hop limits limiting the number of hops over which the LSP path can transport traffic from head end to tail end
Explicit hops specifying either strict (have to go there directly) or loose (have to go there eventually) hops as part
of the path definition
Shared Risk Link Groups (SRLG) telling the head end to exclude from a backup path any links already used by the
primary path
Though not all inclusive, this list demonstrates the network design options that RSVP-TE offers the network operator.
The rest of this section discusses techniques that facilitate the advanced path determination process at the Head-End of
the LSP traffic. This source-based forwarding concept is completely opposite of IP forwarding, which totally revolves
around the idea of destination-based routing.
Module 5 - Page 9
Module 5 |
10
Using RSVP-TE, an operator may set LSP bandwidth reservations as a constraint with which it can control traffic flow in
the network. The operator manually assigns to the LSP a predicted, fixed bandwidth requirement, and the network
operator must first determine the value. This value may be based on a customers Service Level Agreement (SLA), or
based on predicted maximum, or average bandwidth use.
The LSP Head-End uses a links unreserved bandwidth amount to determine if that link is a possible candidate to
support the LSP. The head end eliminates the links which do not match the constraint from consideration, choosing the
best path from those left. From those remaining links, the head end signals the LSP over the IGPs chosen best of the
remaining paths to the destination.
Module 5 - Page 10
Module 5 |
11
At this point, the RSVP-TE bandwidth reservation is purely a control plane mechanism. That is, when the Head-End finds
an available LSP path and requests bandwidth on that path, the router control plane tentatively reserves the
bandwidth.
This reservation only applies to the initial LSP setup and does not consider potential congestion in the data plane. If an
available path is found with a sufficient amount of unreserved bandwidth, the LSP is established over those links;
however, the routers do not enforce the bandwidth reservation constraint on the data plane, where packet processing is
performed. Hence, possible congestion scenarios might arise where an LSP forwards more traffic than they reserved on
a link.
To address this concern, the Alcatel-Lucent Service Routers support granular and highly scalable Quality of Service
(QoS) policies that can be applied at every congestion point in the network. On a packet level, the routers prioritize
traffic and service it in different hardware queues to attain different service quality levels, which are applied on the
routers data plane.
Best network design practices dictate that the operator use congruent QoS and Bandwidth reservation policies for
better network resource usage predictability.
Module 5 - Page 11
Module 5 |
12
In this slide, an operator is setting up an LSP on router R1, targeting router R6. The operator wants to reserve 600 Mbps
of bandwidth for the LSP.
Using RSVP-TE, router R1 automatically searches for a network path that satisfies the required bandwidth constraint.
As we see, LSP1 has already reserved 600 Mbps of bandwidth on the networks upper links. On these links, only 400 Mbps
is left to be reserved. LSP2 needs more that 400 Mbps.
Thus, router R1 eliminates from consideration the top links and discovers that the lower links have sufficient unreserved
bandwidth to support the LSP. Router R1 then signals an LSP path traversing those links.
The unreserved bandwidth figures in the diagram are those that exist before router R1 establishes LSP2. Once LSP2
becomes operational, the network routers advertise the remaining link bandwidths.
Module 5 - Page 12
Module 5 |
13
RSVP-TE allows an operator to combine links that share similar characteristics into administrative groups. Admin groups
can be defined based on any physical or logical constraint that reflect the characteristics of the links.
An example is a network composed of all 1Gbps transmission links. From an IGP perspective, the cost values of these
links are typically the same. In other words, from the standard SPF algorithm perspective, they are all of equal value.
However, some of these links might be satellite links with variable delay characteristics. The operator would prefer that
delay sensitive traffic, such as voice, follow an LSP path that avoided these links. If the operator increased the links
IGP cost, all traffic would go around these links, including time-insensitive traffic which could be transmitted over the
satellite links without notable service degradation.
If the satellite links in this example are made members of the same administrative group, the operator can set a
generic path statement that directs the routers to look for a suitable path excluding the links in that administrative
group.
Administrative groups are also called link colors to provide an intuitive way with which to work with them. Links can be
associate with different colors and later be referred to as green links, blue links, and so on. The routers can then
be configured to include or exclude those links in calculating the LSP paths.
While providing great flexibility, administrative group definitions have to be carefully designed and incorporated in the
network. Errors in the group definitions might result in situations where the Head-End cannot successfully signal certain
LSPs because the router is unable to find a suitable constrained path for them.
Module 5 - Page 13
Module 5 |
14
An operator might wish to impose a limit on the number of routers an LSP path can traverse. For example, they may
want to limit the total delay experienced by applications handling time-critical (real-time) traffic.
In the figure above, the upper path R1-R2-R4-R6 has an overall IGP cost of 300.
If a hop-limit of 3 is imposed on the LSP that is being established on router R1, router R1 will not consider this upper
path because it involves 4 hops, including the originating (source) router.
The only remaining possible path then is the lower path, consisting of 3 hops.
Despite its high IGP cost, router R1 chooses this path as matching the constraints set on the LSP path, and uses it to
forward the LSPs traffic.
Module 5 - Page 14
Hop-Limit
Module 5 |
15
The IGP metric usually represents link bandwidth. Though this metric is useful in many cases, an operator might want to
use separate traffic-engineering metric values on specific links.
Following a similar example as on the previous page, the upper path R1-R2-R4-R6 consists of links with low IGP cost
values (higher physical bandwidth). The total upper path IGP cost is 300, which is much better than the lower path cost
of 2000. Therefore, under normal circumstances, all traffic tends to flow through the upper links.
However, some of the links in the upper portion of the topology might be satellite links with statistically higher delay
and jitter (delay variation) characteristics. To reflect these delay properties, the network administrator may assign to
these links a custom, separate Traffic Engineering (TE) metric that is higher than the other links IGP metrics.
Router R1 takes these TE metric values into account when calculating an LSP path planned to support real-time traffic
applications. While all other traffic types follow the upper path, the real-time traffic follows the lower path based upon
the lower TE metric.
Module 5 - Page 15
TE-Metric
Module 5 |
16
Shared Risk Link Group (SRLG) is a concept similar to administrative groups presented earlier. Again we create groups
and assign links to those groups, but here we are controlling how the head end builds backup LSP paths. SRLG is
particularly useful in providing the maximum level link redundancy when using either one of, or both of the secondary
path or Fast Reroute LSP protection mechanisms.
SRLG works as follows:
1. Router R1 establishes a primary LSP path that will carry the LSP traffic as long as it is operational. The primary
LSP path might travel down links the router choose based on administrative constraints such as bandwidth or hoplimit; however, the primary path does not consider the SRLG constraint.
2. Router R1 then analyzes the primary LSP path. The router checks the primary LSP path to see if any links are a
member of any Shared Risk Link Groups assigned to them beforehand. In the example above, the primary LSP path
links are members of the SRLG-1 group.
3. When calculating a secondary LSP path or a Fast-Reroute protection tunnel path; the routers try to find a path
that does not go over any of the links that are a member of SRLG-1.
This allows the protection tunnel paths to be automatically disjointed from the primary LSP path. If one of the links on
the primary LSP path fails, there could be a possibility that other links in the same SRLG might fail as well, possibly due
to the underlying transmission media characteristics. SRLGs ensure that the secondary or FRR protection tunnels follow
a different path than the primary so that the LSP finds a viable path over which to forward its traffic.
Module 6 introduces secondary and fast reroute protection, where the use and application of Shared Risk Link Groups
are also explained.
Module 5 - Page 16
Module 5 |
17
Additional administrative constraints can be configured locally on each router in the network.
When the network administrator wishes the traffic engineering application on any router to calculate a path using any
of the constraints, it is an obvious requirement that the router already has the relevant information readily available in
its possession. If, for instance, the link between R4-R6 is made a member of administrative group GREEN by means of
local configuration on router R4, this information must be propagated to the rest of the network, including router R1.
It is also strictly required that this information be up-to-date, because constraints might be added or deleted on the
links on any router at any time. As a result, a dynamic, quick-adapting mechanism is needed. This is most conveniently
achieved via the use of a dynamic protocol.
After the Traffic Engineering related information is distributed in the network, another requirement is to allow for an
algorithm that takes into account also the additional constraints specified by the administrator. The standard SPF
(Shortest Path First) algorithm uses only the IGP metric values to make path calculations; therefore, an enhancement is
needed to suit the Traffic Engineering requirements.
The implemented solutions are presented on the following pages.
Module 5 - Page 17
Module 5 |
18
Traffic Engineering requires that information regarding the additional link attributes be known everywhere in the
network. When an administrative constraint is defined on a link attached to a certain router, this new information must
be immediately propagated to all the other routers. Similarly, if an attribute is deleted from a certain link; an update
must be triggered right away to keep the TE information up-to-date and synchronized throughout the network.
The event-triggered nature of these requirements imply a link-state routing protocol. Distance Vector Protocols such as
RIP (Routing Information Protocol) are not suitable, since these protocols provide knowledge about only the directly
connected neighbors, and not the whole topology.
However, the traditional link-state implementations have been designed to carry only the link IGP metric information.
To facilitate MPLS Traffic Engineering, developers defined extensions to the two link-state protocols OSPF and IS-IS
which are used widely in service provider networks today. Similar functionality is offered by both protocols in Traffic
Engineering terms. Alcatel-Lucent Service Routers fully support Traffic Engineering extensions to both OSPF and IS-IS.
To enable traffic engineering support, one simply enables the feature in the routing protocol, configure router ospf
traffic-engineering or configure router isis traffic-engineering. Details regarding TE configuration are covered in
Section 2 of this module.
Module 5 - Page 18
The exact use of the Opaque LSAs is not defined in the RFC.
Module 5 |
19
IETF (Internet Engineering Task Force) defined the general guidelines concerning enhancements in the OSPF protocol in
RFC 2370 (later made obsolete by RFC 5250).
RFC 2370 defines 3 different Opaque LSA (Link State Advertisement) types 9, 10, and 11. Opaque LSAs provide a
generalized mechanism to allow for the future OSPF extensibility. All three Opaque LSA types consist of a standard LSA
header followed by application-specific information.
Opaque LSAs may be used directly by OSPF or indirectly by an application in order to distribute information throughout
the OSPF domain.
RFC 2370 does not define the exact use for Opaque LSAs, and MPLS-TE is simply one implementation. The Opaque LSA
itself defines the container used to transport the information, not the information itself.
Module 5 - Page 19
Type 10 LSA is flooded to all the routers within the same area.
Type 10 LSA (Area Opaque) is used for MPLS Traffic Engineering.
Many IGP deployments use a single area due to MPLS Traffic
Engineering requirements.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
20
MPLS-TE only uses type 10 opaque LSAs. The other two types, types 9 and 11, have other applications and are not
pertinent to this discussion. Each opaque LSA type transports information within a certain portion of the routing
domain, and routers flood type 10 opaque LSAs only within the OSPF area in which they originate; Area Border Routers
(ABRs) and Autonomous System Boundary Routers (ASBRs) do not forward these LSAs between areas.
In standard MPLS Traffic Engineering applications, type 10 opaque LSAs distribute the additional link constraint
information. IGP domains are mostly implemented as a single backbone area to facilitate a straightforward
implementation of Traffic Engineering, though techniques do exist to extend TE capabilities beyond area boundaries.
We discuss LDP over RSVP later in this module.
Module 5 - Page 20
Module 5 |
21
When opaque capable routers and non-opaque capable OSPF routers are mixed together in a routing domain, the
Opaque LSAs are not flooded to the non-opaque capable routers. As a general design principle, optional OSPF Link State
advertisements are only flooded to those routers that understand them. Note that the Alcatel-Lucent Service Routers
are opaque capable by default.
An opaque capable router learns of its neighbor's opaque capability at the beginning of the "Database Exchange
Process", receiving Database Description packets from a neighbor in the ExStart state.
A neighbor advertises that it is opaque capable by setting the O-bit in Database Description packets Options field; no
other packet type sets the O-bit.
Then, in the next step of the Database Exchange process, Opaque LSAs are included in the Database summary list that is
sent to the neighbor if and only if the neighbor is opaque capable. When flooding Opaque LSAs to adjacent neighbors, a
opaque capable router looks at the neighbor's opaque capability.
Opaque LSAs are only placed on the Link State retransmission lists of opaque-capable neighbors. However, when sending
Link State Update packets as multicasts, a non-opaque-capable neighbor may (inadvertently) receive Opaque LSAs. The
non-opaque capable router will then simply discard the LSA, having received LSAs containing unknown Link State types.
In the OSPF TE implementation, the router stores opaque LSAs in a dedicated database called the TED (Traffic
Engineering Database).
Module 5 - Page 21
IGP Link State Database (LSDB) still exists after enabling TE.
LSDB and TED are separate from each other.
Additional link attributes are only present in TED.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
22
An opaque-capable router maintains a specialized database called the Traffic Engineering Database (TED). The TED
contains the network link attributes and topology information needed by the router so that it can compute Traffic
Engineered paths independent of the IGP topology database, and therefore the IP routed topology.
TED contains the topological constraints learned via OSPF Opaque LSAs or IS-IS TLVs.
Topology Link State information learned from the IGP, via flooding within the area
Attributes associated with the state of network resources carried by Link State IGP extensions
Administrative policy requirements, obtained from user configuration, may be used as additional constraints when
calculating a constraint based route.
Module 5 - Page 22
IGP LSDB might contain various LSA types (Types 1-7) that describe
all the links that are OSPF enabled (plus external prefixes
redistributed via policy).
TED contains only Type 10 Opaque LSAs that describe the RSVPenabled interfaces.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
23
When OSPF-TE is enabled, the router builds the TED from all the stored LSAs and the local links running OSPF. The
OSPF-TE TED has a different view of the network topology from the regular IGP Link State Database (LSDB). The TED
contains additional administrative constraint information that can be used to perform more sophisticated path
calculations. The TED and the Link State Database (LSDB) are decoupled and have no correlation with each other.
Since the function of the OSPF-TE TED is to make advanced MPLS LSP Path calculations, OSPF routers do not generate
Opaque LSAs for OSPF interfaces that on which the operator has not enabled RSVP.
Another major difference between TED and the LSDB is that the TED only contains information received from Type 10
LSAs. The LSDB might contain external prefixes advertised by the ASBR into the OSPF AS, called type 4,5 and 7 LSAs.
The LSDB might also contain prefixes from other OSPF areas generated by the ABRs (Area Border Routers). For a
network that contains broadcast link segments, Type 2 LSAs are generated by Designated Routers on each broadcast
segment. For a more detailed discussion of the LSA Types and their uses, refer to the SRC AIRP (Interior Routing
Protocols) course.
Module 5 - Page 23
Module 5 |
24
The Opaque LSA starts with the standard LSA header. The LSA payload consists of one or more nested TLV triplets for
extensibility.
The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length
of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value
would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned.
Unrecognized types are ignored. Only Types 1 and 2 are used.
Module 5 - Page 24
Module 5 |
25
An LSA contains one top-level TLV. The two values define two sub-types of the Type 10 LSA:
Router Address Type 1
The Router Address TLV specifies a stable IP address of the advertising router that is always reachable.
It is typically implemented as a loopback address.
On the Alcatel-Lucent Service Routers, it is by default derived from the System IP address assigned to the router.
As soon as you enable traffic-engineering on the router, it advertises its RID with a Router Address TLV.
Link Type 2
The Link TLV describes a single link.
Only one Link TLV is carried in each LSA.
It is a variable length set of unordered sub-TLVs.
Routers only send link TLVs for those interfaces on which RSVP is enabled.
Module 5 - Page 25
y Link TLV
Module 5 |
26
2.
Link ID (4 octets)
3.
4.
5.
6.
7.
8.
9.
Module 5 - Page 26
A:R4>config>router>ospf#
-------------------------------area 0.0.0.0
interface toR6
interface-type point-to-point
exit
y
y
Link Type : 1
Link ID: 10.10.10.6
Local Interface IP Address: 10.4.6.4
Remote Interface IP Address: 10.4.6.6
TE Metric: 100
(point-to-point)
(Router ID of neighbor)
27
The Link Type sub-TLV type 1 defines the type of the link:
Point-to-point (1)
Multi-access (broadcast) (2)
For a link segment that only two routers reside on either end, point-to-point type should be configured and used. The
default interface-type is broadcast, whereby the initial adjacency establishment takes longer as a result of a mandatory
Designated Router (DR) election, which takes around 40 seconds. DR election is not required on a point-to-point
interface, speeding up the initial convergence times.
The Link ID sub-TLV type 2 identifies the other end of the link. For point-to-point links, this is the Router ID of the
neighbor. For multi-access links, this is the interface address of the designated router. The Link ID is identical to the
contents of the Link ID field in the Router LSA for these link types.
The Local Interface IP Address sub-TLV type 3 specifies the IP address(es) of the interface corresponding to this link. If
there are multiple local addresses on the link, they are all listed in this sub-TLV.
The Remote Interface IP Address sub-TLV type 4 specifies the IP address(es) of the neighbor's interface corresponding to
this link. This and the local address are used to discern multiple parallel links between systems. If the Link Type of the
link is Multi-access, the Remote Interface IP Address is set to 0.0.0.0.
The Traffic Engineering metric sub-TLV type 5 specifies the link metric for Traffic Engineering purposes. This metric
may be different than the standard OSPF link metric. On the Alcatel-Lucent Service Routers, the TE metric is set equal
to the standard IGP metric of the link by default. It is possible to override this setting via explicit configuration, which
is described in Section 2.
Module 5 - Page 27
Module 5 |
28
The Maximum Bandwidth sub-TLV type 6 specifies the maximum bandwidth that can be used on this link, in this
direction (from the system originating the LSA to its neighbor), in IEEE floating point format. This is the true link
capacity. The units are bits per second.
The Maximum Bandwidth sub-TLV is four octets in length. The units carried inside the Opaque LSAs are bytes per
second. The SR OS CLI represents bandwidth in kilobits per second.
Module 5 - Page 28
Module 5 |
29
The Maximum Reservable Bandwidth sub-TLV type 7 specifies the maximum bandwidth that may be reserved on a given
link, in the egress direction (the same direction as the LSP is being established). The values for this TLV is configured as
a percentage of the Maximum Bandwidth.
Note that this value may exceed the maximum bandwidth, enabling link oversubscription, or smaller than the maximum
bandwidth, thus under-subscribing the link. The default value is 100 (%), which means that it is equal to the Maximum
Bandwidth presented in the previous page.
The units carried in the Opaque LSA updates are expressed in bytes per second.
The Maximum Reservable Bandwidth sub-TLV is four octets in length.
Module 5 - Page 29
Module 5 |
30
The example above demonstrates the different configuration options for the Maximum Reservable Bandwidth:
1. Subscription set to 100 in CLI (default): The Maximum Reservable Bandwidth by RSVP-TE LSPs is equal to the
Maximum Bandwidth (true link capacity).
2. Subscription set to a value higher than 100: An over-booking factor is introduced to allow the RSVP-TE LSPs
reserve more bandwidth than the true link capacity. This is a typical implementation where the administrator
wishes to make use of Statistical Multiplexing Gain, where the assumption is that the real bandwidth utilization of
the links exceeding the real capacity is a negligible probability.
3. Subscription set to a value higher than 100: The Maximum Reservable Bandwidth by RSVP-TE LSPs is lower than the
true link capacity. This can also be referred to as under-booking, which can be used in cases where the bandwidth
reservations are supposed to use only a small portion of the real link bandwidth.
Module 5 - Page 30
Module 5 |
31
The Unreserved Bandwidth sub-TLV type 8 specifies the amount of bandwidth not yet reserved at each of the eight
priority levels in IEEE floating point format. The values correspond to the bandwidth that can be reserved with a setup
priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub- TLV, and priority 7
at the end of the sub-TLV. The initial values (before any bandwidth is reserved) are all set to the Maximum Reservable
Bandwidth. Each value will be less than or equal to the Maximum Reservable Bandwidth. The units are bytes per second.
The Unreserved Bandwidth sub-TLV is 32 octets in length.
LSP priorities are explained in Section 3, under the title LSP Soft Preemption.
Module 5 - Page 31
Module 5 |
32
The Unreserved Bandwidth value is a dynamic value that is updated each time an LSP reserves or releases bandwidth on
a link. The example above demonstrates three different scenarios illustrating the use of this TLV. The example assumes
a single priority level (default) for the sake of simplicity.
1. In the initial condition, in which no LSP is established on the link, the Unreserved Bandwidth is equal to the
Maximum Reservable Bandwidth defined for the link. No custom subscription value is defined, so this value equals
to 1 Gbps.
2. An LSP is established with 600 Mbps of bandwidth reserved. The Unreserved Bandwidth value on the link is
immediately updated and reduced to 400 Mbps. The new value is also propagated to other OSPF routers by means
of an Opaque LSA inside the Unreserved Bandwidth Sub-TLV.
3. The operator shuts down the LSP which is no longer deemed necessary, or removes its bandwidth reservation in
the configuration. As the LSP is being cleared (with a PATH Tear or RESV Tear messages), its bandwidth
reservation is also removed from the interface. The unreserved bandwidth value is again 1 Gbps. The OSPF
neighbors are informed of the new situation via another Opaque LSA advertisement.
Module 5 - Page 32
Module 5 |
33
The Administrative Group sub-TLV type 9 contains a 4-octet bit mask assigned by the network administrator. Each set
bit corresponds to one administrative group assigned to the interface. A link may belong to multiple groups. By
convention, the least significant bit is referred to as Group 0, and the most significant bit is referred to as Group 31.
The Administrative Group is also called Resource Class/Color.
Module 5 - Page 33
Module 5 |
34
The example above illustrates the membership assignment of an interface to an administrative group.
The Alcatel-Lucent Service Routers provide an intuitive way in working with administrative groups as opposed to some
other vendor implementations. Network designers can define administrative group names and associate them with
globally unique group numbers that can vary between 0-31. A common convention is to use color names for
administrative groups, which allow for a user-friendly method of configuring and perceiving them. In principle, any
arbitrary names can be defined. The choice of administrative group numbers is also completely arbitrary.
In the example above, an administrative group called GREEN is defined by the administrator and associated with a value
of 4 in CLI.
The interface toR6 is then assigned to this administrative group GREEN. In the consecutive Opaque LSAs advertised to
other OSPF routers, the administrative group Sub-TLV which consists of 4 octets (32 bits) is updated accordingly.
According to the implementation, the bit position corresponding to the CLI configured value is set to 1 in this Sub-TLV.
In this example, the 4th bit position is set as seen in the figure above. This is also referred to as a bitmap
representation.
In the TED CLI output which is actually presented later in the section, the Sub-TLV is expressed both in hexadecimal and
decimal format.
Module 5 - Page 34
The 4th and 10th bit positions are set in the Admin Group Sub TLV.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
35
On TE enabled router, an interface can be made a member of multiple administrative groups, if necessitated by the
network design. The above example is used to illustrate this concept.
An additional administrative group is defined with name BROWN and a group value of 10. The interface toR6 is made a
member of this new administrative group, together with the previous group, GREEN. The 10th bit position in the Sub-TLV
in the Opaque LSA pertaining to the link to reflect this change.
Module 5 - Page 35
Opaque LSAs are flooded through the area and the Traffic
Engineering Databases are populated.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
36
Opaque LSAs are stored in each routers individual and self-contained Traffic Engineering Databases (TEDs).
Routers propagate the Opaque LSAs to each TE capable OSPF neighbor. The received Opaque LSAs on a certain router
are checked against the existing TED and the TED is updated as necessary. As a result of this flooding mechanism, all
routers attain a common view of the topology from a Traffic Engineering perspective.
Module 5 - Page 36
Module 5 |
37
There are various reasons why Opaque LSAs might be advertised and flooded within the network, which include:
Changes in the link status (a link that goes operationally down or up).
Administrative changes in the link configuration. If attributes, such as administrative groups, Shared Risk Link
Groups (SRLG), and TE metric, are included or removed under the interface, an Opaque LSA is advertised
immediately to inform the other routers.
An LSP reserving or releasing a certain amount of bandwidth reserved on the link. By default, Opaque LSA updates
are immediately triggered in these cases. An optimization technique used to augment this behavior is introduced in
Section 3 under the title RSVP-TE Bandwidth Update Trigger.
Link State Updates are, by definition, event triggered. However, LSAs are also refreshed periodically to prevent
them from aging out. An individual age timer is defined for each LSA entry on every router. For OSPF, the initial
age timer is 0 and is incremented every second until 3600 seconds (the maximum age timer) elapse. If the router
receives no further update for this LSA within this time, the router removes the LSA from the database and the
prefix is deemed unreachable. The maximum age timer in OSPF is not configurable. The periodic refresh time is
around half of the maximum age timer in OSPF. In the IS-IS implementation, the maximum age timer is configurable
and is set to 1200 seconds by default. The refresh timer is equal to half of the maximum age timer.
Module 5 - Page 37
Module 5 |
38
The show router ospf opaque-database command displays the list of Opaque LSAs generated and received by the
router. The advertising router ID field indicates the source router that generated the LSA.
The output above is taken on router R1 with a router ID of 10.10.10.1. Not all the Opaque LSAs are shown in the figure
above, for the sake of clarity.
Module 5 - Page 38
0.0.0.0
1.0.0.1
10.10.10.4
Area
0.0.0.0
1.0.0.2
10.10.10.4
Area
0.0.0.0
1.0.0.3
10.10.10.4
Area 0.0.0.0
1.0.0.4
10.10.10.4
------------------------------------------------------------No. of Opaque LSAs: 4
Module 5 |
(Router ID of R4)
(Interface toR2)
(Interface toR6)
(Interface toR5)
39
A useful way of examining the TED in a large network is through filtering the Opaque-Database output by specifying the
advertising router ID of the router under inspection.
In the example above, router R4 has a router ID of 10.10.10.4, which is derived by default from its system IP address
(10.10.10.4/32). The Opaque Database (TED) output indicates that 4 Opaque LSAs are advertised by router R4 in total.
The Link State ID field is used to distinguish between the different LSAs advertised by a router. In the Traffic
Engineering implementation, Opaque LSAs are given Link ID numbers starting from 1.0.0.1, where the last octet is
incremented for each additional Opaque LSA generated by the router.
Router R4 has 3 OSPF and RSVP enabled interfaces and it has generated three separate Opaque LSAs for each of these
interfaces.
Please note that this command output contains only the LSAs header information. The actual information the LSA
carries may be observed by adding the detail keyword, illustrated on the following pages.
Module 5 - Page 39
===============================================================================
OSPF Opaque Link State Database (Type : All) (Detailed)
===============================================================================
------------------------------------------------------------------------------Opaque LSA
------------------------------------------------------------------------------Area Id
: 0.0.0.0
Adv Router Id
: 10.10.10.4
Link State Id
: 1.0.0.1
LSA Type
: Area Opaque
Sequence No
: 0x80000002
Checksum
: 0x1ced
Age
: 107
Length
: 28
Options
: E
Advertisement
:
ROUTER-ID TLV (0001) Len
4 : 10.10.10.4
Module 5 |
40
The Router Address TLV specifies a stable IP address of the advertising router that is always reachable if there is any
connectivity to it; this is typically implemented as a loopback address. The key attribute is that the address does not
become unusable if an interface is down.
In the Alcatel-Lucent Service Router implementation, the router ID value is by default derived from the explicit System
IP address configuration. For TE purposes, an explicitly defined Router ID should be the same as the System interface
address.
Utmost care must be taken to have unique System IP addresses and in turn, unique router IDs all over the network, to
ensure proper IGP and Traffic Engineering operation.
Module 5 - Page 40
Module 5 |
41
Continuation of the command on the previous page reveals more Opaque LSA information generated by router R4.
One of the three Opaque LSAs generated for each network interface is shown in the figure above.
The 9 Sub-TLV types have been previously introduced in this section. Under the Sub-TLV 8 (Unreserved Bandwidth)
section, the 8 possible priority values can be observed with their respective bandwidth reservation information. As
mentioned earlier, by default all LSPs reserve bandwidth at a single common level (Level 0), which results in the same
unreserved bandwidth values to be seen for all priority levels. The priority values are used in conjunction with the LSP
Soft Preemption feature, explained in Section 3.
The Admin-Group Sub-TLV indicates the hexadecimal and decimal values corresponding to the only administrative group
defined for the interface, GREEN.
Module 5 - Page 41
ISIS-TE Extensions
Module 5 |
42
IS-IS as a link-state routing protocol is defined in RFC 1195. Traffic Engineering enhancements that apply to a single
area IS-IS network is defined in RFC 3784.
A 4-octet router ID is advertised for an IS-IS router that provides a unique and stable address that is always reachable by
Traffic Engineering applications. The router ID is derived from the System IP address by default, as in the case of OSPF.
An Extended IP reachability TLV is defined by the RFC, although this is not specifically used for TE applications and is
mentioned here for the sake of completeness.
The new extended IS reachability/neighbors TLV (type 22) contains a new data structure, consisting of:
7 octets of system ID and pseudonode number
3 octets of default metric
1 octet of length of sub-TLVs
0-244 octets of sub-TLVs,
where each sub-TLV consists of a sequence of
1 octet of sub-type
1 octet of length of the value field of the sub-TLV
0-242 octets of value
An additional TLV is defined for SRLG memberships and is optional. Inclusion of this TLV depends on whether an SRLG
configuration exists on the interface or not.
Module 5 - Page 42
Name
10
11
32
Unreserved bandwidth
18
TE Default metric
250-254
255
Module 5 |
43
The IS-IS TE Sub-TLVs exist inside TLVs. TLVs are used to add extra information to IS-IS packets. The table above
summarizes the IS-IS TLVs used in TE implementations.
The implementation and use of the IS-IS Sub-TLVs is similar to the OSPF TE extensions covered earlier in the module;
the discussions are not repeated here.
Module 5 - Page 43
Sub-TLV type
Module 5 |
44
Alcatel-Lucent Service Routers have inherent support for IS-IS Traffic Engineering, as well as OSPF-TE.
Similar to OSPF, enabling the IS-IS TE extensions an a Service Router requires an explicit configuration as displayed
above.
When IS-IS TE is enabled, the Traffic Engineering information is disseminated in the extended TLVs described in the
previous page. The TLVs are included in the same Link State PDU control packets together with the standard IGP TLVs.
This behavior is different than OSPF, where the TE information is carried within separate LSAs called Opaque, or Type
10 LSAs.
As a consequence, the TE related information is stored in the same database with the standard IS-IS routing
information. The Traffic Engineering TLVs can be displayed in the show router isis database [level 1/2]
detail command output. The level number (1 and/or 2) depends on the specific area hierarchy of the IS-IS IGP
network. An IS-IS interface might exist on either one of, or both of the hierarchy levels.
When compared to OSPF, IS-IS offers similar functionality, in terms of Traffic Engineering.
Module 5 - Page 44
Standard Shortest Path First (SPF) algorithm uses only the link costs.
An enhanced algorithm is needed to take into account the
administratively defined constraints when making path calculations.
Constraint-Based Shortest Path First (CSPF) is the solution.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
45
After the Traffic Engineering related information is acquired via the flooding of Opaque LSAs or TE TLVs, the router
must decide how to calculate a path for the LSP to router R6 with the additional specified administrative constraints.
The regular SPF algorithm comes up short because it only takes into account the metric (cost) values assigned to the
links. This is the limiting factor of standard IGP implementations, leading to issues such as hyperaggregation, as
presented earlier.
At this point, a more sophisticated mechanism is required; it must have the ability to work with additional constraints
that can be fed as parameters into the execution of the path calculation algorithm. This has been achieved by
modifying the standard SPF algorithm to meet the Traffic Engineering demands. The enhanced version of the algorithm
is called CSPF (Constraint-Based Shortest Path First) and is introduced in greater detail in the following pages.
Module 5 - Page 45
Module 5 |
46
The CSPF algorithm is used to make path calculations that take additional administrative constraints, such as link
colors, bandwidth, and TE metric, into account.
The use of CSPF for an LSP is optional, and is up to the discretion of the network administrator. CSPF is disabled by
default for each LSP that is created in configuration.
The high-level overview of CSPF operation is rather simple and straightforward. CSPF works on the Traffic Engineering
Database and tries to calculate a path that satisfies the additional administrative constraints explicitly specified in the
LSP configuration.
To accomplish this, CSPF first prunes (disregards) the links that do not meet the administratively defined constraints.
This creates a temporary view of the topology excluding the non-conforming links.
The head end router uses a regular SPF calculation on the CSPF results to determine the hops that the LSP path will
traverse. Then, RSVP signals the end-to-end forwarding path for the LSP.
The above processes are illustrated by some examples in the following pages.
Module 5 - Page 46
Module 5 |
47
In the above example, the links contain additional attributes that have been propagated throughout the network and
are present in the TED of every router. The router R4 link to router R6 is assigned to administrative group GREEN, as is
the router R3 to router R5 link. The unreserved bandwidth values only represent administrative constraints, and do not
reflect the actual data plane utilization figures.
The administrator configures an LSP on router R1 that targets the tail end router R6, and tells router R1 to find a path
that avoids or excludes any GREEN links in the network. Without the availability of the Traffic Engineering Database and
the use of CSPF, the path calculation would be based solely on the IGP link costs, which would yield the same path
definition for each repetitive case under stable conditions.
With the TE related information at hand, and CSPF enabled on the LSP, router R1 is capable of making path calculations
that can override the standard IGP decisions.
Module 5 - Page 47
SPF Run:
Candidate Path #1: R1-R2-R4-R5-R6 (IGP Cost = 400)
Candidate Path #2: R1-R3-R2-R4-R5-R6 (IGP Cost = 500)
Resulting Path: R1-R2-R4-R5-R6
Module 5 |
48
As mentioned, the first step in the execution of the CSPF algorithm is to prune the links that do not meet the
administrative constraints. The figure above illustrates this concept. Router R1 has a view over the entire network
topology, with the GREEN links pruned from the picture.
The next step is to run a regular SPF calculation in the resulting topology to determine the hops that the LSP path will
traverse. Again from a high-level perspective, there are two alternative path definitions to reach router R6 from router
R1. Following the regular SPF rules, router R1 chooses the path with the lowest cumulative IGP cost.
Module 5 - Page 48
Module 5 |
49
The example in this figure demonstrates the use of multiple constraints within the same LSP configuration.
For a link to be eligible in the TE path calculation, it must satisfy all the constraints specified by the administrator.
That is, a link has to be NON-GREEN, and must have 600 Mbps of unreserved bandwidth, to be taken into consideration
by the CSPF algorithm.
In the example above, links R4-R6 and R3-R5 are eliminated because they are both members of administrative group
GREEN. The link R1-R2 is also eliminated because it only has 400 Mbps of unreserved bandwidth.
Module 5 - Page 49
SPF Run:
Candidate Path #1: R1-R3-R2-R4-R5-R6 (IGP Cost = 500)
Resulting Path: R1-R3-R2-R4-R5-R6
Module 5 |
50
The topology after the administrative constraints are executed is illustrated in the figure above. This is an intuitive way
of showing how the CSPF process visualizes the network topology with the specified constraints.
In this example, the pruning of the links that do not conform to the constraints yields to a single path possibility, the
consecutive hop list: R1-R3-R2-R4-R5-R6.
Recall that CSPF is only responsible for making calculations on a router. The signaling of the LSP path is handled by
RSVP, and is explained in the following pages.
Module 5 - Page 50
Module 5 |
51
Signaling of an IGP based RSVP-TE LSP was explained in Module 4. If the path definition does not contain any specific
hops and/or CSPF is disabled, the LSP path follows the normal IGP best path. That is, the RSVP PATH message is
forwarded using the IGP forwarding decisions.
When specific constraints are defined for the LSP, CSPF can calculate a path that is different from the IGP based path.
A method needs to be introduced to ensure that the RSVP PATH message goes through the exact hops calculated by
CSPF, and the LSP gets signaled over those hops. This solution is explained in the next page.
Module 5 - Page 51
Internet Protocol:
Source: 10.10.10.1
Dest. : 10.10.10.6
Options: Router Alert
RSVP PATH Message:
<SESSION>
<SENDER TEMPLATE>
<HOP>
<EXPLICIT ROUTE>
............
Module 5 |
52
The hop information calculated by CSPF is included in the Explicit Route Object (ERO) field of the RSVP PATH message
generated by the Head-End router. Upon receipt of the PATH message, the consecutive hops are obliged to inspect the
ERO to determine the next-hop for the LSP path.
The Explicit Route Object field is modified at each hop, so that a receiving router sees an IP address of its own at the
top of the hop list.
Module 5 - Page 52
Module 5 |
53
In this example, CSPF has calculated a path for the LSP that consists of nodes R1-R3-R5-R6.
The ERO sent from the Head-End (router R1) consists of 3 hops. The first entry is the interface IP address of the nexthop router, which is router R3. When router R3 receives the PATH message, it first verifies that the top entry is a valid
IP address of its own. Router R3 then checks the destination IP address, which belongs to another downstream router.
To determine the next-hop for this address, router R3 does NOT consult the IGP forwarding example, as in the example
presented in Module 4. Since an ERO is present, it must be used.
Router R3 determines the next-hop by checking the next entry in the hop list, 10.3.5.5. It removes the top entry,
10.1.3.3, and forwards the PATH message to router R5.
A similar process occurs on router R5, which forwards the PATH message on to router R6.
Router R6 verifies the remaining ERO entry and determines that it is this LSPs final destination. Router R6 sends an
RSVP RESV message back to router R5, which then forwards it to router R3. Router R3 forwards the RESV message to
router R1, thus establishing the LSP.
Module 5 - Page 53
LINK ID
LOCAL IP ADDRESS
REMOTE IP ADDRESS
UNRESERVED BW
ADMIN_GROUP
:
:
:
:
:
10.10.10.6
10.4.6.4
10.4.6.6
400,000 Kbps
00000010 (16)
LINK ID
LOCAL IP ADDRESS
REMOTE IP ADDRESS
UNRESERVED BW
ADMIN_GROUP
:
:
:
:
:
10.10.10.4
10.4.6.6
10.4.6.4
1,000,000 Kbps
0 None
Module 5 |
54
It is important to note that the administrative constraints apply only in the egress direction. They are checked and
executed in the same direction as the LSP that is being established.
As mentioned, administrative constraints are locally configured parameters on individual router links that are
propagated to other routers via IGP-TE updates. As seen in the example above, it is perfectly possible to have an
administrative group called GREEN configured on one side of the link, and no group definition on the other side. In the
reference figure above, the GREEN administrative group constraint can only be considered for an LSP that is established
towards router R6.
Accordingly, bandwidth reservations are performed and checked in the egress direction only. If an LSP is established
with a 600 Mbps bandwidth reservation from router R4 towards router R6, router R4 checks whether unreserved
bandwidth is available on the link to router R6 and makes the reservation in the same direction, if possible. In the
ingress direction, router R6 does not perform any check against available bandwidth reservation.
Module 5 - Page 54
Module 5 |
55
Module 5 - Page 55
The constraints are not taken into account if CSPF is not enabled on
the LSP. The path is signaled using standard IGP procedures (as
presented in Module 4).
Section Summary
Module 5 |
56
Traffic Engineering refers to the collection of mechanisms used to steer traffic around the network to avoid
congestion points or bottlenecks that eventually lead a well-known phenomenon called hyperaggregation.
Network designers and operators strive to use the network resources in the most efficient way possible to
guarantee different levels of service quality towards customers and maximize profits.
Several methods have been proposed and tried in the networks to perform Traffic Engineering tasks using standard
IGP techniques, which have generally proven to be unscalable and unmanageable.
MPLS offers more straightforward and easy to use features to implement TE in the network.
Several administrative constraints can be defined on the network links to overcome the limitation of standard IGP,
which relies solely on the link costs for path calculation, such as:
Administrative Groups
TE-metric
Hop-limit
Bandwidth Reservation
Shared Risk Link Groups (SRLG)
OSPF and IS-IS routing protocols have been extended to support the traffic engineering extensions that can be
defined on the links.
OSPF TE information is carried in separate Type 10 Opaque LSAs, with a single area scope.
IS-IS TE information is carried in extended IS reachability TLVs within the same Link State PDU protocol packets are
used to carry standard IS-IS routing information.
The standard Shortest Path First (SPF) algorithm has been enhanced to make path calculations based on the
specified administrative constraints. The enhanced algorithm is called CSPF.
When asked to calculate a path to a certain tunnel destination, CSPF first prunes the links that do not meet the
constraints and runs a standard SPF algorithm on the resulting topology based on cost values.
The Explicit Route Object (ERO) is populated by the hop information calculated by CSPF. Routers determine the
next-hop for the RSVP PATH message by checking the ERO when it is present.
Module 5 - Page 56
Module 5 - Page 57
Section Objectives
Module 5 |
58
This section covers the configuration principles of LSPs with certain Traffic Engineering requirements.
Examples of configuring administrative constraints such as administrative groups and TE metric are presented.
The possible variations of composing path definitions with strict and loose hops are explained with different examples.
Several verification and monitoring commands to display the status of LSP paths are included.
The section also covers several scenarios to illustrate possible failures that can result from configuration errors in the
path definitions, or other problems such as path unavailability because of additional constraints or link failures.
Aspects related to bandwidth reservations are not covered in this section; Section 3 is dedicated to this.
A useful CLI verification tool to check CSPF path availability is introduced at the end of the section, with various
examples.
Module 5 - Page 58
Module 5 |
59
As mentioned in the previous section, Traffic Engineering must be enabled on all the OSPF or IS-IS routers in the
network to propagate the TE information related to the links.
Various administrative constraints can be specified on the links, such as administrative groups, TE-metric, and so on,
depending on the pertinent network design. A bandwidth subscription percentage can be defined on a link to allow for
an oversubscription or undersubscription rate. This is covered in section 3 of this module.
A path definition may be composed by using different combinations of strict and loose hops. The path definition can
also be perceived as a constraint for CSPF during path calculation.
The administrator might choose to specify one or multiple constraints in the LSP configuration. If enabled, CSPF prunes
the links that do not meet the constraints and calculates a path using the remaining links. The constraints are not taken
into account if CSPF is not enabled.
Module 5 - Page 59
A:R1>config>router>mpls#
-------------------------------admin-group GREEN" 4
A:R4>config>router>mpls#
-------------------------------admin-group GREEN" 4
interface "toR6"
admin-group GREEN"
exit
Module 5 |
60
Administrative Groups are defined in the global MPLS context. In the example above, an administrative group is defined
with the name GREEN and a value of 4 on router R4. The interface to router R6 is then made a member of this
administrative group. As a result, the 4-bit position is set in the 32-bit admin-group Sub-TLV in the Opaque LSA.
If a path calculation needs to be made on router R1 with the same administrative group constraint, the same group to
value association must be defined on router R1. When an include or exclude statement is used in an LSP configuration
for an admin-group name, CSPF can then search for links with the corresponding admin-group value in the TED, if
required. Note that, in the TED, only the admin group values are present, not the names.
In principle, different admin group names can be used on different routers for the same admin group value. However,
this is very bad practice because it can cause troubleshooting nightmares if a certain value corresponds to different
group names on different routers.
Module 5 - Page 60
A:R1>config>router>mpls#
-------------------------------interface "toR3
te-metric 400
exit
A:R4>config>router>mpls#
-------------------------------interface "toR6"
te-metric 500
exit
Module 5 |
61
A Traffic Engineering metric can be defined on the links that can be different from the standard IGP metric, as
illustrated in the figure above.
Module 5 - Page 61
A path definition may contain a list of nodes that the LSP path
must traverse.
Each of these abstract nodes is called a hop. Hops can be either
strict or loose.
Module 5 |
62
A path may contain a list of abstract nodes that the LSP path must go through. Each of these abstract nodes is a hop. A
hop is expressed as an IP address (interface or system IP address of a router) in the path. Therefore, the path is the list
of the routers that an LSP path must traverse. The hops are specified in sequential order in the path definition.
A hop in the list can have a strict or loose character. Strict or loose describes the relationship between two consecutive
hops in the path definition. This is explained via several examples in the following pages.
Module 5 - Page 62
If enabled, CSPF:
y Calculates the intermediate hops to reach a loose hop
y Checks if a strict hop is valid.
A path definition may be composed by using:
y Fully loose or empty path list
y Fully strict hops
y Mixture of strict and loose hops
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
63
Hops can be specified as either strict or loose inside the path definition.
A hop specified as a strict hop must be an immediate next-hop to the previous hop in the hop list definition of the path.
This means that the two routers must have a direct Layer 3 connection between each other if a strict hop is being used.
If the strict hop is the first hop in the path definition, then it must be an immediate next-hop router of the Head-End
router (the Head-End router IP address is not specified in the path list and is considered an implicit first hop).
If a hop is specified as a loose hop, there is no stringent requirement for it to be an immediate next-hop to the previous
hop. It can be any downstream node from the Head-End node towards the tunnel destination.
CSPF acts differently on the strict and loose hops in a path definition. If enabled in the LSP configuration, CSPF
calculates the intermediate hops from the previous node towards a loose hop. In other words, it fills in the missing gaps
in the path definition with a loose hop.
CSPF is not strictly required for an LSP comprised of only strict hops but, if enabled, it runs a sanity check on the strict
hops and verifies whether they are valid. This avoids unnecessary signaling attempts in case configuration or operational
errors are present that impact the LSP path.
Several combinations are possible when creating path definitions for an LSP using strict and loose hops. Examples are
included in the following pages to illustrating different scenarios.
Module 5 - Page 63
A:R1>config>router>mpls#
-------------------------------path "empty_list"
A:R1>config>router>mpls#
-------------------------------path fully_loose
hop 10 10.10.10.6 loose
no shutdown
no shutdown
exit
exit
lsp "to_R6
to 10.10.10.6
lsp "to_R6
cspf
to 10.10.10.6
primary "empty_list
primary fully_loose
exclude GREEN
exclude GREEN
exit
exit
no shutdown
no shutdown
exit
exit
Module 5 |
64
A fully loose path definition provides a relaxed path constraint for CSPF, so that no specific regulation is imposed on the
intermediate hops of the LSP path by the administrator. CSPF can calculate an end-to-end path for the LSP from the
Head-End to the Tail-End router, taking into account the administrative constraints specified for the LSP path.
A fully loose path definition might contain a single hop the Tail-End (tunnel destination) router specified in the to
field of the LSP configuration.
It is also valid to have an empty path definition with no explicit hops specified. In this case, CSPF again tries to
calculate a path to the tunnel destination specified in the to field of the LSP configuration.
A path definition is administratively shutdown by default. It is important to remember that they must be explicitly
enabled by issuing a no shutdown command at the end of the path definition.
Module 5 - Page 64
cspf
path empty_list"
no shutdown
exit
lsp "to_R6
cspf
to 10.10.10.6
primary "empty_list
exclude GREEN
exit
Module 5 |
65
The example above illustrates the use of a fully loose path definition.
The path definition does not contain any hop information, so CSPF has the fully liberty in choosing the hops for the LSP
path, ensuring only that they comply with the administrative group constraint specified under the primary LSP path
definition.
In calculating the required path, CSPF first prunes all the links that are members of administrative group GREEN. In the
resulting topology, the path with the lowest IGP cost is chosen from the LSP Head-End to the Tail-End. The signaled LSP
path goes around the GREEN links.
Module 5 - Page 65
Actual Hops :
10.1.3.1(10.10.10.1)
-> 10.1.3.3(10.10.10.3)
-> 10.3.5.5(10.10.10.5)
-> 10.5.6.6(10.10.10.6)
Record
Record
Record
Record
Label
Label
Label
Label
:
:
:
:
N/A
131071
131071
131071
ComputedHops:
10.1.3.1
-> 10.1.3.3
-> 10.3.5.5
-> 10.5.6.6
Module 5 |
66
The show router mpls lsp <lsp-name> path [<path-name>] detail command is one of the most handy and
frequently used CLI monitoring commands to get extensive information regarding the LSP path(s) belonging to an LSP.
The Operational State of the LSP path is Up, which indicates that it is functioning properly.
One CSPF calculation has taken for the LSP path so far, as indicated by the CSPF Queries: 1 output.
No explicit hops have been defined by the administrator, who has preferred an empty path definition.
The Computed Hops field is of special interest here. This field is populated by the result of the CSPF calculation that
has taken place after enabling the LSP. Four hops have been computed by CSPF; the first is the Head-End and the last is
the Tail-End router of the LSP. None of the links in the computed LSP path is a member of the administrative group
GREEN.
The Explicit Route Object (ERO) of the RSVP PATH message sent from router R1 (Head-End) consists of the hops visible
in the Computed Hops output, except the first hop, 10.1.3.1, which is the interface IP address of router R1 itself.
The Record Route Object field has a particular use in the RSVP-TE Fast Reroute implementation and is explained in
Module 6.
Module 5 - Page 66
ExplicitHops:
No Hops Specified
A:R1>config>router>mpls#
-------------------------------path fully_strict_A"
A:R1>config>router>mpls#
-------------------------------path fully_strict_B"
no shutdown
no shutdown
exit
lsp "to_R6
lsp "to_R6
to 10.10.10.6
to 10.10.10.6
primary fully_strict_A
primary fully_strict_B
exit
exit
no shutdown
exit
no shutdown
exit
Module 5 |
67
Alternatively, an LSP path can be completely comprised of strict hops. This option gives ultimate control to the network
administrator in determining the specific hops that an LSP path should take. Using the fully strict option, all the hops
along the LSP path needs to be explicitly specified, except the Head-End node.
Specifying interface or system IP addresses for the hops are both accepted as valid configurations by the Alcatel-Lucent
Service Routers. However, using the interface addresses is a recommended practice. Problems can occur in the rather
unlikely cases in which the system IP address is not resolved to an immediate next-hop. This can be caused by improper
IGP metric issues.
A fully strict hop LSP path fails if at least one of the hops in the path definition becomes unavailable as a result of link
failure or other problems. This is a downside unless protection mechanisms, such as secondary or fast reroute
protection paths, are used.
Since the path definition is fixed, CSPF does not need to be enabled in the LSP configuration. If enabled, CSPF runs a
sanity check on the strict hops and verifies their validity.
Module 5 - Page 67
exit
path fully_strict_A"
hop 10 10.1.3.3 strict
hop 20 10.3.5.5 strict
hop 30 10.5.6.6 strict
no shutdown
exit
lsp "to_R6
to 10.10.10.6
primary fully_strict_A
Module 5 |
68
The example above illustrates an LSP path definition composed of only strict hops.
The first strict hop is router R3, from router R1.
The second strict hop is router R5, from router R3.
The third and the final strict hop is router R6, from router R5.
NOTE: The entries in the path definition are enumerated with values between 1-1,023. The specified values need not be
consecutive, but have to be in an increasing order. A common convention is to use hop values in powers of 10 (probably
rooted in the legacy BASIC programming language), but this is by no means mandatory. It has the bleak advantage of
being able to insert an additional hop between any two entries after the initial configuration.
Module 5 - Page 68
-> 10.5.6.6
Configured Hops
ERO
Actual Hops :
10.1.3.1(10.10.10.1)
-> 10.1.3.3(10.10.10.3)
-> 10.3.5.5(10.10.10.5)
-> 10.5.6.6(10.10.10.6)
ResigEligib*: False
LastResignal: n/a
Record
Record
Record
Record
Label
Label
Label
Label
:
:
:
:
N/A
131071
131071
131071
CSPF Metric : 0
Module 5 |
69
The Explicit Hops field indicates the strict hops specified in the path definition.
The ERO of the RSVP PATH message sent from router R1 to router R3 contains these IP addresses as an explicit path list.
The Computed Hops field is not visible in the CLI output if CSPF is disabled in the LSP configuration.
As mentioned, CSPF can verify the strict hops in the path definition before attempting to signal the LSP path, if it is
enabled.
Module 5 - Page 69
ExplicitHops:
10.1.3.3
A:R1>config>router>mpls#
-------------------------------path mixed-2"
no shutdown
exit
no shutdown
lsp "to_R6
exit
cspf
cspf
to 10.10.10.6
to 10.10.10.6
primary mixed-2
primary mixed-1
exclude GREEN
exclude GREEN
exit
exit
no shutdown
exit
no shutdown
exit
Module 5 |
70
Another alternative in creating path definitions is to use hybrid path definitions, where a mixture of strict and loose
hops are being used.
In the mixed path example above, mixed-1 (on the left) consists of two strict hops and one loose hop. CSPF is enabled
in the LSP configuration, so it first checks if 10.1.2.2 (router R2) is a valid strict hop for the Head-End router, R1. It
then checks if 10.2.4.4 (router R4) is a valid strict hop for the previous, that is 10.1.2.2 (router R2). CSPF finally
calculates a path from 10.2.4.4 (router R4) to 10.10.10.6 (router R6) that avoids any of the GREEN links.
In the second example, mixed-2 (on the right) takes the opposite approach. Here CSPF first calculates a path to
10.10.10.5 (router R5), which is defined as a loose hop. The administrative constraint must be taken into account,
which specifies that any GREEN links must be avoided along the first portion of the LSP path. CSPF then verifies that
10.10.10.6 (router R6) is a valid next-hop for 10.10.10.5 (router R5).
CSPF calculates ALL of the intermediate hops in a loose portion of the path definition. The ERO of the RSVP Path
message in this case is composed of strict hops provided by the administrator, and the hops calculated by CSPF for the
loose portion(s).
Module 5 - Page 70
lsp "to_R6
exclude GREEN
Module 5 |
71
The above slide illustrates the CSPF path calculation process when using a mixture of strict and loose hops, as described
on the previous page. The loose portion of the LSP path is calculated by CSPF, taking into account the administrative
group constraint, which requires that all the GREEN links should be avoided. The LSP path consequently traverses over
router R5 to honor this constraint.
Module 5 - Page 71
path mixed-1"
A:R1>config>router>mpls#
-------------------------------path "empty_list"
no shutdown
exit
lsp "to_R6
cspf use-te-metric
to 10.10.10.6
exit
no shutdown
exit
Module 5 |
72
Recall that customary Traffic Engineering values can be specified for the links inside the MPLS interface contexts. The
TE metric values are propagated within the network inside IGP TE updates.
However, CSPF uses the standard IGP metric values of the links as presented in the Link State Database of the router.
The use-te-metric option must be specified, and CSPF must be enabled in the LSP configuration, in order to be able
to use the TE metric values present in the Traffic Engineering Database (TED).
Module 5 - Page 72
primary "empty_list
path empty_list"
no shutdown
exit
lsp "to_R6
cspf use-te-metric
to 10.10.10.6
primary "empty_list
exit
exit
Module 5 |
73
The above slide illustrates the use of the TE metric values in CSPF calculations.
Two alternative paths exist in the ring topology between routers R1 and R6.
Path #1 has a cumulative TE cost value of 700, and Path #2 has a cumulative TE cost of 600.
If the use-te-metric option is enabled in the CSPF configuration, Path #2 will be selected as the LSP path to be
established.
Module 5 - Page 73
If CSPF is enabled:
y The Head-End router validates the path in the TED. If problems
are detected, a PATH message is not sent.
Module 5 |
74
Failures can occur before, during or after an LSP path is established. Possible problems include configuration errors, link
failures or stringent administrative constraints preventing the LSP path from being established. Slightly different
behavior can be observed, depending on whether CSPF is enabled in the LSP configuration.
If CSPF is disabled for the LSP, the Head-End router has no way of knowing if the intermediate hops of an LSP path are
valid or not. It does not have an end-to-end view over the LSP path and can only determine issues related to the
immediate downstream hop. If the next-hop is valid, the Head-End sends out the RSVP PATH message, in the hope that
it will make its way all the way down to Tail-End and receive a RESV message back. This might not be possible in some
cases as presented in the following pages.
CSPF runs a complete check on the specified path definition, and can detect certain potential problems even before the
Head-End attempts to signal the LSP path. CSPF has the entire network topology at its disposal, by virtue of the Traffic
Engineering Database.
Module 5 - Page 74
path wrong-1"
hop 10 10.10.10.5 strict
hop 20 10.10.10.6 strict
no shutdown
exit
Module 5 |
75
The example above illustrates an invalid strict hop configuration that is specified as a next-hop for the Head-End
router, router R1.
As mentioned, a strict hop MUST be an immediate, directly connected next-hop for the previous hop in the list. In this
case, there is no previous hop in the list.
Even if CSPF is not enabled for the LSP, router R1 is capable of determining that router R5 cannot be a strict next-hop
for it by consulting the IGP forwarding table. Accordingly, router R1 does not attempt to signal the LSP path and keeps
it operationally DOWN.
Module 5 - Page 75
path wrong-2"
hop 10 10.1.3.3 strict
hop 20 10.3.5.3 strict
hop 30 10.5.6.5 strict
no shutdown
exit
76
If there is a strict hop configuration error at an intermediate hop, router R1 cannot check this if CSPF is not enabled for
the LSP under consideration. In this case, router R1 attempts to signal the LSP path by sending out a PATH message,
only to receive a PATH Error message sent by router R3, which is the router that the configuration error is detected on
in the ERO.
Here, the problem stems from the fact that both the first and second hops refer to the same router, R3.
Module 5 - Page 76
Next-hop (router R3) returns a PATH Error message with RSVP Error Code:
Routing Problem and Error Value: Bad Strict Node
CLI displays:
y Failure Code: badNode
y Failure Node: 10.1.3.3 (node that identified error)
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
77
The path failure information is visible in the show router mpls lsp <lsp-name> path [<path-name>] detail
command output. According to the RFC specification, router R3 indicates an error code of Routing Error and an error
value of Bad Strict Node to provide an idea about the source of the problem. Both the LSP and the LSP path are
operationally DOWN because of the strict hop configuration error.
Module 5 - Page 77
path wrong-2"
hop 10 10.1.3.3 strict
hop 20 10.3.5.3 strict
hop 30 10.5.6.5 strict
no shutdown
exit
Module 5 |
78
CSPF can detect the problems anywhere in the LSP path definition and prevent unnecessary signaling.
The LSP path is again put to an operationally down state, but this time with a failure code of No CSPF Route To
Destination.
Module 5 - Page 78
Module 5 |
79
The CLI output above indicates that the CSPF process on router R1 has been unable to find a valid path with the
specified path and/or administrative constraint definitions.
The fully strict hop LSP path remains down until the configuration error is corrected.
Module 5 - Page 79
path fully_strict_A"
hop 10 10.1.3.3 strict
hop 20 10.3.5.5 strict
hop 30 10.5.6.6 strict
no shutdown
exit
80
In the example above, all the strict hop definitions are correct from a configuration perspective, but a physical link
failure makes the last hop (10.5.6.6) invalid. With CSPF disabled, router R1 has no way of knowing that this last hop has
become unavailable; so it forwards the PATH message downstream anyway. Router R3 also does the same and forwards
the message on to router R5.
Router R5 is the immediate router that is connected to one side of the failed link. Upon receipt of the RSVP PATH
message, it realizes that the message cannot be delivered any further, and so informs the LSP Head-End about the
problem. This is done again with a PATH Error message sent upstream.
Even though the router R1 will continuously try to establish the LSP on the fully strict path, all of these attempts will
fail until the failure on the R5-R6 link is removed.
Module 5 - Page 80
path fully_strict_A"
hop 10 10.1.3.3 strict
hop 20 10.3.5.5 strict
hop 30 10.5.6.6 strict
no shutdown
exit
81
If CSPF is enabled, it can detect that the last hop in the path definition is invalid by checking the Traffic Engineering
Database. CSPF process reports to router R1 about this problem, which does not attempt to signal the LSP path until the
failure condition is removed.
Module 5 - Page 81
path empty_list"
no shutdown
exit
lsp "to_R6
cspf
to 10.10.10.6
primary "empty_list
include GREEN
exit
Module 5 |
82
The last failure example covers a specific case of using include statements in administrative group definitions.
The rule states that ALL the links along the candidate LSP path must be members of the specified administrative group
for that path to be considered as eligible. In this case, CSPF is unable to find an eligible path to router R6 because none
of the links, except the link between router R4 and router R6, comply with the administrative constraint.
Care must be exercised in using include statements together with administrative groups. Many network designers try to
stick to using exclude statements only, to make things more straightforward and predictable.
Module 5 - Page 82
path empty_list"
no shutdown
exit
lsp "to_R6
cspf
to 10.10.10.6
primary "empty_list
include GREEN
exit
Module 5 |
83
The above slide illustrates the network topology as contemplated by the CSPF process after executing the
administrative group constraint. All of the links, except the link between router R4 and router R6, are pruned,
rendering the network useless for establishing LSP paths using include statements.
Module 5 - Page 83
path empty_list"
no shutdown
exit
lsp "to_R6
cspf
to 10.10.10.6
primary "empty_list
exclude GREEN
exit
Module 5 |
84
Module 5 - Page 84
path empty_list"
no shutdown
exit
lsp "to_R6
cspf
to 10.10.10.6
primary "empty_list
exclude GREEN
exit
Module 5 |
85
Module 5 - Page 85
Module 5 |
86
At times, network operators might want to check for path availability from a certain source router to a specified
destination. In an IP routed network, ping and traceroute can be used for testing reachability. Using traffic engineering,
it might be desirable to find an answer to questions such as: Can I find a path from router R1 to router R6 avoiding
GREEN links? If so, what would the path be like? While an LSP can be configured with certain constraints for testing
purposes, this method is not so efficient and creates unnecessary signaling in the network.
Alcatel-Lucent Service Routers provide a useful tool to run path availability checks without needing to configure and
signal LSPs. The tools perform router mpls cspf command can be used on any Traffic Engineering enabled
router to calculate a path to a certain destination, together with several optional constraints. The command returns the
hop information, if a path is available.
The starting point for the test path is the router on which the command is issued. However, a from address can
optionally be specified to change this.
Several examples are included in the following pages to illustrate the use of the CSPF Path Check Tool.
Module 5 - Page 86
-> Ingr:
-> Ingr:
-> Ingr:
10.1.3.3
10.3.5.5
10.5.6.6
(met 100)
(met 100)
(met 100)
Module 5 |
87
In the example above, the operator wants to determine whether a path is available from router R1 to router R6 that
can reserve 500 Mbps of bandwidth on the links. CSPF returns the viable hop information for the required path, should
an LSP be signaled with that constraint.
Keep in mind that CSPF path check tool is just a local calculation process. No LSP is signaled and no bandwidth is
reserved on the links by the use of this command.
Module 5 - Page 87
->
->
->
->
Ingr:
Ingr:
Ingr:
Ingr:
10.1.2.2
10.2.4.4
10.4.5.5
10.5.6.6
(met
(met
(met
(met
100)
100)
100)
100)
Module 5 |
88
In this second example, the operator wants to determine whether a path is available from router R1 to router R6 that
avoids the GREEN links. The CSPF path check tool does not accept administrative group names as input, and requires
the hexadecimal or decimal equivalents of the bitmap values as seen in the TED to be specified. The calculation of
these values were explained in Section 1.
Module 5 - Page 88
Module 5 |
89
The example above illustrates that if an include statement must be used, ALL the links along the LSP path must belong
to the specified administrative group. There is no such contiguous path between router R1 and router R6, which is why
CSPF is unable to return hop information with the specified constraints.
Module 5 - Page 89
*A:R1# tools perform router mpls cspf from 10.10.10.3 to 10.10.10.6 exclude-bitmap 16
To
: 10.10.10.6
From
: 10.10.10.3
Path 1
: (cost 400)
Start: 10.10.10.3
Egr:
10.2.3.3
Egr:
10.2.4.2
Egr:
10.4.5.4
Egr:
10.5.6.5
End:
10.10.10.6
->
->
->
->
Ingr:
Ingr:
Ingr:
Ingr:
10.2.3.2
10.2.4.4
10.4.5.5
10.5.6.6
(met
(met
(met
(met
100)
100)
100)
100)
Module 5 |
90
The example above illustrates that a different source address can be specified within the command, which can be
different from the router on which the command is being used. CSPF on router R1 is capable of calculating a path
between any two points in the network as long as they are present in the TED.
Module 5 - Page 90
Module 5 |
91
Module 5 - Page 91
Section Summary
Module 5 |
92
Traffic Engineering must be enabled in the IGP (OSPF or IS-IS) configuration of all the MPLS routers to have the TE
functionality with RSVP.
Additional administrative constraints, such as administrative groups or TE metric, can be configured on the links
inside the MPLS context.
A path definition may be composed of a combination of loose and strict hops. If enabled, CSPF:
Determines that the strict hops are valid
Calculates the exact intermediate hops to a loose hop
When LSP paths (primary and/or secondary) are configured in the LSP context, optional constraints may be
specified to regulate the path that will be taken. CSPF needs to be explicitly enabled in the LSP context to take
these constraints into account.
The show router mpls lsp <lsp-name> path [<path-name>] detail command is one of the most
commonly used commands to check for the status and details of LSP paths. The Failure Code and Failure Node
fields in the output provide useful information as to the source of a potential problem.
If CSPF is not enabled for the LSP, the Head-End cannot detect errors or reachability problems regarding the
intermediate hops along the path. In such a case, an RSVP PATH message is sent, which is responded to by a PATH
Error message by the node detecting the error.
If enabled, CSPF checks and verifies the entire path before signaling by consulting the local Traffic Engineering
Database.
The tools perform router mpls cspf command provides a useful path check tool to test Traffic Engineering
availability to a certain destination with several optional constraints. No LSP is signaled by the use of this
command. If a bandwidth constraint is specified, no bandwidth is reserved on the links.
Module 5 - Page 92
Module 5 - Page 93
Section Objectives
Module 5 |
94
This section begins with a recap of bandwidth reservations using RSVP-TE. The significance of enabling CSPF in the LSP
configuration is also emphasized.
SR OS includes a feature to define thresholds for advertising the unreserved bandwidth values for the links, rather than
having immediately triggered updates upon every LSP bandwidth reservation and release. The optimization option is
introduced in the section.
The different bandwidth reservation options over shared links for LSP paths belonging to the same LSP are introduced.
The Make-Before-Break (MBB) concept refers to the adaptive behavior of LSP paths to minimize service downtime in
case of changing bandwidth reservation values on-the-fly.
This section explains the least-fill feature used to achieve more balanced bandwidth reservations over redundant links,
and discusses in detail the LSP Soft-Preemption feature using LSP setup and hold priorities.
The section concludes by having an elaborate discussion on the Diffserv-Aware Traffic Engineering (DiffServ-TE) feature.
Module 5 - Page 94
Module 5 |
95
The network administrator can optionally define a certain amount bandwidth reservation in the LSP path configuration.
In the Service Router CLI, the bandwidth reservation values are expressed in Megabits per second (Mbps).
The bandwidth reservation values are only used in the admission phase of the LSP, that is, during initial establishment.
Once the LSP is established, the routers do not perform further checks on the real, utilized bandwidth of the LSP in
relation to the reserved bandwidth.
The required bandwidth reservation is included in the FLOW_SPEC object of the RSVP PATH message sent by the HeadEnd. Upon receipt of the RSVP PATH message, each router checks whether the requested bandwidth is available on the
egress interface that the LSP is going to traverse. This operation is called CAC (Connection Admission Control).
If the CAC operation fails at a certain downstream node, an RSVP PATH Error message is sent to inform the Head-End of
the LSP. If CSPF is not enabled, the errors might persist, so that the Head-End might continuously attempt to signal the
LSP over the links with insufficient reservable bandwidth. CSPF helps to overcome these problems by making a path
calculation upfront in the Traffic Engineering Database, looking for an available path.
Module 5 - Page 95
It is possible that the LSP has not been computed by CSPF and the
requested bandwidth reservation might not be available at a
downstream router.
The state change might have been caused by another LSP being set
up, originating at another router.
The Traffic Engineering Database might not be 100% up to date at
the time of CSPF computation, most possibly due to Opaque LSA
throttling (see the Bandwidth Thresholds topic in this section.
Module 5 |
96
Even if the path is calculated by CSPF, the Connection Admission Control procedures might still be required.
If another LSP happens to reserve bandwidth on the desired links within the brief time interval between the CSPF path
calculation and the actual signaling, the LSP setup might fail due to insufficient reservable bandwidth.
As a result of the RSVP-TE Bandwidth Update Trigger feature (introduced later in the section), the local TED might not
be fully up-to-date about the latest bandwidth reservation status of the links. In this case, the LSP Head-End must be
informed again with CAC failure error. The RSVP-TE Bandwidth Update Trigger feature also involves an option to
trigger an immediate IGP update, in case of encountering a CAC failure on a link. This is to synchronize the nodes in the
network with the correct TE information to avoid further problems.
Module 5 - Page 96
Even if the LSP was computed by CSPF, the reservation state might
have changed between the computation and signaling.
Module 5 |
97
The example above illustrates the Connection Admission Control (CAC) process performed on each router along an LSP
path.
An LSP is configured with 600 Mbps of bandwidth on router R1, which sends out a PATH message in an attempt to signal
the LSP path. Router R1 itself first determines whether the required bandwidth is available on the link before sending
out the message. This succeeds and the message is delivered to router R2.
Upon receipt of the PATH message, router R2 also verifies that the bandwidth is available and forwards the message to
R4.
R4 repeats the same procedure and the PATH message gets delivered to the tunnel destination, router R6.
It is important to note that the CAC process is just a sanity check performed on the interface. The routers do not
reserve any bandwidth at this stage, as it is uncertain that the CAC will succeed in all the remaining downstream nodes
along the LSP path.
Module 5 - Page 97
Module 5 |
98
After the bandwidth is verified by the CAC process on each router and the PATH message gets to delivered to the TailEnd router, R6. An RESV message is propagated upstream to establish the RSVP sessions for the LSP path. It is at this
stage that the requested bandwidth is reserved on the egress link of each upstream router.
Upon reserving the bandwidth, the routers send out IGP advertisements to inform the other nodes in the network about
the updated unreserved bandwidth values on the links.
It should be emphasized once again that RSVP bandwidth reservation is strictly a control plane process. The reserved
bandwidth values do not have any regulatory impact on the actual utilization on the data plane of the routers. AlcatelLucent Service Routers offer a wide set of Quality of Service policies and features to perform rate limiting controls on
the data plane.
Module 5 - Page 98
===============================================================================
RSVP Interfaces
===============================================================================
Interface
Total
Active
Total BW Resv BW
Adm Opr
Sessions Sessions (Mbps)
(Mbps)
------------------------------------------------------------------------------system
Up Up
toR2
1
1
1000
600
Up Up
toR3
0
0
1000
0
Up Up
------------------------------------------------------------------------------Interfaces : 3
===============================================================================
Module 5 |
99
The show router rsvp interface command output displays the total amount of reservable bandwidth, and the
amount of bandwidth out of this total that has been reserved by LSPs on each link.
The physical bandwidth of all links in the example topology are 1 Gbp; the Total BW value equals this value by default.
It is possible to over-book or under-book this capacity by configuring a subscription rate. An example is shown in the
following page.
The Resv BW value is updated every time an LSP reserves bandwidth on a link, or releases its previous bandwidth
reservation. It reflects the total amount of reserved bandwidth by all LSPs crossing that link in the egress direction.
The unreserved bandwidth values are advertised in the IGP TE updates. These values can simply be calculated by
subtracting the Reserved Bandwidth from the Maximum Reservable Bandwidth.
Module 5 - Page 99
Module 5 |
100
A subscription rate of 40 is applied for the interface toR6 on router R4. This reduces the Maximum Reservable
Bandwidth to 400 Mbps on the link, as is illustrated in the show router rsvp interface command output above.
A:R4>config>router>rsvp#
-------------------------------interface toR6
subscription 40
lsp "to_R6
to 10.10.10.6
primary fully_loose
bandwidth 600
exit
101
The example above illustrates the Connection Admission Control failure that can encountered on any router along the
path of an LSP.
IF CSPF is not enabled for the LSP, router R1 does not have a way of knowing the bandwidth reservation status of all the
links along the LSP path. In this case, an RSVP PATH message is sent blindly with the required bandwidth value over
the IGP chosen best path. Routers R1 and R2 have the bandwidth available, so the CAC process succeeds on these
routers and the PATH message gets delivered to the next-hop.
As a result of CAC, router R4 discovers that it does not have the requested bandwidth available on the egress link.
Therefore, it rejects the PATH request and sends back a PATH Error message that contains certain fields and flags to
indicate the source of the problem. Monitoring of this fault condition in the CLI is presented on the next page.
Module 5 |
102
The operational status of the LSP and the LSP path both appear to be down.
The Failure Code field in the command output above provides a clear indication of the source of the problem.
The admissionControlError indicates that a bandwidth reservation failure has occurred at one of the downstream
nodes.
The downstream node that the failure was detected is also indicated in the Failure Node field. The IP address of
10.2.4.4 belongs to router R4.
With CSPF disabled, router R1 continuously tries to establish the LSP path over the IGP best path. The consecutive path
setup attempts will continue to fail, unless router R4 has the 600 Mbps of reservable bandwidth available on the link, or
the LSP path bandwidth request is lowered or removed by the administrator.
lsp "to_R6
to 10.10.10.6
cspf
primary fully_loose
bandwidth 600
exit
103
The above slide illustrates yet another example of CSPF while using administrative constraints. If CSPF is enabled,
router R1 does not try to establish the LSP over the IGP selected best path, where the requested bandwidth is not
available.
By consulting the TED, CSPF finds a path that has available bandwidth to accommodate the reservation request by the
LSP. As described earlier, the calculated hops are included in the ERO of the PATH message and the LSP gets signaled
over the desired path.
Module 5 |
104
The default behavior of the Service Router is to generate an immediate IGP TE Update when an LSP reserves or releases
bandwidth on an attached link. In a scaled network with many LSPs, the intense amount of updates propagated and
processed can create a certain amount of overhead.
The Bandwidth Update Trigger feature optimizes the flooding behavior. When enabled, only the significant updates are
sent regarding the bandwidth reservations on the links.
Since the interpretation of significant might change from network to network and operator to operator, the Service
Router allows the definition of custom threshold values for the total amount of reserved bandwidth on the RSVP links.
Thresholds can be defined in the up and/or down directions, as explained in the following pages.
Module 5 |
105
The above slide illustrates the default behavior of propagating IGP TE updates.
If the amount of reserved bandwidth changes with an LSP setup or is cleared, an LSA is immediately generated and
flooded through the network. All the receiving routers need to process this LSA and update their Traffic Engineering
Databases, which also consumes processing resources.
Module 5 |
106
If the IGP TE Bandwidth Update feature is enabled, custom thresholds can be defined on the RSVP interfaces in both up
and down directions.
In the up direction, as bandwidth reservations increase on the link, IGP TE updates are sent only when the reserved
bandwidth amount rises above the defined thresholds. In the example above, updates are triggered when the reserved
bandwidth crosses 20%, 50%, 70%, 90%, and 95% of the maximum reservable bandwidth on the link.
Similarly, updates are triggered when the amount of reserved bandwidth on the link falls below the defined thresholds
in the down direction. The threshold values are again defined in percentages of the maximum reservable bandwidth.
The SR OS allows the operators to define up to 16 threshold values in both directions. If the IGP TE Bandwidth Update
feature is enabled, at least one threshold value must be specified in either direction.
Default threshold values also exist that apply in case custom values are not described. These values are shown later in
the section.
Module 5 |
107
The above slide illustrates the CLI configuration command to enable the IGP TE Bandwidth Update feature.
Once enabled, custom threshold values can be configured in up and down directions.
In the up direction, the threshold values must be configured in ascending order. Similarly, the down thresholds must be
configured in descending order (the Service Router CLI issues a warning if done otherwise).
The configurations shown above are done at the global RSVP context, which apply to all the RSVP enabled interfaces. If
it is desirable to use different values for a certain interface or interfaces, the same te-up-threshold and te-downthreshold configurations are available at the interface level.
Periodic updates can also be enabled with a timer value in the 1 300 seconds range.
configure router rsvp te-threshold-update update-timer 300
Module 5 |
108
Two more optional commands are also available with the IGP TE Bandwidth Update feature.
The on-cac-failure option instructs the router to immediately send out an IGP TE update in case an LSP setup
attempt fails because of unavailable bandwidth. The idea behind this is that the Head-End router of the LSP might not
be fully in sync with the actual bandwidth reservations in the network, and is trying to reserve more bandwidth than is
readily available. This option lets the router to send an update, regardless of the configured thresholds, for the sake of
bringing all the routers up-to-date about the status of bandwidth reservations.
Another optional configuration parameter is the update-timer. If configured, the router sends out periodic IGP TE
updates for its links, even if no change has occurred in the reservation status of the links.
IgpThresholdUpdate
Up Thresholds(%)
Down Thresholds(%)
Update Timer
Update on CAC Fail
:
:
:
:
:
Enabled
0 15 30 45 60 75 80 85 90 95 96 97 98 99 100
100 99 98 97 96 95 90 85 80 75 60 45 30 15 0
N/A
Disabled
detail
IGP Update
Up Thresholds(%)
: 0 15 30 45 60 75 80 85 90 95 96 97 98 99 100
Down Thresholds(%) : 100 99 98 97 96 95 90 85 80 75 60 45 30 15 0
IGP Update Pending : No
Next Update
: N/A
* indicates inherited values
Module 5 |
109
*
*
The above slide illustrates the default threshold values programmed into the SR OS, if the te-threshold-update
feature is enabled.
The first show router rsvp status command output displays the values that apply to all the RSVP interfaces of the
router. As seen in the second show router rsvp interface detail command output, these values are
automatically inherited by all the interfaces. As mentioned, it is possible to override these values at an interface level.
Module 5 |
110
As explained in greater detail later in Module 6 (Resiliency), an LSP can have multiple LSP paths configured to provide
resiliency. An LSP path configured as primary, always has precedence and carries the traffic under normal conditions.
Optionally, a hot-standby secondary LSP path can be defined to protect traffic in case of a failure impacting the
primary LSP path. In this case, the amount of bandwidth that will be reserved on the links that the primary and
secondary LSP paths might be sharing is of particular interest. Although sharing links between redundant LSP paths is
not desired, it can be inevitable in some cases as a result of topological or other reasons.
The Alcatel-Lucent Service Routers support two of the reservation styles defined in RFC 2205: Shared Explicit (SE) and
Fixed Filter (FF).
In the Shared Explicit reservation style, the LSP paths should share the bandwidth on the common link(s). The total
amount of bandwidth counted by the router for the LSP is the largest bandwidth reservation requested by all the LSP
paths. This is the default and recommended method.
Conversely, the Fixed Filter reservation requires the routers to maintain separate bandwidth reservation for the LSP
paths, even though they belong to the same LSP, and despite the fact that only one of these LSP paths is carrying the
data traffic at a given time. Accordingly, the total amount of bandwidth reserved for the LSP is the sum of all the
individual bandwidth reservation values of all established LSP paths. This is not a recommended and used method,
but still supported because of compliance reasons.
Multiple LSP paths are known to belong to the same LSP, if they have
the same Tunnel ID.
With the default SE style, 500 Mbps (max. of 500M and 300M)
is reserved on the shared links (R1-R2 and R4-R6).
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
111
In the example above, an LSP is configured with a primary and a (hot) standby secondary LSP path. Since the primary
LSP path is operational, it is carrying the data traffic. The standby secondary LSP path is also established to
immediately take over in case the primary fails.
The primary LSP path is configured for 500 Mbps and the standby secondary LSP path is configured for 300 Mbps of
bandwidth. They are both traversing over the common links between R1-R2 and R4-R6.
Routers R1 and R4 only reserve 500 Mbps for both LSP paths in the default Shared Explicit reservation style. Because
they belong to the same LSP configuration, the two LSP paths are identified by their common tunnel ID (10), assigned by
the Head-End. They are discriminated by their different LSP IDs.
Module 5 |
112
The Fixed Filter reservation style is more resource intensive. Using this method, the sum of both bandwidth reservations
by the two LSP paths (500 Mbps and 300 Mbps) is accounted for on the common links. This why the links R1-R2 and R4R6 have only 200 Mbps of reservable bandwidth left on them after both LSPs are established.
The reservation style of an LSP can be changed from the default SE to FF with the following configuration (this is not
recommended):
A:R1>configure router mpls lsp toR6 rsvp-resv-style ff
Module 5 |
113
After an LSP is successfully established, the bandwidth reservation value can be changed in configuration on the HeadEnd router. The objective, however, is to minimize the service downtime that might be caused as a result of this
operation.
For this purpose, a new LSP path is established first with the new bandwidth information. During the setup of the new
LSP, data traffic remains on the old LSP path.
Once the new LSP is established, the Head-End router of the LSP swiftly moves the traffic over to the new LSP path.
After a successful handover of traffic from the old LSP path to the new one, the old LSP path is torn down with a Path
Tear message issued by the Head-End.
If the new LSP path cannot be established for some reason, traffic remains on the old path.
This behavior is called Make-Before-Break (MBB), also referred to as adaptive.
MBB is not limited to changing bandwidth information on the LSP path. Changes in other configuration parameters might
also trigger the MBB behavior.
lsp "to_R6
to 10.10.10.6
cspf
primary fully_loose
bandwidth 600
exit
Module 5 |
114
In the example above, an LSP is established with 600 Mbps of bandwidth over the links in the upper portion of the
network. Another LSP or LSPs also reserves bandwidth, therefore only 100 Mbps is left unreserved in the upper half.
The links in the lower half still have 1000 Mbps of unreserved bandwidth.
lsp "to_R6
to 10.10.10.6
cspf
primary fully_loose
bandwidth 800
exit
115
A configuration change is performed by the administrator, increasing the bandwidth reservation from 600 Mbps to 800
Mbps. Since CSPF is enabled, it is obliged to search for an available path that can accommodate the updated bandwidth
in the TED.
With Shared Explicit, CSPF only looks for the delta amount of 200M
(800M-600M) on the existing LSP path. It is not available there.
CSPF calculates a new path using the available links.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
116
Since the new LSP path belongs to the same LSP, CSPF first tries to increment bandwidth by the delta amount of 200
Mbps on the existing LSP path. This is in relation to using the default bandwidth reservation style, shared explicit. Only
100 Mbps is left unreserved on the previously chosen LSP path, so CSPF is forced to look for an alternative path.
CSPF finds a new LSP path with the hops: R1-R3-R5-R6. This path is then signaled by RSVP, as shown on the next page.
The new LSP path is established with the same tunnel ID and an
incremented LSP ID.
Data traffic stays on the old LSP path during this process
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
117
The new LSP path is signaled by RSVP over the links in the lower half. Until the signaling is completed, data traffic
assigned to the LSP remains on the old LSP path.
Note that the new LSP path has the same tunnel ID as the old one. This can have a consequence on the bandwidth
reservation style, as described earlier. The LSP ID of the new LSP path is incremented to distinguish the two LSP paths.
Module 5 |
118
Once the new LSP path is established, the Head-End switches the traffic over to it. In other words, the data is
forwarded with new labels that are assigned to the new LSP path over the redundant links.
During this process, both LSP paths co-exist over the network for a short interval, occupying resources at the same
time. Because of this, admission control errors might be encountered if the two LSP paths go over common links and
fixed-filter reservation style is used.
Router R1 sends a PATH Tear message to tear down the old LSP.
RSVP sessions that belong to the old LSP are cleared on all routers.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
119
After a successful switchover, the old LSP path is torn down with a PATH Tear message. The RSVP sessions and the
bandwidth reservation for the LSP path are cleared on all the participating routers.
MBB Remarks
Module 5 |
120
Applies to the case when the Head-End router has multiple paths
with equal IGP costs to a certain LSP destination.
By default, CSPF randomly chooses one of the equal cost links each
time an LSP is configured to the destination.
Module 5 |
121
In a topology with multiple equal cost paths between a Head-End and Tail-End router, CSPF still needs to choose one of
the available paths that have the required bandwidth available. The default selection is done in a random manner to
allow for dispersion in bandwidth reservations. However in some cases, this might lead to an unbalanced distribution of
bandwidth reservation on the alternative paths.
The least-fill option can be enabled in the LSP configuration to force CSPF to choose the path with the least amount of
bandwidth reservation.
The ECMP (Equal Cost Multiple Path) feature introduced earlier in Module 3 (LDP) is not required for the least-fill
feature to function.
Module 5 |
122
In the example above, two LSPs are already established on the two alternative paths with 500 and 200 Mbps of
bandwidth reservation respectively. 500 Mbps is left unreserved on the upper half, and 800 Mbps is yet unreserved on
the lower half of the topology.
Both paths have the same cumulative IGP cost, making them equally preferable for CSPF.
lsp 3
to 10.10.10.6
cspf
primary fully_loose
bandwidth
300
exit
123
A third LSP is configured on router R1, and requests 300 Mbps of bandwidth. Both paths are eligible, and there is the
likelihood that CSPF will choose the upper path. This would result in an uneven distribution of bandwidth reservation
over the two paths. In this scenario, the upper path has 800 Mbps of reserved bandwidth, while the lower path only has
200 Mbps.
lsp 3
to 10.10.10.6
cspf
least-fill
primary fully_loose
bandwidth
300
exit
124
If the least-fill option is enabled in the LSP configuration, CSPF is mandated to prefer the path with the least amount of
bandwidth reservation. This results in a more balanced reserved bandwidth distribution.
Module 5 |
125
Careful network planning is essential when working with RSVP-TE bandwidth reservations. Network designers need to
ensure that LSPs are distributed over different paths in the most efficient manner possible.
Even with the most elaborate network design, situations might arise where an LSP or LSPs cannot be established as a
result of insufficient reservable bandwidth on the links.
The LSP Soft Preemption feature allows the operator to define relative priorities for LSPs that use bandwidth
reservations. This lets a more important LSP, with a better priority value, to preempt (or bump) another, less
important LSP, to free up the bandwidth that it requires on the links.
To accommodate this, LSP paths are given specific priority values to denote their importance. In addition, bandwidth
reservations are performed more granularly, at 8 different priority values.
The unreserved bandwidth values at each priority level are signaled in IGP TE updates, within the Unreserved_BW SubTLV.
Module 5 |
126
LSP paths have two priority values associated to them: Setup and Hold Priorities.
Both the setup priority and the hold priority indicate with their relative values whether an LSP can preempt another
LSP. The lower the priority value, the higher the importance. The setup priority indicates how important the LSP is to
preempt the other LSPs, while the holding priority indicates how the weight of that LSP to hold on to its reservations on
the links.
The RSVP PATH message includes a SESSION_ATTRIBUTE object that indicates the setup and hold priorities of the LSP,
along with other fields.
The default value for the Setup priority is 7 (the LSP can never
preempt another existing LSP).
The default value for the Hold priority is 0 (once established, the
LSP can never be preempted by another LSP).
priority 2 2
exit
Module 5 |
127
The default setup priority for an LSP is 7, which is the worst, or least important, priority value for an LSP. With this
priority value, the LSP cannot preempt any other LSPs that are already established.
The default hold priority for an LSP is 0, which is the best, or most important, priority value for an LSP. With this
priority value, no other LSP can preempt this LSP once it is established.
It is not possible to configure a setup priority that is numerically higher than its hold priority. If this were the case for
two different LSPs contending for bandwidth on the same links, undesirable conditions would occur, where the two LSPs
would continuously preempt each other in an indefinite loop.
The recommended practice is to set both priority values equal, for simpler management. When the routers signal an
LSP, they measure the unreserved bandwidth at their desired setup priority. Then they compare the setup priority at
that level to the hold priority set by existing LSPs. If the new LSP has a higher setup priority and needs the bandwidth
reserved by an low hold priority LSP, the new LSP can preempt the old. The unreserved bandwidth shown in the opaquedatabase represents bandwidth dedicated to a specific hold priority.
For example, LSP A, with setup and hold priorities = 5, reserves 600M of bandwidth on a 1G link. Without
oversubscription, this leaves 400M bandwidth unreserved at P5 and lower. Since higher setup priorities (0-4) can
preempt a hold priority of 5, P0-P4 show all of the links bandwidth, 1000M, as unreserved.
LSP B, with setup and hold priorities = 3, needs 500M of bandwidth on the same link as LSP A. The Head-End checks the
TED for links that (1) provide the needed bandwidth, and (2) can be preempted, if necessary. Since both LSPs must use
the same link, the Head-End determines that LSP B, with setup priority 3, beats LSP A, with hold priority 5. At hold
priority 3, all of the links bandwidth is available, so the Head-End preempts LSP A to obtain the necessary bandwidth
for LSP B. Now, only P0-P2 show all the links bandwidth unreserved, and P3-P7 show only 400M unreserved.
LSP A stays down, as CSPF cannot find a path with the necessary amount of unreserved bandwidth available.
Unreserved Bandwidth
on links:
R1-R2
R2-R6
P2 = hold priority
Module 5 |
128
Initially, both of the links in the example above have 1000 Mbps of unreserved bandwidth. In turn, the unreserved
bandwidth values per each priority level are also set to 1000 Mbps (1,000,000 Kbps).
An LSP is configured with 400 Mbps of bandwidth and a priority value (both setup and hold) of 2.
As a result, the unreserved bandwidth values at priority level 2 and worse priority levels (3-7) are decreased to 600
Mbps. If another LSP with priority between 2-7 wants to reserve bandwidth, it can only do this up to 600 Mbps.
On the other hand, an LSP with a priority value of 0 or 1 can still reserve up to 1000 Mbps on the link. This is because it
can preempt the existing LSP at priority level 2, and clear its bandwidth to make room for its own.
Module 5 |
129
The examples on this and the following series of pages are used to illustrate the use of LSP priorities and soft
preemption.
In the figure above, LSP 1 is established on the shortest IGP path between router R1 and router R6 with a bandwidth
reservation of 600 Mbps. The LSP is configured with a priority value of 2.
The unreserved bandwidth values are updated on the links that the first LSP traverses, as shown in the figure.
Module 5 |
130
A second LSP is configured on router R1, requesting for 300 Mbps of bandwidth at priority level 5. The bandwidth is
available on the shortest IGP path, so LSP 2 is also established on the same path.
At this point,
- an LSP with a priority between 5-7 can only reserve 300 Mbps,
- an LSP with a priority between 2-4 can reserve 600 Mbps,
- an LSP with a priority between 0-1 can still reserve 1,000 Mbps,
on the shortest IGP path.
Module 5 |
131
A third LSP is configured on router R1, requesting 500 Mbps at priority level 7. As the figure above illustrates, this
bandwidth is not available at that level on the shortest IGP path. Therefore, CSPF calculates an alternate path for this
LSP, going over the hops R1-R3-R5-R6. The unreserved bandwidth value at P7 is updated on the lower path.
Module 5 |
132
Recall that the default setup priority for all LSPs is 7, and the default hold priority is 0, which does not allow for
preemption between the LSPs.
If these default values were used, a fourth LSP that is asking for 600 Mbps of bandwidth would not get established,
because of insufficient reservable bandwidth on any of the paths.
The following pages resume the story presented on the previous pages using the priority values.
Module 5 |
133
Module 5 |
134
LSP 4 is established over the shortest IGP path chosen by CSPF. The unreserved bandwidth values at priority level
between 3-7 drop to zero. This means that all the LSPs at a worse priority level than 3 must be preempted.
In this example, LSP 2 must be preempted because there is no more room for the 300 Mbps it reserved on the shortest
IGP path.
Module 5 |
135
When the preemption process is initiated, LSP 2 is not immediately torn down, so as to avoid service impact.
CSPF searches for an alternative path for the LSP. The lower path has the required 300 Mbps of bandwidth at Priority
level 5, so the new LSP 2 gets established over that path. The data traffic is then switched over to the new LSP and
the old LSP is torn down, as imposed by the Make-Before-Break behavior introduced earlier.
As opposed to the scenario presented in one of the previous pages with the default priorities, all LSPs are eventually
established using the preemption techniques.
. . . . . . . . . . . . . . . . . . . . . . .
Len: 32
UNRSRVD_CLS0 :
Kbps P1: 1000000 Kbps P2: 600000 Kbps P3:
Kbps P5:
0 Kbps P6:
0 Kbps P7:
Module 5 |
136
0 Kbps
0 Kbps
The Make-Before-Break state of an LSP is displayed in the show router mpls lsp <lsp-name> path [<pathname>] detail command output.
In the first figure above, the last MBB was initiated by the LSP Soft Preemption process and was successful. The time
that the switchover to the new LSP path took place is indicated in the output. The old metric value, which is calculated
by the IGP metric values of the links on the old LSP path by default, can also be seen.
The unreserved bandwidth values per priority level are visible in the TED detail output, as presented in the second
figure above. As mentioned, these values are propagated to other routers in the network by means of IGP TE updates.
Module 5 |
137
A global preemption-timer, which governs the maximum interval that an LSP can conclude its make-before-break
process, is defined. This is set to 300 seconds by default.
When the preemption process kicks off, the first CSPF re-calculation attempt is performed after 30 seconds, by default.
This interval is determined by the retry-timer, which is configurable per LSP. If an available path is found, the data
traffic is switched over to it in an MBB fashion.
If a new LSP path is not found at the first attempt, CSPF can keep making new calculations at retry-timer intervals.
During this time, the old LSP path is still not torn down and continues forwarding the traffic.
If, for some reason, no new path is found before the preemption-timer expires, the LSP path is set to an operationally
down state and starts discarding traffic.
Module 5 |
138
To regulate the actual traffic flows on the data plane, several models have been proposed and used.
An alternative method to the Differentiated Services model presented briefly on this page is the Integrated Services
model, described in RFC 1633. The Integrated Services model aims at maintaining dedicated Quality of Service
characteristics for each traffic flow, on all the devices that flows are forwarded on. This model has not found
widespread use because of serious limitations on scalability. The routers need to keep track of QoS characteristics for
individual flows, which can be a considerable process and memory intensive task for the routers.
The Differentiated Services model aims to solve these scalability issues by aggregating the numerous microflows into a
limited number of macroflows. The classification of microflows into macroflows can be done using several fields or
markings in the packet headers. The macroflows are named as forwarding classes in the Alcatel-Lucent Service Router
parlance. Up 8 Forwarding Classes can be defined and used on the Service Routers. Packets that belong to specific
forwarding classes can be subject to separate rate limiting, queuing, buffering, policing, and shaping characteristics,
based on the policy configurations. These procedures are all performed in the data plane of the router, where the
actual customer traffic flows through.
The Differentiated Services model is mentioned briefly to explain the main concepts for Traffic Engineering here.
A more elaborate discussion on DiffServ and other related topics can be found in the Quality of Service course of the
SRC program.
Default
Class
Type
High
Priority
(Premium)
Assured
Best
Effort
FC
ID
FC Name
FC
Designation
Definition
Network
Control
NC
High-1
H1
Expedited
EF
High-2
H2
Low-1
L1
Assured
AF
Low-2
L2
Best Effort
BE
Module 5 |
139
The SR/ESS supports eight internal forwarding classes. The graphic shows the default definitions. Users can create QoS
policies that determine which traffic will be mapped on ingress and egress into these forwarding classes. As we have
seen previously, Classifiers can inspect PDUs and many different layers of the OSI models to ensure that the data traffic
is properly marked as it enters and leaves the forwarding classes.
Think of forwarding classes as virtual pipes, configured as services between PE devices in the core of a network. These
macroflows can further be categorized into three class types:
High Priority
High priority forwarding classes are serviced before other forwarding classes. These forwarding classed (FC ID 4, 5, 6,
and 7) are high priority because they are intended for real-time traffic.
Assured
Assured forwarding provides services with a committed information rate (CIR) and a peak information rate (PIR) in the
same way that traditional edge WAN services like Frame Relay do. Assured FC traffic is normally marked as high-priority
or low-priority so that when the network experiences congestion, low priority traffic becomes essentially discard
eligible, and will be discarded in favor of high priority traffic.
Best Effort
The Best Effort forwarding classes do not guarantee delivery. This class is best effort because, at best, the network
will treat packets in this class like low priority packets in the Assured forwarding class.
Module 5 |
140
Diffserv Aware Traffic Engineering (DiffServ-TE), defined in RFC 3564, enables more granular bandwidth reservations,
based on class type.
By default, all LSPs reserve bandwidth from a common pool, which is determined by the maximum reservable
bandwidth defined on each individual link. Different priority levels can be defined, as presented earlier in the section,
but this lacks class differentiation between the LSPs. DiffServ-TE takes the bandwidth reservations one step further by
enabling the option to define separate pools of reservable bandwidth, based on class type.
It is important to note that DiffServ-TE is also a purely control plane mechanism. It does not have a direct impact on
the operations performed on the data plane of the router.
By careful design, the forwarding class definitions in DiffServ-based QoS applied on the data plane can be correlated
with the class definitions in the RSVP DiffServ-TE context applied on the control plane. This would obviously bring the
ultimate benefit in overall Traffic Management.
Module 5 |
141
An important definition in DiffServ-TE is Class Type. A Class Type can be perceived as a network-wide forwarding class,
defined in the context of RSVP-TE bandwidth reservations. Similar to QoS Forwarding Classes, up to 8 Class Types can
also be defined in the DiffServ-TE context.
In the Diffserv-TE context, the Maximum Reservable Bandwidth of a link can be divided into separate pools per Class
Type. The different models that can be used to perform this division is introduced later in the section.
In turn, a certain Class Type can be configured for an LSP at the Head-End. Using DiffServ-TE, the LSP reserves
bandwidth from the pool that is allocated for its specific Class Type. In order to accomplish this, the Class Type
information for an LSP is signaled within the RSVP PATH message. This way, all routers along the LSP path are made
aware of which Class Type pool they should reserve the bandwidth from.
The possible Class Type values are between CT0 and CT7. For backwards compatibility with routers that do not support
DiffServ-TE, the default Class Type 0 is not indicated in the RSVP PATH messages. For routers that support DiffServ-TE,
this means that if the Class Type information is missing the PATH message; CT0 is implied.
Class based forwarding over MPLS LSPs allows the user to direct service packets into specific LSPs based on the
packets forwarding class
Mapping of FCs to LSPs is done at the SDP level
Traffic is classified on ingress using a SAP ingress policy. The traffic is then assigned a FC based on the policy.
Under the SDP, the FC is then mapped to an LSP
There is a verification command under the SDP configuration context to ensure that the FC to CT mapping in the
SDP is the same as the FC to CT mapping in the RSVP configuration:
config>service>sdp>class-forwarding>enforce-diffserv-lsp-fc
The default behavior is NOT to check
The mapping of CT to FC is done under the RSVP configuration
config>router>rsvp>diffserv-te# fc be 0
Module 5 |
142
The above slide illustrates the default mode of operation (even without DiffServ-TE is enabled).
All the LSPs have an implicit Class Type value of CT0 and they can reserve bandwidth at 8 different priority values. The
process is as explained earlier in the section, in LSP Soft Preemption.
Module 5 |
143
DiffServ-TE takes the granularity in bandwidth reservations one step further, by introducing the Class Type concept.
By extending Class Types from the default CT0 to CT7, and combining them with the 8 different priority levels that can
be assigned to LSPs, a bandwidth reservation matrix is achieved as illustrated in the figure above.
Theoretically, this would result in 64 different combinations for an LSP when making bandwidth reservations.
In practice, this is not really the case, as explained on the following page.
Module 5 |
144
The IETF (Internet Engineering Task Force) decided to limit the number of usable LSP Class Type-Priority combinations
to 8 (after heated discussions). The regulation is described in RFC 4124.
Therefore, the 8 CT-Priority combinations must be carefully chosen during the initial network design phase.
To streamline the implementations, each CT-Priority combination is assigned to a separate entity, named TE Class. The
TE Class definitions must be consistently configured on all the DiffServ-TE capable routers in the network.
CT0 is by common convention assigned to LSPs that carry traffic in the lowest QoS priority class, named Best Effort.
Relatively more important traffic classes are assigned increasing Class Type values, CT1, CT2, and so on.
Although the decision depends totally on the specific network design, generally, it might be a good idea to associate
numerically higher (worse) priority levels with lower Class Types (CT0, CT1, and so on), if preemption is required
between the LSPs from different Class Types. Certain examples are presented later in the section to demonstrate in
which cases this approach would apply.
Module 5 |
145
Another important decision in DiffServ-TE deployments is the choice of the bandwidth allocation model.
A bandwidth allocation model determines how the Maximum Reservable Bandwidth will be divided across different pools
dedicated for each Class Type.
Two models have been defined and are supported by the Service Router:
Maximum Allocation Model (MAM)
Russian Dolls Model
These models are explained in the following pages with definitive examples.
In the RFC and the Service Router CLI, the amount of bandwidth allocation defined for a Class Type is called a
Bandwidth Constraint (BC).
Module 5 |
146
Using the Maximum Allocation Model (MAM), each Class Type is assigned a fixed percentage of the Maximum Reservable
Bandwidth on each RSVP-TE link. This allows for a more straightforward bandwidth allocation scheme, with clear
separation between Class Types.
The LSPs in each Class Type can reserve bandwidth from their dedicated pool.
No bandwidth sharing is allowed between different Class Types. This means an LSP in a certain CT is not allowed to
reserve bandwidth from a pool that is designated for another CT.
A bandwidth constraint of zero can be defined for unused Class Types. The sum of the bandwidth constraints for all
Class Types cannot exceed 100.
Module 5 |
147
The Russian Dolls Model (RDM) is named after the infamous decorative items invented in Russia, also called matryoshka.
A matryoshka doll is a set of wooden dolls of decreasing sizes placed one inside the other.
This naming convention is intuitive, as the visualization of the Class Types in RDM resembles the nested structure in
matryoshka dolls. Only 3 Class Types are shown in the figure above for the sake of simplicity.
In the Russian Dolls Model, a lower CT (for example, CT0) is allowed to reserve from the unused portion of bandwidth of
the pools defined for the upper CTs (CT1, CT2, and so on). This model allows bandwidth sharing between different Class
Types, as opposed to the Maximum Allocation Model. This can be useful in cases where a hierarchical model needs to be
deployed for bandwidth reservations in the network.
As an example, CT0 can be assigned to LSPs carrying the least important type of traffic, namely best effort traffic.
None, or very low portion, of the Maximum Reservable Bandwidth can be defined for CT0, and the LSPs in this Class
Type can be allowed to reserve bandwidth from the pools belonging to the upper classes, as long the bandwidth is not
used by those classes. If, for example, an LSP at CT0 has reserved bandwidth from the CT1 pool, and an LSP at CT1 must
be established requiring that bandwidth, the LSP at CT0 will be preempted to make room for the more important LSP.
For this reason, correct priorities must also be carefully assigned to LSPs belonging to different Class Types.
A case study is covered in the following pages to illustrate the use of both bandwidth allocation models.
Requirements are:
y Voice LSPs are considered as more important as they carry more delay
sensitive traffic.
y Voice LSPs should never be driven away from their shortest path because of
Data LSPs.
y A Voice LSP should never preempt another Voice LSP.
y A Data LSP should never preempt another Data LSP.
Module 5 |
148
The case study above covers a scenario for a fictitious service provider providing two types of services: Voice and Data.
The DiffServ-TE feature will be used with RSVP-TE LSPs that are going to be created for each type of service.
The general guidelines and requirements are as follows:
1. Voice LSPs are considered more important because they carry more delay sensitive traffic.
2. Voice LSPs should never be driven away from their shortest path because of Data LSPs.
3. A Voice LSP should never preempt another Voice LSP.
4. A Data LSP should never preempt another Data LSP.
Item #1 is assured by assigning the Voice Class to a higher Class Type in DiffServ-TE (and higher Forwarding Class in data
plane QoS).
Item #2 is assured by assigning a lower numerical (better) priority value for Voice traffic.
Item #3 is assured by assigning the same priority value for all Voice LSPs.
Item #4 is assured by assigning the same priority value for all Data LSPs.
A bandwidth constraint of 20 (%) is defined for each Class Type. The actual amount of reservable bandwidth assigned
for the Class Types depends on the allocation model that is being used.
The case study is repeated for both bandwidth allocation models (MAM and RDM) in the following pages.
Module 5 |
149
Module 5 |
150
A Data LSP is configured with Class Type 0, preemption priority 1, and bandwidth 200 Mbps. It is established on the
shortest IGP path, and occupies the entire pool that is designated for CT0.
Module 5 |
151
Another Data LSP (LSP 2) is configured with the same CT and priority values and 100 Mbps of bandwidth.
There is no more room in the dedicated CT0 pool on the shortest IGP path, thus the LSP is established on the longer
path, occupying half of the CT0 pool there.
As is illustrated above, an LSP at a certain Class Type is not allowed to reserve bandwidth from the pool that is
dedicated to another Class Type, even if the reservable bandwidth is not in use by any other LSP at that time. This can
be seen as a less efficient way of reserving bandwidth with the Maximum Allocation Model, as opposed to its
straightforward nature.
Module 5 |
152
If a Voice LSP needs to be established on router R1 to router R6, it has the dedicated reservable bandwidth available in
the CT1 pool. In the example above, a voice LSP is established with 100 Mbps, taking up only half of the CT1 pool. The
other half of the CT1 pool can only be used by another Voice LSP in the same CT class.
Module 5 |
153
The slide above illustrates the bandwidth reservation pools, if the Russian Dolls Model is used.
Using this model, Data LSPs in Class Type 0 are allowed to overflow to the CT1 pool if there is unused bandwidth in that
pool. However, a Voice LSP can preempt a Data LSP occupying its bandwidth pool, if necessary.
Module 5 |
154
A Data LSP is configured with 200 Mbps of bandwidth constraint. It is established on the shortest path, taking up all the
bandwidth in the CT0 pool.
Module 5 |
155
Another Data LSP is configured with 100 Mbps of bandwidth constraint. Unlike the Maximum Allocation Model, it is also
established on the shortest IGP path, reserving available bandwidth from the CT1 pool.
Module 5 |
156
157
Enabling DiffServ-TE
Module 5 |
158
Enabling DiffServ-TE in an already deployed RSVP-TE based MPLS network might require additional maintenance tasks,
because an administrative shutdown of the entire MPLS context is required. This can introduce service downtime,
depending on the method of migration used. Certain automatization techniques, such as custom developed scripting
tools, can be used to streamline the migration process and minimize downtime. Careful planning is required, regardless
of the preferred migration method.
DiffServ-TE is enabled in the RSVP context with the bandwidth allocation model of choice. MAM (Maximum Allocation
Model) is the default model. Changing the allocation model from one to another also requires a shutdown of the MPLS
context.
The two essential configuration items, class-type-bw and te-class, are explained in the following pages.
. . . . . . . . . . . . .
Bandwidth Constraints for
BC0 : 200000
BC1 : 200000
BC2 : 0
BC3 : 0
. . . . . . . . .
Class Types (Kbps)
BC4: 0
BC5: 0
BC6: 0
BC7: 0
. . . . . . . . . . . . .
Bandwidth Constraints for
BC0 : 400000
BC1 : 200000
BC2 : 0
BC3 : 0
. . . . . . . . .
Class Types (Kbps)
BC4: 0
BC5: 0
BC6: 0
BC7: 0
Module 5 |
159
The Bandwidth Allocation (bandwidth pools) for each Class Type is defined with the class-type-bw command. The
percentage values of the Maximum Reservable Bandwidth can be specified in any order for all the 8 Class Types.
If a certain Class Type is not used, a value of 0 can be specified for it in the configuration. The sum of all the
configured bandwidth percentages cannot exceed 100.
The configuration of the bandwidth allocation percentages per Class Type is irrespective of the allocation model.
However, the actual bandwidth constraints are calculated depending on the allocation model specified when enabling
DiffServ-TE.
Using the Maximum Allocation Model, each Class Type is given a fixed, dedicated bandwidth pool. For this reason, the
bandwidth percentage values translate directly into the values seen in the figure on the left. Both CT0 and CT1 are
allocated 200 Mbps of reservable bandwidth, separately.
Using the Russian Dolls Model, bandwidth sharing is allowed between the Class Types. For this reason, the bandwidth
constraint for CT0 is calculated as the sum of the actual reservable bandwidth for both CT0 and CT1 classes; that is,
400 Mbps. (Recall that, in this model, a CT1 LSP should be able to preempt a CT0 LSP occupying bandwidth in the CT1
pool).
Module 5 |
160
The Bandwidth Constraints calculated by the router for each Class Type and for each RSVP link are advertised in the
network within the IGP TE updates. For this purpose, a new Sub-TLV has been introduced with the intuitive name,
Bandwidth Constraints. The bandwidth allocation model used is also indicated in the Sub-TLV.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sub-TLV: 17
Len: 36
TELK_BW_CONST:
BW Model : MAM
BC0: 200000 Kbps BC1: 200000 Kbps BC2:
0 Kbps BC3:
0 Kbps
BC4:
0 Kbps BC5:
0 Kbps BC6:
0 Kbps BC7:
0 Kbps
Module 5 |
161
Recall that a TE class is one of the 64 possible combinations of the Class Types and priorities.
The configuration of the TE classes must be consistent throughout the network to avoid LSP setup problems.
Module 5 |
162
After enabling DiffServ-TE in the network, extra care must be taken when configuring the priority and class-type values
for the LSPs. It is still the best practice to use the same setup and hold priority for the LSP, as mentioned in the Soft
Preemption topic in this section.
With these principles in mind, the configured priority and Class Type values must correspond to one of the TE classes
defined in the RSVP DiffServ-TE context, as explained in the previous page. LSP establishment failures can occur if
errors are present. An example is included in the next page.
If a Class Type is not configured, it is implicitly assumed that the LSP belongs to CT0.
The following error is displayed in the CLI if the configured ClassType and priorities of an LSP do not map correctly to a TE-Class
configured in the RSVP context:
------------------------------------------------------------------------------LSP mismatch Path fully_loose
------------------------------------------------------------------------------Adm State
: Up
Oper State : Down
Path Name
: fully_loose
Path Type
: Primary
Path Admin : Up
Path Oper
: Down
OutInterface: n/a
Out Label
: n/a
Path Up Time: 0d 00:00:00
Path Dn Time: 0d 00:00:49
SetupPriori*: 6
Hold Priori*: 6
Preference : n/a
Bandwidth
: 100 Mbps
Oper Bw
: 0 Mbps
Hop Limit
: 255
Class Type : 1
...................................
........................
Failure Code: invCtAndSetupAndHoldPri
Failure Node: 10.10.10.1
Module 5 |
163
The CLI output shown above illustrates a possible configuration error caused by specifying incompatible priority and
Class Type values for the LSP. Since the combination does not correspond to a configured TE-Class, the LSP path is set
to an operationally down status, with the failure code indicating the source of the problem.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bandwidth for TE Class Types (Kbps)
TE0-> Resv. Bw
: 0
Unresv. Bw
: 200000
TE1-> Resv. Bw
: 200000
Unresv. Bw
: 0
TE2-> Resv. Bw
: 0
Unresv. Bw
: 0
TE3-> Resv. Bw
: 0
Unresv. Bw
: 0
TE4-> Resv. Bw
: 0
Unresv. Bw
: 0
TE5-> Resv. Bw
: 0
Unresv. Bw
: 0
TE6-> Resv. Bw
: 0
Unresv. Bw
: 0
TE7-> Resv. Bw
: 0
Unresv. Bw
: 0
Module 5 |
164
The reserved and unreserved bandwidth values for each TE class can be observed in the show router rsvp
interface <interface_name> detail command output. If the figures change as a result of reservation or clear
actions, the updated values are propagated to the network within IGP TE update messages.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sub-TLV: 8
Len: 32
UNRSRVD_CLS0 :
P0: 200000 Kbps P1:
0 Kbps P2:
0 Kbps P3:
0 Kbps
P4:
0 Kbps P5:
0 Kbps P6:
0 Kbps P7:
0 Kbps
Module 5 |
165
The unreserved bandwidth values for each TE class are propagated in IGP TE updates. However, no additional TLV is
defined to convey this information. On the contrary, the existing Sub-TLV 8 (Unreserved Bandwidth) per priority level is
still used after DiffServ-TE is enabled. This requires an implicit change in nomenclature while interpreting these values:
P0 stands for TE0, P1 stands for TE1, and so on.
Module 5 |
166
LAB 5 Section 5.2 and 5.3 DiffServ TE LSP MAM and RDM
Section Summary
Module 5 |
167
A bandwidth constraint can be specified for LSP paths in the Head-End LSP configuration.
If CSPF is enabled for the LSP, it looks for an available path in the network that satisifies the bandwidth constraint.
A CAC (Connection Admission Control) check is performed on all the routers along the LSP path to verify the
requested amount of bandwidth before delivering the RSVP PATH message.
The te-threshold-update option can be enabled in the RSVP context to optimize the amount of IGP TE updates
that are flooded in the network.
Custom up and down thresholds can be defined when using the te-threshold-update feature.
Additionally, configuration options exist to trigger IGP TE updates in case of CAC failures and periodically using a
specified update timer.
The bandwidth reservation styles determine how bandwidth is reserved for multiple LSP paths that belong to the
same LSP and traverse through a shared link.
The Shared Explicit reservation style requires that routers reserve the maximum bandwidth constraint defined for
any of the LSP paths that belong to the same LSP on the shared link.
The Fixed Filter reservation style requires that routers reserve the sum of the individual bandwidth constraints
defined for all the LSP paths on the shared link.
Make-Before-Break is targeted to reduce the service downtime when a new LSP path needs to be configured for an
existing LSP path.
The least-fill feature allows CSPF to choose the path with the least amount of reserved bandwidth when there are
multiple equal cost paths. This is an optimization attempt towards achieving more balanced bandwidth distribution
over the alternative links.
Section Summary
Module 5 |
168
LSP Setup and Hold Priorities can be used to enable preemption between different LSP paths.
The priority values range from 0 to 7.
0 is the best priority, given to the most important LSPs.
7 is the least priority, given to the least important LSPs.
Best practice is to set the setup and hold priorities for simpler maintenance and comprehension.
An LSP with a better priority level can preempt LSPs with worse priority levels if they are contending for the same
RSVP-TE bandwidth resources on the same links.
The DiffServ-TE feature enables bandwidth reservations, based on LSP Class Types, with preemption priorities.
The combination of a Class Type and a preemption priority is called a TE Class.
Up to 8 TE Classes can be defined, which must be consistent throughout the RSVP-TE based network.
There are two bandwidth allocation models to determine the bandwidth allocation pools per Class Type.
The Maximum Allocation Model provides separation between Class Types, with fixed bandwidth allocation values for
each Class Type. Preemption is not required between LSPs from different Class Types.
The Russian Dolls Model allows for bandwidth sharing between different Class Types. As a result, preemption is
required between LSPs from different Class Types.
Section Objectives
Module 5 |
170
The LDP-over-RSVP solution used to provide Traffic Engineering in Hierarchical IGP networks is discussed in this section.
The theoretical and configurational principles of LDP-over-RSVP are explained.
Module 5 |
171
Using a flat (single area) IGP network is simple and straightforward from a design and operational perspective.
However, certain scalability issues might arise as the number of routers in the area grow (usually to the scale of
thousands of routers). The number of routes to be propagated and processed by the routers might become resource
intensive for the routers and can have an effect on their performance.
Deploying RSVP Traffic Engineering in a single area is also fairly easy to implement. On the other hand, having a full
mesh of RSVP-TE LSP requirements can be resource intensive, especially for the transit LSRs. Routers need to maintain
session states for thousands of LSPs in this case.
Module 5 |
172
The solution to the scalability problems presented on the previous page is introducing hierarchy into the IGP design.
In relation to this, network designers might want to deviate from a single area and split the IGP domain into multiple
areas. In a hierarchical IGP network, the routing information is self-contained within each area. As a result, the routers
that are internal to the area need to keep track of the topology changes only within their own area. The communication
between different areas is handled by the Area Border Routers that reside on the boundary between two areas.
Only the OSPF hierarchy is presented in this example for simplicity. IS-IS has a slightly different and simpler approach
towards area hierarchy, which is composed of only 2 levels. The main principles of the LDP-over-RSVP solution also
apply to the IS-IS protocol. For a full discussion of the design and operational principles of multiple area IGP networks,
please refer to the SRC Interior Routing Protocols course.
Scalability issues are addressed by introducing hierarchy into the IGP network. On the downside, Traffic Engineering
cannot be performed end-to-end across multiple areas. Recall that the Type 10 Opaque LSAs used to convey Traffic
Engineering have a local area scope; they are not propagated to routers outside the area that they were originated in.
Module 5 |
173
The above slide illustrates the limitation mentioned on the previous page.
In a multiple area IGP network, Traffic Engineering information within each area cannot cross the area boundaries
delimited by the Area Border Routers. Thus, the Traffic Engineering Database on PE1 does not contain any entries about
the links that reside in other IGP areas.
If an LSP is created on PE1 towards PE2 and CSPF is enabled, CSPF will issue a No CSPF Route Destination error
because it will not have the information on how to reach PE2, which resides in another area. The implication of this is
that Traffic Engineering features are related to the use of CSPF and administrative constraints (administrative groups,
TE metric, SRLG, bandwidth reservations, Fast Reroute, and so on).
Note that an IGP-directed LSP, as presented in Module 4, or an LDP-based tunnel, as explained in Module 3, can still be
used to achieve end-to-end transport tunnel connectivity, but with the lack of TE related features.
LDP-over-RSVP tunneling is the solution to this limitation, and is presented in the following pages.
Module 5 |
174
The above slide illustrates that, in a hierarchical network, Traffic Engineering features can be used separately within
each area. CSPF based LSPs can be created, extending to the boundaries of an area.
In the figure above, a CSPF based LSP originates on PE1 and terminates on ABR1.
Another CSPF based LSP originates on ABR1 and terminates on ABR2.
A third LSP is configured on ABR2 that terminates on PE2.
Without an additional mechanism, these three LSPs are unaware or unrelated to each other. For a contiguous
forwarding path from PE1 to PE2, a special method is required stitch or interconnect these separate CSPF based LSPs.
This is presented on the next page.
Module 5 |
175
The interconnection of the separate CSPF based LSPs in the figure above is accomplished by T-LDP.
T-LDP sessions are configured between each PE-ABR and ABR-ABR pair to associate the individual LSPs with each other.
Recall that Targeted LDP sessions can run between non-directly connected peers, which is perfectly suited for this
application.
Module 5 |
176
The above slide illustrates end-to-end service connectivity provided by LDP based transport tunnels. LDP relies solely on
the routing information provided by standard IGP, and is devoid of any sophisticated Traffic Engineering features.
Module 5 |
177
In a hierarchical network, the Service Provider can add a new dimension to inter-area service offerings by introducing
the LDP-over-RSVP solution. From a forwarding perspective, the LDP transport tunnel can be encapsulated within an
RSVP-TE based LSP configured in each area. The individual RSVP-TE based LSPs can fully enjoy the benefits of Traffic
Engineering within their respective areas. This enhancement can bring quality improvements in the service offerings
provided to customers.
Module 5 |
178
From a labeling perspective, the LDP-over-RSVP solution is implemented using a three label MPLS stack.
This generic approach is common to both Layer and Layer 3 VPN services, such as VLL, VPLS, and VPRN.
The signaling of the labels in the LDP-over-RSVP stack is as follows:
Within each area, RSVP-TE based LSPs are created, involving the PE routers, ABRs, and the transit routers inside the
area. The labels signaled for these LSPs are used as the outermost labels in the stack and encapsulate the LDP
traffic.
Within each area, T-LDP sessions are created between the routers at the area boundaries (PE-ABR and ABR-ABR
pairs). LDP transport labels are exchanged over these sessions. Note that this is different from the traditional
implementation, in which Link LDP is used to signal the transport labels. These labels are located in the middle of
the stack and encapsulate the VPN Service Labels.
The bottom label in the stack is the VPN Service Label. VPN Service Labels are exchanged by the PE routers that
have the VPN services configured on them. Separate service labels are signaled for each customer VPN service.
These labels encapsulate the customer traffic, namely the VPN Service Payload. As mentioned in Module 2, VPN
Service Labels are signaled by T-LDP for Layer 2 services, and by MP-BGP for Layer 3 services.
Module 5 |
179
The above slide illustrates a representation of end-to-end data forwarding for a VPN service, using the LDP-over-RSVP
solution. The illustration shows the forwarding of traffic from PE1 to PE2 only, for the sake of clarity. A similar process
also occurs in the opposite direction for bi-directional traffic.
The VPN service label is signaled between the two PE routers, using the methods described in the previous page, and is
not modified by any of the routers along the forwarding path. PE1 pushes the VPN label onto the service payload, which
is indicated as Data, and is encapsulated by two other labels. PE2 uses this label to locate the VPN service that the
packet belongs to.
The LDP labels are negotiated by the T-LDP sessions running between each router pair.
PE1 and ABR1 negotiate a label called LDP1 with each other. PE1 pushes this label onto the stack, which is
encapsulated by the RSVP label RSVP11.
The LDP label is not touched by LSR1, since it is a transit LSR and can only process the top RSVP label in the stack.
The RSVP tunnel terminates on ABR1, so the label RSVP12 is popped. This exposes the LDP label LDP1, which is
swapped with label LDP2 by ABR1, which is responsible for stitching.
The process goes on until PE2, creating end-to-end service tunnel connectivity using the LDP-over-RSVP methodology.
If TE features are required in each individual area, trafficengineering must be enabled in the IGP.
Network interfaces must be configured in the MPLS context.
The MPLS context must be administratively enabled.
The RSVP context must be administratively enabled.
Module 5 |
180
The general prerequisites mentioned earlier for configuring RSVP-TE based LSPs also apply in this context, as shown
above. The main difference is that the IGP domain is split into multiple areas, and area configuration should be
carefully performed on the routers.
RSVP-TE based LSPs are configured in each area between each of the
following pairs using any methods presented earlier in the module
(loose/strict hop, CSPF enabled/disabled, with/without constraints)
y PEABR
y ABRABR
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
181
One of the building blocks to implementing the LDP-over-RSVP solution is configuring RSVP-TE based LSPs in each area.
For uni-directional traffic, LSPs are created in both directions. Any of the desired Traffic Engineering features regarding
the use of administrative constraints and CSPF can be deployed in the LSP configurations.
Note that the configuration steps presented in this section are approached systematically, for clarity purposes. The
actual configurations do not necessarily have to follow this order.
Module 5 |
182
Another important aspect in the LDP-over-RSVP implementation is the configuration of T-LDP sessions. T-LDP sessions
are required to stitch the individual RSVP-TE LSPs on the Area Border Routers. Manual peer relationships must be
defined on each of the PE and ABR routers participating in the solution.
Recall that, with T-LDP, sessions can run between non-directly connected neighbors. This is usually the case between
PE-ABR and ABR-ABR router pairs, which is why T-LDP is used.
T-LDP exchanges labels for the System IP addresses between each T-LDP peer. In order to activate the tunneling of LDP
labels over RSVP, the tunneling keyword must be specified in the LDP peer configuration.
Note that, if Link LDP is also running in the network (configured under the interface-parameters sub-context of LDP),
the transport tunnels created by Link LDP take precedence over the LDP-over-RSVP tunnels. To overcome this default
behavior and use LDP-over-RSVP tunnels instead of Link LDP, the following configuration option can be activated:
A:R5# configure router ldp prefer-tunnel-in-tunnel
Routers exchange labels for their System IP addresses over the T-LDP
sessions.
PE1
targeted-session
peer 10.10.10.2
tunneling
exit
exit
ABR1
targeted-session
peer 10.10.10.1
tunneling
exit
exit
peer 10.10.10.4
tunneling
exit
exit
exit
PE2
ABR 2
targeted-session
peer 10.10.10.2
tunneling
exit
exit
peer 10.10.10.6
tunneling
exit
exit
exit
Module 5 |
183
targeted-session
peer 10.10.10.4
tunneling
exit
exit
An overall view of configuring T-LDP sessions in the example LDP-over-RSVP deployment is seen in the figure above.
Module 5 |
184
With the LDP-over-RSVP solution, the LDP prefixes are resolved by RSVP-TE LSPs reaching out to those prefixes (System
IP addresses of the PEs or ABRs). To facilitate this, the configuration item displayed above must be enabled inside the
IGP context on all the PE routers and ABRs.
After this point, RSVP-TE based LSPs are considered in the SPF
calculations to resolve the LDP advertised prefixes.
Verifying LDP-over-RSVP
Module 5 |
185
As explained in Module 3, the show router ldp bindings active command output displays the LFIB (Label
Forwarding Information Base) of the router that is used in data plane forwarding.
The output shown above is taken on router R1, which resides in OSPF area 1. There is an entry in the output for prefix
10.10.10.6/32, which belongs to router R6 and resides in area 2. Without LDP-over-RSVP, the EgrIntf/LspID field would
indicate a physical interface resolved by IGP, such as 1/1/4. With LDP-over-RSVP activated, this field indicates the
Tunnel ID of the LSP that resolves the LDP prefix 10.10.10.6/32.
The resolving LSP with the indicated Tunnel ID can be verified with the show router rsvp session command, as
seen above.
==========================================================================
Prefix
Op
IngLbl
EgrLbl
EgrIntf/LspId EgrNextHop
-------------------------------------------------------------------------. . . . . . .
10.10.10.6/32
Push
-131068
LspId 147
10.10.10.2
--------------------------------------------------------------------------
Module 5 |
186
To benefit from the LDP-over-RSVP solution, resiliency options, such as secondary LSP path or Fast Reroute Protection
features, can be used for each RSVP-TE based LSP. This might increase the quality of the service offerings provided to
business VPN customers by virtue of improved convergence times.
Aspects related to convergence and resiliency are covered in Module 6.
Module 5 |
187
Having a single Area Border Router for each area can present a single point of failure, which is not desirable.
An area can become isolated from the rest of the network, if the single ABR that it relies on experiences router failure.
For this reason, it might be a good idea to use multiple ABRs to mitigate the risks of prolonged service downtimes in the
event of ABR failure. An example is shown in the figure above.
To ensure proper functioning of LDP-over-RSVP solution in this scheme, PE routers should be made T-LDP peers with all
the ABRs in their area. Accordingly, PE routers should have RSVP-TE LSPs configured with all their ABRs. From a
forwarding perspective, the decision mechanism on each ABR choose the closest ABR to deliver the traffic.
In order to have inter-connectivity between all areas, the ABRs should have a full-mesh of RSVP-TE LSPs and T-LDP
peerings through the backbone network.
Module 5 |
188
LAB 5 Section 5.4 Configuring LDP over RSVP across OSPF Areas
Section Summary
Module 5 |
189
Scalability issues might arise in very large IGP deployments using a flat area design.
If hierarchy is introduced, end-to-end Traffic Engineering does not work across multiple areas.
The LDP-over-RSVP solution enables a segmented form of Traffic Engineering that is self-contained within each
area.
End-to-end service level connectivity for RSVP-TE LSPs is achieved with stitching performed by the ABRs using TLDP sessions.
A three-label stack is implemented for VPN Services using LDP-over-RSVP tunneling.
The outermost label is the RSVP label.
The middle label is the LDP label (signaled by T-LDP).
The bottom label is the VPN service label (signaled by T-LDP for Layer 2 services and by MP-BGP for Layer 3
services).
T-LDP peers must be configured between each PE-ABR and ABR-ABR pairs with the tunneling option.
The ldp-over-rsvp option must be enabled in the IGP context on all PE and ABR routers to be able to resolve the
LDP prefixes via RSVP LSPs.
Resiliency features, such as secondary LSP paths or Fast Reroute protection, can be used for RSVP-TE LSPs within
each area.
Multiple ABRs can be used to avoid a single point of failure and further improve the overall network resiliency.
Section Objectives
Module 5 |
191
The MPLS-shortcut features used to resolve BGP next-hops and native IP prefixes with either LDP or RSVP-TE tunnels is
explained in this section.
192.168.10.0/24
10.6.7.7 (toR7)
Module 5 |
192
BGP
The BGP (Border Gateway Protocol) is the dominating protocol used to interconnect Autonomous System entities
throughout the world. BGP has two types: external BGP (eBGP) and internal BGP (iBGP).
External BGP is used to exchange routing information between different Autonomous Systems (AS). The standard
definition of an Autonomous System is: A group of routers and other networking equipments under a common
administration. It can be perceived as a service provider network, or any other organization that runs its own custom
policies to communicate with the rest of the world. AS numbers are organized and distributed by the IANA (Internet
Assigned Numbers Authority).
In the example above, a service provider network with an AS number of 100 receives external routing information from
another AS 200 via external BGP. Router R6 acts as an Autonomous System Boundary Router (ASBR) that is responsible
for the interaction with the outside world. Router R6 receives several prefixes from router R7, the ASBR in AS 200. The
prefixes are depicted as 192.168.1.0/24 to 192.168.10.0/24 in this simplified example, but keep in mind that there can
be many more.
The next-hop for these prefixes in the FIB of router R6 is 10.6.7.7, which is the directly connected interface address of
router R7.
192.168.10.0/24
10.10.10.6
193
Router R6 has several options to propagate the external prefixes into its own Autonomous System. One option is to
perform route redistribution from BGP to IGP (OSPF or IS-IS), but this is not a preferred method. An important reason is
that the IGP databases might be overwhelmed by the amount of prefixes advertised by BGP. Interior Gateway Protocols
are not designed to handle extensive routing information. Another reason is that the valuable information carried in
extensive BGP protocol fields, the attributes, are lost during redistribution.
Therefore, the preferred method is to use the second type of BGP, which is internal BGP (iBGP). While external BGP
sessions typically run between directly connected peers, internal BGP sessions are typically formed between nondirectly connected peers, as shown in the figure above. eBGP sessions run between routers in different autonomous
systems, while iBGP sessions are formed between routers within the same autonomous system.
Router R6 advertises the prefixes that it learned from router R7 to router R1, over the established iBGP session. A
common convention here is to use a BGP configuration option next-hop-self on router R6, which changes the next-hop
information on the BGP prefixes from 10.6.7.7 to 10.10.10.6. This simplifies the resolution process within the
autonomous system, since the routers (should) already know how to reach to 10.10.10.6 (the system IP address of
router R6). Another option is to redistribute the 10.6.7.7 prefix into IGP on router R6, which requires additional policy
configuration.
In the example above, all traffic destined to the external prefixes will be directed to 10.10.10.6, according to the FIB
output on router R1. Router R1 performs a double lookup process to accomplish the forwarding. The 10.10.10.6 address
needs to be resolved to a directly connected IP address with a second lookup.
192.168.10.0/24
BGP
10.1.2.2 Indirect (toR2)
Module 5 |
194
The second lookup process mentioned in the previous page is illustrated in the figure above. The BGP next-hop address
10.10.10.6 is resolved to the directly connected IP address to router R2 (10.1.2.2), because it is the selected IGP nexthop.
The entries are marked Indirect, to refer to this double lookup process.
Using IP routing, all routers along the forwarding path should have
all the BGP prefixes and valid next-hop information in their FIB.
Because of certain BGP design rules, a full-mesh of iBGP sessions are
required within the core (covered in the SRC BGP course).
This can bring an additional burden on the core routers having to
deal with a large number of BGP routes.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
195
Using native IP routing, all the routers along the forwarding path must have proper routing information regarding the
external BGP prefixes.
Consider the traffic destined to the 192.168.1.0/24 network in the example above. Router R1 sends the traffic with a
destination IP address of 192.168.1.50. If router R2 does not have an entry for this address in its FIB, it will discard the
traffic because it will not know where to send the packets.
Therefore, to attain proper forwarding, all the routers in the network should acquire the external routing information
via iBGP, and store this information in their BGP and FIB tables. This might bring an excessive load on the core routers,
in cases where they must deal with a large number of BGP routes. (At the time of this writing, the full BGP Internet
Routing Tables consist of more than 300,000 entries).
Note that the full aspects of the BGP implementation are covered in the BGP course of the SRC program; only the basic
principles are mentioned here.
Module 5 |
196
To get rid of the iBGP full mesh requirement in the core network, and save the core routers (R2 and R4 in this example)
from having to process a large number of BGP routes, MPLS shortcut-tunnels can be used.
Using this feature, traffic destined to external destinations are encapsulated into an MPLS tunnel that extends to the
ASBR. Thanks to the inherent MPLS forwarding mechanism, the core routers (R2 and R4) only perform label switching,
and are oblivious to the encapsulated BGP traffic inside the tunnel.
Module 5 |
197
The MPLS tunneling feature is enabled with the igp-shortcut feature in the BGP context. There are several options
that influence the decision-making process on the router that performs the forwarding of packets:
ldp: The LDP based tunnel is used to encapsulate the BGP traffic. If an LDP tunnel is not available towards the BGP
next-hop, native IP forwarding is used.
rsvp-te: An RSVP-TE based LSP is used to encapsulate the BGP traffic. If there is no available RSVP-TE LSP towards
the BGP next-hop, native IP forwarding is used.
mpls: RSVP-TE LSPs are preferred over LDP based tunnels to encapsulate the BGP traffic. If neither is available,
native IP forwarding is used.
disallow-igp: For all the options above, disable the fallback option to native IP forwarding, in case an MPLS tunnel
is not available.
If only one of the shortcut options (LDP or RSVP-TE) is set, the router
can only use the specified type of tunnel.
Tunnel Preference values are fixed. RSVP-TE always has priority over LDP.
If multiple RSVP-TE LSPs exist to the same destination, the one with the
lowest metric is chosen.
If the metrics are equal, the LSP with the lowest Tunnel ID is chosen.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 5 |
198
Internally, RSVP-TE based tunnels are preferred over LDP because they are assigned a lower preference value. The
preference value for RSVP-TE based tunnels are 7 and LDP based tunnels are 9, as shown in the show router
tunnel-table output above. These values are fixed, and not configurable.
The metric values displayed in the table are calculated as follows:
For CSPF disabled LSP paths with one or more strict hops, the metric is set to 65535.
For CSPF disabled LSP paths with NO strict hops (IGP directed), the metric is equal to the total IGP cost of the
path.
For CSPF enabled LSP paths, the metric is equal to the total IGP cost of the CSPF calculated path.
For LDP based tunnels, the metric is equal to the total cost of the IGP path.
The metric value for an RSVP-TE based LSP can be set to a custom value as follows:
A:R1>config>router>mpls>lsp# metric [0..65535]
192.168.10.0/24
BGP
10.10.10.6 (Transport:RSVP LSP:148)
Module 5 |
199
The FIB output above displays the resolution of BGP next-hop addresses via an RSVP-TE LSP. The tunnel ID of the
resolving LSP is indicated in the output (148).
.
.
.
.
192.168.10.0/24
BGP
10.10.10.6 (Transport:LDP)
Module 5 |
200
The FIB output above displays the resolution of BGP next-hop addresses via an LDP Transport Tunnel.
MPLS shortcuts can also be used for prefixes learned via IGP.
Both LDP and RSVP-TE based tunnels can be used.
Used to tunnel routed traffic outside of the VPN services context.
Module 5 |
201
Traditionally, MPLS tunneling has been used to carry VPN service traffic or, optionally, to resolve BGP next-hops, as
previously presented. The prefixes learned via IGP are forwarded as native IP packets by default.
The routers allow the use of MPLS tunnels to resolve the prefixes learned via IGP. If the feature is enabled, the traffic
destined to these prefixes can then be encapsulated within the LDP or RSVP-TE tunnels. When the router has a transport
tunnel to the destination, it gives the tunnel priority over the IGP route, and places the tunnel endpoint in the FIB as
the next-hop, indicating the type of tunnel it chose.
192.168.10.0/24
OSPF
10.10.10.6 (Transport:RSVP LSP:148)
Module 5 |
202
If RSVP-TE LSPs need to be used as shortcut tunnels to encapsulate IP traffic, the configuration shown in the figure
above is required in the IGP context. Similar to shortcut feature for BGP next-hops, the LSP with the lowest metric is
chosen if multiple LSPs are available to the destination. If the metrics are equal, the Service Router chooses the LSP
with the lowest tunnel ID.
Module 5 |
203
If the Equal Cost Multiple Path (ECMP) feature is enabled, multiple LSPs with equal metric values can be installed in the
FIB. The router then forwards the incoming traffic over the multiple LSPs in a load-balancing fashion.
192.168.10.0/24
OSPF
192.168.10.0 (Transport:LDP)
Module 5 |
204
To use the LDP-shortcut feature, LDP labels for the additional prefixes must be present in the LFIB of router R1. This is
accomplished by an LDP-Export policy configured on router R6, as explained in Module 3.
Module 5 |
205
Module 5 |
206
There are many issues involved in interconnecting IPv4 and IPv6 networks and many strategies for transitioning to IPv6.
One useful technology that makes use of MPLS tunnels is known as 6PE and involves tunneling IPv6 traffic over an
IPv4/MPLS core.
In the 6PE architecture the PE routers of the IPv4/MPLS core run a dual stack of IPv4/IPv6 and exchange the IPv6 routes
using MP-BGP (Multi-Protocol BGP). IPv6 packets are label-switched across the IPv4/MPLS core network. Two labels are
used:
Inner label has the IPv6 Explicit Null value of 2 to indicate that the payload is a native IPv6 packet.
Outer label is the MPLS transport label used for switching across the network.
Module 5 |
207
The steps to configure and operate 6PE over an IP/MPLS network can be summarized as follows:
1. PE routers run a dual stack of IPv4 and IPv6 with IPv6 interfaces towards the customer network and IPv4
interfaces toward the service provider core.
2. PE routers use MP-BGP to exchange IPv6 routes learned from customer networks across the core network.
3. IPv6 routes learned through MP-BGP on the PE routers have their next hop resolved through an LDP tunnel.
4. PE routers are configured with static routes or an IPv6 IGP such as OSPF3 or IS-IS to exchange routes with
customer routers. Routes learned through MP-BGP are exported to the customer network.
5. IPv6 data received by the PE routers is encapsulated with two MPLS labels for transmission across the core
network. The inner label has the value of 2 for IPv6 Explicit Null.
6PE Topology
Module 5 |
208
The listing on the slide shows the configuration on R1 with the dual IPv4/IPv6 stack. The interface towards R8 is IPv6;
the system interface and the interface towards the MPLS core are IPv4.
R1 is configured with a policy to export the IPv6 routes learned from BGP into the IPv6 network with OSPFv3.
*A:R1# configure router ospf3
*A:R1>config>router>ospf3# info
---------------------------------------------asbr
export "bgp_6pe"
area 0.0.0.0
interface "toR8"
interface-type point-to-point
exit
exit
---------------------------------------------*A:R1>config>router>ospf3# show router policy "bgp_6pe"
entry 10
from
protocol bgp
family ipv6
exit
action accept
exit
exit
Module 5 |
209
The listing on the previous slide shows that R1 is configured with a policy to export the IPv6 routes learned through BGP
to OSPF3. The routers are actually using MP-BGP to exchange the IPv6 routes. MP-BGP is an extended version of
regular BGP that allows it to carry other address families than simply IPv4. It is typically used for carrying IPv6 or
VPRN routes.
The configuration and operation of MP-BGP is the same as classic BGP. On the 7750 SR we simply specify the address
family to be carried as shown in the slide. IPv4 is the default address family. Notice that the neighbor statement for
R6 also specifies advertise-label. This causes R1 to add the IPv6 Explicit Null label so that the recipient (R6) knows it
is receiving tunneled IPv6 data.
===============================================================================
BGP IPv6 Routes
===============================================================================
------------------------------------------------------------------------------RIB In Entries
------------------------------------------------------------------------------Network
: 2001:DB8:1::1/128
Nexthop
: ::FFFF:A0A:A06
From
: 10.10.10.6
Res. Nexthop
: 10.1.2.2 (LDP)
Local Pref.
: 100
Interface Name : toR2
... output omitted ...
Module 5 |
210
The slide above shows the route for R7s system address learned through BGP. Note that the next hop is the IPv4 system
address of R6 mapped to an IPv6 address and is resolved through LDP to the next downstream router, R2.
The output below shows the BGP peering of R1 and R6 and the fact that it is enabled for the IPv6 family.
*A:R1# show router bgp summary
===============================================================================
BGP Router ID:10.10.10.1
AS:100
Local AS:100
===============================================================================
BGP Admin State
: Up
BGP Oper State
: Up
Total Peer Groups
: 1
Total Peers
: 1
Total BGP Paths
: 8
Total Path Memory
: 960
Total IPv4 Remote Rts
: 0
Total IPv4 Rem. Active Rts : 0
Total IPv6 Remote Rts
: 1
Total IPv6 Rem. Active Rts : 1
Total Supressed Rts
: 0
Total Hist. Rts
: 0
Total Decay Rts
: 0
... output omitted ...
===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down
State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
------------------------------------------------------------------------------10.10.10.6
100
1543
0 10h51m28s 1/1/1 (IPv6)
1556
0
===============================================================================
===============================================================================
IPv6 Route Table (Router: Base)
===============================================================================
Dest Prefix
Type
Proto
Age
Pref
Next Hop[Interface Name]
Metric
------------------------------------------------------------------------------2001:DB8:1::1/128
Remote OSPF3
00h22m21s
150
FE80::216:4DFF:FE13:5CAE-"toR1"
100
2001:DB8:2::1/128
Local
Local
01d02h38m
0
system
0
------------------------------------------------------------------------------No. of Routes: 2
===============================================================================
*A:R8# ping 2001:DB8:1::1 count 1
PING 2001:DB8:1::1 56 data bytes
64 bytes from 2001:DB8:1::1 icmp_seq=1 hlim=62 time=4.20ms.
---- 2001:DB8:1::1 PING Statistics ---1 packet transmitted, 1 packet received, 0.00% packet loss
round-trip min = 4.20ms, avg = 4.20ms, max = 4.20ms, stddev = 0.000ms
Module 5 |
211
Once learned through BGP and installed in the route table the route is exported to OSPFv3 and thus to its neighbor, R8. Router R8
receives the route and is able to ping the system address of the remote IPv6 router (R7) through the MPLS tunnel.
The listing below shows the very simple configuration of the providers core P routers, R2 and R4. They have no IPv6 or BGP
configuration. They are configured as pure IPv4/MPLS routers with IS-IS for the providers core and LDP for the transport tunnels.
*A:R2>config>router# info
#-------------------------------------------------echo "IP Configuration"
#-------------------------------------------------interface "system"
address 10.10.10.2/32
exit
interface "toR1"
address 10.1.2.2/27
port 1/1/2
exit
interface "toR4"
address 10.2.4.2/27
port 1/1/3
exit
Section Summary
Module 5 |
212
The MPLS Shortcuts for BGP next-hops feature is available for both LDP and RSVP-TE based tunnels.
Using MPLS Shortcuts reduces the processing and memory load on transit LSRs.
If the mpls option is used with the igp-shortcut configuration in BGP, RSVP-TE LSPs are preferred over LDP
based tunnels.
If there are multiple RSVP-TE LSPs towards the BGP next-hop, the LSP with the lowest metric is preferred.
If the metric values are equal, the lowest tunnel ID is used as a tie-breaker.
The MPLS shortcuts for IGP route resolution is available.
If the rsvp-shortcut configuration is enabled in the IGP context, and if there are multiple LSPs towards the
destination, the LSP with the lowest metric is preferred.
The lowest tunnel ID can again be used as a tie-breaker.
It is possible to achieve load balancing over multiple RSVP-TE based LSPs with the IGP route resolution feature by
enabling ECMP.
Module Summary
Module 5 |
213
Module 5 |
214
Module 5 |
215
CSPF can identify an error many hops away before the router
signals a path message.
Connection Admission Control (CAC) verifies the bandwidth request
at each hop.
A router assigns a bandwidth reservation from the unreserved
bandwidth on the egress (downstream) interface.
Module 5 |
216
Module 5 |
217
Learning Assessment
1.
Module 5 |
218
What limitation is shared by all IGP protocols when selecting best paths?
All IGP protocols are limited to selecting best paths based on limited metrics, such as Hop counts or cost, without
insight into other items, such as link utilization.
2.
Why are Link State protocols better suited for Traffic Engineering than Distance Vector?
Link State protocols are better suited for Traffic Engineering than Distance Vector because they maintain a
database of network topology, which may include the entire domain.
3.
4.
5.
Available constraints include bandwidth reservations, administrative groups, hop limits, explicit hops, and SRLGs.
6.
True or False: Bandwidth reservations apply QoS policies to police and shape traffic in the core.
False
7.
Assuming an LSP hop-limit constraint of 4 hops, would the head-end successfully signal an LSP terminating on the
tail-end 4 hops away?
No; the hop count includes the head-end, so the tail-end is 5 hops away.
8.
Module 5 |
219
Define the term disjointed in the context of Shared Link Risk Groups (SRLGs).
Disjointed means that the secondary and fast reroute paths share no links with the primary path.
9.
10. Link TLVs carry bandwidth, admin group membership, TE metric, and other sub-TLVs.
11. Which type of LSA is implemented for OSPF-TE?
The Opaque Type 10 Area local LSA is implemented for OSPF-TE.
12. True or False: The Maximum Reservable Bandwidth on a link may exceed the Maximum Bandwidth of the link
(over-subscription is allowed).
True.
13. True or False: The Unreserved Bandwidth value for a priority level on a link must be less than or equal to the
Maximum Reservable Bandwidth.
True.
14. True or False: A given link may be assigned to any number of Administrative Groups (up to the maximum number
of 32 groups)
True.
15.
Module 5 |
220
16.
CSPF prunes links which do not meet the specified constraints, then uses the SPF algorithm to calculate the LSP
path.
17.
18.
19.
True or False: CSPF serves no purpose if configured on an LSP with all strict-hop paths.
False. CSPF verifies that the hops are valid before sending the path message.
20.
21.
Why do the SR OS routers perform Connection Admission Control (CAC) on bandwidth reserved LSPs?
The bandwidth may no longer be available downstream, the reservation state may have changed, or the TED
may not be current.
22.
In addition to IGP TE Bandwidth Update thresholds, what additional features can trigger TE updates?
On CAC failure and update timers.
25. Using SE and MBB, and assuming that an existing LSPs bandwidth
reservation is changes from 400 Mbps to 700 Mbps on a link with
200 Mbps unreserved bandwidth left, how will the head-end
handle the increased bandwidth request?
26. TE least fill chooses an LSPs path based on what characteristic?
27. By default, an LSP has a setup priority of ___ and a hold priority
of ____.
28. The DiffServ-TE ____ ____ _____ allows class types to share
bandwidth reservations.
Module 5 |
221
23.
Which reservation style provides each sender with a dedicated reservation that is not shared with other senders?
FF.
24.
Which reservation style creates a single reservation over a link that is shared by an explicit list of senders?
SE.
25.
Using SE and MBB, and assuming that an existing LSPs bandwidth reservation changes from 400 Mbps to 700
Mbps on a link with 200 Mbps unreserved bandwidth left, how will the head-end handle the increased bandwidth
request?
Signal the new path over another set of links, if possible. The delta, 300 Mbps, between the old bandwidth and
the new is >200Mbps. The head-end leaves the LSP up on the old path until it succeeds in bringing up a new path
supporting the new bandwidth constraint.
26.
27.
28.
The DiffServ-TE Russian Dolls Model allows class types to share bandwidth reservations.
29.
Module 5 |
222
Assuming the DiffServ-TE Maximum Allocation Model (MAM), if a CT0 LSP uses all of its available reservable
bandwidth on one link, can the head-end signal another LSP in the same class-type?
Yes, if the new LSP can preempt the first AND enough bandwidth exists for that CT along the original path to
meet the new LSPs requirements, or if there is another available path toward the tail-end meeting the new
LSPs constraints within the same CT.
30.
T-LDP sessions between LERs and ABRs and between ABRs and ABRs stitch together individual intra-area RSVP-TE
LSPs.
31.
BGP Shortcuts eliminate the need to propagate external routes throughout the core network.
32.
In a 6PE network the customer routers run IPv6 only, the PE routers run a dual stack of IPv4 and IPv6 and the
provider core (P) routers run only IPv4.
30. _____ sessions between LERs and ABRs and between ABRs and
ABRs _____ together individual intra-area RSVP-TE LSPs.
www.alcatel-lucent.com
3FL-30635-AAAA-ZZZZA Edition 01
Module 6 Resiliency
Module 6 Page 1
Module Objectives
Module 6 |
Module 6 Page 2
Module 6 Resiliency
Module 6 Page 3
Section Objectives
Module 6 |
This section covers the major aspects of network convergence, including failure detection, propagation, and service
recovery. Various scenarios that use native IP forwarding, secondary LSP-Path and Fast Reroute protection, and LDP
tunnels are presented and analyzed.
Module 6 Page 4
Module 6 |
Network reliability is one of the main concerns of network operators today. Network failure can be the result of
physical link failures, power failures, and hardware or software failures in network devices. It is therefore important to
take necessary precautions against all imaginable failures that can happen in the network.
One of the key aspects in selecting the right networking technology is how quickly that technology can react to network
failures and quickly restore network services by rerouting the traffic around the failure point. The term convergence
refers to the time that it takes to restore the services. Quick detection of network failures and short convergence times
are crucial to a service providers ability to meet the standards set in the Service Level Agreement (SLA).
With the support of RSVP-TE and CSPF, MPLS can bring significant performance advantages, with respect to convergence
times.
Module 6 Page 5
Module 6 |
Module 6 Page 6
Convergence Factors
Module 6 |
Module 6 Page 7
Failure Detection
Module 6 |
Module 6 Page 8
y When the port goes down at physical layer, all upper protocol layers
are notified to trigger convergence.
Module 6 |
Considering a physical layer failure concerning the link directly attached to a router, a local failure is immediately (or
after a very short interval) detected by the routers connected to that link. This initiates convergence and triggers
recovery action on all the upper layer protocols.
In many networks, however, routers are not directly connected by cables; instead, there can be several transmission
devices connecting the router ports. When a failure takes place on the link between two transmission devices, the local
ports on the routers can stay up unless the failure is propagated to the routers. This is referred to as a remote failure
and routers rely on additional mechanisms implemented at protocol level for failure detection in these cases.
Module 6 Page 9
Module 6 |
10
There are several heartbeat mechanisms at different protocol levels to detect failures that go undetected by the
physical layer mechanisms.
Using default IGP Hello Timers, it takes around 30 seconds to detect that an IGP adjacency is lost.
Using default RSVP Hello Timers, it takes around 9 seconds to detect that an RSVP adjacency is lost.
Both Hello timers can be set as low as 1 second; sub-second detection is not possible with Hello timers. However,
aggressive hello timers are usually not recommended because they can bring additional messaging and processing
overhead.
Two alternative methods are widely deployed to provide sub-second detection with low control plane overhead.
Bidirectional Forwarding Detection (BFD) a lightweight heartbeat mechanism that sends and receives simple
periodic protocol packets to determine if the other end of the connection is alive. BFD runs at IP-level (Layer 3)
and is supported by all the major dynamic protocols, as well as by static routes.
Ethernet in the First Mile (EFM) defined in the IEEE specification 802.3ah, EFM provides link-level (Layer 2) OAM
detection.
For configuration and other details of BFD and EFM implementations, please refer to the Service Router Configuration
Guides.
Module 6 Page 10
Minimum value for the IGP and RSVP Hello timer is 1 second.
Module 6 |
11
Failure propagation takes place after a failure is detected. Using link-state protocols like OSPF or IS-IS, link-state
update packets are flooded in the network to inform all the routers about the link failure. The receiving routers
compare the information in the link-state update with their link-state Database and update the routing information to
reflect the failure.
Module 6 Page 11
Module 6 |
12
At the Head-End, the operator can protect the primary path with secondary LSP-Path(s). These can be either:
Cold-standby secondary paths - The Head-End only signals these if a failure occurs on the primary path and the HeadEnd cannot move the primary to another path
Hot-standby secondary paths - Become operational even before any failure takes place.
When the primary LSP-Path experiences failure, a PATH Error message containing this information is delivered to the
LSP Head-End. Since the secondary LSP-Path is configured at the Head-End, only the Head-End can activate the
secondary LSP-Path and switch traffic over to it.
Therefore, the Head-End router is the decision point for service recovery action, in the case secondary LSP-Path
protection.
Module 6 Page 12
Using Fast Reroute, the router that detects the failure can take a
local decision to recover the traffic.
A path error message is still sent to inform the LSP Head-End.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
13
Alternatively, Fast Reroute protection tunnels can be created on the routers along the primary LSP-Path, prior to
failure. Should link failure occur, the router that is connected to the failing resource can make a local decision to
recover the traffic; that is closest point to the failure and it is responsible for taking service recovery action.
The LSP Head-End still needs to be informed, as it might want to take further action to move the traffic to a better
path. Again, an RSVP PATH Error message is sent towards the Head-End for this purpose.
Module 6 Page 13
Module 6 |
14
After failure propagation, service recovery action takes place on the routers.
In the case of link-state protocols, when a new link-state update is received, it implies a topology change in the
network and all the routers need to make a new calculation of the SPF algorithm and re-evaluate the path reachability
to destinations in the network.
Total network convergence occurs only when all the routers reach new steady-state conditions after updating their
Forwarding Tables. This process might take up to several seconds in large networks. During this time, traffic might be
prone to discards, black-holes, or loops, so shorter convergence times are important for critical traffic.
Module 6 Page 14
When the Head-End receives the path error message, it switches the
traffic over to the secondary LSP-Path.
Key factor is the propagation time of the path error message.
The switchover from the primary to the secondary path is hitless.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
15
Once notified of the failure impacting the primary LSP-Path, the Head-End performs a traffic switchover to the
secondary LSP-Path, if it is already established. This is the case with the (hot) standby secondary LSP-Path option
(discussed in more detail in Section 2). The switchover to the secondary path is mostly hitless, and there is no traffic
loss in the majority of the cases.
The crucial factor here is the time it takes to deliver the Path Error message from the point of failure to the Head-End.
This depends on factors such as how far from the Head-End router the failure occurs and the propagation delay on each
of the links along the path.
Module 6 Page 15
Using Fast Reroute, traffic is recovered in less than 50 ms. after the
failure is detected.
The first upstream router from the point of failure switches traffic to
the backup tunnel that was established before the failure.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
16
If the LSP is configured Fast Reroute, the primary LSP-Path can be protected by a series of local protection tunnels,
established on each possible router along the path. When a failure occurs on the primary LSP-Path, the router that
detects the failure can make a local decision to recover the traffic, without waiting for the LSP Head-End.
Most often, traffic is switched over to a Fast Reroute protection tunnel within 50 milliseconds after the detection of
failure. This brings a clear performance advantage over other resiliency methods.
Module 6 Page 16
LDP Convergence
Module 6 |
17
By protocol design, LDP relies heavily on IGP, as relates to operation and convergence.
LDP and IGP must have identical forwarding paths. Therefore, LDP must have the same next-hop information in the LFIB
as in the FIB.
When failure is detected, IGP first calculates a new next-hop as a result of the SPF run and updates the FIB. Following
this, LDP installs the label received from the newly determined IGP next-hop in the LFIB. Thus, the two forwarding
tables are synchronized and label switching can take place.
Thanks to liberal label retention, labels received from inactive IGP peers are kept in the control plane LIB. If a peer
becomes the active next-hop, the previously advertised label can immediately be installed in the LFIB and label
switching of traffic can resume.
A case study is presented in the following pages to illustrate these points.
Module 6 Page 17
Module 6 |
18
Module 6 Page 18
Failure is detected.
Router R2 is deleted from the FIB.
Router R2 withdraws its label.
The label is deleted from the LFIB.
Traffic is being discarded.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
19
The link between R2-R6 fails. The failure is detected and propagated to other routers in the network.
Router R1 deletes router R2 from the FIB, breaking the IP forwarding. The label from router R2 is also deleted from the
LFIB and LIB, as a result of the label withdraw and release actions. MPLS label switching cannot take place.
Module 6 Page 19
Module 6 |
20
Router R1 runs a new SPF calculation and installs router R3 as the new IGP next-hop in the FIB.
LDP also installs router R3 as next-hop in the LFIB. The label from router R3 has been previously received and stored in
the LIB, so router R1 starts using it in the LFIB right away. MPLS label switching can continue.
Module 6 Page 20
Module 6 Resiliency
Module 6 Page 21
Module 6 |
22
Sometimes traffic is lost while reverting to a best IGP next-hop, an example of which is illustrated above.
The link between R2-R6 recovers and updated LSAs propagate through the network. Router R1 runs a new SPF
calculation in response to the topology change and once again installs in the FIB router R2 as the FEC 10.10.10.6/32 IGP
next-hop.
On router R1, the FIB and LFIB entries no longer match: The FIB has router R2 as the next-hop while the LFIB has router
R3 as the next-hop. The LDP RFCs do not allow this and, as a result, router R1 removes router R3 its label from the LFIB.
Label switching cannot take place until router R1 installs a new label binding in the LFIB.
Module 6 Page 22
Module 6 |
23
To handle problems as described in the previous page, the LDP-IGP Sync feature, also referred to as Draft Jork, allows
the routers to continue using the existing LDP next-hop until the next-hop can signal a label for the FEC. This holds
down the new route and prevents temporary traffic loss during the next-hop transition period.
By default, the SR OS routers enable the LDP-IGP sync feature in the IGP context. Whenever a link becomes unavailable,
the routers adjacent to that link advertise it with a metric of 65535. However, you must configure an LDP sync timer
value on each network interface that will use the feature. This value sets the time in seconds the router will hold
down a new route while the router waits for an associated label.
When LDP-IGP sync is activated, the FIB and LFIB next-hop remains unchanged until the downstream node can set up an
LDP session to its next-hop peer. Once the LDP session succeeds, the downstream node still advertises the high metric
for the LDP sync timer. Once the timer expires, the router waiting for the new label updates its FIB and moves the new
label from its LIB to its LFIB.
This feature also helps to prevent rapid switching between different next-hops, in the case of an unstable (flapping)
network link.
Module 6 Page 23
Module 6 |
24
With the LDP-IGP sync feature enabled, router R2 starts advertising the maximum IGP metric (65535) to router R1 for
the FEC 10.10.10.6/32. Router R1 waits for router R2 to establish an LDP session to the new next-hop (router R6 in this
example).
The metric is virtually infinite, thus router R1 does not revert the IGP next-hop to router R2. Router R3 is still the nexthop present in the FIB and the LFIB and traffic forwarding resumes on the existing path.
Module 6 Page 24
Module 6 |
25
The LDP session between routers R2 and R6 is established and router R2 now advertises an LDP label for FEC
10.10.10.6/32. Router R1 installs this label in its LIB, but still holds the FIB and LFIB next-hops are they were previously.
For the duration of the timer, router R2 continues to advertise the link metric as 65535. Router R1 does not switch over
to the new next-hop until it receives a better metric for the link.
Module 6 Page 25
Module 6 |
26
When the LDP-Sync timer expires, router R2 advertises the standard IGP link metric, in this case, 100. As a result,
router R1 updates the FIB next-hop to router R2, and installs the label it received from router R2 in the LFIB.
Traffic forwarding continues on the shortest IGP path. Potential temporary traffic loss during next-hop transition period
is therefore prevented by LDP-IGP Sync.
Module 6 Page 26
Module 6 |
27
LDP-IGP Sync is enabled by default under the IGP configuration, as shown in the figure above. To activate it, an ldpsync-timer is configured under every interface that will use the feature.
Module 6 Page 27
The following output is displayed while waiting for the LDP session
to come up (the LDP Sync Timer is not yet running):
A:R1# show router ospf interface toR2
After the session comes up, the router waits for the LDP SyncTimer to expire before it activates the new next-hop:
A:R1# show router ospf interface toR2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ldp Sync
: inService
Ldp Sync Wait
: Enabled
Ldp Timer State : Timer Active
Ldp Tm Left
: 7
Module 6 |
28
Use the show router ospf interface <interface-name> detail command to verify the operation of the LDPIGP Sync feature. Only fields related to the LDP-IGP Sync feature are shown in the output above, for clarity.
Ldp Sync displays outOfService if the feature is disabled in IGP, or if an LDP Sync timer is not configured under
the interface. Once a Sync Timer is configured, the output shows inService.
LDP Sync Wait displays Disabled under normal operating conditions. Once a new IGP next-hop is found, it
becomes Enabled, as shown in the first command output.
LDP Timer State displays Wait for Ldp Adj. until an LDP session is established to the newly found IGP next-hop.
It changes to Timer Active, as shown in the second command output, after the LDP session becomes active.
LDP Tm Left displays 0 if LDP-IGP Sync is inactive, or the LDP session to the new IGP next-hop is not yet
established, as shown in the first command output. After the session is established, the timer starts to count down
from the user configured LDP Sync timer. The router starts to advertise normal IGP metrics when the timer expires.
Module 6 Page 28
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ldp Sync
: inService
Ldp Sync Wait
: Enabled
Ldp Timer State : Wait for Ldp Adj.
Ldp Tm Left
: 0
Section Summary
Module 6 |
29
Module 6 Page 29
Module 6 Resiliency
Module 6 Page 30
Section Objectives
Module 6 |
31
Module 6 Page 31
Module 6 |
32
An LSP configured at a Head-End router can have up to 8 LSP-Paths defined. One of those paths is the primary LSP-Path,
thus a maximum of 7 secondary LSP-Paths can be configured inside the LSP. (It is possible to configure an LSP without a
primary LSP-Path, but this is not recommended.)
Although multiple LSP-Paths are available to an LSP, only one LSP-Path can be active and can forward data traffic at
any given time. The LSP never attempts to load balance the traffic over multiple LSP-Paths.
The primary LSP-Path, once fully functional, is always the preferred path to use. Secondary LSP-Path and Fast Reroute
protection mechanisms are designed and deployed to protect against failures on the primary LSP-Path only. It is the
assumption here that the designated primary LSP-Path is the best path to forward LSP traffic.
There are two modes for secondary LSP-Paths. The first is secondary (Non-standby), which is the default mode. The
second is standby, which may be changed in the configuration.
Case studies are included in the following pages that illustrate the use of both modes.
Module 6 Page 32
lsp "to_R6
cspf
to 10.10.10.6
primary prim_path
exit
secondary stdby_sec
standby
LSP is enabled.
The Primary LSP-Path is signaled first.
exit
Module 6 |
33
An LSP is configured to 10.10.10.6 with a primary LSP-Path definition, prim_path, and a secondary LSP-Path
definition, stdby_sec. The secondary LSP-Path is configured in Standby mode.
The path configurations for prim_path and stdby_sec are omitted, for the sake of clarity. The resulting paths that
are signaled by RSVP-TE, however, are shown in the output.
When the LSP is enabled, the first priority of router R1 is to signal the primary LSP-Path, regardless of alternative
options configured. The primary LSP-Path is signaled over the path, as shown in the figure above.
Module 6 Page 33
lsp "to_R6
cspf
to 10.10.10.6
primary prim_path
exit
secondary stdby_sec
standby
exit
34
Since the secondary LSP-Path is configured in Standby mode, it is also signaled after the primary.
Both LSP-Paths are established, with RSVP sessions in place and labels negotiated.
Module 6 Page 34
Module 6 |
35
The primary LSP-Path is up, and has precedence over the other LSP-Paths; therefore, router R1 forwards the traffic over
the primary LSP-Path.
The standby secondary LSP-Path is established and it waits in Hot Standby mode, ready to take over the data traffic,
should the primary LSP-Path experience failure.
Module 6 Page 35
Router R4 sends a path error message upon detecting the link failure.
As the Head-End router, router R1 is responsible for recovering the
traffic.
After receiving the path error message, router R1 switches the traffic
to the standby secondary path.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
36
The link between R4-R6 fails so router R4 issues a PATH Error message upstream, towards the LSP Head-End, to notify
router R1 about the failure on the primary LSP-Path.
Router R1 determines that it has an available standby secondary LSP-Path established and ready to deliver traffic. A
switch takes place on router R1, and the standby secondary LSP-Path becomes the new active path.
The only time lost in this process is the time that it takes the PATH Error message to reach the Head-End. No time is
spent signaling the secondary LSP-Path.
Module 6 Page 36
lsp "to_R6
cspf
to 10.10.10.6
primary prim_path
exit
LSP is enabled.
secondary stdby_sec
exit
Module 6 |
37
Presented above is a slightly modified version of the previous case study. In this scenario, the secondary LSP-Path is
configured in Non-standby mode (default).
Again, after the LSP is enabled, the Head-End signals the primary LSP-Path.
Module 6 Page 37
lsp "to_R6
cspf
to 10.10.10.6
primary prim_path
exit
secondary stdby_sec
exit
38
Unlike the previous case, the secondary LSP-Path is not signaled after the primary LSP-Path is established because it is
configured in non-standby mode.
Module 6 Page 38
Module 6 |
39
The link between R4-R6 fails so router R4 issues a PATH Error message upstream, towards the LSP Head-End, to notify
router R1 about the failure on the primary LSP-Path.
Router R1 determines that it has a non-standby secondary LSP-Path, which is not yet signaled. It signals the secondary
LSP-Path with a PATH message and waits for the RESV message response. Data traffic is discarded while router R1 waits.
The total convergence time for a non-standby secondary LSP-Path is thus the propagation time for the PATH Error
message plus the signaling time required for the secondary path. This is obviously worse than the recovery time for a
standby secondary path.
However, a non-standby secondary path is less resource intensive than a standby secondary path, because it does not
consume any RSVP sessions or labels while the primary LSP-Path is up.
Module 6 Page 39
Module 6 |
40
When the secondary LSP-Path is established, Head-End router R1 starts forwarding the traffic over this path.
The Head-End also tries to restore the primary LSP-Path every 30 seconds, by default. This is determined by the retrytimer configuration for the LSP (explained in Section 3).
Module 6 Page 40
Module 6 |
41
The link between R4-R6 is recovered and router R1 re-establishes the primary LSP-Path over its previously used links.
The traffic is switched to the primary LSP-Path.
The primary LSP-Path is now the active LSP-Path.
The secondary LSP-Path is configured in non-standby mode, therefore it is not needed and is torn down with a PATH
Tear message.
Module 6 Page 41
Module 6 |
42
If multiple secondary LSP-Paths are configured to protect the same primary LSP-Path, the Head-End must choose one to
become active, upon failure on the primary.
Path-preference for secondary LSP-Paths allows the operator to choose which secondary the LSP uses and in what
order.
The use of path-preference is optional.
Module 6 Page 42
Module 6 |
43
Module 6 Page 43
primary prim_path
exit
secondary Secondary-1
standby
exit
secondary Secondary-2
standby
exit
Module 6 |
44
The case study on this and the following four pages illustrates Head-End behavior, using default path-preference values
for standby secondary LSP-Paths.
An LSP is configured with a primary LSP-Path and two standby secondary LSP-Paths.
One of the secondary LSP-Paths comprises four hops and the other, six hops.
Both secondary LSP-Paths are established with the primary.
Module 6 Page 44
primary prim_path
exit
secondary Secondary-1
standby
exit
secondary Secondary-2
standby
exit
45
Module 6 Page 45
primary prim_path
exit
secondary Secondary-1
standby
exit
secondary Secondary-2
standby
exit
46
Secondary-1 also goes down because of a failure on the link between R3-R5. At this point, both the primary and
Secondary-1 are down.
Router R1 determines whether another secondary path is available. Secondary-2 is also established, so the traffic is
switched to it.
Module 6 Page 46
primary prim_path
exit
secondary Secondary-1
standby
exit
secondary Secondary-2
standby
exit
47
The link failure between R3-R5 is removed and Secondary-1 is re-established. It offers a better forwarding path than
Secondary-2, with its 4 hops against 6, but the Head-End does not return to Secondary-1. The traffic remains on
Secondary-2.
Module 6 Page 47
primary prim_path
exit
secondary Secondary-1
standby
exit
secondary Secondary-2
standby
exit
Module 6 |
48
The link failure between R4-R6 is removed, and the primary path is re-established.
Router R1 switches the traffic back to the primary LSP-Path.
The standby secondary LSP-Paths remain established, readily available for the next failure.
Module 6 Page 48
Module 6 |
49
With path-preference, standby secondary LSP-Paths can be assigned preference values, between 1 and 255.
The lower the numerical value assigned, the higher the preference for the LSP-Path.
The default path-preference value for secondary LSP-Paths is 255.
Path-preference values take precedence over uptime values.
As a result, the standby secondary LSP-Path with the optimal forwarding path can be configured to receive priority over
all other secondary paths, regardless of uptime values.
Furthermore, if a standby secondary LSP-Path with a better path-preference value becomes available, traffic is
switched to that path.
Module 6 Page 49
primary prim_path
exit
secondary Secondary-1
standby
path-preference 10
exit
secondary Secondary-2
standby
path-preference 20
exit
50
The case study example on this and the following four pages illustrates Head-End behavior, using custom pathpreference values for standby secondary LSP-Paths.
An LSP is configured with a primary LSP-Path and two standby secondary LSP-Paths.
Secondary-1 is configured with a lower (better) path-preference value than Secondary-2, because it goes through a
shorter path. The operator decides that Secondary-1 will be the active forwarding path, if the primary LSP-Path is
down.
Module 6 Page 50
primary prim_path
exit
secondary Secondary-1
standby
path-preference 10
exit
secondary Secondary-2
standby
path-preference 20
exit
51
Module 6 Page 51
primary prim_path
exit
secondary Secondary-1
standby
path-preference 10
exit
secondary Secondary-2
standby
path-preference 20
exit
52
Secondary-1 also experiences link failure between R3-R5. Now both the primary and Secondary-1 are down.
Router R1 determines whether another secondary path is available. Secondary-2 is also established, so the traffic is
switched to it.
Module 6 Page 52
primary prim_path
exit
secondary Secondary-1
standby
path-preference 10
exit
secondary Secondary-2
standby
path-preference 20
exit
53
The link failure between R3-R5 is removed and Secondary-1 is re-established. Router R1 reverts to Secondary-1 because
that path has a lower path-preference value.
This behavior is different from actions taken with default path-preference values.
Module 6 Page 53
primary prim_path
exit
secondary Secondary-1
standby
path-preference 10
exit
secondary Secondary-2
standby
path-preference 20
exit
Module 6 |
54
The link failure between R4-R6 is removed and the primary is re-established.
Router R1 switches the traffic back to the primary LSP-Path.
Both standby secondary LSP-Paths remain established and readily available, in case of more failure.
Module 6 Page 54
Module 6 |
55
Module 6 Page 55
Module 6 |
56
The network operator must ensure that primary and secondary LSP-Paths follow diverse paths through the network.
This becomes especially important with standby secondary LSP-Paths, where traffic must be switched rapidly in case of
a primary LSP-Path failure. Furthermore, if a secondary LSP-Path shares links with a primary path, and failure occurs on
those links, both LSP-Paths can go operationally down and cause undesired traffic outage.
There are several options available to maintain path diversity, including using fully strict hop LSP-Paths, or
Administrative Group or Shared Risk Link Group definitions. The choice depends mainly on the network topology, traffic
type, or administrative requirements.
Several case study examples are covered in the following pages to illustrate the use of these different options.
Module 6 Page 56
A:R1>config>router>mpls#
--------------------------path prim_path"
A:R1>config>router>mpls#
--------------------------path sec_path"
to 10.10.10.6
primary prim_path
exit
no shutdown
exit
no shutdown
exit
A:R1>config>router>mpls#
--------------------------lsp "to_R6
secondary sec_path
exit
Module 6 |
57
Strict hop configurations provide the ability to make exact, pre-determined path definitions. This way, operators can
guarantee the paths the LSP-Paths will take. Although this approach is feasible in many cases, it can present certain
disadvantages in other situations, particularly in large, scaled networks. For example:
Scalability: The explicit hop definitions may introduce huge operational overhead in large networks, as a vast
number of paths and hops may have to be configured.
Flexibility: Hop lists can be affected by network topology changes. Adding or removing routers in the topology can
make a path list invalid, which would require a re-definition of the path. This will bring additional configuration
and management overhead.
Manageability: With the increase in the size of LSPs and path definitions, paths can become difficult to maintain
and troubleshoot in a large network.
Module 6 Page 57
no shutdown
exit
A:R1>config>router>mpls#
--------------------------path prim_path"
A:R1>config>router>mpls#
--------------------------path sec_path"
no shutdown
exit
no shutdown
exit
Module 6 |
58
Strict hop path definitions are more practical in a small topology with a limited number of redundancy options.
In the example above, router R1 has only two possible paths to reach router R6.
A primary LSP-Path is configured with strict hops, following the path R1-R2-R4-R6.
A secondary LSP-Path is also configured with strict hops, following the path R1-R3-R5-R6.
This can provide the path diversity required in this small scale topology.
Module 6 Page 58
Using strict hops, the LSP-Paths must go through the specified hops.
Alternative links cannot be utilized in case of failure (unless Fast
Reroute is in place; covered in Section 3).
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
59
A fully strict hop LSP-Path is a fixed definition. If one of the links along the path fails, the LSP-Path will remain down
until the failure is removed.
In the figure above, two routers are added to the previous topology, which increases redundancy in the upper and lower
paths. This brings further resilience against failures, as well as the ability to work with other administrative constraints,
such as bandwidth reservations.
If strict hop definitions are used, the LSP-Paths cannot make use of the available redundant paths.
Note that a solution exists, even with strict hop path definitions, that makes use of the redundant paths. Two
additional secondary LSP-Paths can be added and configured with strict hops to utilize the redundant paths. However,
this would result in more configuration and signaling overhead.
Fast Reroute offers an alternative solution to make use of the redundant links in the topology; it is covered in Section 3.
Module 6 Page 59
In this example, redundant links in the upper and lower planes are
assigned to different administrative groups.
Primary and secondary LSP Paths can be configured with loose hops
that exclude either one of the groups.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
60
Recall the administrative group concept that was introduced in Module 5. Secondary LSP-Path protection is a good
example of the application of administrative groups.
In the case study above, the redundant links in the upper and lower portions of the network topology are made
members of administrative groups UPPER and LOWER.
Using exclude statements, the different LSP-Paths may be forced to avoid certain group of links in either portion of
the path.
Note: Other design solutions are possible, such as coloring the entire upper and lower planes in different groups and
using include statements.
Module 6 Page 60
A:R2>config>router>mpls#
-------------------------------admin-group UPPER 1
interface "toR4"
admin-group UPPER"
exit
interface toR7
admin-group UPPER
exit
A:R3>config>router>mpls#
-------------------------------admin-group LOWER 2
interface "toR5"
admin-group LOWER"
exit
interface toR8
admin-group LOWER
exit
Module 6 |
61
On router R2, links R2-R4 and R2-R7 are members of administrative group UPPER.
On router R7, link R7-R4 is a member of administrative group UPPER.
On router R3, links R3-R5 and R3-R8 are members of administrative group LOWER.
On router R8, link R8-R5 is a member of administrative group LOWER.
Recall that the administrative group definitions can be asymmetrical; that is, they do not have to match on each end of
a link.
If symmetric operation is desired, similar configurations in the opposite direction of traffic flow (right-to-left) can
provide similar functionality on the adjacent routers.
Module 6 Page 61
Module 6 |
62
The administrative group name-to-value associations are done at the Head-End router. This creates the link between
the group names in the LSP configuration and the group values in the TED.
Two different fully loose path definitions are created with no specific hops, since a path name can be used only once
within an LSP configuration.
One of the path definitions is configured as a primary LSP-Path, and CSPF must calculate a path that avoids links in the
LOWER administrative group.
The other path definition is configured as a secondary LSP-Path, and CSPF must calculate a path that avoids links in the
UPPER administrative group.
Module 6 Page 62
A:R2>config>router>mpls#
-------------------------------admin-group UPPER 1
admin-group LOWER 2
path fully_loose-1
no shutdown
exit
path fully_loose-2
no shutdown
exit
The primary LSP-Path can use any of the links in the upper plane.
The secondary LSP-Path can use any of the links in the lower
plane.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
63
The above slide illustrates the possible paths that the primary and secondary LSP-Paths can traverse.
The Primary LSP-Path can go through:
R1-R2-R4-R6
R1-R2-R7-R4-R6
Both path options avoid LOWER links.
The Secondary LSP-Path can go through:
R1-R3-R5-R6
R1-R3-R8-R5-R6
Both path options avoid UPPER links.
Module 6 Page 63
The rule for CSPF in this case is: Do not use any of the links that
are in the SRLG that the primary LSP-Path goes through.
When the path-preferences of multiple standby LSP-Paths are
equal, the SRLG-enabled standby LSP-Path(s) is preferred.
Module 6 |
64
Administrative groups bring flexibility because they provide path diversity while making use of redundancy in the
network.
However, they require that LSP-Paths use only a certain group of links defined by the constraints.
This can be limiting, especially when trying to use additional constraints, such as bandwidth reservation, for the
primary LSP-Path. Some links may be preferred, given the additional constraints, but the primary LSP-Path may not be
allowed to use them because of administrative group restrictions.
Shared Risk Link Groups (SRLG) add another dimension to establishing controlled redundant paths. SRLG allows the
operators to create secondary LSPs (or Fast Reroute protection tunnels) that are automatically disjointed from the
primary LSP-Path.
The primary LSP-Path is not bound by the SRLG constraint. CSPF can choose the optimal path for the primary LSP-Path,
taking into account any administrative constraints that might be in place. If any of the secondary LSP-Paths are
configured with SRLG constraint, CSPF analyzes the path that the primary LSP-Path is established on. CSPF determines
whether the links on the primary path are members of an SRLG, and then calculates a secondary LSP-Path that avoids
the links in the same SRLG.
SRLG also modifies the secondary LSP-Path selection criteria. When multiple standby secondary LSP-Paths share the
same path-preference value, the path that is established with an SRLG constraint is preferred over those without.
Module 6 Page 64
In this example, redundant links in the upper and lower planes are
assigned to different Shared Risk Link Groups.
In general, SRLG memberships can also be defined according to
transmission (Layer-1) characteristics.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
65
The case study that was presented earlier for administrative groups is here modified to reflect Shared Risk Link Group
memberships. The redundant links in the upper and lower planes are now members of different SRLGs, as shown in the
figure above.
The main idea behind SRLG is that links belonging to the same SRLG present the possibility of a shared risk. Examples
include links going through the same fiber optic channel, transmission facility, or router. A condition which causes the
failure of one of these links might impact multiple LSP-Paths in the same group.
Module 6 Page 65
A:R2>config>router>mpls#
-------------------------------srlg-group SRLG-U value 1
interface "toR4"
srlg-group SRLG-U"
exit
interface toR7
srlg-group SRLG-U
exit
The redundant links in the upper plane are members of the SRLG
called SRLG-U.
The redundant links in the lower plane are members of the SRLG
called SRLG-L.
Module 6 |
66
Module 6 Page 66
CSPF avoids the links that the primary goes through when
calculating the secondary LSP-Path.
If it cannot avoid the primary path links, the secondary fails.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
67
The SRLG name-to-value associations are done at the Head-End router. This creates the link between the group names
in the LSP configuration and the group values in the TED.
The path definitions are the same as those in the previous administrative groups example. The exception is that the
primary LSP-Path is configured with no constraints. CSPF can choose any viable path for the primary.
The secondary LSP-Path is configured with an additional SRLG constraint. After the primary LSP-Path is established,
CSPF will calculate a secondary LSP-Path that avoids all links in the SRLG(s) that the primary LSP-Path traverses.
Module 6 Page 67
A:R1>config>router>mpls#
-------------------------------srlg-group SRLG-U value 1
srlg-group SRLG-L value 2
path fully_loose-1
no shutdown
exit
path fully_loose-2
no shutdown
exit
Module 6 |
68
The primary LSP-Path is established over the R1-R2-R4-R6 path, in the upper plane.
The R2-R4 link is a member of SRLG-U. Therefore, CSPF prunes all the links that are in the same SRLG when
calculating a path for the secondary. The secondary LSP-Path is established over the R1-R3-R5-R6 path, in the lower
plane.
Module 6 Page 68
primary fully_loose-1
bandwidth 400
least-fill
exit
secondary fully_loose-2
srlg
exit
69
In this second variation of the case study, the primary LSP-Path is configured with 400 Mbps of bandwidth reservation
constraint. CSPF determines that this bandwidth is available on the lower plane and establishes the primary over the
R1-R3-R5-R6 path. Accordingly, the secondary LSP-Path is automatically disjointed from the links in the SRLG-L group.
Module 6 Page 69
Module 6 |
70
For an LSP to be in an operationally up state, at least one of its LSP-Paths must be up.
In case of a standby secondary path, the secondary can be up, in addition to the primary.
In case of a non-standby secondary path, the secondary can be down, while the primary is up.
Recall that in either case, only primary LSP-Path is active and carrying the LSP traffic.
Module 6 Page 70
Module 6 |
71
The first command output above illustrates that three LSP-Paths are up at the same time for the given LSP.
The command output in the second figure shows that only one of the LSP-Paths - the primary LSP-Path - is active and
carrying the LSP traffic.
Module 6 Page 71
Module 6 |
72
The detailed secondary LSP-Path CLI output are displayed in the above slide.
Path Type indicates that the secondary LSP-Path is configured in standby mode.
Path Oper indicates that the LSP-Path is operationally up.
Preference indicates the custom path-preference value configured for the LSP-Path.
Srlg indicates that the SRLG constraint is enabled for the secondary LSP-Path.
SrlgDisjoint indicates that the secondary LSP-Path is successfully disjointed from the primary LSP-Path.
Module 6 Page 72
A separate RSVP session exists for each standby secondary LSPPath, resulting in more resource use:
===============================================================================
RSVP Sessions
===============================================================================
From
To
Tunnel LSP
Name
State
ID
ID
------------------------------------------------------------------------------10.10.10.1
10.10.10.6
155
47620 to_R6::fully_loose-1
Up
10.10.10.1
10.10.10.6
155
47624 to_R6::fully_loose-2
Up
10.10.10.1
10.10.10.6
155
47626 to_R6::fully_loose-3
Up
------------------------------------------------------------------------------Sessions : 3
===============================================================================
The primary and secondary LSP-Paths share the same Tunnel ID.
The primary and secondary LSP-Paths have different LSP IDs.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
73
Standby secondary LSP-Paths are established with the primary LSP-Path, for maximum resiliency.
This can also be verified in the show router rsvp session command output.
The output indicates that all the LSP-Paths belonging to the same LSP share the same Tunnel-ID. They are identifiable
by their LSP IDs.
Module 6 Page 73
Module 6 |
74
Module 6 Page 74
Section Summary
Module 6 |
75
Module 6 Page 75
Module 6 Resiliency
Module 6 Page 76
Section Objectives
Module 6 |
77
Module 6 Page 77
Module 6 |
78
Network operators expect their networks to be robust and to converge as quickly as possible after a failure. To meet
these demands, the RSVP-TE protocol has been enhanced so that protection tunnels for primary LSP-Paths can be
automatically established.
Recall how secondary LSP-Path protection can be used to provide LSP resilience. One advantage of using secondary LSPPath protection is the high administrative control given to network operators, who can determine the paths of the
secondary protection LSP-Paths. Another benefit is that a secondary LSP-Path protects the entire primary LSP-Path,
end-to-end. Regardless of the number and nature of failures along the primary LSP-Path, the secondary LSP-Path is able
to assume the traffic forwarding responsibilities.
A major disadvantage of secondary LSP-Path protection, however, is its potential operational complexity, the result of
managing a large number of manual path definitions.
Fast Reroute helps to reduce this configuration overhead with automatic path calculation and signaling capabilities. It
also allows the MPLS router closest to the point of failure to recover the traffic. This can improve convergence times
over secondary path protection.
With Fast Reroute, one protection tunnel can be used to protect multiple primary LSP-Paths, as long as they have
shared path segments. This comes with the use of the facility bypass method and helps to reduce the signaling and
session maintenance overhead in the network. The CSPF algorithm that was presented earlier plays an integral role in
the calculation of protection tunnels.
Fast Reroute is applicable for primary LSP-Paths of LSPs signaled by RSVP-TE.
Module 6 Page 78
Module 6 |
79
When an LSP is configured with a Fast Reroute protection request, the operational mode - one-to-one OR facility - must
also be specified in configuration. These modes are mutually exclusive for an LSP; only one mode can be used at any
given time. The characteristics of and differences between these modes are explained in the following pages.
Even though Fast-Reroute is enabled at an LSP level, it is only available for the primary LSP-Path. Secondary LSP-Paths
cannot be protected by Fast Reroute.
If the protection mode is not specified in the LSP Fast Reroute configuration, one-to-one is assumed by default.
Module 6 Page 79
MP
Module 6 |
80
In the one-to-one FRR protection mode, each LSP-Path requiring one-to-one backup has a protection tunnel signaled and
dedicated to protect only that LSP-Path. The backup that is signaled is called a detour.
In the figure above, three LSPs are established and each is configured with a one-to-one FRR protection request. As a
result, router R2 calculates and signals a detour tunnel for each of these primary LSP-Paths.
Should there be link failure between R2-R3, the traffic from each primary LSP-Path is rerouted over its designated
detour.
Module 6 Page 80
PLR
MP
Module 6 |
81
If facility Fast Reroute protection is required, a common bypass tunnel can be used to protect multiple primary LSPPaths. This allows resources to be shared more effectively.
In the figure above, one of the LSP-Paths is configured with facility FRR request. A bypass tunnel is created on router
R2, in response to this request. If there is a failure of the link between R2-R3, traffic can be rerouted over this tunnel.
After the bypass tunnel is established, any LSP-Path that goes through the same link can also be protected by that
bypass tunnel.
Module 6 Page 81
PLR
Module 6 |
82
A Fast Reroute protection tunnel can protect against the failure of the next node or link along the primary LSP-Path.
Although node protection can provide extensive protection for multiple links, it is not always possible because of
topological constraints or administrative reasons.
Link protection is an alternative method that can cover such cases.
When an LSP is configured, the protection type should be indicated along with the protection mode. Node protection is
enabled, by default, and can optionally be disabled.
Module 6 Page 82
Module 6 |
83
The primary LSP-Path is configured with a Fast Reroute request and node protection is enabled (default).
After the primary LSP-Path is established, router R2 observes the request and signals a protection tunnel that avoids all
of the links that are attached to router R3.
This is the process regardless of the Fast Reroute mode that is in use (one-to-one or facility). More details regarding the
establishment of router protection tunnels, based on the FRR mode, will be discussed later in the section.
Module 6 Page 83
Next
next-hop
Module 6 |
84
Module 6 Page 84
Next-hop
Module 6 |
85
With either of the Fast Reroute modes (one-to-one or facility), node protection is enabled by default.
If node protection is enabled in the LSP Head-End configuration, all routers along the primary LSP-Path (except the TailEnd) attempt to establish protection tunnels that avoid the next router in the downstream direction.
However, this might not be possible every time because of topological constraints, or other reasons. If the first node
protection attempt is not successful, the router can make two more attempts to establish a node protection tunnel. If
the third attempt also fails, the router reverts to link protection.
Note: If the first link protection attempt also fails, the router can make up to two more attempts to establish a link
protection tunnel. If all of them fail, the router reverts back to node protection again. This process can go on
indefinitely until a protection path is found. As long as the Fast Reroute request is present on the primary LSP-Path, the
router continuously tries to establish a protection tunnel in this fashion.
Node-protection can be disabled in the LSP configuration. In this case, only link-protection is attempted by the routers.
Module 6 Page 85
Module 6 |
86
In RSVP-TE Fast Reroute terminology, the routers along the protected primary LSP-Path can assume several roles,
depending on their location in the perspective of the protection tunnels.
Head-End and Tail-End terms refer to the originating and terminating points of an LSP-Path, as already described in
Module 4.
Point of Local Repair (PLR) refers to the originating point of a Fast Reroute protection tunnel.
Merge Point (MP) refers to the terminating point of a Fast Reroute protection tunnel.
Basically, all the routers along the LSP-Path (except the Tail-End) attempt to establish FRR protection tunnels
originating on them; making them all potential PLRs.
The Merge Point selection depends on the protection mode, type and the network topology under consideration. Several
case study examples are included later in the section to demonstrate these variations.
Module 6 Page 86
Point of Local Repair (PLR) is the router where the protection tunnel
originates. When the link fails, the LSP traffic is locally recovered at
this point.
Merge Point (MP) is the router where the protection tunnel
terminates and merges into the original LSP-Path.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
87
The above slide illustrates the Head-End, Tail-End, PLR, and MP concepts.
Router R1 is the Head-End router where the LSP is configured with FRR request.
In this simple topology, only router R2 has a redundant path available to perform FRR. Thus, it assumes the PLR role and
establishes a protection tunnel originating on itself.
Router R3 is the Merge Point where the protection tunnel merges back into the original LSP-Path.
Router R4 is the Tail-End router of the LSP, where the LSP terminates and the traffic is eventually delivered to.
Module 6 Page 87
Module 6 |
88
Must CSPF be enabled in the LSP configuration for Fast Reroute to work?
The answer to this question depends on the path definition. To generalize, the Head-End requires that the entire path
with all the individual hops be known prior to signaling the LSP-Path with an FRR request. There are several ways to
achieve this:
If the primary LSP-Path is configured only with strict hops, define the entire path end-to-end; Fast Reroute still
works even if CSPF is not enabled. Protection tunnels are established on every possible PLR and traffic is switched
to it in case of a failure. However, an implication of disabling CSPF is that Global Revertive will not work at the
Head-End, if reverting from a failure. Global revertive is discussed in detail at the end of the section.
If the primary LSP-Path consists of one or more loose hops, CSPF must be enabled in case Fast Reroute protection is
also enabled. CSPF calculates the intermediate hops to reach a certain loose hop, and gives the Head-End visibility
over the entire LSP-Path before signaling it.
Module 6 Page 88
Module 6 |
89
Configuration of Fast Reroute is a fairly easy task, as opposed to the amount of time and effort required to explain and
understand its operation.
The request to create Fast Reroute protection tunnels is indicated in the LSP configuration at the Head-End, together
with the desired protection mode and type.
This request is signaled to all the routers along the primary LSP-Path within the RSVP PATH message. As a result, all the
available routers assume PLR roles and automatically start the process of calculating and establishing FRR protection
tunnels. No extra configuration is required on any of the routers.
Module 6 Page 89
A:R2>config>router>mpls#
-------------------------------path fully_loose
no shutdown
lsp "to_R4
to 10.10.10.4
cspf
fast-reroute one-to-one
exit
no shutdown
exit
Module 6 |
90
The above slide illustrates example configuration to enable Fast Reroute with one-to-one router protection.
Since the path definition is empty (fully loose) and FRR is enabled, CSPF needs to be enabled in the LSP configuration.
The following pages describe the actions that are taken after the LSP is enabled with this Fast Reroute request, step-bystep. The signaling requirements to trigger these actions are also described.
Module 6 Page 90
node-protect
primary fully_loose
Module 6 |
91
In order to allow for the automatic signaling of Fast Reroute protection tunnels, certain configuration and operational
information need to be conveyed to the other routers. This is accomplished by introducing the new Fast_Reroute and
Detour objects inside the RSVP PATH messages, as defined by RFC 4090.
The description and use of these objects are provided separately in the following pages.
Module 6 Page 91
Module 6 |
92
The Fast_Reroute object is mainly used to convey the configuration information regarding the FRR options, as they are
configured at the Head-End of the LSP.
The Fast_Reroute object is included in the RSVP PATH message sent from the Head-End to signal the primary LSP-Path.
The most significant of the options that are signaled is the FRR type, which can be one-to-one or facility.
The Session_Attribute object is always included in the PATH messages, even without FRR. When FRR is enabled, the
local-protection-desired flag indicates that the receiving routers are supposed to establish FRR protection tunnels. In
addition, the protection type is indicated with the node-protection-desired flag set, if it is enabled (by default, router
protection is enabled).
Module 6 Page 92
Module 6 |
93
The example above illustrates the options signaled in the RSVP PATH message sent from the Head-End to establish the
primary LSP-Path.
Module 6 Page 93
Module 6 |
94
A sequence of events follow after enabling the LSP with Fast Reroute request.
The first task is to enable the primary LSP-Path. This is done by the usual forwarding of RSVP PATH and RESV messages.
The routers will attempt to establish the Fast Reroute tunnels after the LSP is successfully established and verified.
Module 6 Page 94
Module 6 |
95
The routers need to verify that the primary LSP-Path is successfully established, before they initiate the setup process
of protection tunnels. As explained in Module 4, LSPs are periodically refreshed after being established.
Accordingly, the first Reservation Refresh message received by a router serves as the trigger to start the pending FRR
process.
Module 6 Page 95
Protected Path
Module 6 |
96
Fast Reroute protection tunnels are calculated individually by each router assuming the Point of Local Repair (PLR) role.
Calculation is performed by the internal CSPF process embedded in each router. This requires that the Traffic
Engineering Database is readily available on all the routers.
Module 6 Page 96
Upon receipt of the second RESV message, all routers along the
primary LSP-Path (except the Tail-End):
y Assume the PLR (Point of Local Repair) role.
y Calculate separate protection tunnels that originate on
themselves, taking into account the protection method and type
(one-to-one and node-protect in this example)
Module 6 |
97
The second RESV message after initial establishment serves as a session refresh message to keep the LSP alive.
When a router receives the refresh message for the previously established primary LSP-Path, it initiates the pending
detour calculation process. As a result of the randomization introduced in the session refresh timers, as described in
Module 4, the detour calculation and establishment processes may start at slightly different times on each router.
While testing with Fast Reroute, establishing all the detours along the primary LSP-Path might take a while (mostly up
to 60-70 seconds) because of the reasons described above.
Module 6 Page 97
Protected Path
The router just before the Tail-End always performs linkprotection (failure of the Tail-End router is catastrophic for the
LSP).
FRR protection tunnels do not follow any protected path
constraints other than Shared Link Risk Groups (srlg-frr option
needs to be enabled in the global MPLS context, if that is desired).
Module 6 |
98
The requirement for Fast Reroute can also be perceived as a constraint input for CSPF.
Using node-protection, CSPF on each PLR looks for the answer to the following question in the TED: What does the
topology look like without the next downstream router all of its network links?
Using link-protection, the question becomes: What does the topology look like without the link connected to the next
downstream router?
After executing the constraints, a protection tunnel can be calculated and established on the remaining topology.
Constraints, such as administrative groups or bandwidth reservation, are not taken into account when calculating the
FRR protection tunnels, although you can configure bandwidth constraints and hop limits on the detour tunnel.
SRLG concept can also be used for Fast Reroute, if the following system-wide configuration is enabled:
A:R1>config>router>mpls# srlg-frr [strict]
Strict: With the strict option, CSPF will not establish any FRR protection tunnel if there is no path that meets the
SRLG constraint.
Non-Strict: With the non-strict (default) option, if CSPF cannot find a path for the protection tunnel using the SRLG
constraint, it disregards the constraint and tries to establish a tunnel over links that are not complaint to SRLG.
Module 6 Page 98
Module 6 |
99
The above slide illustrates the resulting network topology after the CSPF process on router R1 prunes the links according
to the FRR node-protection constraint. The next router R2 and all its network links are pruned from the topology. A
calculation will be performed on the remaining links.
Module 6 Page 99
Module 6 |
100
After CSPF pruning, the next question is: Over which links should the protection tunnel be established, and on which
router should it terminate?. The router that the protection tunnel is terminated on and merged with the original
protected path becomes the Merge Point (MP).
The answer to the question above depends on the protection mode (one-to-one or facility) and the resulting network
topology.
Using one-to-one protection, CSPF calculates a path for the detour tunnel towards the Tail-End through the shortest IGP
path. In this case, the actual location of the Merge Point also depends on the topology conditions. Some examples are
included in the following pages to illustrate this.
Merge Point selection and tunnel calculation for Facility Protection will be explained later in the section.
Using equal metric values for the links, the detour tunnel has been
calculated, as illustrated in the figure.
The Merge Point (MP) is router R4.
Module 6 |
101
For the topology in this first example, the best IGP path chosen by CSPF for the detour is as shown in the figure above.
The tunnel terminates on router R4, making router R4 the Merge Point for the detour.
Module 6 |
102
If the metric values are tweaked as shown in the figure, the shortest IGP path towards the Tail-End changes to go over
router R3. In this case, router R3 assumes the Merge Point role for the detour.
The PLR sends a separate RSVP PATH message to signal the detour
tunnel.
The detour tunnel uses the same Tunnel ID and LSP ID as the
original primary LSP-Path. This is to identify the association on all
the routers.
The LSP-Name field in the PATH message of the detour tunnel
takes the following format:
y <LSP-Name>::<Path-Name>_detour
y For example, to_R6::fully_loose_detour
Module 6 |
103
When a PLR router calculates a path for the detour, the hop information calculated by CSPF is inserted into the ERO of
the PATH message sent by the PLR. This PATH message is used to signal the detour.
As mentioned, in one-to-one protection, a separate detour tunnel is signaled for each requesting LSP. In this sense, the
detour tunnels are associated and identified with the original LSP-Paths that they are protecting.
This association is achieved by assigning the same Tunnel ID and LSP ID for the detour tunnels as their protected LSPPath. The difference lies in the LSP-Name given to detour tunnels. A _detour suffix is appended to the original LSPPath name to identify the detours.
Module 6 |
104
Another enhancement made in the RSVP-TE protocol to support Fast Reroute is the Detour Object.
In one-to-one protection, multiple detours can be created by different PLRs protecting the same LSP.
Accordingly, multiple detours protecting the same LSP might be transiting or terminating on a certain router. The main
purpose of the Detour object is to distinguish between them.
The Detour Object is included in the RSVP PATH message to signal the detour path.
Router 1 assumes the PLR role as well as Head-End for the LSP.
A PATH message is sent to establish the detour tunnel.
A detour object indicates that the tunnel from router R1 avoids
router R2.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
105
A truncated version of the RSVP PATH message sent by router R1 to signal the detour is shown above.
The ERO field contains the hops that are calculated by the PLR for the detour.
The Detour object indicates the PLR_ID as 10.10.10.1, which is the System IP address of router R1.
The Avoid_Node field indicates that the detour is created to avoid the next router for router R1, which is router R2,
with a System IP address of 10.10.10.2.
Module 6 |
106
Router R1 is the originating router (PLR) for the detour signaled for the primary LSP-Path.
Router R4 is the terminating router, also named as the Merge Point (MP).
Routers R5, R6, R7, and R8 assume transit LSR roles for the detour.
RSVP sessions are created and maintained for the detour on all the participating routers. The session states are
maintained by periodic PATH and RESV messages over the detour path, as with a normal LSP.
The detail keyword can be used with each command to see the
session details.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
107
The separate RSVP sessions created for the detours, as well as all the other sessions on the router, can be viewed in the
show router rsvp session command output.
In this example, two sessions are established on router R1. One of the sessions is for the protected primary LSP-Path
and the other session is for the detour associated with this LSP-Path.
The association can be clearly seen from this output, as indicated by the Tunnel ID, LSP ID, and LSP Name fields.
The command output can be filtered to display only the detour session status using the keywords displayed above.
If the detail keyword is used at the end of any of the mentioned commands, extensive information can be obtained
regarding the detours such as ingress/egress labels, total count of messages sent and received, and so on.
===============================================================================
From
To
Tunnel LSP
Name
State
ID
ID
------------------------------------------------------------------------------10.10.10.1
10.10.10.4
155
47620 to_R4::fully_loose
Up
10.10.10.1
10.10.10.4
155
47620 to_R4::fully_loose_detour
Up
------------------------------------------------------------------------------Sessions : 2
===============================================================================
Module 6 |
108
Similar detour path calculation and establishment takes place on router R2, as described for router R1.
CSPF on router R2 prunes all the links that belong to router R3 and achieves the resulting topology as seen in the figure
above.
The detour is signaled and terminated on router R4.
Module 6 |
109
The router just before the Tail-End always performs link protection, even if router protection is requested by router R1.
For obvious reasons, the failure of the Tail-End router is unrecoverable for the LSP.
Module 6 |
110
By default, the Record Route Object (RRO) is included in all the RSVP PATH and RESV messages used to establish and
refresh the LSPs. The RRO is populated by all the routers along the LSP-Path. It provides information about the interface
IP addresses and labels for all the hops along the path.
Having a recorded path information readily available is useful in Fast Reroute implementation, as explained in the
following pages.
Module 6 |
111
When sending the PATH message, the Head-End router R1 inserts its own interface IP address (10.1.2.1) in the RRO list.
Router R2 adds its own address (10.2.3.2) to the top of the list, when forwarding the PATH message to router R3.
Router R3 does the same so that, eventually, router R4 has full visibility over the path that the RSVP PATH message has
traversed.
Module 6 |
112
This gives the Head-End FRR status visibility over the entire
primary LSP-Path.
Module 6 |
113
One of the uses of the RRO in the Fast Reroute implementation is the reporting of protection tunnel status to the HeadEnd.
When a PLR router is able to successfully establish a protection tunnel, it sets the local-protection-available flag in
the following RESV refresh messages that it sends.
If node-protection was requested by the Head-End, and a node-protection tunnel is successfully established by the PLR,
the node-protection-available flag is also set. If a link-protection tunnel is established instead, then the flag value
remains at zero.
In the end, the Head-End router has full visibility of the routers and labels along the LSP-Path, as well as the tunnel
protection status on each router.
Module 6 |
114
The above slide illustrates the reporting of protection tunnel process performed by all the PLRs.
Router R4 is the Tail-End router, and does not perform the PLR role.
Router R3 is able to establish a link protection tunnel and sets only the local protection available flag, which is
indicated with a @ symbol in the SR OS CLI.
Router R2 is able to establish a node protection tunnel and sets both the local protection available (@) and node
protection available (n) flags in the RESV refresh messages.
Record
Record
Record
Record
Label
Label
Label
Label
:
:
:
:
N/A
200
300
400
ComputedHops:
10.1.2.1
-> 10.1.2.2
-> 10.2.3.3
-> 10.3.4.4
The Actual Hops field is extracted from the RRO of RESV message
(except the first hop, which is the Head-End router itself).
The FRR status of each router is included in the output.
NOTE: The label values shown above are not actual SR OS generated labels.
Module 6 |
115
The RRO is visible in the Actual Hops field of the show router mpls lsp <lsp-name> path detail command
output.
Note that the label values shown in the example above are simplified values, used for demonstration purposes. The
actual values should be in the dynamic label range between 32,768 and 131,071.
Actual Hops :
Detour Merging
Module 6 |
116
An optimization made in the Fast Reroute One-to-One backup implementation is Detour Merging.
The high number of detour tunnels established for each protected LSP can present considerable signaling and processing
overhead in a scaled network. To help reduce the load, RSVP 4090 allows multiple detour tunnels to merge on a router,
if they protect the same LSP-Path, and if they egress on the same link.
This means that the information in Detour Objects present in all the common detours is merged into a single PATH
message sent over the egress link.
Detour Merging is the default implementation mode on the Alcatel-Lucent Service Routers; there is no configuration
option to disable it.
Module 6 |
117
A case study is presented on this and the following pages to illustrate the Detour Merging concept.
Router R1 establishes a node protection detour tunnel that avoids the next router, R2. This information is visible in the
Detour Object of the PATH message sent by router R1.
The Tunnel_ID, LSP_ID, and Name fields are also indicated to emphasize the resemblance with the other detour path
messages in the following pages.
The attention should be focused on router R6 in the following page, as another detour will transit through it.
118
The detour calculated by router R1 is already established, as described on the previous page.
Assuming the PLR role, router R2 also calculates a detour and sends a PATH message to signal it. The Tunnel_ID, LSP_ID,
and LSP_Name fields are identical to those of the detour originated by router R1. This is a clear indication that both
detours are protecting the same LSP-Path. The detour originated by router R2 will also egress on the interface R6-R7.
Realizing this fact, router R6 terminates the detour from router R2 on itself and sends a single PATH message to router
R7.
The Detour Object included in the PATH message sent to router R7 contains the PLR_ID and Avoid_Node fields from both
merged detours.
Router R6 is named as a Detour Merge Point in the RFC terminology, after the merge operation.
Module 6 |
119
A similar merging process occurs on router R7 as well, as illustrated in the figure above.
The link protection detour originated by router R3 is terminated on router R7 and merged with the detour PATH
message received from router R6.
Router R7 is also named as a Detour Merge Point after the merge operation.
Module 6 |
120
The above slide illustrates the normal data plane forwarding operation on the original primary LSP-Path.
Detour tunnels are established on all routers assuming the PLR role, and detour merging has taken place on routers R6
and R7, as described in the previous pages.
Module 6 |
121
When a failure occurs on the link between R2-R3, or if router R3 fails, router R2 will detect the failure along the
primary LSP-Path.
Router R2 has already established a detour tunnel to protect against such failures and is responsible for locally
recovering the traffic. Therefore, router R2 switches the traffic coming in on the primary LSP-Path to the detour
protection tunnel.
The label switching operation is depicted above with simplified label values. 60, 70, 80 and 40 are the label values
previously signaled by RSVP-TE on the detour tunnel.
After the failure, router R2 swaps the incoming (outer) RSVP-TE label of 200 on the primary path with 60 on the detour
path.
Routers R6, R7 and R8 also perform label swapping along the detour path.
Router R4 is the Merge Point for the detour tunnel. Router R4 is also the terminating point for the original protected
LSP-Path.
Therefore, the detour tunnel label 40 is popped, the correct service is identified by the VPN label and the original Data
packet is delivered to the customer end.
Note that the depth of the label stack does not change at any point along the forwarding path.
It will be illustrated later in the section how label forwarding on the bypass tunnel is different for Fast Reroute Facility
protection.
Module 6 |
122
Fast Reroute Facility protection method allows multiple LSPs to be bound to the same bypass tunnel. In this sense, it is
a less resource intensive way of providing FRR protection, in terms of signaling and labels and session states needed to
be maintained.
Since the intention is to protect as many LSPs as possible with the same bypass, the selection of the Merge Point is
optimized to be more topology efficient.
The main principles of Merge Point selection and data plane forwarding in facility bypass tunnels are covered later in
the section.
A:R2>config>router>mpls#
-------------------------------path fully_loose
no shutdown
lsp "to_R4
to 10.10.10.4
cspf
fast-reroute facility
exit
no shutdown
exit
Module 6 |
123
The configuration for facility bypass protection requires a change of the one-to-one keyword to facility, as shown
above. Node protection is again the desired protection type, by default.
node-protect
primary fully_loose
Module 6 |
124
CSPF processing of the node-protection constraint is the same as in the one-to-one detour case.
The selection logic of the Merge Point is different from a one-to-one detour, however, to provide the ability to protect
as many LSPs as possible.
node-protect
Specifically:
y Link-protect MP is the PLRs Next-Hop router (1 hop away)
y Node-protect MP is the PLRs Next-Next-Hop router (2 hops
away)
Module 6 |
125
If multiple LSPs go through a certain shared portion of the network, they can all be protected by the same bypass
tunnel.
In order to accomplish this, the bypass protection tunnel must merge with the protected LSP at the closest point after
the point of failure.
In case of link protection, the closest point after the failure of the next link is the next-hop router along the protected
LSP-Path.
In case of router protection, the closest point after the failure of the next router is the next-next-hop router along the
protected LSP-Path.
These concepts are illustrated with examples in the following pages.
Module 6 |
126
In the example above, the LSP is configured with a facility bypass protection request. Node protection is disabled in
configuration, which means the routers should only attempt link protection.
Router R1 assumes the PLR role and triggers the bypass tunnel calculation process. On the resulting topology, after the
next link is pruned, the first router in the downstream direction is router R2. In other words, router R2 is the router on
which the forwarding of protected LSP traffic can resume right after the point of failure. Router R2 is chosen as the
Merge Point, and the link bypass tunnel is established to terminate on it.
The bypass tunnel established in this case can be identified with the name bypass-link10.1.2.2 in the SR OS CLI
command outputs.
no node-protect
Module 6 |
127
In the second example above, the facility bypass protection is configured with the default node protection request.
Router R1 again assumes the PLR role and triggers the bypass tunnel calculation process. On the resulting topology,
after the next router is pruned, the first router in the downstream direction is router R3. In other words, router R3 is
the router that the forwarding of protected LSP traffic can resume right after the point of failure. Router R3 is chosen
as the Merge Point, and the bypass tunnel is established to terminate on it.
Router R3 is also named as next-next-hop router in the RFC terminology.
The bypass tunnel established in this case can be identified with the name bypass-node10.10.10.2 in the SR OS CLI
command outputs.
node-protect
The complete and exact original primary LSP-Path hop and label
information is required for facility FRR.
Next-next-hop and label information are also required.
This information is obtained from the RRO of the RESV message
received on the primary LSP-Path.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
128
Using facility bypass protection, it is crucial to have the hop and label recording enabled over the original protected
LSP-Path. As elaborated more in the following pages, the PLR routers require visibility over the exact path information
for the protected LSPs. This way, they can perform the Merge Point selection to establish the bypass tunnels. PLRs can
also decide if an already established bypass tunnel can be used for another LSP requesting Fast Reroute Facility by
analyzing its recorded route information.
This information is readily available in the Record Reroute Object. The recorded route information is also required
when forwarding the traffic from the original LSP-Path in the bypass tunnel when protection is active in case of a
failure.
NOTE: Recording is enabled on Alcatel-Lucent Service Routers by default. There is an option in the CLI to disable
recording as in the following example:
A:R1>configure router mpls lsp to_R4 primary fully_loose no record
However, this is not a recommended practice because Fast Reroute cannot function in this case.
The SR OS CLI issues the following error if Fast Reroute is activated on an LSP with recording disabled:
A:R1>configure router mpls lsp to_R4 fast-reroute
INFO: MPLS #1017 LSP parameter conflict - Cannot set 'fast-reroute' because 'no record' is already set on primary path
Module 6 |
129
Fast Reroute Facility protection strives to use the resources in a more efficient way by associating multiple protected
LSPs to the same bypass tunnel whenever possible.
In order to accomplish this, the PLR router checks the Record Route Object (RRO) of the LSP that requests facility
bypass. Depending on the protection mode, the methodology of checking the RRO is as follows:
Node Protection: The PLR router checks the RRO of the requesting LSP and determines the next-next-node in the list.
The PLR then determines whether a bypass tunnel terminating on that router is already established. If it is, the new LSP
is also bound to that same bypass tunnel. The protected LSP count of the bypass tunnel is incremented to notify the
change.
On the other hand, if a bypass tunnel to the next-next-node does not yet exist, a new bypass is created. The LSP is
bound to the new bypass tunnel and the protected LSP count is set to 1.
Link Protection: The PLR router in this case again checks the RRO of the requesting LSP and determines the next-node
in the list. The PLR determines whether a bypass tunnel terminating on the next-node is already established. If it is, the
new LSP is also bound to that same bypass tunnel. The protected LSP count of the bypass tunnel is incremented to
notify the change.
On the other hand, if a bypass tunnel to the next-node does not yet exist, a new bypass is created. The LSP is bound to
the new bypass tunnel and the protected LSP count is set to 1.
The main objective is to use the same facility bypass tunnel for
multiple LSPs.
fast-reroute facility
Module 6 |
130
The case study here, which will illustrate the bypass tunnel establishment process, will involve two different protected
LSPs.
The first protected LSP established is shown above. Fast Reroute Facility is requested, so router R2 assumes the PLR
role and analyzes the RRO of the LSP. The next-next-hop router is router R4, and router R2 determines whether a
bypass tunnel that terminates on router R4 has already been established. It does not yet exist, so router R2 signals a
new bypass tunnel that avoids the next router R3 with a System IP address of 10.10.10.3/32.
The Protected LSP Count field of the bypass tunnel is set to 1.
node-protect
fast-reroute facility
node-protect
Module 6 |
131
The second protected LSP is introduced here that shares a common path segment with the previous one.
Hence, it would be possible to use an existing bypass tunnel at certain points.
fast-reroute facility
node-protect
Module 6 |
132
Router R2 again assumes the PLR role for the new protected LSP. It analyzes the RRO, and determines that the nextnext-hop router is again router R4. A router protection bypass tunnel has already been established for the previous LSP,
so that the new LSP is also bound to that same bypass tunnel.
The Protected LSP Count of the bypass tunnel is incremented to 2 to signify the change.
fast-reroute facility
Module 6 |
133
For the first LSP, router R3 is the router just before the Tail-End. The desired router protection method is not
applicable to router R3, so that it falls back to link protection.
A link protection tunnel has not yet been established on router R3 to terminate on router R4. A new link protection
bypass tunnel is established and the LSP is bound to it.
The Protected LSP Count field of the bypass tunnel is set to 1.
node-protect
fast-reroute facility
node-protect
Module 6 |
134
Router R3 again assumes the PLR role for the new protected LSP. It analyzes the RRO and determines that the nextnext-hop router is router R8. This time, it can provide router protection, unlike with the previous LSP.
A router protection bypass tunnel has not yet been established, so that a new one is created and the LSP is bound to it.
The Protected LSP Count field of the bypass tunnel is set to 1.
fast-reroute facility
node-protect
Module 6 |
135
Finally, router R4 assumes the PLR role for the second protected LSP. The desired router protection method is not
applicable to router R4, so that it falls back to link protection.
A link protection tunnel has not yet been established on router R4 to terminate on router R8. A new link protection
bypass tunnel is established and the LSP is bound to it.
The Protected LSP Count field of the bypass tunnel is set to 1.
The bypass tunnel establishment process is completed for both of the protected LSPs.
Module 6 |
136
To illustrate and emphasize the use of facility bypass protection tunnels, consider the example in the figure above.
Two LSPs are established between router R1 and router R4 going over the same links. Router R2 has created a link
bypass tunnel assuming the PLR role to protect both LSPs. The Protected LSP Count indicates this.
Module 6 |
137
When a failure occurs on the link between R2-R3, the data traffic coming in on both of the original LSP-Paths needs to
be tunneled into the same bypass tunnel.
After the traffic from both LSPs is forwarded over the bypass tunnel, they are delivered to router R3. At this point,
router R3 needs to be able to identify the two different types of traffic from each other in order to continue forwarding
them over their original LSP-Paths.
The challenge here is that, since a single bypass tunnel exists, only a single set of labels are signaled over that bypass
tunnel. Therefore, a special method needs to be implemented so that the traffic from the two LSPs is readily
identifiable at the Merge Point. This methodology is presented in the following pages.
Module 6 |
138
The label switching on the original protected LSP-Path is depicted in the figure above.
A link bypass protection tunnel is available on router R2, terminating on router R3.
Of particular interest is the label that router R3 receives, which is 300. When the link failure occurs, router R3 still
needs to receive the label 300 from the bypass tunnel, in order to identify which original LSP-Path the traffic belongs
to. This is true for all the protected LSP-Paths going over the same link, which are not shown in the figure above. All
their traffic needs to be forwarded with the same labels that router R3 expects on the original LSP-Paths, so that they
can be distinguished from each other.
The solution to this forwarding paradigm is presented in the following pages.
Module 6 |
139
The forwarding solution mentioned in the previous page is shown above for the link protection case.
When Fast Reroute is active, upon a link failure, the label that router R3 expects on the original LSP-Path (300) is
encapsulated into the label signaled for the bypass tunnel.
In more detail, router R2 (PLR) receives the traffic with an outer RSVP-TE label of 200 on the original path. It swaps this
label with 300 and then pushes a label of 60, which was signaled on the bypass tunnel. As a result, the depth of the
label stack changes from 2 to 3 on along the forwarding path of the bypass tunnel.
Router R6 swaps the outer bypass tunnel label with 70.
Router R7 swaps the outer bypass tunnel label with 30.
Router R3 is the MP or the terminating point for the bypass tunnel. Therefore, it pops the label 30 and the original
RSVP-TE label of 300 is exposed. Router R3 performs the normal swap operation for label 300 as it did on the original
LSP-Path, and forwards the traffic with label 400 to router R4.
Using facility node-protect, the PLR needs to know the Next-NextHop Router (MP), and the label it expects.
This information is available in the RRO.
Module 6 |
140
For the facility bypass node protection scenario, the Record Route Object again happens to be the key element.
To be able to deliver the traffic to router R4 on the bypass tunnel with the original label it expects for the LSP-Path,
router R2 check the RRO. The RRO indicates that 400 is the label that R4 expects.
This is true for all the protected LSP-Paths going over the same set of routers (R2-R3-R4), which are not shown in the
figure above. All their traffic needs to be forwarded with the same labels that router R3 expects on their respective
original LSP-Paths, so that they can be distinguished from each other.
Module 6 |
141
When Fast Reroute is active, upon a failure that results in the loss of communication to router R3, the label that router
R4 expects on the original LSP-Path (400) is encapsulated into the label signaled for the bypass tunnel.
In more detail, router R2 (PLR) receives the traffic with an outer RSVP-TE label of 200 on the original path. It swaps this
label with 400 and then pushes a label of 60, which was signaled on the bypass tunnel. As a result, the depth of the
label stack changes from 2 to 3 on along the forwarding path of the bypass tunnel.
Router R6 swaps the outer bypass tunnel label with 70.
Router R7 swaps the outer bypass tunnel label with 80.
Router R7 swaps the outer bypass tunnel label with 40.
Router R4 is the MP or the terminating point for the bypass tunnel. Therefore, it pops the label 40 and the original
RSVP-TE label of 400 is exposed. Router R4 performs the normal pop operation for label 400 as it did on the original
LSP-Path, and delivers the traffic to the correct service instance based on the VPN label. Eventually, the VPN label is
also popped and the original data traffic is forwarded towards the customer end.
R4 receives transport
tunnel label 400
===============================================================================
From
To
Tunnel LSP
Name
State
ID
ID
------------------------------------------------------------------------------10.10.10.1
10.10.10.4
155
47620 to_R4::fully_loose
Up
10.10.10.5
10.10.10.8
158
18432 to_R8::fully_strict
Up
10.10.10.1
10.4.8.4
63491 8
bypass-node10.10.10.3
Up
------------------------------------------------------------------------------Sessions : 3
===============================================================================
Module 6 |
142
In the case of Fast Reroute one-to-one protection, separate detours are created that are dedicated to protect a single
LSP-Path.
It has been explained that this is not the case in facility protection. Once a bypass tunnel is created upon the request of
an LSP, it stands as a separate LSP entity, and future LSPs are associated to it as necessary. In other words, the
individual LSPs do not own the bypass tunnels; they are bound to the bypass tunnels and protected by them whenever
applicable.
This can also be observed by the fact that bypass tunnels are assigned totally unique Tunnel IDs and LSP IDs, as shown in
the example output above.
===============================================================================
MPLS Bypass Tunnels (Detail)
===============================================================================
------------------------------------------------------------------------------bypass-node10.10.10.3
------------------------------------------------------------------------------To
: 10.4.8.4
State
: Up
Out I/F
: 1/1/1
Out Label
: 131068
Up Time
: 0d 03:22:04
Active Time
: n/a
Reserved BW
: 0 Kbps
Protected LSP Count : 2
Type
: Dynamic
SetupPriority
: 7
Hold Priority
: 0
Class Type
: 0
Actual Hops
:
10.2.6.6
-> 10.6.7.7
-> 10.7.8.8
-> 10.4.8.4
===============================================================================
Module 6 |
143
The details of a bypass protection tunnel are indicated above. The Protected LSP Count field displays the number of
LSPs that are bound to this bypass tunnel.
===============================================================================
MPLS Bypass Tunnels
===============================================================================
Legend : m - Manual
d - Dynamic
p - P2mp
===============================================================================
To
State Out I/F
Out Label
Reserved
Protected Type
BW (Kbps) LSP Count
------------------------------------------------------------------------------10.4.8.4
Up
1/1/1
131069
0
2
d
Protected LSPs to_R4::fully_loose
From: 10.10.10.1
To: 10.10.10.4
to_R8::fully_strict
From: 10.10.10.5
To: 10.10.10.8
------------------------------------------------------------------------------Bypass Tunnels : 1
===============================================================================
Module 6 |
144
The above command can be used to see the list of the LSPs protected by the bypass tunnel.
As with many other CLI commands, the detail keyword can be appended to the end of the command to retrieve more
extensive information.
The Head-End, notified of the failure, is also aware that the traffic
is protected by FRR.
The Primary LSP-Path remains up, with the FRR protection active
on the PLR.
This is independent of the protection method and type.
Module 6 |
145
Establishing Fast Reroute protection tunnels and forwarding traffic over the protection tunnels after a failure has
occurred in the network has been discussed in this section so far.
The rest of the section focuses on the events that take place after Fast Reroute protection has been activated by a PLR
router, and the actions that are taken by the Head-End after being informed of this fact.
After detecting the failure and immediately recovering the traffic on the protection tunnel, the next priority of the PLR
router is to inform the Head-End of the new situation. It sends a PATH Error message in the form of an RSVP Notify
Error. The Error Value field indicates that the tunnel is locally repaired at the PLR router issuing the Error message.
This tells the Head-End router that traffic forwarding still continues on the primary LSP-Path; the sole difference is that
it is on an FRR protection tunnel, and not on the original path. As a result, the Head-End does not set the primary LSPPath status to down, and keeps it operationally up and active. This is applicable to all the one-to-one/facility and
router/link protection cases.
If a standby secondary path exists, the Head-End, upon learning that a PLR has recovered the traffic, will move traffic
to the standby LSP, using MBB. If only a secondary exists, the traffic stays on the FRR path, unless the detour or bypass
tunnel fails.
There might be further actions that are taken by the LSP Head-End upon being informed of the FRR status. The
conditions and details of these actions are covered later in the section.
Module 6 |
146
The case study above is used to illustrate the concepts related to the events and actions taken after an FRR protection
tunnel activation.
A primary LSP-Path is configured with no specific hops and CSPF enabled. No additional constraints are specified for the
LSP-Path. CSPF calculates the entire LSP-Path based on the link costs. The path R1-R2-R4-R6 is chosen and signaled.
Fast Reroute one-to-one is also requested for the LSP. Router R2 signals a link protection detour that goes over routers
R7 and R8. Note that routers R1 and R4 can also establish detours going over the lower plane of the topology, but only
the detour of router R2 is shown for the sake of simplicity.
No link failures exist at present, and traffic forwarding takes place on the original LSP-Path.
Module 6 |
147
Link failure takes place and router R2 switches the traffic on the link protection detour.
Router R2 sends a PATH Error message towards router R1 that serves as a notification.
Router R1 is informed that the traffic it is pushing on the primary LSP-Path resumes on a protection tunnel established
by router R2.
Router R1 keeps the LSP-Path operationally up.
The FRR status is also visible in the RESV Session Refresh messages.
The # sign indicates that FRR is active on the router.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
148
The PLR sets the FRR in-use flag in the consecutive RESV Session Refresh messages that it sends. This provides a
continuous indication about the FRR status over the PLR, and is also useful for monitoring purposes in the CLI.
This flag can be observed in the Actual Hops field of the show router mpls lsp <lsp-name> path detail
command output.
Module 6 |
149
Router R1 is aware that the primary LSP-Path is recovered on a Fast Reroute protection tunnel, but also accounts for
the possibility that it might not be the best forwarding path available in the network at the moment.
If CSPF is enabled for the LSP, router R1 can initiate the process to look for a better path for the primary LSP-Path.
The general guidelines for this process are explained in the following pages.
If a path with a better metric than one being used (total metric of
Primary-FRR) is found, traffic is switched to it in an MBB fashion.
The Head-End can keep trying at every retry-timer expiry, until a
better path is found.
This behavior is called Global Revertive.
Module 6 |
150
As mentioned in the previous page, router R1 considers the possibility that a more optimal forwarding path might exist
in the network after Fast Reroute protection is activated.
If CSPF is enabled for the LSP, the receipt of the PATH Error message from the PLR initiates the Global Revertive
procedure on the Head-End.
As the first action, the Head-End initiates the retry-timer. The retry-timer is a configurable parameter per LSP, and is
set to 30 seconds by default.
At the first expiry of the retry-timer, the Head-End makes a new CSPF calculation for the primary LSP-Path. If a path
better than the existing one (primary-on-FRR) is found, the Head-End performs a switchover to it, using the MBB
procedures described earlier.
If a better path is not found, the retry-timer is reset and a new calculation is done at the next expiry of the timer. This
process can continue until a better path is found for the primary LSP-Path. If the link failure is removed until the retrytimer expires, this can again be the original primary LSP-Path that existed before the failure.
The case study continues with a scenario to illustrate these concepts in the following pages.
Module 6 |
151
Since CSPF is enabled for the LSP, router R1 starts the retry-timer upon receiving the PATH Error message.
The retry-timer value is set to 30 seconds by default.
Retry-Timer Initiation
Module 6 |
152
When the retry-timer expires, router R1 runs a new CSPF calculation for the primary LSP-Path.
The path calculated is R1-R3-R5-R11-R6. This path has a better metric than the existing primary-on-FRR path, which
goes over a larger number of hops. Router R1 decides to signal this new path.
Router R1 establishes the new Primary LSP-Path and switches traffic over in
MBB fashion.
The old primary LSP-Path and its detours are torn down.
If the protection type is facility, the bypass tunnel is not torn down if it still
protects other LSPs.
Alcatel-Lucent Multiprotocol Label Switching v2.1
Module 6 |
153
The new primary LSP-Path is signaled, traffic is switched over to it, and a PATH TEAR message is sent to tear down the
old LSP-Path.
The PATH Tear message serves to clear all the session states regarding the original LSP-Path and the detour tunnels that
are associated with it.
Note that this explanation is valid for the one-to-one protection case used in this example. If the protection mode is
facility, the existing bypass tunnel might still be protecting other LSPs in the network. In this case, the bypass tunnel is
not torn down. However, if this is the only LSP that the bypass tunnel is protecting, the bypass tunnel is also torn down,
as it is no longer needed at the moment.
Module 6 |
154
The retry-timer is only activated when using a Fast Reroute protection tunnel. Since the traffic is now on the original
data path of the new primary LSP-Path, the retry-timer is inactive. Router R1 will not attempt new CSPF queries for the
LSP-Path.
In the meanwhile, new detours are established on the new primary LSP-Path because the FRR request is still present in
the PATH message sent on this new path.
Retry-Timer Inactivation
Module 6 |
155
It is possible to customize the retry-timer value per LSP, as shown in the first figure above.
There is also a retry-limit under the LSP configuration. This can be used to instruct the Head-End router to stop making
new CSPF calculations after a certain number attempts are reached. The default value is set to zero, which means the
Head-End should try indefinitely until a path better than the primary-on-detour path is found for the LSP.
(Global) Resignal-Timer
Module 6 |
156
Another characteristic of LSP-Paths calculated by CSPF is that they tend to remain on their current path indefinitely,
until impacted by failure.
The implication of this is that a better path might become available after the initial CSPF calculation and LSP
establishment, but the Head-End will not attempt to switch to it under steady-state network conditions.
To override this default behavior, a global resignal timer can be activated right under the MPLS context. Note that this
is a system-wide configuration; it applies to all CSPF enabled LSP-Paths.
This timer is disabled by default. If enabled, the minimum configurable timer value is 30 minutes.
Once the resignal timer is enabled, at every expiry of this timer the Head-End checks the active LSP-Paths (the ones
that are forwarding the LSP traffic) at that time. The Head-End then triggers a new CSPF calculation for all these active
paths.
The signaling of a newly calculated path depends on the current forwarding path. Since the objective now is
optimization, The Head-End switches to the new path only if it is better than the existing one. The metric values are
compared to perform this decision.
Module 6 |
157
The case study above is used to illustrate the concepts related to global LSP re-optimization.
Traffic is currently forwarded along the primary LSP-Path, over 5 hops.
The failure on the link between R2-R4 is removed, presenting a better path between routers R1 and R4, consisting of
only 4 hops.
The Head-End will remain unaware of this fact until the configured resignal-timer expires.
Module 6 |
158
The resignal timer expires and router R1 triggers a new CSPF calculation for all the originating active LSP-Paths that
have CSPF enabled in their LSP configurations.
For the LSP-Path under consideration, the CSPF calculation yields to a better path that goes over the R1-R2-R4-R6 path.
Router R1 will switch to this LSP-Path in a make-before-break fashion.
Module 6 |
159
Router R1 has calculated a new primary LSP-Path that goes over the R1-R2-R4-R6.
The RSVP-TE signaling of this path is performed and the traffic is switched over to it in a hitless fashion.
A PATH Tear message is sent on the now-old primary LSP-Path to tear it down, along with its detours.
Module 6 |
160
The LSP is running again on the most optimal path available in the network. New detours are established as usual.
The resignal-timer will keep on running as long as it is enabled. Router R1 will repeat the re-optimization process every
time the resignal-timer expires. In this example, this happens every 30 minutes.
Module 6 |
161
LAB 6 Section 6.3 and 6.4 Fast Reroute Facility and One-to-One
Section Summary
Module 6 |
162
A separate detour tunnel is established for each protected LSP-Path, using one-to-one protection.
A single bypass tunnel can be used to protect multiple LSP-Paths that request facility protection.
Point of Local Repair (PLR) is the router performing the Fast Reroute protection.
Merge Point (MP) is the router on which the protection tunnel terminates and merges with the original LSP-Path.
In node protection, the PLR establishes a protection tunnel that avoids the next router along the original LSP-Path.
In link protection, the PLR establishes a protection tunnel that avoids the next link along the original LSP-Path.
Node protection is enabled by default, and all PLRs attempt to signal router protection tunnels. If this is not
possible, they can fall back on link protection.
CSPF is used to calculate the protection tunnels on the PLRs.
Protection tunnels are automatically signaled. Only the LSP on the Head-End is configured with the FRR
requirements. No additional configuration is required on any of the routers.
In one-to-one protection, multiple detours protecting the same LSP-Path can be merged if they transit a common
router and egress on a common link. The router performing the merging process on the detours is called a Detour
Merge Point (DMP).
Detour Merging takes place automatically and is enabled by default. It cannot be disabled in configuration.
Module 6 |
163
Enhancements were defined in RFC 4090 to enable the automatic signaling of protection tunnels.
The Fast_Reroute Object is included in the RSVP PATH message used to signal the original LSP-Path. The desire to
establish FRR tunnels and the protection mode (one-to-one or facility) is signaled in this object.
The protection type (router or link) is included in the SESSION_ATTRIBUTE object of the PATH message.
The Detour_Object is included in the RSVP PATH message used to signal the detour tunnel in one-to-one protection.
The Detour_Object indicates the PLR_ID and the protected resource (link or router ID) of the PLR performing the
protection.
In one-to-one protection, the PLR swaps the incoming RSVP-TE label on the original LSP-Path with the label signaled
on the detour path. The depth of the label stack does not increase as a result of this operation.
In facility protection, the PLR swaps the incoming RSVP-TE label on the original LSP-Path with the label that the MP
expects again on the original LSP-Path. The PLR then pushes the label signaled on the bypass tunnel. The depth of
the label stack increases by one label as a result of this operation.
Module 6 |
164
The Record Route Object (RRO) is included in all RSVP PATH and RESV messages by default.
The RRO provides exact and actual hop information about the path, together with label values.
The RRO is required for Fast Reroute functionality.
One-to-one detours have the same Tunnel ID and LSP ID as their respective protected LSPs. They are identified by
the (_detour) suffix appended to the original path names.
Facility bypass tunnels have individual and unique Tunnel and LSP IDs. LSPs are associated to bypass tunnels as
required.
The PLR router issues a PATH Error message when it activates the FRR tunnel. This notifies the Head-End of the
protection status.
The Head-End keeps the LSP-Path up and active upon receiving the PATH Error.
If CSPF is enabled in the LSP configuration, the Head-End can try to find a better path, as long as the primary LSPPath is on a protection tunnel. The retry attempts can occur at every retry-timer intervals.
The default retry-timer is 30 seconds and is configurable per LSP.
A retry-limit is also configurable and is set to 0 (retry forever) by default.
If calculated by CSPF, an LSP stays on the current path under stable network conditions. By default, it does not
attempt to switch to a more optimal path even if one becomes available after initial LSP-Path establishment.
A global resignal-timer can be configured to make a new CSPF calculation for all the active originating LSP-Paths on
a router in an attempt to find a better forwarding path.
The minimum configurable resignal timer is 30 minutes.
The Head-End switches to the newly calculated LSP-Path, only if it is better than the existing path.
Module Summary
LDP-IGP Sync ensures that the Head-End does not replace an active
LFIB entry until is receives a label from its peer.
The Head-End router moves traffic to a secondary path as soon as
it learns of a failure on the primary path.
By default, the Head-End moves traffic to the standby secondary
path with the longest uptime.
Module 6 |
165
Module 6 |
166
An FRR Merge Point (MP) returns traffic to the original LSP path
downstream of the failure.
SR OS routers enable FRR one-to-one and node protection by
default.
Merge point locations differ between FRR one-to-one and facility
bypass.
Module 6 |
167
Module 6 |
168
Learning Assessment
1.
Module 6 |
169
2.
3.
4.
What is the term used for an LSP with one or multiple associated backup tunnels?
Protected LSP
5.
6.
In what circumstances will the Head-End revert traffic to a previous secondary path?
Only if standby path-preferences are configured.
7.
If an LSP includes admin group green for use by the primary path, and red for the secondary paths, and a green link
between the Head-End and the tail-end routers is unavailable, over which path will the Head-End signal the primary
path?
It cannot signal the primary path on any other link, so it will signal the secondary, if possible.
4. What is the term used for an LSP with one or multiple associated
backup tunnels originating at that hop?
8.
9.
What is the term used for the LSP that is used to re-route traffic
around a failure in one-to-one backup?
10. What is the term used for the techniques to repair LSP tunnels
quickly when a node or link along the LSPs path fails?
11. What is the name of the Head-End LSR of a backup tunnel or a
detour LSP?
12. What are the two methods used to protect links and nodes
during network failure?
13. True or False: FRR facility attempts to return protected traffic
as close to the tail-end as possible.
8.
Module 6 |
170
If the operator configures SRLG, does the primary path have to choose links that are members of a defined SLRG
group for the secondary to come up on a disjointed path?
No; the primary path does not consider SRLG links. CSPF chooses a path for the secondary that avoids links chosen
by the primary, if possible.
9.
What is the term used for the LSP that is used to re-route traffic around a failure in one-to-one backup?
Detour LSP
10. What is the term used for the techniques to repair LSP tunnels quickly when a node or link along the LSPs path
fails?
Local Repair
11. What is the name of the Head-End LSR of a backup tunnel or a detour LSP?
Point of Local Repair (PLR)
12. What are the two methods used to protect links and nodes during network failure?
One-to-one Backup and Facility Backup
13. True or False: FRR facility attempts to return protected traffic as close to the tail-end as possible.
False. Facility bypass returns traffic to the original path as close downstream from the failure point as possible.
Module 6 |
171
14. By default, a router will attempt to protect the downstream node 3 times before reverting to link protection.
15. The Head-End router needs to know the exact path of the protected path before signaling the protection tunnel.
16. A PLR signals the detour object to inform the downstream routers of the path over which it chooses to signal the
detour tunnel.
17. The detour tunnel may terminate at the merge point or at a detour merge point.
18. Before building a bypass tunnel, the PLR checks the RRO of the requesting LSP to determine if a tunnel already
exists around the protected link and node.
19. The process the Head-End enacts to attempt to return the protected LSP path to operation is called Global
Revertive.
15. The Head-End router needs to know the _____ path of the
protected path before signaling the protection tunnel.
www.alcatel-lucent.com
3FL-30635-AAAA-ZZZZA Edition 01