alcatel-lucent multi protocol label switching student guide v1-3

Multi-protocol Label Switching

Module 0 – Course Introduction

Alcatel-Lucent Multi-protocol Label Switching v1.3 2

Module 0 | 2 All rights reserved © 2008 Alcatel-LucentAlcatel-Lucent Multi-protocol Label Switching v1.3

Multiprotocol Label Switching (MPLS) - Objectives

Day 1Module 0 – Course IntroductionModule 1 – MPLS Overview

— Lab 1 - Lab Infrastructure and IGP Configuration

Module 2 – MPLS Label Structure Module 3 – MPLS Label Signaling

— Lab 2– Static LSP Configuration

Day 2Module 3 – MPLS Label Signaling (Cont’d)

— Lab 3-1 – LDP Session Establishment




Day 2 (cont’d)Module 4 – Implementing LDP

— Lab 3-2 - Implementing Provider Core LDP — Lab 3-3 – Enabling ECMP LDP — Lab 3-4 – Applying Export Policy for Label Distribution— Lab 3-5 – Enabling Targeted LDP

Day 3Module 5 – Constraint Based IGP

— Lab 4 – Enabling Provider Core OSPF-TE and MPLS— Lab 5-1 – CSPF Based LSPs and LSP Establishment




Day 4Module 6 – RSVP Implementation

— Lab 5-2 RSVP-TE LSP Establishment— Lab 6 – Implementing Primary & Secondary LSPs

Day 5Module 6 – RSVP Implementation (cont’d)

— Lab 7 – Implementing FRR One-to-One Backup— Lab 8 – Implementing FRR Facility Backup




Understand the requirement for the implementation of MPLSDemonstrate an overall understanding of MPLS architectureDescribe the operation of the MPLS protocol and the function and operation of the MPLS control and data planesDemonstrate a good understanding of LDP and its operationDifferentiate between LDP and Targeted LDPConfigure, monitor and troubleshoot LDP in an Alcatel-Lucent environmentUnderstand packet label distribution through configuration of Static LSPsUnderstand the need for and use of Traffic Extensions to IGP protocols to support Traffic Engineering

After successful completion of this course, you should be able to:




Demonstrate a good understanding of RSVP and RSVP-TE

Describe and implement multiple methodologies for creating RSVP paths

Describe and implement LSP Traffic Protection

Understand the behavior of Secondary Path protection and its configuration

Understand the behavior of Fast Reroute and its configuration

Understand the difference between One-to-One and Facility bypass

Configure, monitor and troubleshoot RSVP in an Alcatel-Lucent environment

After successful completion of this course, you should be able to:



Prerequisites

Suggested Prerequisites• In order to fully appreciate the concepts to be discussed in this

course, it is strongly recommended that the following courseswill have already been successfully completed

• Alcatel-Lucent Scalable IP Networks • Interior Gateway Protocols



Follow On

Suggested Follow-on Courses• Based on the material covered in this course, it is recommended

that this course be followed with the Alcatel-Lucent Intro to Services Architecture course.

MPLS Exam• In order 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.



Multiprotocol Label Switching (MPLS) - Introduction

MPLS is a label switching technology combines the traffic engineering capability of ATM with the flexibility and scalability of IP. MPLS provides the ability to establish connection-oriented paths over a connectionless IP network, and facilitates a mechanism toengineer network traffic patterns independently from routing tables. MPLS technology offers many services including Layer 3 VPN, Traffic Engineering, traffic protection andLayer 2 VPN.

This 5-day instructor-led course is designed to introduce and explore MPLS concepts and related signaling protocols. This course examines in detail the LDP and RSVP protocols and their position in the MPLS topology. To reinforce the course objectives there will be discussions, comprehensive lab exercises and case studies.



Multiprotocol Label Switching (MPLS) - Course Goal

Provide the participants with a foundation knowledge of MPLS and related protocols, their application and implementation in an Alcatel-Lucent network environment.


Typical graphic symbols found in this courseware.


Presentation Graphics

Generic routers

7750 SR

Generic switch

7450 ESS

Packet (showing detail)

Network Cloud

Table/Storage Internet

Customer sites

Customer sites Tunnel or LogicalConnection

Layer 2

Header

Layer 3

Header

IP Data



Administration

Registration

Facility Information

Restrooms

Communications

Materials

Schedule

Introductions• Name and Company• Experience• Familiarity with the MPLS protocol

Questions ?

3FL-30635-AAAA-ZZZZA Edition 01

www.alcatel-lucent.com/src

Module 1 – Page 1Alcatel-Lucent Multi-protocol Label Switching v1.3


Module 1 — MPLS Overview

Module 1 – Page 2Alcatel-Lucent Multi-protocol Label Switching v1.3 2


Module Objectives

Understand the requirement for MPLS

Recognize the benefits MPLS provides

Understand IP Network Packet Forwarding and its limitations

Describe a traditional Forwarding Equivalence Class (FEC)

Understand the high level operation of MPLS

Name and describe the components of an MPLS enabled network

Understand the function of the MPLS data and control planes

Recognize the principles of the MPLS Label Swapping mechanism

After successful completion of this module, you should be able to:

Alcatel-Lucent Multiprotocol Label Switching

This course is part of the Alcatel-Lucent Service Routing Certification (SRC) Program. For more information on the SRC program, see www.alcatel-lucent.com/src

To locate additional information relating to the topics presented in this manual, refer to the following:

Technical Practices for the specific product

Internet Standards documentation such as protocol standards bodies, RFCs, and IETF drafts

Technical support pages of the Alcatel-Lucent website located at: http://www.alcatel-lucent.com/support



Module Objectives

Understand the principles of MPLS network forwarding including• Packet forwarding at an MPLS node• MPLS Forwarding Equivalence Classes (FEC)• Packet forwarding via Label Switched Path (LSP)• MPLS label operations• Label Switched Path (LSP)

Understand the concept of MPLS Traffic Engineering (TE)




MPLS Overview - Section Outline

MPLS introduction & comparison to traditional IP routing

MPLS technology drivers and benefits

Label Switching overview

Introduction to Label Distribution

Applications of MPLS


MPLS Overview

Section 1 Introduction to MPLS


Multiprotocol Label Switching (MPLS) enables 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.


Multiprotocol Label Switching

The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031

MPLS is a packet forwarding technology that uses labels to make packet forwarding decisions• The packets are identified by a label inserted into each packet

Multiprotocol because it will work with IP, ATM or Frame Relay (and others)

MPLS is independent of the IP routing protocol used• The underlying routed infrastructure may be provided by any

IGP


MPLS provides the ability to establish connection-oriented paths over a connectionless IP network. This is achieved by establishing a logical path called a Label Switched Path (LSP) that traverses the IP network.

The LSP is used by MPLS as the specific path followed by a selected sequence of packets. The packets are identified by a label inserted in each packet. Multiple LSPs may exist at any time.

In this fashion, MPLS facilitates network traffic flow and provides a mechanism to engineer network traffic patterns independently from traditional IGP routing protocols.

The MPLS Working Group of IETF at http://www.ietf.org/html.charters/mpls-charter.html may be used as a further reference.



Provides the capability to establish connection oriented paths over a connectionless IP network

This path is called a Label Switched Path (LSP)

This path will be followed by a selected sequence of packets

The LSP provides a mechanism to engineer network traffic independently from the IP routing protocol


A Forwarding Equivalence Class (FEC) is a group of IP packets that will be forwarded in the same manner, over the same path and with the same forwarding treatment. In conventional IP routing, a packet is assigned to a FEC each time a Layer 3 routing lookup is performed (i.e. at each hop).

Refer to the diagram on the next page. At Router A:

A packet with a destination IP address of 10.2.1.1 matches IP prefix 10.2.0.0/16.

A packet with a destination IP address of 10.2.2.1 also matches IP prefix 10.2.0.0/16.

As a result, both IP packets are considered to be part of the same Forwarding Equivalence Class (FEC).


Forwarding Equivalence Class – Traditional IP Routing

An IP router considers two packets to be in the same FEC if an IP prefix in the routing table is the "longest match" for each packet's destination address

As the packet traverses the network, each hop in turn re-examines the packet header and assigns it to a FEC

In conventional IP routing, a packet is assigned to a FEC at each hop when performing a Layer 3 lookup


Each router in a IP network runs an IGP routing process (i.e. static routes, OSPF, RIP, IS-IS, BGP, etc.) in order to populate their respective routing tables. Different routing protocols may be run between any set of routers, providing reachability information as required. This is a function of the control plane.

The data plane function consists of the following.

When a packet is to be forwarded, each router in the network makes an independent forwarding decision by performing the following basic tasks:

Analyzing the IP header of the received packet.

Referencing the local routing table to find the longest match for the received packet, based on the destination address in the IP header.

The routing tables typically contain entries consisting of a list of:

Each known IP network prefix, the associated egress port and the next-hop forwarding address.

Each router independently chooses a next-hop address:

Partitions the entire set of possible packets into a group of Forwarding Equivalence Classes (FECs).

Maps each FEC to a next-hop.


Traditional IP Network Operation

IP header

IP Network10.1.1.0/24

10.1.2.0/24

10.2.1.0/24

10.2.2.0/24

Port 3Port 3 Port 1

Port 3 Port 1Port 2

Port 2

Port 3

Port 1 Port 2

Port 2

Layer 2

Header

ToS TTL other

fields

Source IP

10.1.1.1

Destination IP

10.2.1.1

IP Data

Rtr-A

FIB

Prefix via

10.1.1.0/24 Port 3

10.1.2.0/24 Port 2

10.2.0.0/16 Port 1

RTR-1 RTR-2 RTR-3RTR-4

Rtr-2

FIB

Prefix via

10.1.0.0/16 Port 3

10.2.0.0/16 Port 1

Rtr-4

FIB

Prefix via

10.1.0.0/16 Port 2

10.2.1.0/24 Port 1

10.2.2.0/24 Port 1

RTR-5

IGP

Rtr-A


Due to IP’s connectionless nature, packets are transported across a network on a hop-by-hop basis, with an independent routing decision made at every node based on the destination IP address of a packet’s header.

Typically, all packets will be routed across the paths with the highest bandwidth, as this will exhibit the lowest IGP metric. This results in link congestions for that path and link underutilization for other paths through the network. This is referred to as Hyper Aggregation.

The simple, connectionless IP routing scheme contributes to a very high resiliency for IP networks. However, it does not provide anything other than a best effort delivery for all packets in the network. This makes it very difficult to support services that require more definite service levels.

The IP address plan is very simple to use and provides some basic levels of hierarchy. However, all users of a public network are required to follow specific addressing rules and address allocations. For example, if a service provider has two customers both using private addressing, the service provider must maintain a completely separate infrastructure for these customers.


Benefits and Caveats of IP Networks

Due to IP’s connectionless nature, packets are transported on a hop-by-hop basis with routing decisions made at every node

Hyper aggregation of data on certain links is the typical result

This may impact the providers ability to provide guaranteed service levels across the network end to end

IP Benefits IP Caveats

Scalability Hyper Aggregation

Overall network resiliency End to end service level limitations

Simple addressing scheme Address-based forwarding is limiting


Routing protocols cannot make use of all available network resources due to their limited mechanisms for selection of best path.

Routing protocols do not provide routers with any visibility into the state of network resource utilization, and therefore the routers are not aware of congestion in the network on certain links, underutilized alternate paths, or even links that may be completely idle.

Distributing the aggregate network traffic load over all available resources becomes difficult to achieve in conventional IP routing, and IP Hyper Aggregation remains a problem.


IP Hyper Aggregation

IP has a limited ability to alleviate Hyper Aggregation which leads to network and link congestion• All network traffic will flow via the primary path

Alternate network paths may be unused or underutilized

Primary Link

Alternate Link

IP Network

IGP


The IP protocol alone is also unable to provide guaranteed service levels across a network end to end. Certain applications may require a guaranteed amount of bandwidth over the series of links that route their packets end to end. The Service Provider may also offer service level agreements to their customers guaranteeing bandwidth and resource availability.

Traditional IP routing protocols do not provide routers with any visibility into the available bandwidth in the network across the primary or alternate links, therefore, the routers in the network can not be aware if bandwidth resources are available over the primary or alternate paths.

As shown in the example above, if all packets take the primary path, which has a low amount of available bandwidth, the link would become oversubscribed and packet loss would result.


Service Level Limitations

Inability to provide guaranteed service levels across a network end to endThe primary or alternate link may have the required resources available

Primary Link

Alternate Link

IP Network

Path Available Bandwidth

Primary Low

Alternate High


A Forwarding Equivalence Class (FEC) is a group of IP packets that will be forwarded in the same manner, over the same path and with the same forwarding treatment. It is a logical entity defined on a router to associate packets of similar characteristics, such as all packets destined for the same network. Although a FEC may be based on administrative criteria, it is typically based on the destination network.

All packets associated to a particular FEC will be forwarded along the same logical path (LSP) to the same destination.

In order to forward a packet, two primary functions are involved:

The first function partitions the entire set of possible packets into a group of FECs.

The second function maps each FEC to an LSP.

Separate packets which are mapped into the same FEC are indistinguishable.

Packets which belong to the same FEC will follow the same LSP.


Forwarding Equivalence Class - MPLS

Forwarding Equivalence Class (FEC)• A group of IP packets forwarded in the same manner, over the

same path, with the same forwarding treatment• A logical entity created by the router to represent a class

(category or group) of packets• FECs may be based on the IP destination network, or on other

criteria

All packets which belong to a particular FEC and which travel from a particular node will follow the same path• Known as a Label Switched Path (LSP)

Forwarding a packet involves:• Determining the packet’s FEC• Mapping each FEC to an LSP and adding a label• Label switching the packet across the network


In MPLS, a FEC is described as a group of packets with similar or identical characteristics which will be forwarded the same way. In MPLS, this means they may be bound to the same MPLS label.

When a packet enters the MPLS network at the first MPLS router (RTR-1), the packet is mapped into an FEC, which in turn uses a pre-assigned LSP. FEC assignment is performed only once at the ingress, and the packet follows the LSP assigned to the FEC until network egress.

This provides a significant benefit over conventional IP routing, where a packet is assigned to a FEC at each hop based on a separate and independent routing table lookup.


MPLS Forwarding Equivalence Class

In MPLS, packets are assigned to a FEC at the network ingress• FEC packets are transported by the LSP which has a label to identify

it• Label switching is used to switch the labelled packet

MPLS Network

RTR-5

RTR-3RTR-2RTR-1

RTR-4Label Switched Path

Label Switched Path


In an MPLS network IP packets are forwarded based on labels along a Label Switch Path (LSP).

A packet is mapped to a Forwarding Equivalent Class (FEC) at the first MPLS router. This essentially puts the packet onto the LSP corresponding to the FEC. At the intermediate routers along the LSP the packet is forwarded by switching incoming labels with outgoing labels. At the end of the LSP the IP packet continues its way to its destination based on traditional IP forwarding.

In order to establish the LSP, a label distribution mechanism must exist to enable the MPLS routers to exchange labels.


Packet Forwarding in an MPLS Domain

IP routing must exist in the domain independent of MPLS

MPLS label distribution is required for establishing the MPLS LSPs

Packets in a FEC travel via the LSP from RTR-1to RTR-4

LSPs are always unidirectional

MPLS Network

RTR-5

RTR-3RTR-2RTR-1

RTR-4

IGP

Label Switched Path


As in traditional IP networks, traffic flows will occur bi-directionally across the MPLS domain. A router may be the ingress to the MPLS domain for some flows and the egress for other flows, depending on where the source and destination networks (FECs) are located. In the diagram above RTR-1 is the ingress router to the MPLS domain for the top flow (red) and the egress router to the MPLS domain for the bottom flow (blue).

A single LSP is unidirectional. In common practice, because the bidirectional nature of most traffic flows is implied, the term LSP often is used to define the pair of LSPs that enable the bidirectional flow, as shown in the above diagram.

For ease of terminology and discussion however, the LSP is often referred to as a single entity. When discussing an LSP across a network, the implied meaning is a pair of unidirectional LSPs.


Traffic Flows

IP Forwarding

Traffic flows will occur bidirectionally across the MPLS domainA router may be the ingress to the MPLS domain for some flows and the egress for other flows

IP Forwarding

MPLS Network

RTR-5

RTR-3RTR-2RTR-1RTR-4

MPLS Label Switching

Label Switched Path

Label Switched Path


The FEC can be constructed based on the number of hops, bandwidth requirements, or through certain specific links or nodes in the network. Service Providers use this capability to provision customized LSPs that support specific application requirements.

The most important benefit of the label swapping mechanism is its ability to map any type of user traffic to an LSP that has been specifically engineered to satisfy user traffic requirements. The deployment of technologies based on label swapping techniques offer Service Providers precise control over the flow of traffic in their networks.

This high level of control results in a network that operates more efficiently and provides a more predictable and scalable service.


Benefits of Label Swapping

Forwarding decision is now made independently of the destination address

The choice of FEC can be based on the contents of the IP packet header or administrative policy

Allows customized LSPs• Customized LSPs may be created based on hop count,

bandwidth requirements or routed via specific network links or nodes

High level of control over the flow of traffic • Ability to map any type of user traffic to a specifically designed

LSP


Incoming packets can be assigned to an FEC by using several different characteristics. These characteristics can be based on packet header information or platform characteristics such as incoming port. In MPLS, this is done at network ingress as opposed to each hop in conventional IP forwarding.

The considerations that determine how a packet is assigned to a FEC can be very complicated, but may be made without impact to the LSRs that forward labeled packets. This determination can be made on IP header and other information.

A packet that enters the network at a particular MPLS router can be labeled differently than the same packet entering the network at a different MPLS router, and as a result forwarding decisions that depend on the ingress MPLS router can be easily made. This cannot be done with conventional forwarding, since the identity of a packet's ingress MPLS router does not travel with the packet.

MPLS offers more robust, scalable and faster converging network redundancy and resiliency options compared to IGP techniques alone.

A packet can be forced to follow a particular route which is administratively chosen, rather than being chosen by the normal IGP dynamic routing algorithm. This typically is done to support Traffic Engineering requirements.


MPLS Benefits in Comparison to Traditional IP Routing

FEC assignment is performed once at network ingress instead of at each hop

Information not contained in packet headers can be used for FEC determination• Packets arriving on different ports may be assigned to different

FECs• Same packet that enters a network via two different LSRs or LSR

ports can be forwarded via two different paths

MPLS offers improved network resiliency and recovery options compared to traditional IP networks

MPLS is able to traffic engineer packets to follow certain paths

Allows for manual or dynamic path assignment across the MPLS domain


Assuming equal costs on all the links in this network, and equal bandwidths of 1 Gigabit on all links, what is the routing problem that can be anticipated in the core of this network (routers A, B, C, D and E)?

Hyper aggregation. If all IGP metrics are equal, traffic between the cluster of nodes on the left and the cluster of nodes on the right will all follow the link between nodes A and E. The traffic flows can be altered by manipulating the IGP metrics, but there is no way to change the path used based on the level of congestion on that link.


IP Routing Issues – Example 1

A

BC

D

E


There is a desire to add high bandwidth, high latency satellite links across the core between routers A and D and between B and C. These are intended for the transfer of large volume, batch datasets. Discuss the routing issues.

The dotted lines between A and D and between B and C represent high bandwidth, high latency satellite links. It is desirable to send bulk data traffic such as large file transfers over the satellite links, while more delay sensitive traffic should travel over the terrestrial links between A and C and between B and D. Although IP Precedence values can be used to identify the different types of traffic, traditional IP routing does not typically make routing decisions based on this information.



A

B C

D

10100

10

High bandwidth, high latency satellite links


A national service provider has a high bandwidth core across the country. However there is concern about the effect of queuing delays on premium voice traffic. It is desirable to minimize the number of hops for voice traffic and therefore additional, lower bandwidth and higher cost links are added to the network. Discuss the routing issues.

In this scenario there is a core backbone network with high bandwidth links that have low IGP metrics represented by the links with a cost of 10 and a number of additional, more expensive and lower capacity links with a cost of 1000. These additional links are intended for traffic on the network for which it is desirable to minimize the number of hops traversed. The additional links are provided as alternate routes for delay and jitter sensitive traffic so that it can avoid queuing delays on the backbone routers. Again, traditional IGPs are not able to make routing decisions to support this scenario.



10 10 10 10

1000

10001000

Low capacity link High capacity link


MPLS technology is driven by the high demand for reliable and differentiated IP services including some of the following:

VPLS

VLL

Layer 3 VPRNs (Virtual Private Routed Networks)

Provider Managed Services

• Internet

• Outsourced Firewall

• Voice Over IP (VoIP)

• Network Management


MPLS Technology Drivers

There exists a high demand for IP services including• VPLS• VLL• Layer 3 VPRNs (Virtual Private Routed Networks)• Provider Managed Services

— Internet— Outsourced Firewall— Voice Over IP (VoIP)— Network Management

Customer demands for reliable and differentiated services• Traffic Engineering is required


Deployment of the MPLS protocol offers many benefits and solutions to the issues presented on the previous pages, including the following:

Reduces cost by using existing and ubiquitous IP and Ethernet technologies

The ease of use of Ethernet and familiarity of IP may be leveraged

Offers enhanced routing capabilities by supporting more than just destination based forwarding

Packet flows may be defined based on criteria such as bandwidth or service classes

Standards-based technology that promotes multi-vendor interoperability

MPLS is an IETF standard supported by most router vendors

Flexibility to evolve control functionality without changing the forwarding mechanism

The MPLS label swapping process is the same regardless of how labels are assigned or distributed


MPLS Technology Benefits

Reduces cost by using existing and ubiquitous IP and Ethernet technologies

Offers enhanced routing capabilities by supporting more than just destination based forwarding

Standards based technology that promotes multi-vendor interoperability

Flexibility to evolve control functionality without changing the forwarding mechanism


Some of the main MPLS applications are MPLS Traffic Engineering (TE), Layer 2 VPN (VPLS), Layer 3 VPN (VPRN), and Quality of Service (QoS).

These services may be offered over virtually any Data Link layer technology and supports both IP unicast and multicast flows.

MPLS minimizes the IP lookup, forwarding, and classification process over traditional IP networks, as IP lookup, forwarding and classification are done only at ingress and egress of the MPLS connection.

Evolution of the MPLS base technology as now been extended to Generalized MPLS (GMPLS). In GMPLS, the control plane remains IP based, however the data plane can now diversify to include more varieties of traffic (TDM, Lambda, packet, and fiber, etc). GMPLS supports multiple types of switching including the addition of support for TDM, lambda, and fiber (port) switching.

In summary, GMPLS extends MPLS functionality by establishing and provisioning paths for:

Time Division Multiplexing (TDM) paths, where time slots are the labels (SONET).

Frequency Division Multiplexing (FDM) or Wavelength Division Multiplexing (WDM) paths, where electromagnetic frequency is the label (light waves).

Space division multiplexed paths, where the label indicates the physical position of data (photonic cross-connect).

GMPLS is expected to help Service Providers dynamically provision bandwidth and capacity, improve network restoration capabilities, and reduce operating expenses.

Refer to RFC 3945 - Generalized Multi-Protocol Label Switching (GMPLS) Architecture for more information on GMPLS.


MPLS Technology Benefits (Cont’d)

Permits delivery of new services that are not readily supported by conventional IP routing techniques• Traffic Engineering• ToS and CoS based forwarding• Layer 2 and Layer 3 Virtual Private Networks (VPN)

Runs over any Data Link layer technology

Supports the forwarding of both unicast and multicast traffic flows

Minimizes the IP lookup, forwarding, and classification process over traditional IP networks


On the end-to-end path between two systems, part of the network may be a traditional IP network and part of the network an MPLS domain. In the part of the network that is not MPLS, traditional IP forwarding methods are used.


Packet Forwarding via the Label Switched Path (LSP)

• The LSP defines a path through a network that is followed by allpackets assigned to a specific FEC

MPLS Network

RTR-5

RTR-3RTR-2RTR-1

RTR-4

IP ForwardingIP ForwardingMPLS Label Switching

Label Switched Path


An MPLS label is a short, fixed length field contained in the MPLS header. The MPLS header, when present in a frame, exists between the frame header and the IP packet header.

The MPLS data plane is based on a label swapping (switching) forwarding mechanism. This is a similar in function to the mechanism used to forward data in ATM and Frame Relay switches. As a result, the MPLS label itself is very similar in function to the ATM VPI/VCI or a Frame Relay DLCI.

When a packet enters the network it is assigned a label. As it traverses the MPLS domain, forwarding decisions are made by exchanging the received MPLS label for a new MPLS label and forwarding the packet. As the packet leaves the network, all labels must be removed.


MPLS Label Swapping

A label is a short, fixed length field in the MPLS header• The MPLS header is between the frame header and the IP

packet

The MPLS label swapping (switching) mechanism is similar to switching used in ATM and Frame Relay networks• A label is similar to an ATM VPI/VCI or a Frame Relay DLCI

The label swapping mechanism requires packet classification at the ingress to the MPLS domain in order to assign an initial label to each packet

Signaling and label distribution mechanisms are required to define the labels to be used for an LSP


In order to create an LSP, it is necessary to distribute labels for the path. Labels are always distributed by a downstream router in the upstream direction (relative to the data flow). There are a number of different protocols used for label distribution.

LDP (Label Distribution Protocol) can be considered as an extension to the network IGP. As routers become aware of new destination networks, they advertise labels in the upstream direction that will allow upstream routers to reach the destination.

RSVP-TE can also be used to signal LSPs across the network. RSVP-TE is used for traffic engineering when the ingress router wishes to create an LSP with specific constraints beyond the best route chosen by the IGP. RSVP-TE identifies the specific path desired for the LSP and may include resource requirements for the path.

Targeted LDP is a version of LDP used by the two end points of a Layer 2 VPN service to identify that service.

Multiprotocol BGP is a version of BGP used by the two end points of a Layer 3 VPN service to identify that service.


Label Distribution

Label switched paths are created by distributing labels for them

Egress (or downstream) router provides labels for its destinations

Different label distribution protocols are used for different applications

• LDP (Label Distribution Protocol) is used for basic MPLS forwarding and for the transport of VPN services

• RSVP-TE (Resource Reservation Protocol – Traffic Engineering) is used for services that require traffic engineering

• Targeted LDP is used for end-to-end signalling of Layer 2 services• M-BGP (Multiprotocol Border Gateway Protocol) is used for end-to-

end signalling of Layer 3 services

Once labels have been distributed the path can be used for the transport of data



Applications of MPLS

IGP shortcuts• Reduces requirement for full iBGP mesh

Traffic engineering• More efficient use of network resources• Provide service guarantees and resource reservations• Enable other constraints on traffic flow

High availability and redundancy• Set up alternate paths to provide high availability services• Enable fast reroute to adapt quickly to topology changes

Virtual Private Network services (VPNs)• Provide virtual point-to-point links• Emulate private Layer 2 and Layer 3 networks• Support any other tunnelling requirements


IGP shortcuts enable a service provider to reduce the requirement for a full mesh of peering sessions for iBGP. With IGP shortcuts, a full mesh of peering sessions and LSPs are established between all the edge BGP routers (those with EBGP sessions to other autonomous systems). The edge routers then define the peer at the other end of the LSP as the next hop and sends its packet flow through the LSP tunnel. Since the packets are transmitted in an LSP tunnel, the core routers do not perform any IP forwarding and since they do not need to know the external routes, they do not need to participate in the IBGP mesh.


IGP Shortcuts

Shortcut LSP

Shor

tcut

LSPShortcut LSP

Shortcut LSP

External Network

External Network

External Network

External Network


IP routing protocols are unable to select a best route based on network utilization. The selection of best route is done by the lowest cost, which often leads to hyper aggregation of traffic flows on some links. Because the forwarding of packets in an MPLS network is no longer done hop-by-hop, alternate paths across the network can be created as required. Besides relieving congestion on over-subscribed links, alternately routed paths can be used to meet other constraints such as quality of service requirements.


MPLS Traffic Engineering

Hyper aggregation leads to some links being congested while others are underutilized

Traffic engineered LSPs can shift traffic to other paths

Primary Link

Alternate Link

IP Network

IGP best path

Traffic engineered path


IP routing protocols are unable to select a best route based on network utilization. The selection of best route is done by the lowest cost, which often leads to hyper aggregation of traffic flows on some links. Because the forwarding of packets in an MPLS network is no longer done hop-by-hop, alternate paths across the network can be created as required. Besides relieving congestion on over-subscribed links, alternately routed paths can be used to meet other constraints such as quality of service requirements.


MPLS High Availability

IP routing protocols provide high availability, but can be slow to re-converge after a topology change

Alternate paths can be established in advance

Primary Link

Alternate Link

IP Network

Primary Path

Secondary Path


Since all data in an MPLS network is transported in LSP tunnels, MPLS provides an ideal foundation for the construction of Virtual Private Networks (VPNs). Customer traffic is identified as it enters the service provider’s network and is assigned to the appropriate LSP for transport across the network. At the egress side of the network the traffic is delivered to the appropriate customer.

This configuration allows a service provider to use a common infrastructure for multiple customers while maintaining complete separation between customers. Since customer data is encapsulated in an MPLS labelled packet, the type of packet and its addressing is irrelevant. Thus, MPLS can be used to support Layer 3 VPNs that appear as a routed network to the customer, as well as Layer 2 virtual links and virtual networks.


MPLS VPN Services

Customer traffic is identified at the ingress to the network andtransported separately across the network

Customer A10.1.1.0/24

Customer B10.1.1.0/24

Customer B10.2.1.0/24

Customer A10.2.1.0/24

Customer A VPN

Customer B VPN


MPLS Overview

Section 2 - MPLS Basic Operation



MPLS Basic Operation - Section Outline

Terminology

MPLS basic operation• POP• SWAP• PUSH

MPLS tables


MPLS supports the following link-layer protocols:

Ethernet - Ethernet Type Code 0x8847.

Cisco High-level Data Link Control (HDLC) - Ethernet Type Code 0x8847.

Generic Routing Encapsulation (GRE) tunnel - Ethernet Type Code 0x8847.

Point-to-Point Protocol (PPP) - Protocol ID 0x0281, Network Control Protocol (NCP) protocol ID 0x8281.

Asynchronous Transfer Mode (ATM) - Subnetwork attachment point encoded (SNAP-encoded) Ethernet type 0x8847. Supports both point-to-point or Nonbroadcast Multiaccess (NBMA) mode. Support is not included for encoding MPLS labels as part of the ATM Virtual Path Identifier (VPI)/ Virtual Circuit Identifier (VCI).

Frame Relay - SNAP-encoded, Ethernet type 0x8847. Support is not included for encoding MPLS labels as part of the Frame Relay Data-Link Connection Identifier (DLCI).


Layer 1

MPLS OSI Integration

MPLS operates over any underlying Layer 2 protocol or Layer 1 media

Ethernet Frame Relay ATM PPP

MPLS

IP


Service Provider terminology is used to describe the physical position of a device in the provider network.

Provider Edge (PE) devices have at least one interface outside the provider domain.

Provider Core (P) devices have all interfaces internal to the provider domain.


Provider Terminology - PE and P

Provider Edge Routers (PE)• These devices have at least one interface outside the provider

domain facing the customer

Provider Core Routers (P)• These devices have all interfaces internal to the provider

domain

Provider Network

PE

PE

P

PP


A Label Edge Router (LER) is a device at the edge of an MPLS network, with at least one interface outside the MPLS domain. A router is usually defined as an LER based on its position relative to a particular LSP. The MPLS router at the head-end of an LSP is called the ingress Label Edge Router (iLER). The MPLS router at the tail-end of an LSP is called the egress Label Edge Router (eLER).

These devices receive unlabeled packets from outside the MPLS domain, apply MPLS labels to the packets and forward the labeled packets into the MPLS domain, or they receive labeled packets from the MPLS domain, remove the labels and forward unlabeled packets outside the MPLS domain.

Label Switching Routers (LSR) is a device internal to an MPLS network, with all interfaces inside the MPLS domain. These devices switch labeled packets inside the MPLS domain. In the core of the network, LSRs ignore the packet’s network layer (IP) header and simply forward the packet using the MPLS label swapping mechanism.

The MPLS routers along an LSP perform one of the following tasks:

The iLER encapsulate packets with an MPLS header and forwards it to the next router along the Label Switched Path. An LSP may have only one ingress router.

A Label Switch Router (LSR) can be any intermediate router in the MPLS Service provider network between the ingress and egress LERs. A transit router swaps the incoming label with the outgoing MPLS label and forwards the MPLS packets it receives to the next router along the Label Switched Path. An LSP can only contain an ingress and egress LER without transit LSRs in between, or it can contain up to 253 transit LSRs.

The eLER strips the MPLS header, which changes it from an MPLS packet to an IP data packet, and then forwards the packet to its final destination using information in the forwarding table. Each LSP can have only one egress router.

The ingress and egress routers in an LSP cannot be the same router. An MPLS router in any network can act as an ingress, egress, or transit LSR for one or more LSPs, depending on the network topology.


MPLS Terminology – iLER, eLER and LSR

The router at the beginning of an LSP is called the ingress Label Edge Router (iLER)

The router at the end of an LSP is called the egress Label Edge Router (eLER)

The router(s) at the intermediate points along the LSP between the iLER and eLER is called the Label Switching Router (LSR)

MPLS Network

LSR

LSRLSRiLER eLER

Packet Flow

Label Switched Path


A Label Switched Path (LSP) is the unidirectional logical path across an MPLS domain that is followed by all packets associated to a specific FEC. LSPs are unidirectional in nature. LSPs are functionally equivalent to an ATM or Frame Relay virtual circuit (VC).

An LSP is often referred to as a Transport Tunnel.

Each LER or LSR performs a different MPLS function based on its position relative to the LSP, and the direction of the LSP.


MPLS Terminology - Label Switch Path (LSP)

A Label Switched Path (LSP) is the unidirectional logical path across an MPLS domain based on a specific FEC

An LSP is often referred to as a Transport Tunnel

Ingress and egress are relative to the packet flow

MPLS Network

LSR

LSRLSRiLER eLERLabel Switched Path


The egress router to the MPLS network (eLER) receives a labeled packet and transmits an unlabeled IP datagram. The ingress interface and incoming label identify that the labeled packet has reached the end of the LSP. The egress router removes the label and forwards the packet based on conventional IP forwarding.

RTR-4 performs a POP label processing operation to remove the MPLS label header and forwards the packet to its next hop, Rtr C.

To summarize the egress LER performs the following functions:

Receives labeled IP packets from within the MPLS domain via the LSP

Removes the MPLS header from the IP packet (there may be one or more MPLS headers present in the packet, depending on the configuration)

Perform a table lookup to determine the next-hop and egress interface to be used for packet forwarding

Forwards unlabeled IP packets outside the MPLS domain based on the IP packet destination address


The eLER removes the label and forwards the packet based on traditional IP forwarding


POP

RTR-4 In

Label

Next hop

200 Rtr C

MPLS Network

RTR-1

RTR-4

10.1.1.0/24

10.2.1.0/24

RTR-5

RTR-3RTR-2Rtr A

Rtr B

Rtr C

Label Switched Path


The table above summarizes common terminology used to describe devices and device roles in an MPLS enabled network.


Terminology Summary

A summary and comparison of device terminology

Terminology Role

PE •Router at the edge of the service provider network.•Faces the customer router and provides services (i.e. are service aware)•Typically an LER

P •Router in the core of the service provider network •Normally not service aware•Typically an LSR

LSR •Router in the MPLS Domain responsible for swapping labels•An intermediate router along an LSP path•Typically a P router

iLER •Router at the edge of the MPLS domain responsible for pushing labels •The router at the ingress (head-end) of a LSP•Typically a PE router

eLER •Router at the edge of the MPLS domain responsible for popping labels•The router at the egress (tail-end) of a LSP•Typically a PE router


On the end-to-end path between two systems, part of the network may be a traditional IP network and part of the network an MPLS domain. In the part of the network that is not MPLS, traditional IP forwarding methods are used.

At the customer router Rtr A the IP packet is forwarded based on the destination IP address in the IP packet header.


Outside the MPLS domain the unlabeled packet is forwarded using conventional IP forwarding methods


MPLS Network

RTR-1

RTR-4

10.1.1.0/24

10.2.1.0/24

IP Forward

Rtr A FEC Next hop

10.2.1.0/24 RTR-1

RTR-5

RTR-3RTR-2Rtr A

Rtr B

Rtr C

Label Switched Path


At the ingress router to the MPLS domain (iLER), the incoming packet is assigned to an FEC. Every FEC has an LSP that defines the path the packet will follow over the MPLS network. This LSP is uniquely identified by the label assigned for the LSP and the next hop router. The ingress MPLS router adds the MPLS header to the original IP datagram before it forwards the packet. This is known as a label PUSH operation.

In the diagram above, RTR-1 inspects the IP header of the packet and PUSHes a MPLS label header with a label value of 100 for packets that are destined to FEC 10.2.1.0/24.

To summarize, the ingress LER performs the following functions:

Receive unlabeled IP packets from outside the MPLS domain

Perform a table lookup to determine which label to assign to the packet, based on the FEC

Determines the next-hop and egress interface to be used for packet forwarding

Insert one (or more) MPLS headers onto each IP packet

Forward labeled IP packets into the MPLS domain via the LSP


The iLER assigns the incoming packet to an FEC, which has a corresponding LSP identified by a label


PUSH

RTR-1 FEC Out

Label

Next hop

10.2.1.0/24 100 RTR-2

MPLS Network

RTR-1

RTR-4

10.1.1.0/24

10.2.1.0/24

RTR-5

RTR-3RTR-2Rtr A

Rtr B

Rtr C

Label Switched Path


The intermediate MPLS routers (LSRs) receive the incoming labeled packet and based on the incoming label look up the corresponding outgoing label and next hop router for this LSP. The incoming label is replaced with the outgoing label when the packet is transmitted. This is known as a label SWAP operation.

At RTR-2 no further analysis of the packet's IP header is performed. Rather, the label value 100 is used as an index into a table which specifies the next-hop and a new label value of 300. The incoming label is replaced with the new outgoing label of 300 and the packet is forwarded to its next-hop. At RTR-3 the process is repeated. This time incoming label 300 is swapped with outgoing label 200 and the packet is forwarded to the next-hop along the LSP.


LSRs use label switching only to forward the packet


SWAP

RTR-2 In

Label

Out Label

Next hop

100 300 RTR-3

SWAP

RTR-3 In

Label

Out Label

Next hop

300 200 RTR-4

MPLS Network

RTR-1

RTR-4

10.1.1.0/24

10.2.1.0/24

RTR-5

RTR-3RTR-2Rtr A

Rtr B

Rtr C

Label Switched Path


When the packet reaches Rtr C, it is no longer labeled and is handled like any other IP datagram. Rtr C forwards the packet based on the longest prefix match from the IP routing table.


Rtr C performs conventional IP forwarding of the unlabeled packet


IP Forward

Rtr C Prefix Next hop

10.2.1.0/24 Direct

MPLS Network

RTR-1

RTR-4

10.1.1.0/24

10.2.1.0/24

RTR-5

RTR-3RTR-2Rtr A

Rtr B

Rtr C

Label Switched Path


PUSH (insert, add, impose) an MPLS header onto an unlabeled IP packet.

Packet Flow

1. An unlabeled IP packet arrives on an interface of the iLER at the edge of the MPLS domain.

2. A routing lookup is performed and it is determined the packet is to be forwarded into the MPLS domain, since an MPLS label is associated to the egress interface.

3. The iLER must PUSH an MPLS header (containing the label) onto the existing IP packet before forwarding into the MPLS domain.


MPLS Label Operations - PUSH

MPLS Network

LSR

LSRLSRiLER

eLER

An MPLS header containing a label is inserted into each IP packet when it enters the MPLS domain at the iLERThis behavior is referred to as a PUSH operation

Data Link Header

IP Header IP Data FCS

Data Link Header

MPLS Header


Label Switched Path


SWAP (exchange, replace) the label int the MPLS header at the top of the label stack with a specified new label value.

Packet Flow

1. A labeled IP packet arrives on an interface of an LSR internal to the MPLS domain.

2. A lookup on the label value and ingress interface is performed, and a new header is assigned to the packet for forwarding through the MPLS domain.

3. The LSR must SWAP the label value in the incoming packet for a new label before forwarding to the next LSR in the MPLS domain.

4. This process is repeated at each LSR inside the MPLS domain.


MPLS Label Operations - SWAP

MPLS Network

LSR

LSRLSRiLER

eLER

The label in the MPLS header in each IP packet is exchanged for a new label as it passes through each LSR within the MPLS domainThis behavior is referred to as a SWAP operation

Data Link Header

MPLS Header

IP Header

IP Data FCS

Data Link Header

MPLS Header


Label Switched Path


POP (remove) the top label in the label stack.

Packet Flow

1. A labeled IP packet arrives on an interface of the eLER at the edge of the MPLS domain.

2. A lookup is performed and it is determined the packet is to be forwarded outside the MPLS domain, since there is not an MPLS label associated to the egress interface.

3. The eLER must POP the MPLS header from the packet and forward only unlabeled packets outside the MPLS domain.


MPLS Label Operations - POP

MPLS Network

LSR

LSRLSRiLER

eLER

The MPLS header containing the label is removed from each IP packet as it leaves the MPLS domain at the eLERThis behavior is referred to as a POP operation

Data Link Header

MPLS Header


Data Link Header


Label Switched Path


MPLS is composed of two distinct functional components (planes); a control component (control plane) and a forwarding component (data plane). In the Alcatel-Lucent 7750 these components are also physically separate. The CPM performs the functions of the control plane; the data plane functions are handled by the IOMs.

The control plane uses standard routing protocols to exchange information with other LSRs to build and maintain forwarding tables, and label exchange protocols to communicate label binding information with other LSRs.

The routing control plane component selects the best route for each unique prefix from the RIB. If more than one routing protocol is in use, there may be more than one RIB. Best routes from each protocol are evaluated by the Routing Table Manager (RTM) and the RTM's selection of best route will be propagated to the FIB, where it will become the active route.

The second component is label control plane. MPLS enabled devices will generate labels for selected FECs and exchange them with other MPLS enabled devices, similar to routing exchange. The locally generated labels and those received from other devices are populated into the Label Information Base (LIB). A selection is made from those labels, and the labels that will be used for switching packets are propagated from the LIB to the Label Forwarding Information Base (LFIB).


Alcatel-Lucent 7750 is functionally and physically separated into a control plane and data, or forwarding plane

Control plane• Exchanges routing information with other routers using standard

routing protocols— Information is stored in the routing table or RIB

• Communicates label binding information with other LSRs using label exchange protocols

— Information is stored in a label database or LIB

Data plane• Forwarding information base (FIB) is populated from the RIB

— Used for forwarding unlabeled packets

• Label forwarding information base (LFIB) is populated from LIB— Used for forwarding labelled packets

Router Control Plane and Data Plane


An IP router forwards only unlabeled packets. It participates in the routing domain, exchanging routing updates with its neighbors. This information is used to populate the routing information base (RIB). The route table manager (RTM) selects the best routes from all routing protocols enabled on the router and completes the route table. This is passed to the IOM as the FIB. The FIB is used to perform IP forwarding of unlabeled packets.


Control Plane vs. Data Plane – IP Router

IP router forwards only unlabeled packets

FIB Unlabeled IP PacketUnlabeled IP Packet

Routing

Exchange

Routing

Exchange

Data Plane

Control Plane

RIB


An LER must function fully in the IP forwarding domain (as an IP router) and in the MPLS domain (as a label switching router). The LER control plane participates in the IP routing domain through the exchange of routing updates and participates in the MPLS domain through the exchange of labels to be used for label switching.

The MPLS data plane utilizes the tables maintained by the control plane to make routing or label switching decisions as each packet arrives.

It performs IP packet forwarding, label packet forwarding, and label operations. The data plane examines information contained in the packet’s header, searches the respective forwarding table for a match, and directs the packet from the input port to the output port.

An LER may receive an unlabeled IP packet and forward it as a labeled IP packet or as an unlabeled IP packet.

An LER may also receive a labeled IP packet and forward it as a labeled IP packet or as an unlabeled IP packet.


Control Plane vs. Data Plane – LER

A packet may arrive at the LER labeled or unlabeled and may leave the router labeled or unlabeled

FIB

Unlabeled IP Packet

Labeled IP Packet

LFIB

Unlabeled IP Packet

Labeled IP Packet

Routing

Exchange

Routing

Exchange

Label

Exchange

Label

Exchange

Data Plane

Control Plane

LIB

RIB


The role of a LSR as the intermediate router along an LSP is simply to perform label switching of labeled packets. It is not meant to forward unlabeled packets. However it must still participate in the routing domain in order exchange routing information with the other routers, and learn the FECs advertised by other routers. If a router does not learn of the FECs it will not be able to generate labels for these FECs and hence it will not be able to label switch packets to the FECs.


Control Plane vs. Data Plane – LSR

LSR switches only labeled packets

Still needs to participate in the IGP routing domain

Labeled IP PacketLFIBLabeled IP Packet

Routing

Exchange

Routing

Exchange

Label

Exchange

Label

Exchange

Data Plane

Control Plane

LIB

RIB


There are multiple tables maintained by a router in an MPLS enabled network which are summarized above.

These tables are populated by control plane functions, with the FIB and LFIB used by the data plane to forward packets.


Tables in an MPLS Network

A summary of tables seen in an MPLS network and their contents

Table Name

Meaning Contents Populated By

RIB Routing Information Base

Routing updates received

Routing protocol exchange - Each routing protocol has a separate RIB

FIB Forwarding Information Base

Active routes RTM selects the active routes from all protocol "Best" routes

LIB Label Information Base

Locally generated and received MPLS labels

MPLS label exchange

LFIB Label Forwarding Information Base

Labels used by the LSR The labels assigned to the active routes (for each next-hop)

Tables are populated by control plane functionsFIB and LFIB are used for forwarding packets


In the diagram above, identify the following components of an MPLS network:

CE router

PE router

P router

LER

LSR

For any specific link in the network state whether it will carry unlabeled packets, labeled packets or both.


Customer A

Customer B

Customer C

Customer A

Customer B

Customer C

Customer A

Customer B

Customer C

MPLS Network Components

Service provider MPLS network


FEC out_label next_hop X 100 rtr5 Y 200 rtr3 Z 300 rtr5 Q 400 rtr3

Given the topology in the slide and the Routers’ label tables below, trace the LSP for each FEC listed in RTR-6’s table and identify the routers which originated these FECs. Identify the labels and routers used for each hop.

RTR-6 Table

in_label out_label next_hop rtr1 240 130 rtr2 110 pop IP 330 pop IP 140 160 rtr2 150 170 rtr2 rtr2 170 pop IP 210 330 rtr1 130 150 rtr4 160 260 rtr5 rtr3 100 110 rtr1 140 130 rtr2 220 330 rtr1 120 210 rtr2 400 140 rtr1 130 260 rtr5 350 150 rtr1 200 240 rtr1 rtr4 150 pop IP rtr5 160 130 rtr2 100 120 rtr3 300 350 rtr3 260 pop IP


Label Switching Exercise

rtr5

rtr4

rtr1

rtr3

rtr6

rtr2

Starting point



LAB 1 Core Configuration

Pod 1 Pod 2

Pod 3

P2P1

P3

PE1

PE 3

PE 2

Pod 4

P4

PE 4

10.48.1.0/24 10.64.1.0/24

10.16.1.0/24 10.32.1.0/24

10.x.y.z/24

Service Provider CoreIGP Routing



Module Summary

MPLS allows optimum routing with Layer 3 awareness over any Layer 2 medium solving many issues of traditional IP forwarding

MPLS label switching technology provides the ability to establish connection-oriented paths over a connectionless IP network

MPLS label forwarding provides performance improvement over traditional packet lookup and forwarding particularly in older routers

MPLS enables Service Providers to build highly reliable and scalable core networks and offer customers IP and differentiatedservices based on QoS and other features

A Forwarding Equivalence Class (FEC) is a group of IP packets that will be forwarded over the same path with the same forwarding treatment



Module Summary (continued)

MPLS Traffic Engineering allows Service Providers to distribute traffic flows over any core link independently from IP routing tables

Routers that support MPLS are generically known as Label Switch Routers (LSRs)

The router at the beginning of an LSP is the ingress LER (iLER)

The router at the end of an LSP is the egress LER (eLER)

The MPLS control plane exchanges routing information, label bindings and maintains the forwarding table

The MPLS data plane forwards labeled or unlabeled packets based on information contained in the packet’s header




A Label Switched Path (LSP) defines an ingress to egress path through a network that is followed by all packets assigned to a specific FEC

LSPs are unidirectional in nature

The three label operations are PUSH, SWAP and POP

The label swapping mechanism requires packet classification at the ingress of the network to assign an initial label to each packet

The label swapping mechanism in an LSR replaces the incoming label with the outgoing label and directs the packet to the outbound port for transmission to the LSP next-hop address

The egress LER will remove MPLS labels from the packet and forward unlabeled IP packets outside the MPLS domain




Four tables are maintained by routers in an MPLS network• Routing Information Base (RIB)• Forwarding Information Base (FIB)• Label Information Base (LIB)• Label Forwarding Information Base (LFIB)



Learning Assessment

1. List three reasons to employ MPLS technology?

2. MPLS is a label switching technology that provides the ability to set up _____________ paths over a ________________IP network.

3. Explain the IP forwarding process in a traditional IP network.

4. Define Forwarding Equivalence Class (FEC) as used in traditionalIP networks.

5. Describe the 'longest match' criteria as used in traditional IP networks.

6. What are the limitations of traditional IP networks?

7. Explain IP hyper aggregation.



Learning Assessment

8. What additional capabilities are required in an IP router directly connected to an MPLS network?

9. How can MPLS be used to alleviate hyper aggregation?

10. What advantage can MPLS offer over the reliability provided by anormal IGP?

11. What is the key characteristic of MPLS that makes it popular as a platform for VPNs?

12. What are four benefits of MPLS technology in comparison with traditional IP routing?

13. The router at the beginning of an LSP is the _________________.

14. An intermediate router in the LSP between the ingress and egressrouters is a _______________ LSR.



Learning Assessment

15. The router at the end of an LSP is the_____________________.

16. Define the three MPLS label operations.

17. Define an MPLS Forwarding Equivalence Class (FEC).

18. What information is contained in the LFIB?

19. What is the difference in configuration between an iLER and an eLER?

20. What is required to set up a bidirectional LSP?

21. What information does a label switching router require in order to label switch an incoming packet?

22. How does an LSR know which label to use for transmission to the downstream router?


1. List three reasons to employ MPLS technology?1. MPLS offers enhanced routing capabilities by supporting more than just destination based forwarding2. Reduces the complexity of network operation3. It is a standards based technology that promotes multi-vendor interoperability

2. MPLS is a label switching technology that provides the ability to set up connection-oriented paths over a connectionless IP network.

3. Explain the IP forwarding process in a traditional IP network.1. When a packet is to be forwarded, each router in the network makes an independent forwarding decision by analyzing

the destination IP address of the received packet, referencing the local routing table to find the longest match and forwarding via the egress port to the next-hop address.

4. Define Forwarding Equivalence Class (FEC) as used in traditional IP networks.1. A traditional FEC is defined as a subset of packets that are all treated the same way by a router.

5. Describe the 'longest match' criteria as used in traditional IP networks.1. Longest match means that in traditional IP forwarding, a packet will be forwarded via the entry in the routing table that

matches the destination IP address by the most number of bits.6. What are the limitations of traditional IP networks?

1. Hyper aggregation2. End to end service level limitations

7. Explain IP Hyper Aggregation.1. IP Hyper Aggregation causes all traffic to flow via the primary path across the network because path selection is

performed only by the IGP.8. No additional capabilities are required9. Hyper aggregation can be reduced by routing some LSPs over less used links.10. The primary advantage is that alternate paths can be established in advance. When an outage occurs traffic can be switched to

these paths immediately instead of waiting for the IGP to reconverge.11. Packets are tunnelled across the network as label switched packets. Since they are encapsulated with a label, forwarding is

independent of the nature or address of the packet that is being carried.12. What are four benefits of MPLS technology in comparison with traditional IP routing?

1. MPLS label indexing and forwarding is faster than IP packet lookup and forwarding2. FEC assignment is performed only once at network ingress instead of at each hop3. Information not contained in packet headers can be used for FEC determination4. MPLS is able to traffic engineer packets to follow certain paths


Learning Assessment Answers

Answers to module review questions are found in the notes section of the following pages


13. The router at the beginning of an LSP is the ingress Label Edge Router (iLER).14. An intermediate router in the LSP between the ingress and egress routers is a transit LSR

15. The router at the end of an LSP is the egress Label Edge Router (eLER).16. Define the three MPLS label operations.

13. PUSH - An MPLS header is inserted into an IP packet

14. SWAP - An existing MPLS header is exchanged for a new MPLS header

15. POP - An MPLS header is removed from an IP packet

17. Define an MPLS Forwarding Equivalence Class (FEC).

13. An MPLS FEC is a group of packets with similar or identical characteristics which may be forwarded the same way.

18. What information is contained in the LFIB?

13. The labels assigned to the active route for each next-hop are contained in the LFIB.

19. What is the difference in configuration between an iLER and an eLER?

13. There is no difference. All LERs will generally act as both ingress and egress LERs.

20. What is required to set up a bidirectional LSP?

13. LSPs are always unidirectional. Two LSPs are required for bidirectional data flow.

21. What information does a label switching router require in order to label switch an incoming packet?

13. The LSR examines the incoming label to determine the outgoing label to use as well as the next hop router. This also provides the egress interface to be used

22. How does an LSR know which label to use for transmission to the downstream router?

13. The label is maintained in a table in the router. The label values are distributed between routers using a label distribution protocol






Module 2 — MPLS Label Structure and Operation








Module 2 introduces the details of MPLS label structures and explains the label operations such as pop, push, and swap. In addition, issues related to label forwarding such as Penultimate Hop Popping, Invalid Label Processing, TTL, Packet Fragmentation and Packet MTU sizes will be covered.


Module Objectives


Recognize the different implementations of an MPLS label stack

Understand the MPLS label header structure, the header fields and their usage

Describe MPLS label allocation, lookup, stack operation and forwarding

Understand the following terminology as it relates to MPLS • Label space• Downstream on Demand vs. Downstream Unsolicited• Ordered vs. Independent Control• Conservative vs. Liberal Label Retention



Module Objectives


Understand the process for the assignment and distribution of label bindings

Recognize Upstream and Downstream LSRs

Understand Penultimate Hop Popping

Understand the operation of the MPLS reserved labels


MPLS Label Structure and Operation

Section 1 - MPLS Label Header



MPLS Label Header - Section Outline

MPLS Label Function Overview

MPLS Header Structure

• MPLS Label Stack

• MPLS Packet Processing Review


A label is a short, fixed length, locally significant identifier which is applied to each packet. The label that is applied to a particular packet represents the Forwarding Equivalence Class (FEC) to which that packet is assigned.

Most commonly, a packet is assigned to an FEC based on its network layer destination address. However, the label is never an encoding of that address. The label is an arbitrarily assigned value used to classify the packet to a FEC.

Enhanced packet ingress classification may be performed based on policy parameters other than the network layer destination address, such as source IP address, port or interface, QoS markings, administrative policy and others.


MPLS Label Function Overview

A label is a short, fixed length, locally significant identifierapplied to each packet • Used to identify the Forwarding Equivalence Class (FEC) to which

that packet is assigned

Typically, packets are assigned to a FEC based on their destination IP address

Enhanced packet ingress classification may be performed based on other policy parameters including the following• Source IP address• Ingress port or interface• QoS markings


A labeled packet is a packet into which an MPLS label has been encoded. Two techniques are used to encode the MPLS label in the frame: frame mode and cell mode.

In frame mode MPLS, the label resides in an encapsulation header which exists specifically for this purpose. In cell mode the circuit ID in the existing data link layer header of the unlabeled frame is mapped to the MPLS label information.

The MPLS encapsulation header is referred to as a shim header, since in the case of the encapsulation header, it exists as a shim in the frame between the layer 2 header (typically Ethernet) and layer 3 packet (typically IP).

The particular encoding technique to be used must be agreed upon by both the entity which encodes the label and the entity which decodes the label. In other words, the sender and receiver of the packet must use the same MPLS encoding technique, either the shim header or mapping of the native Layer 2 encapsulation.


Labeled Packet

A labeled packet is a packet into which an MPLS label has been encoded

Two techniques are used to encode the MPLS label in the packet• Frame mode

— An additional header, the MPLS header, is added to the frame containing the MPLS label and other information

• Cell mode— In the case of ATM or Frame Relay, the label is based on a mapping

of the circuit ID in the existing data link layer header— Cell mode is not supported on the Alcatel-Lucent 7x50

The MPLS header is referred to as a shim header, since it existsas a shim in the frame between the Layer 2 and IP header


Shown above is a representation of the two types of MPLS label implementations with a comparison to an unlabeled IP packet.

The MPLS label values may be carried in an MPLS specific Shim header or may be carried in a technology specific Layer 2 header, such as in the case of ATM or Frame Relay.

In the case of ATM, the VPI/VCI field in the cell header is used as the MPLS label. In the case of 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 on the 7x50.


MPLS Label Implementation

In frame mode, MPLS label values are carried in an MPLS specific shim header • Label values are encoded in a shim header that sits between

the data link and network layer headers

In cell mode, MPLS labels are carried in the Layer 2 header, such as an ATM or Frame Relay header • Label values are encoded in the existing data link layer header

Unlabeled IP packet

IP Packet with MPLS Shim header

IP Packet withLayer 2 header

Data Link

Header

IP PacketMPLS Label

Data Link Header

IP Header

IP Data FCS

Data Link Header

MPLS Header

IP Header

IP Data FCS


As defined at IANA (http://www.iana.org/assignments/ethernet-numbers), the Ethertype (type) field of an Ethernet frame must carry the following type codes to identify the payload of the frame.

Ethernet Description References

0x0800 Internet IP (IPv4) [IANA]

0x8847 MPLS Unicast [Rosen]

0x8848 MPLS Multicast [Rosen]


MPLS Ethertype

Ethernet frame carrying an IP packet as a payload

DA SA Type = 88 47

MPLS Header

IP Header

IP Packet FCS

DA SA Type = 08 00

IP Header

IP Data FCS

Frame header

Ethernet frame carrying an MPLS unicast packet as a payloadFrame header

DA SA Type = 88 48

MPLS Header

IP Header

IP Packet FCS

Ethernet frame carrying an MPLS multicast packet as a payloadFrame header


The structure of the MPLS shim header, which exists specifically for MPLS, is shown above. Each MPLS header is a fixed length of 4 bytes (32 bits) in size and contains the following fields:

Label: The label value, 20 bits

Exp: Experimental Use, 3 bits , typically used to carry the mapping from the Layer 3 TOS or Layer 2 COS bits

S: Bottom of Stack, 1 bit , (0 = additional labels follow, 1 = last entry in label stack)

TTL: Time to Live, 8 bits, used for loop prevention similar to traditional IP TTL implementations

Since the label is a fixed length, packet indexing and lookup is much simpler and faster than in conventional IP forwarding.

The MPLS encoding technique implementing the MPLS shim header is sometimes referred to as frame mode MPLS.


MPLS Label Header Structure

Each MPLS shim header is a fixed 4 bytes in size

0 3119 22 23

MPLS Header

Field Name Size (bits) Purpose

Label MPLS Label 20 The MPLS label

EXP Experimental 3 QoS mapping from the TOS/COS bits

S Bottom of Stack 1 Flag to indicate bottom of MPLS stack

TTL Time to Live 8 Packet lifetime in MPLS hops

Label EXP S TTL


MPLS implements a general model in which a labeled packet may carry any number of labels, organized as a last-in, first-out sequence. This sequence is referred to as an MPLS label stack. There may be one or more labels in a stack.

An MPLS frame with a single label is said to have a label stack of 1. An MPLS frame with two labels has a label stack of 2 etc.

Multiple entry label stacks are used in the implementation of MPLS based services such as VPLS, VPRN, MPLS Fast-Reroute, trace, ping and others or Traffic Engineering applications.


Label Stacked IP packet

MPLS Label Stack

Label EXP S TTL

A label stack is a sequence of last-in, first-out MPLS labelsThere may be one or more labels in a stackMultiple labels may exist in service implementations or Traffic Engineering applications

Data Link Header

MPLS Header 1

MPLS Header 2

IP Header

IP Data FCS

4 Bytes


The primary fields contained in the MPLS header is the MPLS label itself. The MPLS label field is twenty bits in length carries the label used to forward the packet inside an MPLS domain.

Packets traveling along an LSP are identified by a label, a 20 bit unsigned integer value, typically contained in the MPLS header. The range of label values is 0 through 1, 048, 575.

Label values 0 – 15 are reserved (MPLS)

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

Note: RFC 3032 specified that the IPv4 and IPv6 Explicit Null label values had to be at the bottom of the stack. This restriction has been removed as described in RFC 4182.


MPLS Header Fields - Label

The MPLS label field is twenty bits in length and carries the label used to forward the packet inside an MPLS domainLabel values range from 0 through 1, 048, 575Label values 0 – 15 are reserved

MPLS Reserved Label Values

Label Name Usage

0 IPv4 Explicit NULL The label stack must be popped and processed based on the next label or IPv4 header

1 Router Alert The router must perform additional processing of the packet before forwarding it based on the label beneath it in the stack. It cannot be at the bottom of the stack

2 IPv6 Explicit NULL The label stack must be popped and processed based on the next label or IPv6 header

3 Implicit NULL The router must pop the label from the stack instead of doing a label swap and forward it based on IP header.

4 - 15 Future Use


Other label values are shown below, used for MPLS and Service implementations:

16 – 31 are reserved for future use

32 – 1, 023 are reserved for static LSPs

1, 024 – 2, 047 are reserved for future use

2, 048 – 18, 431 are statically assigned for services

18, 432 - 32, 767 are reserved for future use

32, 768 – 131, 071 are dynamically assigned for both MPLS and services

131, 072 – 1, 048, 575 are reserved for future use


Label Allocation on the Alcatel-Lucent 7x50

MPLS label ranges for the Alcatel-Lucent 7x50 platform

Other Label Values Label Usage

16 – 31 Reserved for future use

32 – 1, 023 Reserved for static LSPs

1, 024 – 2, 047 Reserved for future use

2, 048 – 18, 431 Statically assigned for services

18, 432 - 32, 767 Reserved for future use

32, 768 – 131, 071 Dynamically assigned for both MPLS and services

131, 072 – 1, 048, 575 Reserved for future use


The other fields contained in the MPLS outer label may also be read and processed by the receiving device, in addition to simply the label value.

The EXP (Experimental) field is three bits in length and was initially reserved for experimental use by the MPLS designers. Many implementations now use the experimental bit to propagate QoS parameters inside or across an MPLS domain. Three available EXP bits allow for 8 separate QoS settings.

Primarily, these bits are used for:

•Mapping of Layer 2 CoS bits from a frame header to the MPLS EXP bits

•Mapping of Layer 3 ToS based on IP precedence bits to the MPLS EXP bits

Typically, the QoS markings of the IP packet’s ToS field or the Ethernet frame’s CoS bits are mapped into a corresponding value in the EXP field of the encapsulating MPLS header. In the example above, the 8 bit ToS field of the IP header is mapped to the MPLS EXP bits using only the high order 3 bits in the ToS, the precedence bits. However, mapping of the L2 or L3 QoS markings into EXP depends on the implementation.


MPLS Header Fields - Experimental Bits

The MPLS EXP field is three bits in length and was initially reserved for experimental useMany implementations use the experimental bits to propagate QoS parameters inside or across an MPLS domain• Mapping of Layer 2 CoS bits• Mapping of Layer 3 ToS based on IP precedence bits

Label EXP S TTL

Data Link

Header

ToS TTL other

fields

Source IP Destination IP IP Data

P P P T T T x x


The MPLS EXP field is used to specify the QoS treatment of the packet within the MPLS network.

There are two modes for handling the EXP field in the MPLS header.

With uniform mode, the QoS marking of the IP packet is taken into consideration within the MPLS network. With pipe mode, the QoS marking of the IP packet is only taken into consideration at the ingress and egress of the LSP. It is not used within the MPLS network.

At the iLER, with uniform mode the IP packet’s DSCP value is copied into the EXP field. Typically the first 3 most significant bits of the DSCP value are copied to the 3 bits of the EXP field. The LSRs within the MPLS may modify the EXP value, depending on the QoS requirements of the network. At the eLER, the value of the EXP field is copied back into the DSCP field of the IP header. Therefore, if the EXP value was modified within the MPLS network, this new value will be used at the egress of the MPLS network.

With pipe mode the iLER applies a specific value for the EXP field. Within the MPLS domain the LSRs copy the EXP value into any new MPLS header that may be pushed onto the stack or swapped. And if an outer MPLS header is popped, then its EXP value is copied into the newly revealed inner MPLS header. The EXP value may be modified as the packet traverses the MPLS network, depending on the QoS requirements. At the eLER, the MPLS header is popped and the original DSCP value of the IP header is maintained.


MPLS Header Fields – Experimental Bits (EXP)

Two approaches to EXP handling on ingress LER• Uniform mode: Router copies the DSCP value from the IP header to

the MPLS header EXP field• Pipe mode: Router sets EXP to specific value

— Alcatel-Lucent 7x50 supports pipe mode and enables user to specify the EXP value to use (which could be the same as DSCP value of IP packet)

At LSRs EXP value is copied into swapped label, into new label that may be pushed or into inner label after a pop operation (incase of label stacking)• The EXP value may be changed as packet traverses MPLS network;

this depends on QoS requirements of the network

At egress LER• Uniform mode: MPLS EXP value is copied to the IP header• Pipe mode: initial DSCP value of IP header at LSP ingress is kept


The incoming EXP value of a labeled packet is defined to be the value of the EXP field contained in the outer label stack entry when the packet is received.

In many implementations, the value of the EXP bit of the outer MPLS header is set to be the same as the value of the inner MPLS header’s EXP bit at the iLER.

An LSR receiving a labeled packet will copy the EXP value from the current MPLS header into any new MPLS header it may push onto the stack, or swap. And if the LSR performs a pop operation on a packet with multiple stacked MPLS headers, it will copy the EXP value of the outer header into the inner header. Thus, the EXP value of all MPLS headers in the stack will be the same.


MPLS Incoming EXP with Stacking

Only the MPLS EXP field value contained in the outer label is significant in processing

Normally, the EXP value of the inner MPLS header is set to the same value as the outer EXP value

MPLS Label Stacked Packet

Label EXP=2 S=0 TTL

Label EXP=2 S=1 TTL

Data Link Header

MPLS Header 1

MPLS Header 2

IP Header

IP Data FCS


The other fields contained in the MPLS outer label may also be read and processed by the receiving device.

Bottom of Stack (S) - The Bottom of Stack bit is one bit in length and indicates that the bottom or last entry of the MPLS label stack has been reached and that the IP packet header immediately follows.

This bit is set to one for the last entry in the label stack (i.e., for the bottom of the stack), and zero for all other label stack entries.


MPLS Header Fields - Bottom of Stack Bit

This bit indicates that the bottom of the label stack has been reached and the IP packet header follows• Bit is set to ‘1’ for the last entry in the label stack• Bit is set to ‘0’ for all other label stack entries

Label EXP S=0 TTL

Label EXP S=1 TTL

Data Link Header

MPLS Header 1

MPLS Header 2

IP Header

IP Data FCS


The MPLS TTL field is used as a control mechanism over the packet lifetime similar to IP TTL, to prevent packets looping in the network.

Label processing is always based on the outer label in the stack, which includes information about the operations to perform on the packet's label stack, including modification to the MPLS TTL header field.

RFC 3443 defines Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks. RFC 3443 defines TTL handling for two approaches to MPLS LSPs, Uniform mode and Pipe mode. In Uniform mode the MPLS network is considered “visible” from the outside and thus MPLS nodes should handle TTL as any other node. In Pipe mode the MPLS network is considered “invisible” from the outside in the sense that the network appears a single pipe between the ingress and egress LER. In Pipe mode TTL handling in the MPLS network is independent of the IP TTL. The IP TTL is decremented by the ingress LER and the egress LER, but not by any intermediate LSRs.


MPLS Header Fields - Time to Live (TTL)

The MPLS header TTL field is 8 bits long and is used to encode Time-to-Live (TTL) values

Two approaches to TTL handling on ingress to the MPLS network• Uniform mode: Router copies the TTL value from the IP header to

the MPLS header• Pipe mode: Router sets TTL to specific value

— Alcatel-Lucent 7x50 supports pipe mode and sets MPLS TTL value to 255

MPLS TTL value is decremented by 1 at each LSR• A packet with TTL of 0 is not transmitted• TTL field in IP packet is not changed

At egress of the MPLS network• Uniform mode: MPLS TTL value is copied to the IP header• Pipe mode: IP TTL value at ingress to LSP is decremented by one


The received unlabeled IP packet undergoes standard TTL treatment on ingress by the iLER (as per RFC 1812). If the resulting TTL is non-zero, the packet will be accepted for processing by the iLER.

Depending on the mode used, the iLER will either copy the value of the TTL from the IP header to the MPLS header TTL field (uniform mode) or set the MPLS TTL value to a specific value (pipe mode). On the Alcatel-Lucent 7x50 pipe mode is used and the TTL value is set to 255.

The example in the slide above (and the next two slides) shows the behavior with pipe mode.


MPLS Time to Live (TTL) –at the iLER

The TTL of the incoming unlabeled IP packet is decremented by 1 on ingress by the iLER

If the resulting TTL is non-zero, packet is processed by the iLER and the MPLS TTL is set to 255 (pipe mode) or copied from the IP TTL field

Data Link Header

MPLS Header

TTL=255

IP Header

TTL=4

IP Data FCS

Data Link

Header

IP Header

TTL = 5

IP Data FCS

MPLS Network

iLEReLER

LSR-3

LSR-2

LSR-1

Label Switched Path


The received labeled packet has the MPLS TTL decremented on ingress at each LSR. If the resulting outgoing TTL value is non-zero, the packet will be accepted for further processing by the LSR.

When a new MPLS label header is to be exchanged for the existing MPLS label header, then the outgoing MPLS TTL value is copied to the outer MPLS label header TTL field and the packet is switched to the next LSR along the LSP, where the process repeats.


MPLS Time to Live (TTL) – at the LSRs

The received labeled MPLS packet TTL is decremented by 1 on ingress by each LSR

If the resulting TTL is non-zero, the packet is processed by the LSR and the outgoing TTL is copied to the new MPLS header

MPLS Network

iLEReLER

Data Link Header

MPLS Header

TTL=254

IP Header

TTL=4

IP Data FCS

Data Link Header

MPLS Header

TTL=255

IP Header

TTL=4

IP Data FCSLSR-3

LSR-2LSR-1

Label Switched Path

Data Link Header

MPLS Header

TTL=253

IP Header

TTL=4

IP Data FCS

Data Link Header

MPLS Header

TTL=254

IP Header

TTL=4

IP Data FCS


The received labeled packet has the MPLS TTL decremented on ingress at the eLER. If the resulting outgoing TTL value is non-zero, the packet is accepted for further processing, otherwise it is dropped.

If uniform mode is used, the TTL value in the MPLS header is copied into the IP header (after having been decremented). If pipe mode is used, the MPLS label is removed and processing of the packet continues with the TTL value that was in the IP header when the packet was encapsulated into MPLS at the iLER.

In either modes, the eLER decrements the IP TTL value. If the resulting outgoing TTL value is non-zero the packet is accepted for further processing, otherwise it is dropped.


LSR-3

MPLS Time to Live (TTL) – at the eLER

The received labeled MPLS packet TTL is decremented by 1 at ingress to the eLER

If the resulting TTL is non-zero, the packet is processed by the eLER, the IP TTL is decremented and the unlabeled IP packet is transmitted

MPLS Network

iLER

eLER

Data Link

Header

MPLS Header

TTL=253

IP Header

TTL=4

IP Data FCS

LSR-2LSR 1

Label Switched Path

Data Link

Header

IP Header

TTL = 3

IP Data FCS

Data Link

Header

MPLS Header

TTL=252

IP Header

TTL=4

IP Data FCS


At the iLER, when pipe mode is used, the specific value (e.g. 255) is copied into the inner and outer TTL field. When uniform mode is used, the IP TTL value is copied into the TTL field of the inner and outer MPLS header.

At the LSRs, the incoming TTL value of a labeled packet is defined to be the value of the TTL field contained in the outer label stack entry when the packet is received. It is the TTL value of the outer MPLS header which is decremented. The TTL value of the inner label is not touched.

In pipe mode, after the eLER decrements the outer TTL value and pops the outer label, the TTL value is not copied into the inner MPLS header TTL field. With uniform mode the outer TTL value is copied into the inner TTL field.

In the example above, the incoming TTL value is 5, therefore the outgoing TTL would be 4. At an LSR, the MPLS labeled packet would be forwarded with an MPLS TTL value of 4 contained in the outer label. The inner TTL value of 50 remains unchanged.

Should an MPLS router determine that the outgoing MPLS TTL value of any packet is zero, the packet will be dropped.


MPLS Incoming Time to Live (TTL) with Stacking

Only the MPLS TTL field value contained in the outer label is significant in processing

Incoming TTL is defined to be the TTL value contained in the outer MPLS header of the received packet

MPLS Label Stacked Packet

Label EXP S=0 TTL = 5

Label EXP S=1 TTL = 50

Data Link Header

MPLS Header 1

MPLS Header 2

IP Header

IP Data FCS


Each Frame Relay header is 2 bytes (16 bits) in size and contains the fields listed in the slide. If Frame Relay Extended Addressing is in use, the header may be up to 32 bits long.

The MPLS label value may be encoded in the Cell header using the DLCI field.


Frame Relay Header Structure

The MPLS label value may be carried in the DLCI field

0 1686 12

Frame Relay Header

Field Name Size (bits)

Purpose

DLCI Data Link Connection Identifier 10 Frame Relay address

C/R Command/Response 1 Application Specific

EA Extended Address 1 Extended Header

FECN Forward Explicit Congestion Notification 1 Network Control

BECN Backward Explicit Congestion Notification 1 Network Control

DE Discard Eligible 1 Prioritization

DLCI DLCIC/R EA C/R EAFECN BECN


Each ATM cell header is 5 bytes (40 bits) in size and contains the fields listed in the slide. A UNI cell format is shown above. The NNI format is similar, except that the GFC field does not exist and the first 4 bits are part of the VPI field.

The MPLS label value may be encoded in the Cell header using the VPI/VCI fields.


ATM Cell Header Structure

The MPLS label value may be carried in the VPI/VCI fields

0 324 28

ATM Header

Field Name Size (bits)

Purpose

GFC Generic Flow Control 4 Flow Control

VPI Virtual Path Identifier 8 ATM Address

VCI Virtual Channel Identifier 16 ATM Address

PT Payload Type 3 Payload Identification

CLP Cell Loss Priority 1 Prioritization

HEC Header Error Control 8 Error Checking (not shown)

GFC VCIVPI CLPPT

12 40

HEC


Labels are used as the key packet forwarding mechanism across an MPLS enabled network.

Packet processing and forwarding decisions are always performed based on the contents of the outer label, which is the label adjacent to the data link header.

Note that the term ‘outer’ label is sometimes also referred to as ‘top’ label, while the term ‘inner’ label is also called ‘bottom’ label.


Labeled IP Packet

MPLS Label Processing

An LSR always processes the outer label in the stackForwarding decisions are made on outer (outer) label only

4 Bytes

Label EXP S TTL

Data Link Header

MPLS Header

IP Header

IP Data FCS


An LSR generates labels based on the contents of the local FIB, but not necessarily for all entries. The labels generated are propagated to other routers in the MPLS domain and represent the label value that each LSR expects to receive in packets destined for a particular FEC. Each FEC corresponds to a particular LSP or Transport Tunnel.

It is important to note that the label value generated and advertised by an LSR is the egress label for the neighbor who receives the label, but is the ingress label for the device generating the label.

When an unlabeled packet arrives, the packet is associated to a FEC based on the destination IP address in the IP header.

When a labeled packet arrives, the packet will be associated to a FEC based on the received MPLS label in the MPLS header.


MPLS Label Operation Overview

An LSR generates labels based on the contents of the FIB

The labels are propagated to other routers in the MPLS domain

The label represents the value each LSR expects to receive for a particular FEC

Each FEC corresponds to a particular LSP or Transport Tunnel

When an unlabeled packet arrives, the packet is associated to a FEC based on the destination IP address of the packet

When a labeled packet arrives, the packet is associated to a FEC based on the received label of the packet


When a unlabeled packet is received, the IP header information is identified and read. If the destination IP address of the received packet is successfully matched in the FIB, the following actions result in order to properly forward the packet

1. Learn the next-hop to which the packet is to be forwarded, for forwarding to the next LSR

2. Learn the outgoing interface for the data link encapsulation

3. A label stack operation of PUSH may be performed if the IP packet matches to a FEC which is associated with an LSP, in which case the packet will be forwarded as a labeled packet. Otherwise it will be forwarded as an unlabeled packet.


Unlabeled Packet Operations - PUSH

When an unlabeled packet is received, the IP header information is identified and read

If destination IP address is matched in the FIB, the following actions result to properly forward the packet• Learn the next-hop forwarding address• Learn the outgoing interface for the data link encapsulation• A PUSH label stack operation may be performed

Data Link Header

IP Header

IP Data FCS

Data Link Header

MPLS Header

IP Header

IP Data FCS

FIB

MPLS Network

PUSH


In order to properly forward the labeled packet the following actions must occur before forwarding.

The next-hop to which the packet is to be forwarded is required for forwarding to the next LSR.

A label stack operation needs be performed on the label stack before forwarding. This operation may be:

• To replace the outer label stack entry with another (SWAP)

• To replace the outer label stack entry and then to add one or more additional entries on the label stack (SWAP and PUSH)

In addition, the outgoing data link encapsulation and the egress port are needed in order to properly forward the packet.


MPLS Network

Labeled Packet Operations - SWAP

When a labeled packet is received, the label value at the top of the stack is identified and read

A successful lookup in the LFIB results in• Learning the next-hop forwarding address• Learning the outgoing interface for the data link

encapsulation• A label stack operation being performed on the label stack

before forwarding (SWAP or SWAP & PUSH)Data Link Header

MPLS Header

IP Header

IP Data FCS

Data Link Header

New MPLS Header

IP Header

IP Data FCS

LFIB

SWAP


When the label is popped from a packet's label stack and it is the last label in the stack this results in the stack being emptied, and further processing of the packet is based on the packet's IP header. In this case the packet is forwarded as an unlabeled packet.

If there is another label in the stack, then further processing of the packet is based on that label value. The operation performed on the next label may be swap or pop.


MPLS Network

Labeled Packet Operations - POP

When a labeled packet is received and the router is the eLER for that label stack, the label is POPed

If there is another MPLS label in the stack for which the router is not the eLER, forwarding of the packet is performed as per previous slide

Otherwise the packet is forwarded as an unlabeled packet

Data Link Header

IP Header

IP Data FCS

Data Link Header

MPLS Header

IP Header

IP Data FCS

FIB

POP



Section 2 - MPLS Label Binding and Distribution



MPLS Label Binding and Distribution - Section Outline

MPLS Prerequisites

Label Bindings and Distribution Characteristics• Type of Label Spaces• Label Origination models• Label Exchange models• Label Retention Strategies


The core IGP is responsible for distribution of routing information across the service provider domain. All destinations in the MPLS domain should be reachable in the IGP, and IGP paths should be optimized based on provider requirements to fully leverage any load sharing or redundant links that may be available.

The MPLS topology must match the IGP topology to ensure that no issues arise in trying to establish the LSPs, when using a hop by hop mechanism such as LDP.


MPLS Prerequisites - IGP Routing

The core IGP is responsible for distribution of routing information

Destinations in the MPLS domain must be reachable in the IGP

IGP paths should be optimized based on provider requirements

MPLS Network

LER10.1.1.0/24

10.2.1.0/24

LER

LSR-3

LSR-2LSR 1

IGP


There are multiple control planes involved in the operation of an MPLS enabled network.

The IGP control plane is responsible for the distribution and convergence of routing information, an action that is required with or without MPLS. Even if MPLS is present, IGP control plane activity is independent of MPLS.

MPLS control plane activity is responsible for the distribution and convergence of label binding information. A label binding associates a FEC (typically a destination IP address) to a locally significant label.

These label bindings are used to establish the Label Switched Paths and represent the LSP itself. There will be multiple LSPs established, typically one per FEC.


Label Bindings

Routing is responsible for exchanging FEC information independent of label exchange• The core IGP must be present and functional prior to MPLS

A label binding is the association between a FEC and a label

Label bindings are exchanged to establish the Label Switched Paths

Each binding represents a specific LSP or Transport Tunnel


Label signaling and distribution protocols define the procedures and messages by which MPLS LSRs inform each other of the label bindings they have made and their meanings. Label distribution must be done prior to the forwarding of any data. The label values are assigned and distributed in the control plane before any packet switching may occur, but it may be done before of after the actual arrival of the data.

The central mechanism used within the MPLS network for forwarding data is the mechanism which makes use of label swapping. Label swapping is based on the traditional ATM and Frame Relay models and other earlier, vendor-proprietary tag-based switching techniques.

After the label assignment and distribution, all data traffic is forwarded and processed in the same manner. Labels are assigned to packets on network ingress, get swapped inside the network, and are then removed on egress from the MPLS portion of the network.


Label Signaling and Swapping

Label signaling and distribution protocols define the procedures and messages by which MPLS LSRs inform each other of the label bindings they have made and their meaning

The label values are assigned and distributed in the control plane before any packet switching occurs

Label swapping (switching) is used in the data plane to forward packets across an MPLS network

Labels are assigned to packets on MPLS network ingress, are swapped inside the network, and are removed on egress

LSR-1 LSR-2


Upstream and downstream are relative terms to each FEC or LSP.

In the example shown above, for FEC 10.2.1.0/24, the downstream direction of data flow is relative to the upstream direction of label distribution. For this FEC, LER 2 allocates a label for the FEC 10.2.1.0/24 and sends that label binding upstream to router LSR-2. Similarly, LSR-2 allocates a label for the FEC 10.2.1.0/24 and sends that labelbinding upstream to router LSR 1. LSR 1 will allocate a label and send it to LER 1 completing the LSP (in one direction). Label allocation (control plane) occurred upstream. The resulting data plane is from LER 1 (in this case the iLER) to LER 2 (in this case the eLER)

Label bindings are distributed in the upstream direction representing the label distribution control plane. Data packets flow in the downstream direction representing the data plane.

The terms ingress and egress (as used with ingress LER and egress LER) usually refer to data plane direction.

For FEC 10.1.1.0/24, the data and control planes are reversed.

It is important to note that IGP route exchange must also occur in the control plane of the provider core.


Upstream and downstream are relative terms to each FEC or LSP• Label bindings are distributed in the upstream direction• Data packets flow in the downstream direction

Ingress and egress usually refer to the data plane (packets)

Upstream and Downstream Reference

MPLS Network

LER 110.1.1.0/24

10.2.1.0/24

FEC 10.2.1.0/24

FEC 10.1.1.0/24

Data Plane

LER 2

Control Plane

Control Plane

Data Plane

LSR-3

LSR-2LSR 1


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 assign a single label to each FEC per device (platform), that will be used for all interfaces of the same device.

Per interface label space assigns a unique label to each FEC per interface, typically based on interface specific resources such as a 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 7x50 family implements per platform label space.


Type of Label Spaces

Per platform label space• One label is used across all interfaces of the device• Typically used in frame mode MPLS

Per interface label space• Interface specific resources are used for labels• Typically used in cell mode MPLS

The Alcatel-Lucent 7x50 family implements per platform label space


Per platform label space

Platform wide incoming labels are used for interfaces that can share the same labels. A single label may be assigned to a FEC and used across all interfaces of the same router.

Per interface label space

Interface specific incoming labels are used for interfaces that use interface resources for labels. A separate label is used for each interface that the FEC is advertised on.


Types of Label Spaces

Per platform label space• One label per FEC per device

LSR-1 LSR-2LSR-4

LSR-3

Per interface label space• One label per FEC per interface

per device

FEC 10.1.1.0/24=Label 400

LSR-1

LSR-2

LSR-3

FEC 10.1.1.0/24=Label 400

ATM/F.R.

ATM/F.R.

FEC 10.1.1.0/24=Label 300


Three pairs of attributes are defined for label distribution in MPLS. In theory, any combination of the three attributes is possible. In practice, only certain combinations are used. For example, a combination such as Downstream on Demand with Liberal Retention does not make sense and would never be used.

The Alcatel-Lucent 7x50 uses two modes:

1.Downstream on Demand, Ordered Control with Conservative Retention

2.Downstream Unsolicited, Ordered Control with Liberal Retention


Label Distribution Modes

Label Distribution Modes

Distribution Downstream On Demand Downstream Unsolicited

Control Ordered Control Independent Control

Retention Conservative Retention Liberal Retention

In theory, any combination of the three attributes is possible

In practice, only certain combinations are used


The MPLS architecture allows an LSR to generate and distribute label bindings to other LSRs without first receiving an explicitly request for them.

In Downstream Unsolicited mode, a LSR will generate label mappings for local FECs and advertise them to all peers for which it might be a next-hop for the given FECs. This would typically be done at least once during the lifetime of a peer relationship between adjacent LSRs. The label received from the router providing the active IGP route for the FEC is used (i.e. the router that is the best next-hop to reach the FEC).

In the example shown above, eLER generates label 100 for the FEC 10.2.1.0/24 and distributes it to LSR-2, even though it has not received an explicit request to do so. LSR-2 receives the label for FEC 10.2.1.0/24 from the eLERand installs it in its LIB.

LSR-2’s FIB contains all the known IGP paths to FEC 10.2.1.0/24. The active route for FEC 10.2.1.0/24 was learned via the eLER.

LSR-2 uses the label received from the eLER since the IGP routing topology prefers the route to IP destination 10.2.1.0/24 via the eLER (and in this case, it is the only path).

The LFIB of LSR-2 contains a binding of the FEC and the label received from the eLER since the eLER provided the IGP route to the destination, indicating it is the best IGP path.


Label Exchange - Downstream Unsolicited

The LSR generates and distributes label bindings to other LSRswithout receiving an explicit request from themLabel mappings are provided to all peers for which the local LSR might be a next-hop for a given FEC

LSR-3

LSR-2LSR-1iLER

eLER10.2.1.0/24

FEC 10.2.1.0/24=Label 100

LSR-2 FIB

Prefix Next-hop

10.2.1.0/24 eLER

LSR-2 LFIB

Prefix Next-hop Label

10.2.1.0/24 eLER 100

LSR-2 LIB


10.2.1.0/24 eLER 100


In the example shown above, LSR-2 generates label 200 for FEC 10.2.1.0/24 and advertises it to LSR-1 and LSR-3.

LSR-1 and LSR-3 install the label they received from LSR-2 about FEC 10.2.1.0/24 into their respective LIBs.

On both LSR-1 and LSR-3, their respective FIBs contains all the known IGP paths to FEC 10.2.1.0/24. The active route for FEC 10.2.1.0/24 was learned via LSR2. Therefore, both LSR-1 and LSR-3 use the label received from LSR-2 since the IGP routing topology prefers the route to IP destination 10.2.1.0/24 via LSR-2. The LFIB of LSR-3 will contain a binding of the FEC and the label received from LSR-2. The same is true for LSR-1.



LSR-3

LSR-2LSR-1iLER

eLER10.2.1.0/24

LSR-1 FIB

Prefix Next-hop

10.2.1.0/24 LSR-2

LSR-1 LFIB


10.2.1.0/24 LSR-2 200

LSR-1 LIB


10.2.1.0/24 LSR-2 200

FEC 10.2.1.0/24=Label 200

LSR-3 FIB

Prefix Next-hop

10.2.1.0/24 LSR-2

LSR-3 LFIB


10.2.1.0/24 LSR-2 200

LSR-3 LIB


10.2.1.0/24 LSR-2 200


In the example shown above, LSR-1 generates label 300 for FEC 10.2.1.0/24 and distributes it to his peers, iLER, LSR-3 and LSR-2. LSR-2, LSR-3 and iLER install the label received for FEC 10.2.1.0/24 into their respective LIBs.

Because LSR-1 is not the next-hop router to reach the FEC, LSR-2 and LSR-3 will not use label 300 and this label binding is not be populated in their respective LFIBs.

However, iLER does install label 300 into its LFIB because LSR-1 is its next-hop to reach the FEC.

Similarly, LSR-3 generates label 100 for FEC 10.2.1.0/24 and distributes it to its peers, LSR-1 and LSR-2, both of which install the label in their respective LIBs. But since LSR-3 is not their next-hop to reach FEC 10.2.1.0/24, neither will populate the label 100 in their respective LFIBs.



MPLS Network

LSR-2LSR-1iLER

eLER10.2.1.0/24

LSR-3

LSR-1 FIB

Prefix Next-hop

10.2.1.0/24 LSR-2

LSR-1 LFIB


10.2.1.0/24 LSR-2 200

LSR-1 LIB


10.2.1.0/24 LSR-2 200

10.2.1.0/24 LSR-3 100

FEC 10.2.1.0/24=Label 300

FEC 10.2.1.0/24=Label 100

LSR-3 FIB

Prefix Next-hop

10.2.1.0/24 LSR-2

LSR-3 LFIB


10.2.1.0/24 LSR-2 200

LSR-3 LIB


10.2.1.0/24 LSR-2 200

10.2.1.0/24 LSR-1 300


In the example shown above, the iLER has received label 300 for FEC 10.2.1.0/24 from LSR-1 and installed it in the LIB.

The FIB contains all the known IGP paths to FEC 10.2.1.0/24. The active route for FEC 10.2.1.0/24 was learned via LSR-1.

Therefore, iLER uses the label received from LSR-1 since the IGP routing topology prefers the route to IP destination 10.2.1.0/24 via LSR-1. The LFIB of iLER will contain a binding of the FEC and the label received from LSR-1.



MPLS Network

LSR-3

LSR-2LSR-1iLER

eLER10.2.1.0/24

FEC 10.2.1.0/24=Label 300

iLERLIB


10.2.1.0/24 LSR-1 300

iLERFIB

Prefix Next-hop

10.2.1.0/24 LSR-1

iLERLFIB


10.2.1.0/24 LSR-1 300


In Downstream On Demand label distribution mode, label mappings are provided to an upstream LSR only when requested by the that LSR.

In the example above, the iLER does not have a valid label mapped to the FEC 10.2.1.0/24. Similarly, none of the other MPLS routers have a label binding for this FEC.

Before data may be forwarded, signaling must be generated into the MPLS domain to provide a label mapping for this FEC and establish an end to end LSP.


Label Exchange - Downstream on Demand

The MPLS architecture allows an LSR to explicitly request a label binding for a FEC from its next-hop for that FEC

This is known as Downstream On Demand (DOD) label distribution

MPLS Network

LSR-3

LSR-2LSR-1iLER

eLER10.2.1.0/24

iLERLIB


10.2.1.0/24 LSR-1

iLERFIB

Prefix Next-hop

10.2.1.0/24 LSR-1

iLERLFIB


10.2.1.0/24 LSR-1


A label for the FEC will be requested based on demand, such as when a LSP is configured.

Each LSR will propagate the request away from the source (downstream) until an LSR is able to answer the request.

The request will propagate until it reaches an LSR that can provide a label binding for the requested FEC. In the case of FEC 10.2.1.0/24, which is external to the MPLS domain, the eLER is the router which may provide the label mapping for this FEC.


Label Exchange - Downstream on Demand Request

A label for the FEC will be requested based on demand

The request will propagate until an LSR provides a label binding

iLER

eLER10.2.1.0/24

FEC 10.2.1.0/24=Label ? FEC 10.2.1.0/24=Label ? FEC 10.2.1.0/24=Label ?

LSR-3

LSR-2LSR-1

iLERLIB


10.2.1.0/24 LSR-1

iLERFIB

Prefix Next-hop

10.2.1.0/24 LSR-1

iLERLFIB


10.2.1.0/24 LSR-1

MPLS Network

Tables are similar at all routers in the MPLS domain


The eLER responds with a label mapping of 100 for the requested FEC and propagates the response to LSR-2, which is the LSR that propagated the request to the eLER. When LSR-2 receives a response to its request it will install the label in its LIB and LFIB.

Now, LSR-2 may generate its own label mapping for the FEC in order to respond to the request it received from LSR-1.


10.2.1.0/24

Label Exchange - Downstream on Demand Reply

A label for the FEC will be requested based on demand• The request will propagate until an LSR can provide a label• Each LSR in the path will map the label received to the FEC

LSR-2 LIB


10.2.1.0/24 eLER

LSR-2 FIB

Prefix Next-hop

10.2.1.0/24 eLER

LSR-2 LFIB


10.2.1.0/24 eLER

iLER

eLER

LSR-3

LSR-2LSR-1

MPLS Network

FEC 10.2.1.0/24=Label 100

100

100


LSR-2 responds with a label mapping of 200 for the requested FEC and propagates the response to LSR-1, which is the LSR that propagated the request to LSR-2. When LSR-1 receives a response to its request it will install the label in its LIB and LFIB.

Now, LSR-1 may generate its own label mapping for the FEC in order to respond to the request it received from the iLER.


Label Exchange - Downstream on Demand Reply (cont)


iLER

eLER10.2.1.0/24

LSR-3

LSR-2LSR-1

MPLS Network

FEC 10.2.1.0/24=Label 200

LSR-1 LIB


10.2.1.0/24 LSR-2

LSR-1 FIB

Prefix Next-hop

10.2.1.0/24 LSR-2

LSR-1 LFIB


10.2.1.0/24 LSR-2 200

200


LSR-1 responds with a label mapping of 300 for the requested FEC and propagates the response to the iLER, which is the LSR that originated the request. When the iLER receives a response to its request it will install the label in its LIB and LFIB.

All routers in the domain now have a label mapping for the FEC and an LSP has been created across the MPLS domain.


Label Exchange - Downstream on Demand Reply (cont)


iLERLIB


10.2.1.0/24 LSR-1

iLERFIB

Prefix Next-hop

10.2.1.0/24 LSR-1

iLERLFIB


10.2.1.0/24 LSR-1

300

300

iLER

eLER10.2.1.0/24

LSR-3

LSR-2LSR-1

MPLS Network

FEC 10.2.1.0/24=Label 300


LSP establishment can be done in one of two ways: Ordered or Independent Control mode.

Ordered Control mode

In Ordered Control mode, LSP setup is initiated at one LSR and propagates downstream toward a termination point. A feature of Ordered Control mode is that an LSP is not completely set up until the associated control setup messages have propagated from end to end. As a consequence, data is not sent on the LSP until it is known to be loop free.

Independent Control mode

In Independent Control mode, each LSR, upon noting that it recognizes a particular FEC, makes an independent decision to bind a label to that FEC and to distribute that binding to its label distribution peers. This corresponds to the way that conventional IP datagram routing works; each node makes an independent decision as to how to treat each packet, and relies on the routing algorithm to converge rapidly so as to ensure that each datagram is correctly delivered.


Ordered vs. Independent Control Mode

LSP establishment may be done in one of two ways

Ordered Control• LSP setup is initiated at one point and propagates from there

towards a termination point

Independent Control • Each LSR makes an independent decision to bind a label to a FEC• Each LSR makes an independent decision to distribute that

binding to its label distribution peers


When using Ordered Control mode, LSP setup is initiated at one point in the network and propagates from there towards a termination point. Typically this occurs from egress to ingress inside the MPLS domain.

It is important to note that any LER may be an egress for some FECs and a non-egress for others.

As shown above, LER 1 is the egress LER for FEC 10.1.1.0/24 and therefore will generate a label for this FEC. Similarly, LER 2 will generate a label for FEC 10.2.1.0/24.


Ordered Control Mode - Label Origination

LSP setup is initiated at one point and propagates from there towards a termination point• Typically occurs from egress to ingress

MPLS Network

LER 1

LER 210.2.1.0/24

LSR-3

LSR-2LSR-1

FEC 10.2.1.0/24=Label 100

10.1.1.0/24

FEC 10.1.1.0/24=Label 400


For each FEC for which the LSR is not the egress and no label mapping already exists, the LSR must wait until it has received a label from the LSR that is the next-hop for the FEC, before it can generate a label mapping for that FEC and passing the corresponding labels to upstream LSRs.

If the next-hop router for the FEC is unreachable, the LSR would not be able to forward labeled packets to that destination via either the FIB or the LFIB.


Ordered Control Mode - Label Propagation

An LSR propagates a label mapping upstream for a FEC only if it has a label mapping for the FEC next-hop

MPLS Network

iLER

eLER10.2.1.0/24

LSR-3

LSR-2LSR-1

FEC 10.2.1.0/24=Label 100

10.1.1.0/24

FEC 10.1.1.0/24=Label 400

FEC 10.2.1.0/24=Label 300

FEC 10.1.1.0/24=Label 200


Using Independent Control mode, each LSR makes an independent decision to bind a label to a FEC, and then distributes the bindings to its label distribution peers. This corresponds to the way that conventional IP datagram routing works; each node makes an independent decision as to how to treat each packet, and relies on the routing algorithm to converge rapidly so as to ensure that each datagram is correctly delivered.

When using Independent Control, each LSR may advertise label mappings to its neighbors at any time it desires.

For example, when operating in Independent Control mode with Downstream on Demand, an LSR may answer requests for label mappings immediately, without waiting for a label mapping from the next-hop.

When operating in Independent Control mode Downstream Unsolicited, an LSR may advertise a label mapping for a FEC to its neighbors whenever it becomes aware of that FEC.

A consequence of using independent mode is that an upstream label can be advertised before a downstream label is received.


Independent Control Mode - Label Origination

Each LSR makes an independent decision to bind a label to a FEC

Each LSR distributes the bindings to its LDP peers without any dependencies

MPLS Network

iLER

eLER10.2.1.0/24

LSR-3

LSR-2LSR-1

10.1.1.0/24

FEC 10.1.1.0/24=Label 100


Label retention mode refers to the way in which an LSR treats the label mappings it is not currently using. Labels are stored in the Label Information Base (LIB) of the receiving LSR.

Using Conservative Label Retention mode, any unused label mapping received from a peer LSR is released. An unused label is any label received from a peer that is not being used to switch MPLS packets, since it was not provided from the LSR that is the next-hop for the advertised mapping. This approach consumes less memory on the LSR, but results in a longer convergence time if new labels are required, as signaling must be initiated to acquire the new label.

Using Liberal Label Retention mode, all label mappings received from all peer LSRs are saved. This approach consumes more memory on the LSR, but has the benefit of faster convergence. If the used label is lost, a label for the same FEC may have been previously received from another peer and is already present on the router, without the need for signaling.


Label Retention Modes

Retention mode determines the label binding storage technique implemented by an LSR

Conservative Label Retention mode• Any unused label mapping received from any peer LSR is

discarded

Liberal Label Retention mode• All label mappings received from all peer LSRs are saved


In Conservative Label Retention mode, any label mapping received from a peer LSR that is not used is released. Conservative Label Retention is primarily used with Downstream on Demand.

The advantage of Conservative Label Retention is that only labels that will be used given the existing topology are retained, reducing the amount of memory consumed in retaining labels.

The potential cost is delay in obtaining new labels when a topology change occurs. When this mode is combined with Downstream On Demand label distribution (as is most likely the case), the number of labels distributed from adjacent peers will be fewer as well.

The main advantage of the Conservative mode is that only the labels that are required for the forwarding of data are allocated and maintained. This is particularly important in LSRs where the label space is inherently limited, such as in an ATM switch. A disadvantage of Conservative mode is that if routing changes the next-hop for a given destination, a new label must be explicitly requested from the new next-hop before labeled packets can be forwarded.


Example: Conservative Label Retention with Downstream On Demand

Label mappings are retained only if they are received from the best IGP next-hop

MPLS Network

iLER

eLER10.2.1.0/24

FEC 10.2.1.0/24=Label 300

FEC 10.2.1.0/24=Label 200FEC 10.2.1.0/24=Label 100

LSR-3

LSR-2LSR-1

DOD RequestDOD Reply

LSR-1 LIB


10.2.1.0/24 LSR-2 200

LSR-1 FIB

Prefix Next-hop

10.2.1.0/24 LSR-2

LSR-1 LFIB


10.2.1.0/24 LSR-2 200


In Liberal label retention mode, all label mappings received from all peers are retained. Liberal retention is typically used with Downstream Unsolicited.

In Downstream Unsolicited advertisement mode, each LSR distributes label bindings without the requirement for explicit requests. Therefore, label mapping advertisements for all (or many) routes may be received from all LDP peers.

Liberal retention specifies that every label mapping received from a peer LSR is retained regardless of whether the LSR is the next-hop for the advertised mapping. The main advantage of Liberal label retention mode is that it permits rapid reaction and convergence in the case of routing changes, since labels for all FECs from all peers already exist locally.

The tradeoff is increased memory utilization and the maintenance of unused label mappings.


Example: Liberal Label Retention with Downstream Unsolicited

All label mappings from a peer LSR are retained regardless of whether the LSR is the next-hop for the advertised mapping

MPLS Network

LSR-3

LSR-2LSR-1iLER

eLER10.2.1.0/24

FEC 10.2.1.0/24=Label 300 FEC 10.2.1.0/24=Label 200 FEC 10.2.1.0/24=Label 100

FEC 10.2.1.0/24=Label 200

FEC 10.2.1.0/24=Label 100

LSR-1 FIB

Prefix Next-hop

10.2.1.0/24 LSR-2

LSR-1 LFIB


10.2.1.0/24 LSR-2 200

LSR-1 LIB


10.2.1.0/24 LSR-2 200

10.2.1.0/24 LSR-3 100


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


Label Distribution and Retention Summary

Most implementations use one of the following combinations• Conservative Label Retention with Downstream On Demand• Liberal Label Retention with Downstream Unsolicited

Other combinations of label signaling and retention are possible but not used

MPLS Label Distribution and Retention Matrix

Downstream Unsolicited Downstream on Demand

Conservative

Liberal



Section 3 - MPLS Special Use Labels



MPLS Special Use Labels - Section Outline

Implicit Null

Explicit Null

Penultimate Hop Popping

Invalid Label Processing


In some MPLS implementations, the label generated by the egress LSR will be the MPLS label value of 3, known as IPv4 Implicit Null.

This reserved label value is a label that an LSR may assign and distribute, but which never appears in the MPLS encapsulation (shim) header. An LSR receiving the IPv4 Implicit Null will not map an outgoing label to the FEC in the LFIB.

An LSR will normally SWAP the label at the top of the stack with the new label. If the new label is IPv4 Implicit Null, the LSR will POP the outer label from the stack instead of performing a SWAP operation.

Although this value may never appear in the encapsulation header, it needs to be specified in the Label Distribution Protocol (LDP), so a value is reserved.


Implicit Null Label Distribution

MPLS label value of 3 specifies the IPv4 Implicit Null

Some LSRs will generate an IPv4 Implicit Null for FECs that it is the egress for

iLER

eLER10.2.1.0/24

LSR-3

LSR-2LSR 1

FEC 10.2.1.0/24=Label 3FEC 10.2.1.0/24=Label 301 FEC 10.2.1.0/24=Label 101

MPLS Network

iLERLIB

Prefix Egress

Label10.2.1.0/24 301

LSR-2 LIB

Ingress

Label

Egress Label

101 -

eLERLIB

Ingress

Label

Next-hop

- External

LSR 1 LIB

Ingress

Label

Egress Label

301 101


The penultimate LSR, receiving an MPLS implicit null label, will not map an outgoing label to the FEC.

Since an outgoing label mapping does not exist in the LFIB, the penultimate router will POP the outer label from the packet, and forwards packets to the egress LER with the outer label removed (as if the penultimate router was the egress router).

The eLER receives unlabeled packets in the case of a single label stack or packets with (n-1) labels in the case of a label stack.

This behavior is referred to as Penultimate Hop Popping or PHP.

The primary benefit of this function is to allow only a single lookup to be performed on the eLER, resulting in a potential performance optimization. However, any additional information carried in the MPLS header, such as QoSparameters in the EXP bits, is lost over the last link between the penultimate router and the eLER, and thus the packet may not receive its proper QoS treatment at the eLER.


Implicit Null Label Assignment - Penultimate Hop Popping

An LSR receiving label value 3 will not have an outgoing label for the FEC

This causes the label to be popped at the penultimate hop and only a single lookup is performed at the eLER

MPLS Network

iLER

eLER10.2.1.0/24

LSR-3

LSR-2LSR 1

iLERLIB

Prefix Egress

Label10.2.1.0/24 301

LSR-2 LIB

Ingress

Label

Egress Label

101 -

LSR 1 LIB

Ingress

Label

Egress Label

301 101

eLERLIB

Ingress

Label

Next-hop

- External


Alcatel-Lucent Service Routers support penultimate hop, but not as a last hop, i.e. as a last hop the Alcatel-Lucent router will never advertise a null label to the penultimate hop, but as penultimate hop Alcatel-Lucent SR will treat null labels from the last hop according to RFC 3031, Multiprotocol Label Switching Architecture.

Penultimate hop processing is supported for the purpose of interoperability with other vendor’s LSRs.

PHP is used commonly to improve processing performance in egress LERs, since with PHP the label POP function is delegated to the penultimate router, and the eLER is only required to perform a single lookup on either the MPLS or IP header.

The Alcatel-Lucent 7x50 SR does not require this functionality as the CPU performance is not an issue.


Alcatel-Lucent SR PHP Support

Alcatel-Lucent Service Routers support penultimate hop, but not as last hop• As a last hop, the Alcatel-Lucent router will never advertise a null

label to the penultimate hop• As penultimate hop, the Alcatel-Lucent SR will treat null labels

from the last hop according to RFC 3031

Penultimate hop processing is supported for the purpose of interoperability with other vendors LSRs

PHP is commonly used to improve processing performance in egress LERs

Alcatel-Lucent SR routers do not require this functionality as the CPU performance in Alcatel-Lucent 7x50 routers is not an issue


An LSR may be an egress for some FECs and a non-egress for others. If an LSR is the egress LSR with respect to aparticular FEC, then it may generate a label for that FEC.

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 solved the issue of PHP, in which the QoS of the packet was lost. The Explicit null label is not popped off at the penultimate router thus the EXP value is retained. The eLER can thus treat the packet based on its EXP value before it pops the Explicit null label.


Explicit Null Label Distribution

MPLS Label value of 0 specifies the IPv4 Explicit Null

An LSR may generate an IPv4 Explicit Null for all FECs that it is the egress for

MPLS Network

iLER

eLER10.2.1.0/24

LSR-3

LSR-2LSR 1

FEC 10.2.1.0/24=Label 0FEC 10.2.1.0/24=Label 301 FEC 10.2.1.0/24=Label 101

iLERLIB

Prefix Egress

Label10.2.1.0/24 301

LSR-2 LIB

Ingress

Label

Egress Label

101 0

eLERLIB

Ingres

Label

Next-hop

0 External

LSR 1 LIB

Ingress

Label

Egress Label

301 101


If the eLER advertises the label value of 0 to the penultimate (next to last) LSR, the eLER will receive packets for the FEC containing a 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 following header in the packet must then be inspected and a second lookup is performed at the eLER on the that header.

The second header could be another MPLS header in the case of a multiple label label stack, or the IP packet header.


Explicit Null Label Assignment

An LSR receiving a packet containing a outer label value of 0 must POP the outer label and perform a second lookup on the next header• The next header could be MPLS or IP

MPLS Network

iLER

eLER10.2.1.0/24

LSR-3

LSR-2LSR 1

eLERFIB

Prefix Next-hop

10.2.1.0/24 External

iLERLIB

Prefix Egress

Label10.2.1.0/24 301

LSR-2 LIB

Ingress

Label

Egress Label

101 0

eLERLIB

Ingres

Label

Next-hop

0 External

LSR 1 LIB

Ingress

Label

Egress Label

301 101


There are two common cases where an LSR may receive invalid labels.

The first case involves a router that may receive a Control Plane update containing a label for an unknown route. The LSR can not create an LSP binding since the FEC is unknown locally.

The second is where an LSR may receive a labeled packet in the Data Plane and the label is either unknown or not the valid label for that FEC. Since each LSR generates and distributes labels to other routers containing the values it expects to receive for a FEC, if a packet arrives with an unknown label, it is certain that it was not generated by the local LSR or it is no longer a valid label due to topology or configuration changes and should not be accepted.

In both cases, the packet with the invalid label is dropped. The packet is dropped instead of forwarding it hop-by-hop based on its IP destination address for the following reasons:

1. Forwarding it hop-by-hop may result in a loop (e.g. the router receiving the invalid labeled packet could forward the packet back towards one of the upstream nodes along the LSP)

2. The labeled packet was following a path which cannot be inferred from the IP header (e.g. when MPLS is used for IGP shortcuts)


Invalid Label Processing

A router may receive an update with a label for an unknown route (Control Plane)

An LSR may receive a labeled packet and the label is not known locally (Data Plane)

MPLS Network

iLER

eLER10.2.1.0/24

LSR-3

LSR-2LSR 1

Data Link Header

MPLS Header


iLERLIB

Prefix Egress

Label10.2.1.0/24 400

LSR 1 LIB

Ingress

Label

Egress Label

301 101



Section 4 - Label Signaling Methods and LSP Types



Label Signaling Methods and LSP Types - Section Outline

Label Signaling and Distribution

LSP Types• Static• Signaled

Dynamic Label Signaling Protocols• Label Distribution Protocol (LDP)

— Signaled LSPs via the IGP

• RSVP-TE - Extensions to RSVP for LSP Tunnels— Signaled LSPs via the IGP— Signaled LSPs via CSPF — Explicit Path LSPs— RSVP-TE - Extensions to RSVP for LSP Tunnels

Other Label Signaling Protocols


The MPLS architecture does not assume a single label distribution protocol. A number of different label distribution protocols have been or are being standardized. In some implementations, existing protocols have been extended so that label distribution procedures can be piggybacked on them. New protocols have also been defined for the explicit purpose of distributing labels.

The MPLS network administrator has many options available to them depending on the protocols supported by their hardware, and the desired network behavior.

Similar to static routing, manual procedures are possible for the assignment and distribution of MPLS labels.

New protocols have been defined for the explicit purpose of distributing labels such as Label Distribution Protocol (LDP).

Existing protocols have been modified and extended with additional capabilities so that label distribution can be piggybacked on them, such as Resource Reservation Protocol for Traffic Engineering (RSVP-TE).


Label Signaling and Distribution

The MPLS architecture does not assume a single label distribution protocol

Options are available for implementing label signaling and exchange in an MPLS enabled network

MPLS signaling protocols include the following• Manual• Dynamic via LDP (Label Distribution Protocol)• Dynamic via RVSP-TE (Resource Reservation Protocol for Traffic

Engineering)


A static LSP is specified by administratively defining a static path. The ingress, transit and egress routers must be manually configured with labels and a label action for each LSP (per FEC) the administrator wishes to define. Recall that an LSP is unidirectional, so in fact this requires the provisioning of two LSPs to enable a bidirectional traffic flow.

The benefit of a static LSP is that Dynamic label signaling protocols are not required. Should the network topology or administrative preferences change, maintenance of static LSPs becomes solely an administrative task.


LSP Types - Static

Static LSPs are established by manually defining fixed paths across the MPLS domain• All transit routers must be configured manually with labels and

label actions• An LSP must be established in both directions• Dynamic signaling protocols are not required


Signaled LSPs are established dynamically using a signaling protocol such as LDP or RSVP-TE.

Operators are required to configure the MPLS routers with either the LDP or RSVP-TE protocol to dynamically signal the path selection and to distribute label bindings for the assignment of the labels in the LSRs.

There are multiple options available for the configuration of signaled LSPs. However, the basic prerequisite for the signaling to occur is the establishment of the IGP routing topology across the service provider domain.


LSP Types - Signaled

The Transport Tunnels, or LSPs, are dynamically established using a dynamic label signaling protocol• LDP• RSVP-TE

Within each signaling protocol there are multiple dynamic options

MPLS network IGP routing is a prerequisite for dynamic label signaling exchange


Dynamic label signaling protocols allow MPLS enabled routers to exchange information and request the establishment and label binding for an end to end LSP.

Each router will generate labels for selected FECs and advertise these labels to other routers running the same dynamic signaling protocol. The router that receives these labels will store them in a table associated to its own local label for the same FEC and the interface used to reach the destination.

Dynamic signaling protocols are resilient to network outages and failures, and may automatically establish a new path should the primary path fail.


Signaled (Dynamic) Label Exchange

LSPs are established dynamically using a label distribution protocol

Dynamic Label Exchange

1/1/1

1/1/2

1/1/3

1/1/4

1/1/1

LSR 1

LER 1

LER 2

MPLS Network

1/1/5

10.2.1.0/24

1/1/3

1/1/4

1/1/11/1/2

LSR 2

LER 1

LFIB

Prefix Ingress Label

Egress Label

Egress Interface

next-hop

10.2.1.0/24 - 123 1/1/2 LSR 1

LER 2

LFIB


Egress Label

Egress Interface

next-hop

10.2.1.0/24 456 - 1/1/1 external

LSR 1

LFIB


Egress Label

Egress Interface

next-hop

10.2.1.0/24 123 456 1/1/4 LER 2


Although there are different modes for label distribution in LDP, in its typical use, labels are advertised to identify an LSP to the destination networks. When a router learns of a new network it will advertise this to its IGP neighbors who will flood it through the routing domain. At the same time, the router provides a label mapping to this destination. The upstream routers advertise labels in turn, thus establishing an LSP to the destination.

This is an over simplification of the LDP protocol, but it describes the essence of its operation.


Egress router floods the IGP area with a Link State Advertisement of its known networks

Sends Label Mapping messages with labels to reach them

Label Distribution – LDP Snapshot

MPLS Network

iLER

eLER

10.1.1.0/24

10.2.1.0/24

eLER Prefix Cost Peer

10.2.1.0/24 20 Rtr 3

10.2.2.0/24 20 Rtr 3

LSR-3

LSR-2LSR-1Rtr 1

Rtr 2

Rtr 3

10.2.2.0/24

eLER FEC Label

10.2.1.0/24 200

eLER FEC Label

10.2.2.0/24 300


RSVP-TE is used for label distribution when constraint-based routing is required. This applies to situations where the best route calculated by the IGP is not appropriate. RSVP-TE uses a constraint-based IGP to calculate the desired route. A message is sent along the route to request a label mapping for this route and may also contain resource requirements.

The egress router replies with a label mapping. Assuming they can meet the constraints of the request message, all the routers in the path provide a label in turn and the reply message returns to the ingress router, establishing the LSP. There is substantially more to the RSVP-TE protocol than shown in this simple example, which are covered in Module 6.


Ingress router requests a label for a specific path

Egress router replies with label mapping.

Label Distribution – RSVP-TE Snapshot

MPLS Network

iLER

eLER

10.1.1.0/24

10.2.1.0/24

iLER FEC Resource Path

10.2.1.0/24 10 Mbps LSR-1, LSR-3, LSR-2, eLER

LSR-3

LSR-2LSR 1Rtr 1

Rtr 2

Rtr 3

10.2.2.0/24

eLER Label Path

300 LSR 1, LSR-3, LSR-2, eLER


Multiple protocol options exist for the dynamic signaling and creation of LSPs (Transport Tunnels). Within each protocol exists multiple techniques to control creation of the LSP.

Using LDP, IGP based LSPs may be created. 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 used by the LSP.

RSVP-TE establishes LSP tunnels that enable the allocation of resources along the path. For example, bandwidth can be allocated to an LSP tunnel using standard RSVP reservations and Integrated Services service classes.

RSVP-TE also supports LSP establishment based on the IGP using a constraint based algorithm such as CSPF or based on explicitly defined paths. IGPs require additional protocol extensions to allow CSPF to be implemented.

RSVP-TE and CSPF will be discussed in detail in Module 6 of this course.


Dynamic Label Signaling Protocol Options

Label Distribution Protocol (LDP) - RFC 3036• Signaled LSPs via the IGP

RSVP-TE - Extensions to RSVP for LSP Tunnels - RFC 3209 • Signaled LSPs via the IGP• Signaled LSPs via CSPF • Explicit Path LSPs


The table above provides a high level comparison of LDP and RSVP-TE as label signaling protocols.


Dynamic Label Signaling Protocol Comparison

Feature LDP RSVP-TE

Standards Based Yes Yes

Dependency on the IGP Yes Yes

Traffic Engineering Support No Yes

Signaled LSPs via the IGP Yes Yes

Signaled LSPs via CSPF No Yes

Explicit Path LSPs No Yes

Administrative Control Medium High

Network Resiliency Depends on IGP re-convergence

Fast Reroute mechanisms

Configuration Complexity Low Medium


IGP Based LSPsLDP and RSVP-TE will both use the IGP to establish the LSP. The LSP hops are determined by the IGPs choice of routes, and thus the LSP follows the same least cost path as would be taken by traditional IP routing. These LSPs are usually deployed where Traffic Engineering capabilities are not required or for multi-vendor interoperability.

LDP is an IETF standards based protocol typically deployed in networks where Traffic Engineering capabilities are not required or for multi-vendor interoperability. LDP supports a best effort model of operation based on the IGP route selection.

RSVP-TE may use IGP routing to determine the LSP paths, when traffic engineering is not required, but where faster traffic protection may be desired.


Signaled LSP Types - by Establishment Mechanism

IGP based LSPs• Deployed where traffic engineering capabilities are not

required• The intermediate hops of the LSP are dynamically assigned by

the IGP routing protocols best route selection, thus LSP path follows the IGP least cost path

• LDP and RSVP-TE may both use the IGP to establish their LSPs• Uses hop-by-hop routing


Constrained Path LSPsA constrained path LSP relies on the constraint based algorithm to find a least cost path which satisfies the constraints for the LSP, such as a bandwidth requirements, links to avoid or maximum hops to traverse. Once the path is found, RSVP-TE includes the computed path in its LSP establishment request.



Constrained Path LSPs• A constrained path LSP relies on a constraint based routing

algorithm to find a path which satisfies the defined constraintsfor the LSP

• Deployed where traffic engineering capabilities are required• Only RSVP-TE can establish LSP based on constraint routing to

determine the path• Uses hop-by-hop routing


Explicitly RoutedFor explicitly routed LSPs, each LSR does not independently choose the next-hop; rather, the LSP ingress specifies several (or all) of the LSRs traversed in the LSP. If every hop in the entire LSP is specified, the LSP is "strictly" explicitly routed. If only some of the LSP hops are specified, the LSP is "loosely" explicitly routed.

Explicit routing may be useful for a number of purposes, such as policy routing or manual Traffic Engineering.



Explicit Path LSPs• Deployed where manual control of traffic engineering

capabilities is required• Only RSVP-TE can be used to set up explicit path LSPs• The hops within the LSP are manually configured• Strict Path LSP

— Every hop along the path is specified

• Loose Path LSP— Some of the hops along the path are specified


The flow diagram shown above outlines the different MPLS LSP configuration options available.


Label Signaling and Distribution Summary

Label Signaling &Distribution

Manual Dynamic

LDP RSVP-TE

IGP based Hop by Hop Explicit Path

Signaled via CSPF

Signaled via IGP

Strict Path

Static

Loose PathTargeted

Best Effort


Other MPLS label signaling protocols exist, but are usually configured and used when implementing MPLS-based services. Their role is to signal the inner (service) label of the MPLS label stack. They serve a different purpose than LDP or RSVP-TE.

Targeted LDP (T-LDP)

Targeted LDP is used in the implementation of services across an MPLS network. It is used to signal the label that identifies the particular service, from the eLER to the iLER, such as an ePipe or VPLS. Targeted LDP (T-LDP) is discussed further in Module 4 of this course.

Multiprotocol BGP (MP-BGP)

The Multiprotocol extensions to BGP (MP-BGP) define enhancements to the BGP protocol that enable BGP to carry the MPLS labels required for the implementation of BGP/MPLS VPNs based on RFC 4364. Multiprotocol extensions to BGP (MP-BGP) are discussed in the Alcatel-Lucent VPRNs course.


Other Label Signaling Protocols

Other label signaling protocols exist which are usually configured in service implementations

Targeted LDP (T-LDP)• Used to signal the inner labels for services such as ePipe or

VPLS

Multiprotocol BGP (MP-BGP)• Used to signal the inner labels for Virtual Private Routed

Networks based on RFC 4364



Module Summary

A label is a locally significant value used to identify a FEC

An MPLS label may reside in MPLS specific Shim Header or in an existing data link header such as ATM or Frame Relay

Each label is 4 bytes in size containing a 20 bit label field, 3 EXP bits, 1 S bit indicating the Bottom of Stack and an 8 bit TTL field

EXP bits typically carry QoS parameters such as CoS or ToS bits

The S bit is set to 1 to indicate the last entry in the label stack and 0 for all other label stack entries

A label stack is a sequence of last-in, first-out MPLS labels

An LSR generates labels based on the contents of the local FIB, which are propagated to other routers representing the label value that each LSR expects to receive in packets destined to that particular FEC



Module Summary

A label binding is the association between an FEC and a label that represents a specific LSP

IGP routing is a prerequisite for MPLS configuration

A packet received by an LSR may be forwarded as a labeled or unlabeled packet

The label swapping algorithm includes label actions and modifying the TTL or other fields

The three possible label actions are PUSH, SWAP and POP

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




LSP are established via either Independent or Ordered Control

An LSR distributes label mappings independently of other LSRs using Independent Control mode

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

Downstream Unsolicited (DU) label distribution is used by an LSR to distribute label bindings to other LSRs without a specific label request

Downstream On Demand (DOD) label distribution is used by an LSR to explicitly request a label binding from its next-hop for a particular FEC




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

Data flows in the downstream direction

Label bindings are distributed in the upstream direction

Penultimate Hop Popping eliminates the requirement for the egress router to perform two packet lookups

The Alcatel-Lucent 7x50 supports PHP solely for inter vendor compatibility



Learning Assessment

1. A label is used to identify what?

2. A packet can be assigned to a FEC based on what attributes?

3. In cell-mode MPLS, how is the label value encapsulated?

4. The MPLS label resides in an encapsulation header referred to as a ___________ ____________.

5. An MPLS header is ___________bits in size comprised of ___ bits for the label field, ___ bits for Experimental Use, ___ bits for Bottom of Stack and ___ bits for MPLS TTL.

6. Briefly describe each of the three basic label operations



Learning Assessment

7. In an MPLS network are the label values considered locally significant or globally significant?

8. Describe the difference between cell mode and frame mode in an MPLS network.

9. The MPLS shim header corresponds to which OSI layer?10. What is the purpose of the EXP field in the MPLS header?11. An iLER receives a packet with an IP TTL of 10, labels the packet,

transmits it over an LSP with 3 transit LSRs and then to the eLER. What is the TTL value after the packet leaves the eLER, when the Pipe mode is used?

12. If there are multiple, stacked labels in a labeled packet, each LSR will decrement the TTL of all labels in the stack (T or F?).

13. Describe the sequence of events when an unlabeled packet with a TTL value of 1 arrives at an ingress LER.



Learning Assessment

14.What is the role of the IGP in an MPLS network?

15.In discussing label distribution techniques, does downstream refer to the flow of the control plane or the data plane?

16.Does the Alcatel-Lucent 7750 use a per platform or per interface label space?

17.If a router generates two different labels for the same FEC, which label space is used?

18.Can a router receive different labels from two different peers, for the same FEC?

19.Describe the difference between Downstream on Demand and Downstream Unsolicited label distribution.



Learning Assessment

20. Describe the difference between Ordered and Independent Control modes.

21. Define and describe the two types of label retention modes.

22. Which router (ingress or egress LER) initiates the distribution of labels for an LSP in downstream unsolicited distribution?

23. Which router (ingress or egress LER) initiates the distribution of labels for an LSP in downstream on demand distribution?

24. What is the advantage of liberal label retention mode?



Learning Assessment

25. What is the difference between static label distribution and dynamic label distribution?

26. What is the label with a value of 0 called?

27. How is the label value 3 used?

28. What is the purpose of penultimate hop popping?


1. A label is used to identify a FEC .

2. A packet can be assigned to a FEC based on its Network Layer Destination address, Source IP address, Port or interface, ToS etc.

3. The label is encapsulated using the VPI/VCI connection identifier in ATM and the DLCI connection identifier in Frame Relay.

4. The MPLS Label resides in an encapsulation header referred to as a shim header.5. An MPLS header is 32 bits in size comprised of 20 bits for the label field, 3 bits for Experimental Use, 1 bits for

Bottom of Stack and 8 bits for MPLS TTL.

6. The three label operations are PUSH, SWAP and POP. During a PUSH operation a label is added to a labeled or unlabelled packet. If the packet is labeled the new label becomes the outermost label. During a SWAP operation the outermost label is exchanged for a new label. In a POP operation, the outermost label is removed and the appropriate action taken based on the contents of the LFIB.

7. In an MPLS network label values are locally significant

8. In a cell mode MPLS network, the layer 2 protocol (frame relay or ATM) VC ID is used as the label. In a frame mode network, the MPLS shim header is used to carry the label value.

9. The MPLS shim header does not correspond to any of the OSI layers. It is sometimes referred to as layer two and a half.

10. The EXP field is widely used to carry CoS or QoS information.

11. The TTL is decremented once by the ingress LER and once by the egress LER. Therefore the value is 8.

12. False. Only the outer label is examined and decremented.

13. The packet is dropped.






1. The IGP is necessary to distribute information about reachable FECs and the best path to reach them. In addition the IGP allows the routers to communicate with each other to exchange routing and label information.

2. Downstream refers to the data plane, as it refers to the flow of data in the network.

3. The Alcatel-Lucent 7750 uses a per platform label space.

4. Per interface label space.

5. Yes, a router may receive different labels from different peers for the same FEC, regardless of whether it is operating with a per interface or per platform label space.

6. Describe the difference between Downstream on Demand and Downstream Unsolicited label distribution.

§ Downstream on Demand allows an LSR to explicitly request a label binding for a FEC from its next-hop for that particular FEC upon the arrival of data.

§ Downstream Unsolicited allows an LSR to distribute label bindings to other LSRs prior to data arrival.

7. Describe the difference between Ordered and Independent Control modes.

§ Ordered Control mode requires that an LSR wait until it has a label binding for the LSP next-hop before it may respond to a label request from an upstream LSR.

§ Independent Control mode allows an LSR to advertise a label binding at any time it is ready to forward data.

8. Define and describe two types of label retention modes.

Liberal label retention defines that an LSR will retain in memory all label bindings it receives.

Conservative Label Retention means an LSR retains only the labels that it is actually using to forward packets

9. In downstream unsolicited mode, label distribution is initiated by the egress LER.

10.In downstream on demand, a request from the ingress LER initiates label distribution.

11.Liberal label retention reduces the delay in establishing a new LSP when there is a topology change, since no additional signalling of the LSP is required.





1. With static label distribution, labels are manually assigned to create the LSP. Dynamic label distribution uses a label distribution protocol to distribute labels.

2. The label with a value of 0 is the Explicit Null label. It indicates that the next router should pop the label.

3. The label value 3 is the Implicit Null label. It is not used as a label value, but is used to signal the upstream router from the egress that no label should be used on the final link of the LSP.

4. Penultimate hop popping is intended to accommodate less capable routers that may not be able to efficiently pop a label AND do an IP forwarding lookup.






Module 3 — MPLS Label Signaling Overview








This module discusses MPLS label signaling with emphasis on the LDP protocol.


Module Objectives

Understand the function of label signaling protocols

Recognize different methods used to establish LSPs• Manual • Dynamic via LDP

List the different methods for label signaling and distribution

Configure and verify Static LSPs

Understand Label Distribution Protocol (LDP) including• Neighbor establishment and session maintenance• Message types and transport protocols • Methods of neighbor discovery• Label signaling operation



MPLS Label Signaling

Section 1 - Configuring Static LSPs



Configuring Static LSPs - Section Outline

Static LSP Overview

Configuring Static LSPs

Verifying Static LSPs


A static LSP is a manually configured LSP, where the next-hop IP address, the outgoing label and the label action are explicitly specified. These parameters must be configured on every node along the path.

To enable a bidirectional flow of traffic, two LSPs must be created, one in each direction across the provider core.

Dynamic label signaling protocols such as LDP or RSVP may be shutdown, or may coexist with static label mappings.


Static LSPs

A static LSP is a manually configured LSP

The following parameters must be explicitly specified• The next-hop IP address• The outgoing label• The label action

Static LSPs must be configured on every node along the path

To configure a complete end-to-end LSP, an LSP is required in both directions


A static LSP uses a manually configured MPLS path, where the next-hop IP address and the outgoing label are explicitly specified. No dynamic signaling protocol is required to set up the path.

On the ingress LER, it is required to configure the mapping of a label to the given FECs, which equates to a PUSH action.

On the transit LSRs, you must configure both the ingress and egress labels for the SWAP action. On the egress LER you must configure the removal of the label, which is the POP action.

Static LSPs require that the operator manually determine the routing of the LSP, and keep track of labels assigned.

As the network topology changes or if the rate of change increases and the network becomes larger and more complex with increased dynamics, the static approach becomes increasingly complex and resource intensive to maintain.

In the example shown above, the static LSP is configured from LER 1 to LSR 1 to LER 2. If any if the elements along the statically defined path fail or become unavailable, the available redundancy via LSR 2 would not be used until the path was manually modified to compensate for the change.


Static LSPs

All routers are manually configured with labels to establish theLSP

1/1/1

1/1/2

1/1/3

1/1/4

1/1/1

LSR 1

LER 1

LER 2

MPLS Network

1/1/5

LER 1

LFIB


Egress Label

Egress Interface

next-hop

10.2.1.0/24 - 123 1/1/2 LSR 1

1/1/3

1/1/4

1/1/1

1/1/2

LSR 2

LER 2

LFIB


Egress Label

Egress Interface

next-hop

10.2.1.0/24 456 - 1/1/1 external

LSR 1

LFIB


Egress Label

Egress Interface

next-hop

10.2.1.0/24 123 456 1/1/4 LER 2

10.2.1.0/24


Manual label definition provides the following benefits:

High degree of control over each static LSP to manually tune each path

Does not require dynamic label signaling protocols or their associated configuration

The following caveats must be considered:

Every node in the network must be manually configured

Changes or modifications must be manually implemented

There are no dynamic redundancy features

Label stacking is not supported


Benefits and Caveats of Static LSPs

Manual label definition provides the following benefits• High degree of control over each static LSP• Does not require dynamic label signaling protocols

The following caveats must be considered• Every node in the network must be manually configured• Changes or modifications must be manually implemented• There are no dynamic redundancy features.• Label stacking is not supported


Enable MPLS on the provider core routers

Configure MPLS on the network interfaces

Interfaces must be previously configured with Layer 1 and Layer 2 parameters and IP addresses before they can be specified in MPLS

Any interface used by the static LSP must be added into the MPLS protocol instance, even though RSVP is not actually used to signal labels. (Static LSPs are configured within the MPLS configuration context, but do not rely on dynamic label signaling.)

Configure the Static LSP (one in each direction)

Verify the available labels prior to beginning the configuration and verify the acceptable label range for use with static configurations.

Configure the head-end of a MPLS Static LSP in the iLER. The configuration of the iLER is notably different than a transit or egress device.

Configure MPLS label maps on all transit routers along the LSP path with a SWAP operation, and configure a MPLS label map on the eLER with a POP operation.


Configuring Static LSPs

Enable MPLS on the provider core routers

Configure MPLS on the network interfaces• Interfaces must be previously configured before they can be

specified in MPLS• Any interface used by the static LSP must be added into the

MPLS protocol instance

Configure the Static LSPs• Verify the available labels• Configure an MPLS Static LSP in the iLER• Configure MPLS label maps on all other routers along the LSP

path


The 'show router mpls label-range' command displays the total number of available labels on the router per defined range.

Static LSPs should be configured using labels in the range of 32 through 1023.


Label Range available for Static LSPs

‘show router mpls label-range ‘ displays the reserved label ranges and the number remaining available for usage

A:P1# show router mpls label-range

==============================================================================Label Ranges==============================================================================Label Type Start Label End Label Aging Total Available ------------------------------------------------------------------------------Static-lsp 32 1023 - 991 Static-svc 2048 18431 - 16384 Dynamic 32768 131071 0 98304 ==============================================================================A:P1#

A:P1# show router mpls label-range

==============================================================================Label Ranges==============================================================================Label Type Start Label End Label Aging Total Available ------------------------------------------------------------------------------Static-lsp 32 1023 - 991 Static-svc 2048 18431 - 16384 Dynamic 32768 131071 0 98304 ==============================================================================A:P1#


The 'show router mpls label' command as shown above displays the contents of the Label Information Base (LIB) for only labels in-use.

Prior to configuring static labels, ensure the labels have not already been allocated to another configuration.


Identifying Labels In Use for Static LSPs

Use ‘show router mpls label‘ to verify the range of available labels before allocating additional static labels

A:P1# show router mpls label 32 131071 in-use

================================================================MPLS Labels from 32 to 131071 (In-use)================================================================Label Label Type Label Owner ----------------------------------------------------------------598 static-lsp RSVP999 static-lsp RSVP131069 dynamic ILDP 131070 dynamic ILDP 131071 dynamic ILDP ----------------------------------------------------------------In-use labels (Owner: All) in specified range : 5In-use labels in entire range : 5================================================================A:P1#




Context: config>router>mpls

Syntax: static-lsp lsp-name

Description: This command is used to configure a static LSP on the ingress router. The static LSP is a manually set up LSP where the next-hop IP address and the outgoing label (push) must be specified.

Parameters: lsp-name - Name that identifies the LSP. Values Up to 32 alphanumeric characters.

to ip-address

Description: This command specifies the system IP address of the egress router for the static LSP. When creating an LSP this command is required. For LSPs that are used as transport tunnels for services, the to IP address must be the system IP address. If the to address does not match the SDP address, the LSP is not included in the SDP definition.

Continued on next page


MPLS Static LSP CLI Structure - Ingress LER

A:PE1# config routerA:PE1>config>router# mplsA:PE1>config>router>mpls# static-lsp- no static-lsp <lsp-name>- static-lsp <lsp-name>

<lsp-name> : [32 chars max]

[no] push - Label to be pushed on the label stack and the next hop IP address

[no] shutdown - Administratively enable/disable the static LSPto - IP address of the egress router for the static LSP

A:PE1# config routerA:PE1>config>router# mplsA:PE1>config>router>mpls# static-lsp- no static-lsp <lsp-name>- static-lsp <lsp-name>

<lsp-name> : [32 chars max]

[no] push - Label to be pushed on the label stack and the next hop IP address

[no] shutdown - Administratively enable/disable the static LSPto - IP address of the egress router for the static LSP

CLI syntax for configuring a Static LSP on the iLER


Parameters: ip-address - The system IP address of the egress router.

push out-label nexthop ip-address

Description: This command specifies the label to be pushed on the label stack and the next hop IP address for the static LSP.

out-label - The label to push on the label stack. Label values 32 through 1,023 are available for static assignment.

nexthop ip-address — This command specifies the IP address of the next hop towards the LSP egress router. If an ARP entry for the next hop exists, then the static LSP is marked operational. If ARP entry does not exist, software sets the operational status of the static LSP to down and continues to ARP for the configured next-hop. Software continuously tries to ARP for the configured next-hop at a fixed interval.


MPLS Static LSP CLI Structure - Ingress LER

Notes page


Context: config>router>mpls>if

Syntax: label-map in-label

Description: This command is used on transit LSRs when a static LSP is defined. An in-label can be associated with either a pop or a swap action, but not both. If both actions are specified, the last action specified takes effect.

Parameters: in-label - Specifies the incoming MPLS label on which to match. Values 32 - 1023

popDescription: This command specifies that the incoming label must be popped (removed). No label stacking is supported for a static LSP. The service header follows the top label. Once the label is popped, the packet is forwarded based on the service header.

swap out-label nexthop ip-addressDescription: This command swaps the incoming label and specifies the outgoing label and next hop IP address on an LSR for a static LSP.

Parameters out-label - Specifies the label value to be swapped with the in-label. Values 32 - 1023

nexthop ip-address - The IP address to forward to. If an ARP entry for the next hop exists, then the static LSP will be marked operational. If ARP entry does not exist, software will set the operational status of the static LSP to down and continue to ARP for the configured next-hop. Software will continuously try to ARP for the configured next-hop at a fixed interval.


A:P1# config routerA:P1>config>router# mplsA:P1>config>router>mpls# interface "P1-P2"A:P1>config>router>mpls>if# label-map ?- label-map <in-label>- no label-map <in-label>

<in-label> : [32..1023]

[no] pop - Enable/disable the pop action on the incoming label[no] shutdown - Administratively enable/disable the label-map definition[no] swap - Enable/disable the swap action on the incoming label

A:P1>config>router>mpls>if# label-map

A:P1# config routerA:P1>config>router# mplsA:P1>config>router>mpls# interface "P1-P2"A:P1>config>router>mpls>if# label-map ?- label-map <in-label>- no label-map <in-label>

<in-label> : [32..1023]

[no] pop - Enable/disable the pop action on the incoming label[no] shutdown - Administratively enable/disable the label-map definition[no] swap - Enable/disable the swap action on the incoming label

A:P1>config>router>mpls>if# label-map

MPLS Static LSP CLI Structure - LSR and Egress LER

CLI syntax for configuring a Static LSP on a transit LSR or the eLER


The configuration above shows the static LSP configuration for PE-1. The static LSP transport tunnel is configured to forward traffic across the provider core from PE-1 to PE-2.

The Static LSP is configured between these devices, from system address 10.10.10.61 to the device with system address 10.10.10.66.

PE-1 performs a PUSH operation and forwards the incoming packets to the next-hop address of 172.16.1.1, LSR-1, with a label of 999.


PE-1PE-2

LSR 4

LSR 3

10.10.10.66172.16.1.110.10.10.61

A:PE-1# configure routerA:PE-1>config>router# mplsA:PE-1>config>router>mpls# static-lsp "PE-1 to PE-2"A:PE-1>config>router>mpls>static-lsp$ to 10.10.10.66A:PE-1>config>router>mpls>static-lsp$ push 999 nexthop 172.16.1.1A:PE-1>config>router>mpls>static-lsp$ no shutdownA:PE-1>config>router>mpls>static-lsp$ exit all

A:PE-1# configure routerA:PE-1>config>router# mplsA:PE-1>config>router>mpls# static-lsp "PE-1 to PE-2"A:PE-1>config>router>mpls>static-lsp$ to 10.10.10.66A:PE-1>config>router>mpls>static-lsp$ push 999 nexthop 172.16.1.1A:PE-1>config>router>mpls>static-lsp$ no shutdownA:PE-1>config>router>mpls>static-lsp$ exit all

Configuring a Static LSP

LSR 2

LSR 1Static LSP


The configuration above shows the static LSP configuration for LSR 1 and LSR 2. The transit LSRs perform SWAP operations and forward the packet to the manually defined next-hop.


A:LSR-2>config>router# mplsA:LSR-2>config>router>mpls# interface "to LSR 1"A:LSR-2>config>router>mpls>if$ label-map 998A:LSR-2>config>router>mpls>if>label-map$ swap 997 nexthop 172.16.3.1A:LSR-2>config>router>mpls>if>label-map$ no shutdown


LSR 4

LSR 3

10.10.10.66172.16.1.110.10.10.61

LSR 2

LSR 1 Static

LSP

172.16.2.1

172.16.3.1

Static LSP

A:LSR-1>config>router# mpls

A:LSR-1>config>router>mpls# interface "to PE-1"

A:LSR-1>config>router>mpls>if$ label-map 999

A:LSR-1>config>router>mpls>if>label-map$ swap 998 nexthop 172.16.2.1

A:LSR-1>config>router>mpls>if>label-map$ no shutdown

PE-1PE-2


The configuration above shows the static LSP configuration for LSR 3 and PE-2. The transit LSRs perform SWAP operations and forward the packet to the manually defined next-hop.

PE-2 performs a POP operation and forwards unlabeled packets external to the MPLS domain.



LSR 4

LSR 3

10.10.10.66172.16.1.110.10.10.61

LSR 2

LSR 1Static LSP

172.16.2.1 172.16.3.1

A:PE-2>config>router# mplsA:PE-2>config>router>mpls# interface "to LSR 3"A:PE-2>config>router>mpls>if$ label-map 996A:PE-2>config>router>mpls>if>label-map$ popA:PE-2>config>router>mpls>if>label-map$ no shutdown

172.16.4.1

A:LSR-3>config>router# mplsA:LSR-3>config>router>mpls# interface "to LSR2"A:LSR-3>config>router>mpls>if$ label-map 997A:LSR-3>config>router>mpls>if>label-map$ swap 996 nexthop 172.16.4.1A:LSR-3>config>router>mpls>if>label-map$ no shutdown

PE-1PE-2



Section 2 - Verifying Static LSPs


The 'show router mpls static-lsp' command is used on the originating PE of the LSP (iLER) to verify the operational status of the static LSP configuration.


MPLS static LSP configuration on the originating PE

A:PE-1# show router mpls static-lsp

===============================================================================MPLS Static LSPs (Originating)===============================================================================LSP Name To Next Hop Out Label Out I/F Adm Opr-------------------------------------------------------------------------------PE-1 to PE-2 10.10.10.66 172.16.1.1 999 1/1/2 Up Up-------------------------------------------------------------------------------LSPs : 1===============================================================================A:PE-1#

A:PE-1# show router mpls static-lsp

===============================================================================MPLS Static LSPs (Originating)===============================================================================LSP Name To Next Hop Out Label Out I/F Adm Opr-------------------------------------------------------------------------------PE-1 to PE-2 10.10.10.66 172.16.1.1 999 1/1/2 Up Up-------------------------------------------------------------------------------LSPs : 1===============================================================================A:PE-1#

show router mpls static-lsp


The 'show router mpls static-lsp transit' command is used on a transit LSR to verify the operational status of the static LSP configuration.


A:LSR-1# show router mpls static-lsp transit

===============================================================================MPLS Static LSPs (Transit)===============================================================================In Label In I/F Out Label Out I/F Next Hop Adm Opr-------------------------------------------------------------------------------999 1/1/2 998 1/1/3 172.16.2.1 Up Up-------------------------------------------------------------------------------LSPs : 1===============================================================================

A:LSR-1#

A:LSR-1# show router mpls static-lsp transit

===============================================================================MPLS Static LSPs (Transit)===============================================================================In Label In I/F Out Label Out I/F Next Hop Adm Opr-------------------------------------------------------------------------------999 1/1/2 998 1/1/3 172.16.2.1 Up Up-------------------------------------------------------------------------------LSPs : 1===============================================================================

A:LSR-1#

show router mpls static-lsp transit

MPLS static LSP configuration on a transit P router


The 'show router mpls static-lsp terminate' command is used on the terminating PE of the LSP (eLER) to verify the operational status of the static LSP configuration.


A:PE-2# show router mpls static-lsp terminate ===============================================================================MPLS Static LSPs (Terminate)===============================================================================In Label In I/F Out Label Out I/F Next Hop Adm Opr-------------------------------------------------------------------------------996 1/2/2 n/a n/a n/a Up Up-------------------------------------------------------------------------------LSPs : 1===============================================================================A:PE-2#

A:PE-2# show router mpls static-lsp terminate ===============================================================================MPLS Static LSPs (Terminate)===============================================================================In Label In I/F Out Label Out I/F Next Hop Adm Opr-------------------------------------------------------------------------------996 1/2/2 n/a n/a n/a Up Up-------------------------------------------------------------------------------LSPs : 1===============================================================================A:PE-2#

show router mpls static-lsp terminate

MPLS static LSP configuration on the egress PE


The 'show router mpls interface label-map' command is used on a transit LSR or eLER to verify the labels and label actions associated with the static LSP configuration. This command provides the same information as the ‘show router mpls static-lsp transit’ command.


A:LSR-1# show router mpls interface label-map

===============================================================================MPLS Interfaces (Label-Map)===============================================================================In Label In I/F Out Label Out I/F Next Hop Type Adm Opr-------------------------------------------------------------------------------999 1/1/2 998 1/1/3 10.1.3.3 Static Up Up-------------------------------------------------------------------------------Interfaces : 1===============================================================================

A:LSR-1#

A:LSR-1# show router mpls interface label-map

===============================================================================MPLS Interfaces (Label-Map)===============================================================================In Label In I/F Out Label Out I/F Next Hop Type Adm Opr-------------------------------------------------------------------------------999 1/1/2 998 1/1/3 10.1.3.3 Static Up Up-------------------------------------------------------------------------------Interfaces : 1===============================================================================

A:LSR-1#

show router mpls interface label-map

Verify the labels and label actions associated with the static configuration


The 'show router mpls label' command can be used again after configuring the static LSPs to verify the configured labels.

After configuring the static LSP, the labels used for the configuration done in the 'configure router mpls' context will display RSVP as the Label Owner. This is typical for any configuration done under the MPLS context, even though static LSPs do not use a dynamic label distribution protocol like RSVP-TE.

Note that in the example above, there are 3 labels used for LDP signaled LSPs.


show router mpls label





Verify the labels that are bound to MPLS and their owner


The 'show router mpls status' command is used to verify each of the LSP types, the number configured and whether they originate on, transit through or terminate on the router.


show router mpls status

A:PE-1# show router mpls status

===============================================================================

MPLS Status

===============================================================================

Admin Status : Up Oper Status : Up

FR Object : Enabled Resignal Timer : Disabled

LSP Counts Originate Transit Terminate

-------------------------------------------------------------------------------

Static LSPs 1 1 1

Dynamic LSPs 0 0 0

Detour LSPs 0 0 0

===============================================================================

A:PE-1#

A:PE-1# show router mpls status

===============================================================================

MPLS Status

===============================================================================




-------------------------------------------------------------------------------

Static LSPs 1 1 1

Dynamic LSPs 0 0 0

Detour LSPs 0 0 0

===============================================================================

A:PE-1#

Verify the static LSPs that have been configured



LAB 2 Static LSPs

Pod 1 Pod 2

Pod 3

P2 P1

P3

PE1

PE3

PE 2

Pod 4

P4

PE 4

Service Provider Network Static LSP

Static LSP

Static LSP Static LSP

Static LSP

Static LSP

Static LSP



Section 3 - Label Distribution Protocol



Label Distribution Protocol - Section Outline

Label Distribution Protocol (LDP)

Alcatel-Lucent’s LDP Implementation

LDP Operation• Messaging• Transport Protocols• Neighbors• LDP Identifier

Alcatel-Lucent Multiprotocol Label Switching v1.3


LDP is a protocol defined for distributing labels based on RFC 3036. Routers configured for the LDP protocol will establish an LDP session between them and become peers. The LDP sessions allow for the exchange of label/FEC binding (mapping) information

The LDP protocol in the Alcatel-Lucent 7x50 product family is used for:

Establishing Transport Tunnel LSPs

Establishing Targeted LDP sessions between directly or non-directly connected peers


Label Distribution Protocol (LDP)

LDP is a protocol defined for distributing labels based on RFC 3036

Routers configured for the LDP protocol will establish an LDP session between them and become peers

The LDP sessions allow for the exchange of label/FEC binding (mapping) information

The LDP protocol in the Alcatel-Lucent 7x50 product family is used for:1. Establishing Transport Tunnel LSPs2. Establishing Targeted LDP sessions between directly or

non-directly connected peers


Each LDP Protocol Data Unit (PDU) is an LDP header followed by one or more LDP messages. The LDP header contains the following fields.

Version: Two octet unsigned integer containing the version number of the protocol. This version of the specification specifies LDP protocol version 1.

PDU Length: Two octet integer specifying the total length of this PDU in octets, excluding the Version and PDU Length fields. The maximum allowable PDU Length is negotiable when an LDP session is initialized. Prior to completion of the negotiation the maximum allowable length is 4096 bytes

LDP Identifier: Six octet field that uniquely identifies the label space of the sending LSR for which this PDU applies. The first four octets identify the LSR and must be a globally unique value. It should be a 32-bit router Id assigned to the LSR and also used to identify it in loop detection Path Vectors. The last two octets identify a label space within the LSR. For a platform-wide label space, these should both be zero. Note that there is no alignment requirement for the first octet of an LDP PDU


LDP Protocol Data Unit

Each LDP PDU is an LDP header followed by one or more LDP messages

The LDP header consists of three fields:• Version • PDU Length • LDP Identifier

16 310Version PDU Length

LDP ID


U bit - Unknown message bit. Upon receipt of an unknown message, if U is clear (=0), a notification is returned to the message originator; if U is set (=1), the unknown message is silently ignored.

Message Type - Identifies the type of message.

Message Length - Specifies the cumulative length in octets of the Message ID, Mandatory Parameters, and Optional Parameters.

Message ID - 32-bit value used to identify this message. Used by the sending LSR to facilitate identifying notification messages that may apply to this message. An LSR sending a notification message in response to this message should include this Message Id in the Status TLV carried by the notification message.

Mandatory Parameters - Variable length set of required message parameters. Some messages have no required parameters. For messages that have required parameters, the required parameters MUST appear in the order specified by the individual message specifications.

Optional Parameters - Variable length set of optional message parameters. Many messages have no optional parameters. For messages that have optional parameters, the optional parameters may appear in any order.


LDP Messages

All LDP messages have the following format

Parameters are encoded in the message using a Type Length Value (TLV) scheme

1 16 310U Message Type Message Length

Message ID

Mandatory Parameters

Optional Parameters


All LDP messages use a common format implemented in a Type Length Value (TLV) encoding scheme. The value field of any TLV may itself contain additional TLVs.

An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify a Type and 2 bits to specify behavior when an LSR doesn't recognize the Type, followed by a 2 octet Length Field, followed by a variable length Value field.

U bit - Unknown TLV bit: Upon receipt of an unknown TLV, if U is clear (=0), a notification must be returned to the message originator and the entire message must be ignored; if U is set (=1), the unknown TLV is silently ignored and the rest of the message is processed as if the unknown TLV did not exist.

F bit - Forward unknown TLV bit: This bit applies only when the U bit is set and the LDP message containing the unknown TLV is to be forwarded. If F is clear (=0), the unknown TLV is not forwarded with the containing message; if F is set (=1), the unknown TLV is forwarded with the containing message.

Type: Encodes how the Value field is to be interpreted.

Length: Specifies the length of the Value field in octets.

Value: Octet string of Length octets that encodes information to be interpreted as specified by the Type field.

The TLV specifies a general message container. Anything appearing in an LDP PDU could be encoded as a TLV including a FEC, a label or a hop count.


Type Length Value Encoding

All LDP messages use a common format implemented in a Type Length Value (TLV) encoding scheme

The value field is variable length and may itself contain additional TLVs

1 16 310U F Type Length

Value (variable - may contain additional TLVs)

2

U=0 ignore entire message

U=1 ignore unknown TLV only

F=0 forward TLV without unknown

F=1 forward TLV with unknown TLV


Message ID - 32-bit value used to identify this message.

Common Hello Parameters TLV – specifies values common to all hello messages. The parameters included in the hello messages are:

Hold Time – specifies the time an LSR will maintain its record of Hellos received from a peer LSR before declaring the adjacency down if it does not receive another Hello from the peer. The Hello hold timer is reset each time a Hello is received from the peer. The LSR peers each send their Hold time in their Hello message. They negotiate the Hold time for the Hellos. The Hello hold time value used is the smaller of the two.

T (Targeted Hello) – specifies whether this is a Targeted Hello or a Link Hello. A value of 1 signifies a Targeted Hello and a value of 0 signifies a Link Hello.

R (Request Send Targeted Hello) - specifies if the sender of the Hello message requests that the receiver send a periodic Targeted Hellos to it. A value of 1 makes this request, while a value of 0 does not.

Optional Hello Parameters include:

IPv4 or IPV6 Transport Address – specifies the IPv4 (or IPv6) address to be used to open the LDP session TCP connection between the peers. If this TLV is not included, the transport address used is the source address of the Hello message (i.e. the address of the egress interface).

Configuration Sequence Number – specifies a sequence of numbers (4 octets) that identifies the configuration state of the sending LSR, which is used by the receiving LSR to detect configuration changes on the sending LSR.


LDP Hello Message

Format of the LDP Hello message

16

310

0 Hello (0x0100) Message Length

Message ID

Common Hello Parameters TLV

Optional Parameters

1 16 3100 0 Common Hello Parms 0x0400 Length

Hold Time T R Reserved

0 0 IPv4 Transport Addr 0x0401 Length

System interface address



Common Session Parameters TLV – specifies values proposed by sending LSR for parameters that must be negotiated for every LDP session. The common session parameters are:

Protocol version – specifies the version of the LDP protocol supported by the LSR

KeepAlive Time – indicates the number of seconds the sending LSR proposes for the value of the KeepAlive Timer by using the smaller of its proposed value and the KeepAlive Time received from the peer LSR. The KeepAlive value chosen is the maximum amount of time that may elapse between the receipt of LDP messages, before the LDP session is declared down. Each time a LDP message is received, the KeepAlive timer is reset.

A (label advertisement discipline) – specifies the type of label advertisement. A value of 0 indicates Downstream Unsolicited, while a value of 1 indicates Downstream on Demand.

D (loop detection) – indicates whether loop detection based on path vectors is enabled. A value of 1 means loop detection is enabled, while a value of 0 means that it is disabled.

PVLim (Path vector limit) – specifies the maximum length of the path vector (i.e. maximum hops). This value must be 0 if loop detection is disabled.

Max PDU Length – specifies the proposed maximum allowable length for the LDP messages for the session. The default maximum length is 4096 octets. The LDP peers negotiate the maximum PDU length to use. This is the smaller of the two proposed values.

Receiver LDP Identifier – identifies the receiving peer’s label space. This LDP identifier together with the sender’s LDP identifier (contained in the message header) is used by the receiving peer to match the Initialization message with one of its Hello adjacencies. If there is no matching Hello adjacency the receiving peer must send a Notification message to the sending router and not establish the session.


LDP Initialization Message

Format of the LDP Initialization message

16

310

0 Initialization (0x0200) Message Length

Message ID

Common Session Parameters TLV

Optional Parameters

0 0 Common Sess Parms 0x0500 Length

Protocol Version KeepAlive Time

A D Reserved Max PDU Length

Receiver LDP Identifier

PVLim



FEC TLV - Specifies the FEC component of the FEC-Label mapping being advertised.

Label TLV - Specifies the Label component of the FEC-Label mapping.

Optional Parameters - This variable length field contains 0 or more parameters, each encoded as a TLV.

The optional parameters are:

Label Request Message ID - If this Label Mapping message is a response to a Label Request message it must include the Request Message Id optional parameter. The value of this optional parameter is the Message Id of the corresponding Label Request Message.

Hop Count - Specifies the running total of the number of LSR hops along the LSP being setup by the Label Message.

Path Vector - Specifies the LSRs along the LSP being setup by the Label Message.


LDP Label Mapping Message

Format of the LDP Label Mapping Message

1 16 3100 0x0400 Message Length

Message ID

FEC TLV

Label TLV

Optional Parameters


An LSR uses Generic Label TLVs to encode labels for use on links for which label values are independent of the underlying link technology. Examples of such links are PPP and Ethernet.

The Value field of the Label TLV contains the MPLS label signaled.

The Value field of the FEC TLV contains the type and value of the FEC. The possible FEC types are:

Wildcard Type 0x01 – no value : only used in Label Withdrawal and Label Release messages.

Prefix Type 0x02 – consists of 4 fields:

Prefix – Address prefix encoded according to the Address Family field

Address Family – Two octets containing a value from the ADDRESS FAMMILY NUMBERS in [RFC1700] that encodes the address family for the address prefix in the Prefix field. (e.g. IPv4 address family)

PreLen – Length in bits of the address prefix (one octet)

Host Address Type 0x03 – consists of 4 fields:

Address Family – Two octets containing a value from the ADDRESS FAMMILY NUMBERS in [RFC1700] that encodes the address family for the address prefix in the Prefix field. (e.g. IPv4 address family)

Host Addr Len – Length of the host address in octets (one octet)

Full host address - Address encoded according to the Address Family field.


Label and FEC TLV

Format of the Label TLV1 16 310

0 0 Generic Label 0x0200 Length

Label

2

Format of the FEC TLV1 16 310

0 0 FEC 0x0100 Length

FEC Element 1

FEC element ….

FEC Element n

2


There are four categories of LDP messages:

1. Discovery messages, used to periodically announce and maintain the presence of an LSR in a network.

2. Session messages, used to establish, maintain, and terminate sessions between LDP peers.

3. Advertisement messages, used to create, change, and delete label mappings for FECs.

4. Notification messages, used to signal errors and other events of note.

Correct operation of LDP requires reliable and ordered delivery of messages. To satisfy these requirements, LDP uses TCP as a transport protocol for session, advertisement and notification messages (for everything except the UDP based discovery mechanism).


LDP utilizes both UDP and TCP for transport services

UDP based messages• Discovery messages periodically announce and maintain the

presence of an LSR in a network

TCP based messages• Session messages establish, maintain and terminate sessions

between LDP peers• Advertisement messages create, change and delete label

mappings for FECs• Notification messages signal errors and other events

LDP Message Categories


The table above provided a list of all the different LDP message types supported by LDP.


LDP Message Types

Type Name Function

0x0001 Notification Signal errors and other events

0x0100 Hello Announces the presence of an LSR

0x0200 Initialization Initiates the session establishment process

0x0201 KeepAlive Monitors the integrity of the LDP session transport connection

0x0300 Address Advertise the interface addresses to an LDP peer

0x0301 Address Withdraw Withdraws a previously advertised interface address

0x0400 Label Mapping Advertises a FEC-label binding to an LDP peer

0x0401 Label Request Requests a FEC-label binding from an LDP peer

0x0402 Label Withdraw Signals the peer that the previously advertised FEC-label mapping may no longer be used

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 Label Abort Request Aborts an outstanding Label Request message

0x3E00 -0x3EFF

Vendor Private Used to convey vendor-private information between LSRs

0x3F00 -0x3FFF

Experimental LDP Experimental Extensions


LDP uses IANA Registered port number 646 for both TCP and UDP.

UDP is used as the transport protocol for the discovery mechanism, primarily the HELLO messages which are used to discover directly connected neighbors. This is done since the reliability of a HELLO message is not critical and because no connection setup is required to use UDP.

TCP is used as the transport protocol for session, advertisement and notification messages, used to exchange LDP information such as the label bindings, and for sending information to non directly connected neighbors.


LDP Transport Protocols

LDP uses Well Known port number 646 for both TCP and UDP

UDP is used as the transport protocol for the discovery mechanism• HELLO messages

TCP is used as the transport protocol for session, advertisement and notification messages• All messages except HELLOs

UDP based HELLO

10.1.1.1 10.1.1.2

TCP based Messages

LDP HELLO

OtherLDP Messages


Routers configured for the LDP protocol will establish an LDP session between them and become peers, often referred to as neighbors.

In any pair of potential LDP peers, one router will initiate an LDP session, sending a message to the other router using UDP or TCP port number 646. If that port is open on the receiving device (meaning LDP is configured correctly), an LDP neighbor relationship will form.

LDP peers are always directly connected, sharing a common data link.


Routers configured for the LDP protocol will establish an LDP session between them and become peers

When using LDP, neighbors are directly connected

LDP Peers

LSR LSR LSR

LDP Session LDP Session


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 a globally unique value, such as a 32 bit router ID assigned to the LSR. The last two octets identify a specific label space within the LSR. The last two octets of LDP Identifiers for platform wide label spaces are always set to zero.

This is what is typically seen on the Alcatel-Lucent 7x50.

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 the last two octets of the LDP Identifier for per interface label spaces will be non-zero.

A situation where an LSR would need to advertise more than one label space to a peer and hence use more than one LDP Identifier occurs when the LSR has two links to the peer and both are ATM, both of which use per interface labels.

Another situation would be where the LSR had two links to the same LSR peer, one of which is Ethernet, which uses per platform labels, and the other of which is ATM which uses per interface labels.

.


Label Space ID(Zero for per platform Label Space)

4 Bytes 2 Bytes

LDP Identifier

An LDP identifier is a six byte quantity used to identify an LSR’slabel space

The first four octets identify the LSR and must be a globally unique value

• Typically a 32 bit router-ID assigned to the LSR

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 set to zero

• Example:10.1.1.1:0

LSR ID(32 bit router-ID)

LDP Identifier



Section 4 - Label Distribution Protocol - Neighbor Discovery



Label Distribution Protocol - Neighbor Discovery - Section Outline

LDP Neighbors• Discovery• Session Establishment• Label Origination • Label Exchange


LDP discovery is a mechanism that enables an LSR to discover potential LDP peers. Discovery makes it unnecessary to explicitly (manually) configure an LSR's label switching peers.

To engage in LDP discovery, an LSR periodically sends LDP Link HELLO messages out of each LDP enabled interface. LDP Link HELLO messages are sent as UDP packets addressed to the well known LDP discovery port, using the all routers multicast group address of 224.0.0.2. The source IP address of the LDP HELLO is the egress interface of the router.

An LDP Link HELLO sent by an LSR carries the LDP Identifier for the label space the LSR intends to use for the interface.

Receipt of an LDP Link HELLO on an interface identifies a HELLO adjacency with a potential LDP peer, reachable at the link level on the interface, as well as the label space the peer intends to use for the interface.


LSRs periodically announce their presence on a network by sending HELLO messages out each LDP enabled interface to multicast address 224.0.0.2

Receipt of a HELLO on an interface identifies a HELLO adjacency• Referred to as a Link Adjacency

LDP Discovery

Link Adjacency

10.1.1.1 10.1.1.2

HELLOs

192.168.1.1/32 192.168.1.2/32


Before sending a HELLO, each LSR must select a transport address that it will use for the local end of the session connection.

When an LSR sends a HELLO message, it uses the HELLO message as a mechanism to advertise the transport address.


LDP Transport Address

Each LSR must select an LDP transport address

Each LSR will advertises the transport address for its end of the session using a HELLO message

192.168.1.1/32

10.1.1.1

10.1.2.1

HELLO

10.1.3.1


The transport address may be different from the address used as the source of the HELLO messages.

The transport address selected by an LSR may be advertised in one of two ways:

Explicitly, by including the transport address in an optional Transport Address TLV.

Implicitly, by omitting the TLV and using the HELLO source address as the transport address.

By default on the Alcatel-Lucent 7x50 includes the Transport address TLV and specifies the system address of the router.



The transport address may be a different address than the address that is used as the source of the HELLO

LDP Session

Source IP = 10.1.1.2:646

10.1.1.1 10.1.1.2

192.168.1.1/32 192.168.1.2/32

Source IP =192.168.1.2:646

10.1.1.1 10.1.1.2

192.168.1.1/32 192.168.1.2/32

Transport AddressTLV omitted

Transport AddressTLV specified


The first step in LDP neighbor establishment is the generation of a HELLO message on all LDP enabled interfaces. Receipt of a HELLO from another device identifies a potential LDP peer.

When an LSR chooses to establish an LDP session with another LSR learned via a HELLO message, it uses the TCP based LDP initialization procedure.

Session establishment is a two step process:

1. Transport connection establishment.

The peer with the higher transport address will be the Active device in the exchange. The other peer assumes a Passive role. The Active device will attempt to establish a TCP session with the Passive device, by initiating a TCP connection using the well known TCP port number of 646, which defines LDP. The Passive device waits for an LDP TCP connection to its well-known LDP port.

2. Session initialization.

After a transport connection is established, the peers negotiate session parameters by exchanging LDP Initialization messages. The parameters negotiated include LDP protocol version, authentication parameters, timer values, and others.

If all parameters are compatible, a successful LDP session is the result.


LDP Session Establishment

After a HELLO is seen from another LSR, the peer with the higher transport address will initiate establishment of the LDP session

Session establishment is a two step process• Transport connection establishment (authentication)• Session initialization 192.168.1.1/32 192.168.1.2/32

10.1.1.1 10.1.1.2

HELLO Session


An LSR must advertise the same transport address in all HELLOs that advertise the same label space. This requirement ensures that two LSRs linked by multiple HELLO adjacencies using the same label spaces play the same connection establishment role for each adjacency.

In the diagram shown above, both LSRs will generate HELLO messages from all LDP enabled interfaces, and in this case, send two separate LDP HELLOs, but to the same router. However, since the transport address of an LSR is consistent across the label space advertised, the routers are able to determine that the two LDP HELLOs received are in fact from the same router, and therefore only a single LDP session is established between them.

If the HELLO source address was used as the transport address, the routers would receive two separate HELLO messages but would not be able to determine that they are from the same device.


The transport address of an LSR must be consistent across the label space advertised

This ensures only a single LDP session exists between any pair of routers

LDP Session Establishment

192.168.1.1/32 192.168.1.2/32

10.1.1.1 10.1.1.2

10.1.2.1 10.1.2.2

Single LDP Session

LDP HELLO

Transport Address = 192.168.1.2

LDP HELLO

Transport Address = 192.168.1.2


The table above shows the LDP Session Initialization State Transition Table. Each valid LDP state is shown, alongside the events that will cause the noted state transitions to occur.


Session Initialization State Transition Table

State Event New StateNON EXISTENT Session TCP connection established INITIALIZED

INITIALIZED Transmit Initialization message (Active Role) OPENSENT

Receive acceptable Initialization message (Passive Role )

Action: Transmit Initialization and KeepAlive message

OPENREC

Receive any other LDP message

Action: Transmit Error Notification (NAK) message and close transport connection

NON EXISTENT

OPENREC Receive KeepAlive message OPERATIONAL



NON EXISTENT

OPENSENT Receive acceptable Initialization message

Action: Transmit KeepAlive message

OPENREC



NON EXISTENT

OPERATIONAL Receive Shutdown message

Action: Transmit Shutdown message and close transport connection

NON EXISTENT

Receive other LDP messages OPERATIONAL

Timeout

Action: Transmit Shutdown message and close transport connection

NON EXISTENT


During the discovery phase, the routers periodically send LDP Link Hello messages out their LDP interfaces, as UDP packets to the well-known multicast address 224.0.0.2. The HELLO message contains the router’s LDP ID.

The router with the bigger transport address (often the router’s system interface address) takes the active role and initiates the TCP connection setup. The router with the smaller transport address takes the passive role.

After the TCP connection is established, the routers exchange Initialization messages to negotiate session parameters such as LDP protocol version, label distribution method, and timer values. The active router sends the INIT message to the passive router, and enters the OpenSent state. The passive router verifies the parameters proposed by the active router, and if acceptable sends back an INIT & KEEPALIVE message, and enters the OpenRec state. If it rejects the proposed session parameters, it sends a ERROR NOTIFICATION message and closes the TCP connection.

The active router responds to the passive router’s INIT/KEEPALIVE message with a KEEPALIVE message and enters theOpecRec state. When the Passive router receives the KEEPALIVE message it enters the Operational state. If the Passive router reces an ERROR NOTIFICATION message, indicating that the Active router has rejected the proposed session parameters, it closes the TCP connection.

The Passive router responds with a KEEPALIVE message back to the Active router, and the Active router now also enters the Operational state. At this point the LDP session is established, and LDP message can begin to be exchanged.


LDP Session Establishment Timeline

P1192.168.1.1/32

P2192.168.1.2/32

Transport address is

bigger - active role

Transport address is smaller -

passive role HELLO adjacency established

TCP Connection established

OpenRec state

Initialized StateInitialized State

OpenSent state

OpenRec state

Operational State

Operational State

HELLO1 HELLO 1

Setup TCP connection to

port 646

2

INIT 3

INIT/Keepalive

4

Keepalive

5

Keepalive

6

LDP Session established

78

9 10


The output shown above is obtained by enabling debug on ldp using the ‘debug router ldp peer <peer address> packet [hello | init | keepalive | label] detail” command on the router.

The output shows the Initialization packet sent by this router (which is the Active router) to its peer router 10.10.10.223, the Initialization packet received from the Passive peer, and finally the Keepalive packet sent back in response.


LSP Session Establishment Packet Exchange Example

1 2006/07/27 23:35:33.41 UTC MINOR: DEBUG #2001 - LDP

"LDP: LDP

Send Initialization packet (msgId 2) to 10.10.10.223:0

Send 10.10.10.223:0

Protocol version = 1 Keepalive Timeout = 30

Label Advertisement = downStreamUnsolicited

Loop Detection = Off PathVector Limit = 0 Max Pdu = 4096

"


"LDP: LDP

Recv Initialization packet (msgId = 2) from 10.10.10.223:0

Recv 10.10.10.243:0

Protocol version = 1 Keepalive Timeout = 30

Label Advertisement = downStreamUnsolicited

Loop Detection = Off PathVector Limit = 0 Max Pdu = 4096

"


"LDP: LDP

Send Keepalive packet (msgId 3) to 10.10.10.223:0

"

Packets sent/received by Active router


The LDP Session Initialization state transition diagram for the device with the Active role in session establishment is shown above. This state diagram corresponds to the Session Initialization state transition table shown on the previous page.

The numeric codes shown in the diagram above correspond to the list below, which are reasons why the session may not become operational

1.Receive message other than Init, or a timeout occurs

2.Receive message other than Init , or a timeout occurs, send NAK message

3.Receive message other than Init or keepalive, or a timeout occurs, send NAK message

4.Receive shutdown message, or a timeout occurs, send shutdown message

The difference in the diagram above between the devices with the Active and Passive role in session establishment occurs on the transition following the Initialized state. This Active device sends an Init and transitions to OpenSent, while the Passive device waits for an Init and transitions to OpenRec.

Complete documentation on the LDP Session Initialization and State Transition Diagram may be found in RFC 3036, LDP Specification.


LDP State Diagram

Non Existent

Initialized

OpenRec

OpenSent

Operational

Send Init SessionEstablished

Receive Init/Send Keepalive

Receive KeepaliveAny message exceptshutdown or timeout

4

1

23Receive Init, send Init and

Keepalive message

Active DevicePassive DeviceAny DeviceError Message


LDP will establish a separate session per label space advertised by the router. As the Alcatel-Lucent 7x50 user per platform label space, there should be only one LDP session between any 2 peers.

The LDP sessions allow for the exchange of FEC/label binding (mapping) information. A single LDP session per label space allows each peer to learn the other's label mappings.

Label bindings received from other LDP peers are stored in the Label Information Base (LIB).


There is a separate LDP session established per label space

An LDP session allows for the mutual exchange of FEC/label bindings using LDP label Mapping messages

LDP Label Exchange

Exchange LabelBindings

Exchange Label Bindings

LIB LIB LIB

LSR LSR LSR



The output shown above is obtained by enabling debug on ldp using the ‘debug router ldp peer <peer address> packet [hello | init | keepalive | label] detail” command on the router.

The output shows the Address Message sent by the router to its peer, to advertise its interface addresses. This message is sent when a new LDP session is initialized and before sending Label Mapping or Label Request messages. It also shows the Label Mapping Message sent by the router to its peer, to advertise its FEC-label bindings – in this case it is advertising a label for its system address.


Label Advertisement Packet Exchange Example

4 2006/07/27 23:35:33.43 UTC MINOR: DEBUG #2001 - LDP"LDP: LDPSend Address packet (msgId 4) to 10.10.10.223:0Address Family = 1 Number of addresses = 2Address 1 = 10.48.1.2Address 2 = 10.10.10.243“

5 2006/07/27 23:35:33.43 UTC MINOR: DEBUG #2001 - LDP"LDP: LDPSend Label Mapping packet (msgId 5) to 10.10.10.223:0Label 131071 advertised for the following FECsAddress Prefix Address Family = 1 Prefix = 10.10.10.243/32"

Packets sent/received by router


Label bindings will be exchanged in LDP Label Mapping messages after session establishment is successful.

By default, label bindings are generated and advertised for only the system address on the Alcatel-Lucent 7x50.


Alcatel-Lucent Default Label Generation

By default, a label binding is generated and advertised for only the system address of the Alcatel-Lucent 7x50

LDP Advertisement

Exchange LabelBindings

Exchange Label Bindings

LIB LIB LIB


System192.168.1.1/32

System192.168.1.3/32

System192.168.1.2/32

10.2.1.0/24


An LSR may originate a label mapping for a FEC only if it is the egress of the MPLS domain. An LSR is considered egress if one of the following conditions are met:

The FEC is a directly connected interface

The next-hop is external to the MPLS domain

To originate labels for other prefixes in the routing table, export policies must be used to generate a label.


Additional Label Generation

An LSR may originate a label mapping for a FEC only if is the egress of the MPLS domain

An LSR is considered egress if one of the following conditions are met:• The FEC is a directly connected interface• The next-hop is external to the MPLS domain

To originate labels for other prefixes in the routing table, export policies must be used to generate a label

To control label acceptance from LDP peers, import policies must be used


The LIB is populated based on the label exchange process. The LFIB is built from the LIB and the FIB.

The LFIB contains only the labels that will be used for label switching packets. If a label is received from a neighbor for a FEC, and the FIB contains a route for the same FEC for which the same neighbor is the next-hop, then it is populated into the LFIB.


Contents of the LIB and LFIB

The LIB is populated based on label exchange with neighbors

The LFIB is populated with the labels received from a neighbor if the active route for the FEC originated from that neighbor• The neighbor providing the label is the next-hop for the FEC

Table Name

Meaning Contents Populated By

RIB Routing Information Base

Routing updates received

Routing Protocol Exchange - Each routing protocol has a separate RIB

FIB Forwarding Information Base

Active routes RTM selects the active routes from all protocol "Best" routes

LIB Label Information Base

Locally generated and received MPLS labels

MPLS Label Exchange

LFIB Label Forwarding Information Base

Labels used by the LSR The labels assigned to the active routes (for each next-hop)


In summary,

Per platform label space

Platform wide incoming labels are used for interfaces that can share the same labels

Downstream Unsolicited Label distribution mode

Label mappings are provided to all peers for which the local LSR might be a next-hop for a given FEC

Liberal Label Retention mode

All label mappings received from a peer LSR is retained regardless of whether the LSR is the next-hop for the advertised mapping

Ordered Control mode

An LSR initiates the transmission of a label mapping only for a FEC for which it has a label mapping for the FEC next-hop, or for which the LSR is the egress

An LSR propagates a label mapping only for a FEC for which it has a label mapping for the FEC next-hop


Alcatel-Lucent LDP Default Settings

The Alcatel-Lucent 7x50 LDP default settings are summarized below• Per platform label space

— Platform wide incoming labels are used for interfaces that can share the same labels

• Downstream Unsolicited label distribution mode— Label mappings are provided to all peers for which the local LSR might

be a next-hop for a given FEC• Liberal Label Retention mode

— All label mappings received from a peer LSR are retained regardless of whether the LSR is the next-hop for the advertised mapping

• Ordered Control mode— An LSR initiates the transmission of a label mapping only for a FEC for

which it has a label mapping for the FEC next-hop, or for which the LSR is the egress

— An LSR propagates a label mapping only for a FEC for which it has a label mapping for the FEC next-hop


The ‘show router ldp parameters’ command displays the default settings for label distribution and retention.

LDP defaults are Downstream Unsolicited label distribution mode, Liberal Label Retention mode and Ordered Control mode.

RSVP-TE operates in Downstream on Demand (DOD) label distribution mode, Conservative label retention mode and Ordered Control mode.

RSVP-TE is discussed in detail in Module 6 of this course.


Verifying Alcatel-Lucent LDP Default Settings

LSR-1# show router ldp parameters

=====================================================================

LDP Parameters (LSR ID 10.10.10.1)

=====================================================================

---------------------------------------------------------------------

Interface Parameters

---------------------------------------------------------------------

Keepalive Timeout : 30 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

---------------------------------------------------------------------LSR-1#

LDP defaults are Downstream Unsolicited label distribution mode, Liberal Label Retention mode and Ordered Control mode


The label for a given FEC may be withdrawn, and as a result invalidated, if any of the following actions occur:

•LDP withdraws the previously assigned label, and re-signals the FEC with the new MTU in the interface parameter

•A network change occurs causing the router to no longer recognize a FEC for which it had previously generated and advertised a label

•The router is configured to cease the generation of labels for specified FECs

•When a service manager command is issued to clear the labels, the labels are withdrawn, and new label mappings are issued.

An LDP Label Release message may be generated if one of the following conditions occur:

•The LSR has received a label withdraw message from a peer.

•The LSR operates in Conservative label retention mode, and has received 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 as a result of a network failure or topological change).

•If there is no memory to store a received label, the label is released.


Reasons for Label Removal Actions

LDP may issue a label Withdraw message under the following conditions

• MTU changes

• Router no longer recognizes a FEC for which it had generated & advertised a label

• Router configured to no longer generate labels for given FECs

• Labels are cleared (via configuration)

LDP may issue a label Release message under the following conditions

• In response to a Label Withdraw message

• If LSR operates in Conservative retention mode, and the peer from whom it received the label is not or no longer the next hop router

• Memory allocation failure



LAB 3.1 LDP Session Establishment

Pod 1 Pod 2

Pod 3

Core 2 Core 1

Core 3

Edge 1

Edge 3

Edge 2

Pod 4

Core 4

Edge 4

10.48.1.0/24 10.64.1.0/24

10.16.1.0/24 10.32.1.0/24

10.x.y.z/24

Service Provider Network LDP Enabled Core

LDP



Section 5 - Label Distribution Protocol - Label Signaling



Label Distribution Protocol - Label Signaling - Section Outline

LDP Signaling• Label Origination• Label Exchange

Data Plane Operations


Once LDP neighbors have been established, each LSR will originate a label for its system address, and may originate a label for each FEC for which it has a next-hop that is external to the MPLS domain.

In the example shown above, LSR 4 has an external next-hop for FEC 10.2.1.0/24 and has created a local label binding for this FEC and will propagate it into the MPLS domain to its LDP peer of LSR 3.

Similarly, LSR 1 will originate a label for FEC 10.1.1.0/24.


10.2.1.0/24

LDP Signaling

Each LSR will originate a label for its system address by default

Each LSR may originate a label for a FEC for which it has a next-hop that is external to the MPLS domain

LSR 4LSR 3LSR 2LSR 1

10.1.1.0/24

Control Plane

1/1/3

1/1/11/1/2

1/1/11/1/2

1/1/1

1/1/2

1/1/3

LSR 4

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.2.1.0/24 100 - 1/1/1 ext.

LSR 1

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.1.1.0/24 100 - 1/1/3 ext.


Each LSR will propagate labels for each FEC for which it is a possible next-hop to its LDP peers.

In the example shown above, LSR 3 has received a label (100) for FEC 10.2.1.0/24 from LSR 4 and has installed the label binding for this FEC in the LFIB. LSR 3 will generate a label mapping of its own for FEC 10.2.1.0/24 and send it to LSR 2.

Label binding messages are only exchanged between direct LDP peers.

Similarly, LSR 2 has received label 100 for FEC 10.1.1.0/24 from LSR 1.


10.2.1.0/24

LDP Signaling

Each LSR will propagate labels for each FEC for which it is a possible next-hop to its LDP peers


10.1.1.0/24

1/1/3

1/1/11/1/2

1/1/1

1/1/2

1/1/1

1/1/2

1/1/3

Control Plane

LSR 3

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.2.1.0/24 200 100 1/1/2 LSR4

LSR 2

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.1.1.0/24 101 100 1/1/1 LSR1


The labels will propagate bidirectionally hop by hop to the edge of the MPLS domain.

In the example shown above, LSR 2 has received a label (200) for FEC 10.2.1.0/24 from LSR 3 and has installed the label binding for this FEC in the LFIB. LSR 2 will generate a label mapping of its own for FEC 10.2.1.0/24 and send it to LSR 1.

Similarly, LSR 3 has received label 300 for FEC 10.1.1.0/24 from LSR 2.


10.2.1.0/24

LDP Signaling

The labels will propagate bidirectionally to the edge of the MPLS domain


10.1.1.0/24

1/1/3

1/1/11/1/2

1/1/11/1/2

1/1/1

1/1/2

1/1/3

Control Plane

LSR 3

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.1.1.0/24 300 101 1/1/1 LSR2

10.2.1.0/24 200 100 1/1/2 LSR4

LSR 2

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.1.1.0/24 101 100 1/1/1 LSR1

10.2.1.0/24 300 200 1/1/2 LSR3


The labels have now propagated across the MPLS domain.

It is important to note the following:

The egress router has a blank egress label for the FEC

The ingress router has a blank ingress label for the FEC

Label binding messages are only exchanged between direct LDP peers

An LSR may be ingress for one FEC and egress for another FEC

The egress LER does not generate a label for the given FEC since that FEC is not its system address, nor an address that is outside the MPLS domain, and for which it is the next hop.

In the example shown above, LSR 4 has an external next-hop for FEC 10.2.1.0/24 and therefore the egress label is blank indicating that if it receives a packet for this FEC it must POP the label and forward the packet unlabeled.

Similarly, LSR 1 will POP the received label and forward unlabeled packets for FEC 10.1.1.0/24.


10.2.1.0/24

LDP Signaling

When the labels have propagated across the MPLS domain• The ingress router has a blank ingress label• The egress router has a blank egress label


10.1.1.0/24

1/1/3

1/1/11/1/2

1/1/1

1/1/2

1/1/1

1/1/2

1/1/3

Control Plane

LSR 1

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.1.1.0/24 100 - 1/1/3 ext.

10.2.1.0/24 - 300 1/1/2 LSR2

LSR 4

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.1.1.0/24 - 300 1/1/3 LSR3

10.2.1.0/24 100 - 1/1/1 ext.


Once the control plane (IGP Routing and LDP) has established a path across the provider core, LSPs exist for each of the FECs that have been signaled.

The LDP signaled LSPs have established an end to end Label Switched Path by establishing LSPs between each directly connected LDP neighbor, comparable to traditional IP hop-by-hop forwarding.

A packet arriving at LSR 4 for FEC 10.1.1.0/24 should arrive unlabeled and will have a label PUSHed onto it.


10.2.1.0/24

Data Plane Operation

A packet arriving at LSR 4 for FEC 10.1.1.0/24 should arrive unlabeled and will have label 300 PUSHed onto it

• It will then be forwarded to LSR 3 via interface 1/1/3


10.1.1.0/24

1/1/3

1/1/11/1/2

1/1/1

1/1/2

1/1/1

1/1/2

1/1/3

Data Plane

Label Switched Path

PUSH

LSR 4

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.1.1.0/24 - 300 1/1/3 LSR3

10.2.1.0/24 100 - 1/1/1 ext.


A packet arriving at LSR 3 for FEC 10.1.1.0/24 should arrive labeled, in this case with label 300 if it arrives from LSR 4. Label 300 will be SWAPped for label 101 and the packet will be forwarded to LSR 2 via interface 1/1/1.



The packet arriving at LSR 3 for FEC 10.1.1.0/24 should arrive with label 300

Label 300 will be SWAPped for label 101• It will then be forwarded to LSR 2 via interface 1/1/1

Data Plane

SWAP

10.2.1.0/24


10.1.1.0/24

1/1/3

1/1/11/1/2

1/1/11/1/2

1/1/1

1/1/2

1/1/3Label Switched Path

LSR 3

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.1.1.0/24 300 101 1/1/1 LSR2

10.2.1.0/24 200 100 1/1/2 LSR4


A packet arriving at LSR 2 for FEC 10.1.1.0/24 should arrive labeled, in this case with label 101 if it arrives from LSR 3. Label 101 will be SWAPped for label 100 and the packet will be forwarded to LSR 1 via interface 1/1/1.




Label 101 will be SWAPped for label 100 • It will then be forwarded to LSR 1 via interface 1/1/1

Data Plane

SWAP

LSR 2

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.1.1.0/24 101 100 1/1/1 LSR1

10.2.1.0/24 300 200 1/1/2 LSR3

10.2.1.0/24


10.1.1.0/24

1/1/3

1/1/11/1/2

1/1/11/1/2

1/1/1

1/1/2



A packet arriving at LSR 1 for FEC 10.1.1.0/24 should arrive labeled, in this case with label 100 if it arrives from LSR 2. Label 100 will be POPped and the packet will be forwarded unlabeled via interface 1/1/3 external to the MPLS domain.




Label 100 will be POPped since there is no outgoing label • It will then be forwarded via interface 1/1/3 outside the MPLS

domain

Data Plane

POP

LSR 1

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.1.1.0/24 100 - 1/1/3 ext.

10.2.1.0/24 - 300 1/1/2 LSR2

10.2.1.0/24


10.1.1.0/24

1/1/3

1/1/11/1/2

1/1/11/1/2

1/1/1

1/1/2



A FEC identifies the set of IP packets which map to an LSP. A packet matches an LSP if and only if that LSP has a FEC which matches the packet's destination address. A packet matches an LSP based on longest match to the prefix.

In a simple Traffic Engineering application, it may be desirable for LSR 1 to send traffic matching a specific criteria via a selected LSP to LSR 2, rather than forwarding the traffic along the IGP routed path.

In the example above, if a packet for destination address 10.2.1.3 arrives it will be forwarded via LSP A, while a second packet for destination 10.2.2.3 will be forwarded via LSP B.


Label Switching Longest Match

A packet matches an LSP if and only if that LSP has a FEC which matches the packet's destination address

A packet matches an LSP based on longest match to the prefix

LSP A

10.2.1.0/24LSR 2LSR 1LSP B

Prefix LSP

10.1.1.0/24 LSP A

10.2.1.0/24 LSP B



Section 6 - Convergence in an LDP Network


The default settings for LDP are Downstream Unsolicited and Liberal Label retention. In a converged LDP network, routers should have labels for FECs from all LDP peers.

As shown above, LER 1 has a route for 10.2.1.0/24 from LSR 1 and LSR 2 stored in the RIB, but has chosen the entry received from LSR 1 as the active route, since the best IGP metric was received from LSR 1.

Similarly, LER 1 has a label for FEC 10.2.1.0/24 from LSR 1 and LSR 2 stored in the LIB, but has chosen the label received from LSR 1 as the active label, since the best IGP route is via LSR 1.

In this steady state condition, the control plane has processed all changes and updates to both IGP routing and LDP protocols, and the network is considered to be converged.


MPLS Network Steady State

Tables on other routers are similar

1/1/1

1/1/2

1/1/3

1/1/4

1/1/1

LSR 1

LER 1

LER 2

MPLS Network

1/1/5

LER 1

LFIB


Egress Label

Egress Interface

next-hop

10.2.1.0/24 - 100 1/1/2 LSR 1

1/1/3

1/1/4

1/1/1

1/1/2

LSR 2

10.2.1.0/24

LER 1 LIB


10.2.1.0/24 LSR 1 100

10.2.1.0/24 LSR 2 200

LER 1 RIB

Prefix Next-hop Interface

10.2.1.0/24 LSR 1 1/1/2

10.2.1.0/24 LSR 2 1/1/3

LER 1 FIB


10.2.1.0/24 LSR 1 1/1/2

LSP


Should the link between LER 1 and LSR 1 fail, the failure first must be detected.

It is typically detected by the physical nature of the event, such as the interface going down. This results in the loss of any logical sessions associated to that interface, such as IGP routing or link level LDP.

When a protocol session is torn down, it results in the invalidation and loss of all information that originated from the lost neighbor(s).


MPLS Convergence

1/1/1

1/1/2

1/1/3

1/1/4

1/1/1

LSR 1

LER 1

LER 2

MPLS Network

1/1/5

LER 1

LFIB


Egress Label

Egress Interface

next-hop

10.2.1.0/24 - 100 1/1/2 LSR 1

1/1/3

1/1/4

1/1/1

1/1/2

LSR 2

10.2.1.0/24

LER 1 LIB


10.2.1.0/24 LSR 1 100

10.2.1.0/24 LSR 2 200

LER 1 RIB


10.2.1.0/24 LSR 1 1/1/2

10.2.1.0/24 LSR 2 1/1/3

LER 1 FIB


10.2.1.0/24 LSR 1 1/1/2

All logical sessions associated to the interface are lost on failure


IGP convergence requires a recalculation of the SPF algorithm and a new selection of best route. The IGP best route must then be offered to the Routing Table Manager (RTM) to determine if this route is to be the active route and subsequently installed in the FIB.

In this case, the new best and active route to the destination 10.2.1.0/24 is the route via LSR 2.


IGP Convergence

1/1/1

1/1/2

1/1/3

1/1/4

1/1/1

LSR 1

LER 1

LER 2

MPLS Network

1/1/5

LER 1

LFIB


Egress Label

Egress Interface

next-hop

1/1/3

1/1/4

1/1/1

1/1/2

LSR 2

10.2.1.0/24

LER 1 LIB


10.2.1.0/24 LSR 2 200

LER 1 RIB


10.2.1.0/24 LSR 2 1/1/3

LER 1 FIB


SPF

LER 1 FIB


10.2.1.0/24 LSR 2 1/1/3


LDP convergence may then follow. One benefit of Liberal Label retention is that the label previously received from the new best route is already installed in the LIB. It has been present all along, but until IGP routing converges, the LFIB may not be populated.

Now that IGP routing has converged, the LFIB may use the label from LSR 2 since the next-hop now belongs to the active route.


LDP Convergence - New Steady State

1/1/1

1/1/2

1/1/3

1/1/4

1/1/1

LSR 1

LER 1

LER 2

MPLS Network

1/1/5

LER 1

LFIB


Egress Label

Egress Interface

next-hop

1/1/3

1/1/4

1/1/1

1/1/2

LSR 2

10.2.1.0/24

LER 1 LIB


10.2.1.0/24 LSR 2 200

LER 1 RIB


10.2.1.0/24 LSR 2 1/1/3

LER 1 FIB


10.2.1.0/24 LSR 2 1/1/3

LER 1

LFIB


Egress Label

Egress Interface

next-hop

10.2.1.0/24 - 200 1/1/3 LSR 2

LSP


If the previously failed link is restored the convergence issues are similar to the previous situation.


Link Restoration

1/1/1

1/1/2

1/1/3

1/1/4

1/1/1

LSR 1

LER 1

LER 2

MPLS Network

1/1/5

LER 1

LFIB


Egress Label

Egress Interface

next-hop

10.2.1.0/24 - 200 1/1/3 LSR 2

1/1/3

1/1/4

1/1/1

1/1/2

LSR 2

10.2.1.0/24

LER 1 LIB


10.2.1.0/24 LSR 2 200

LER 1 RIB


10.2.1.0/24 LSR 2 1/1/3

LER 1 FIB


10.2.1.0/24 LSR 2 1/1/3

LSP


The link must be detected to be up. Once this has occurred, the IGP must flow through its state transitions and establish a new neighbor relationship and adjacency, followed by a Link State routing exchange.

The SPF algorithm must be recalculated, and if a new best route results, the route must be offered to the RTM for consideration as a new active route. If the RTM selects this route as the active route then it must be installed in the FIB.


IGP Convergence

1/1/1

1/1/2

1/1/3

1/1/4

1/1/1

LSR 1

LER 1

LER 2

MPLS Network

1/1/5

LER 1

LFIB


Egress Label

Egress Interface

next-hop

10.2.1.0/24 - 200 1/1/3 LSR 2

1/1/3

1/1/4

1/1/1

1/1/2

LSR 2

10.2.1.0/24

LER 1 LIB


10.2.1.0/24 LSR 2 200LER 1 RIB


10.2.1.0/24 LSR 2 1/1/3

LER 1 FIB


10.2.1.0/24 LSR 2 1/1/3

LSP

SPF

LER 1 RIB


10.2.1.0/24 LSR 1 1/1/2

10.2.1.0/24 LSR 2 1/1/3

LER 1 FIB


10.2.1.0/24 LSR 1 1/1/2

IGP Session


LDP convergence may then follow. Liberal Label retention does not play a significant role when the link is restored as the labels received from LSR 1 were invalidated when the LDP session failed.

A new LDP session must be established (as discussed earlier in this module) then label bindings must again be exchanged to populate the LIB.

The label from the new best route may now be populated in the LFIB.


LDP Convergence - New Steady State

1/1/1

1/1/2

1/1/3

1/1/4

1/1/1

LSR 1

LER 1

LER 2

MPLS Network

1/1/5

LER 1

LFIB


Egress Label

Egress Interface

next-hop

10.2.1.0/24 - 200 1/1/3 LSR 2

1/1/3

1/1/4

1/1/1

1/1/2

LSR 2

10.2.1.0/24

LER 1 LIB


10.2.1.0/24 LSR 2 200

LSP

LER 1 RIB


10.2.1.0/24 LSR 1 1/1/2

10.2.1.0/24 LSR 2 1/1/3

LER 1 FIB


10.2.1.0/24 LSR 1 1/1/2

LER 1 LIB


10.2.1.0/24 LSR 1 100

10.2.1.0/24 LSR 2 200

LER 1

LFIB


Egress Label

Egress Interface

next-hop

10.2.1.0/24 - 100 1/1/2 LSR 1


The process illustrated in the previous pages was based on a physical network link failure. Situations may arise that result in the physical link remaining up but the logical sessions carried over the physical link being lost. The lost session could be the IGP or LDP.

If this situation occurs, failure detection times will typically increase, as the neighbor is assumed to be valid until the hello mechanism times out the neighbor and declares them down. In many cases, this time is a multiple three to four times the hello frequency.


MPLS Convergence

On a network physical link failure:

MPLS Convergence =Failure Detection Time + IGP Convergence + LDP Convergence

If the physical link remains up but the neighbor is lost, then failure detection times may increase



Section 7 - ECMP for LDP



Equal Cost Multi-Path for LDP tunnels – Section Outline

Overview

Comparisons between ECMP and non ECMP behavior

Hashing Algorithm

Control plane operation

Data plane operation

Implementation


ECMPECMP is a method of distributing traffic to multiple destinations over several equivalent paths. Several routing protocols, including OSPF, BGP, and ISIS explicitly allow ECMP routing. Equal-cost multipath means that if multiple equal-cost routes to the same destination exist, they can be discovered and used to provide load balancing among redundant paths.

Multipath computation produces several paths between source and destination, and one path is selected from this set for the packet routing. Multipath routing allows the traffic load to be divided over different paths (load balancing). To preserve the ordering of packets sent by a single connection with multipath routing, a router applies some hash function to the connection identifier (eg. source and destination IP address) to determine the next hop. The hash function provides the ability to balance the load over several outgoing links, while each connection always selects the same outgoing link.


Overview

Supported for routing protocols such as OSPF, ISIS and BGP

Provides load balancing among equal cost IGP, BGP paths

Supported for LDP in release 4.0 of the Alcatel-Lucent 7x50

Load balancing on LDP based LSPs by having multiple outgoing next-hops for a given FEC/IP prefix

Requires liberal retention mode for label mapping i.e. an LSR will retain all labels received from multiple next-hop peers

Use hashing algorithm to split traffic flows between multiple equal cost LSPs



Without ECMP support • one valid next hop peer and only one label will be inserted into

the forwarding plane (LFIB) for a particular FEC/IP prefix despite multiple next-hops sending multiple labels for the same FEC/IP prefix

• This is done by simply looking at the Routing Table Manager (RTM) for the FEC/IP prefix and finding the first valid LDP next-hop peer

With ECMP support • All valid next hop peers, i.e. those that sent the label for the

same FEC will be installed in the forwarding plane (LFIB)• At ingress LER and transit LSR, multiple labels will be retained in

the Forwarding plane (LFIB) for the same FEC/destination IP prefix

• LER/LSR uses hashing to split flows among multiple labels. Each flow will be hashed to only one Label

Comparisons


The initial hashing is based on the system IP/ingress port for the node receiving the data packet. The hashing algorithm generates a number which will then decide which of the equal cost ( a max of 16) paths is to be taken to send data.


Hashing

Ingress LER hashing• Initial hash is based on system IP and physical ingress port • If an IP packet has a label binding, the source, destination and

source port address is further used in the hashing• For services (VLL,VPLS, VPRN), other parameters such as service

id, source and destination MAC or IP addresses can be used in the hashing

• The egress label and interface is determined and the label is pushed

Transit LSR hashing• Initial hash is based on system IP and physical ingress port• The incoming MPLS packet label is then used in the hashing prior

to getting swapped • If multiple incoming labels are present in the MPLS header, all of

them (a maximum of 5) are used in the hashing algorithm


The egress LER ( LER2), advertises label 200 for the FEC corresponding to its system address prefix of 10.10.10.22/32 and enters a POP entry in its LFIB for that prefix.


Behaviour (Control Plane Operation)

LDP is enabled on all network interfaces

The links have costs shown in diagram

Three labels will be sent out on three interfaces from LER2 for FEC 10.10.10.2/32

1/1/1

1/1/2

1/1/3

1/1/4

LSR 1

LER 1

LER 2

MPLS Network1/1/5

1/1/3

1/1/4

1/1/1

1/1/2

LSR 2 LER 2

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.10.10.2/32 200 - - -

10.10.10.2/32 200 - - -

10.10.10.2/32 200 - - -

10.10.10.2/32

LSR 31/1/7

1/1/61/1/5

1/1/7

10

10

10

10

5

5


If an router is the ingress for the given IP prefix (e.g. LER1), it will populate in its LFIB, the FEC and labels it has received from each of its peers which are possible next-hop routers, with a PUSH operation.

If the router is to behave as a transit for the given IP prefix (e.g. LSR1), it will populate in its LFIB, the FEC and label it has generated for the FEC with a SWAP operation. The ingress label may have to map to multiple egress labels, if there are equal cost paths to the FEC. In this example, LSR1 could map the ingress label it generated for FEC 10.10.10.22/32 to either the label it receives from both LSR3 and LER2 given that they are both next-hops for the two equal cost paths available to reach FEC 10.10.10.22/32.

If an LSR is an egress for the given IP prefix (e.g. LER2), it will populate in its LFIB, the FEC and label it has generated for the FEC with a POP operation. As this is the egress router, there is no egress label.


Behaviour (cont’d)

1/1/1

1/1/2

1/1/3

1/1/4

LSR 1

LER 1

LER 2

MPLS Network1/1/5

1/1/3

1/1/4

1/1/1

1/1/2

LSR 2

LER 2

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf Next-hop

10.10.10.2/32 200 - - -

10.10.10.2/32 200 - - -

10.10.10.2/32 200 - - -

10.10.10.2/32

LSR 31/1/7

1/1/61/1/5

1/1/7

LSR2

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.10.10.2/32 400 200 1/1/2 LER2

LSR3

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.10.10.2/32 300 200 1/1/6 LER2

LSR1, LSR2 and LSR3 will generated ingress labels as per DU modeLSR1

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf Next-hop

10.10.10.2/32 301 200 1/1/4 LER2

10.10.10.2/32 301 300 1/1/5 LSR3

10

10

10

10

5

5



Behaviour (cont’d)

LSR1

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.10.10.2/32 301 200 1/1/4 LER2

10.10.10.2/32 301 300 1/1/5 LSR3

1/1/1

1/1/2

1/1/3

1/1/4

LSR 1

LER 1

LER 2

MPLS Network1/1/5

1/1/3

1/1/4

1/1/1

1/1/2

LSR 2

LER 2

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.10.10.2/32 200 - - -

10.10.10.2/32 200 - - -

10.10.10.2/32 200 - - -

10.10.10.2/32

LSR 31/1/7

1/1/61/1/5

1/1/7

LSR2

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.10.10.2/32 400 200 1/1/2 LER2

LSR3

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.10.10.2/32 300 200 1/1/6 LER2

LER 1

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.10.10.2/32 - 301 1/1/2 LSR1

10.10.10.2/32 - 400 1/1/3 LSR2

All labels are retained in the LFIB on all nodes

10

10

10

10

5

5


1. Data packet arrives at 1/1/1 on LER1

2. Hashing algorithm (iLER based hashing) is used at this point to determine which of the egress labels will be pushed on top of the data packet

3. If 301 is pushed and the data travels to LSR1via 1/1/2, another hashing function (transit LSR hashing function) will be used to determine which will be the new pushed label (200,300)

4. If 300 is pushed, data then travels to LSR3 via 1/1/5 and since only one label is available, no hashing will be performed here.

5. At the eLER for the FEC, the appropriate label will be popped



LSR1

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.10.10.2/32 301 200 1/1/4 LER2

10.10.10.2/32 301 300 1/1/5 LSR3

1/1/1

1/1/2

1/1/3

1/1/4

LSR 1

LER 1

LER 2

MPLS Network 1/1/5

1/1/3

1/1/4

1/1/1

1/1/2

LSR 2

LER 2

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.10.10.2/32 200 - - -

10.10.10.2/32 200 - - -

10.10.10.2/32 200 - - -

10.10.10.2/32

LSR 31/1/7

1/1/61/1/5

1/1/7

LSR2

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.2.1.0/24 400 200 1/1/4 LER2

LSR3

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.10.10.2/32 300 200 1/1/6 LER2

LER 1

LFIB

Prefix Ing. Label

Egr. Label

Egr. Intf

Next-hop

10.10.10.2/32 - 301 1/1/2 LSR1

10.10.10.2/32 - 400 1/1/3 LSR2

Apply iLER based hashing. Push

label 301

Apply LSR based hashing. Swap label

301 with 300No ECMP, swap

label 300 with 200

10

10

10

10

55



Configuring ECMP

Configured on a global perspective for the IGP (OSPF, ISIS) protocolsA:PE1>config>router# ecmp

- ecmp <max-ecmp-routes>

- no ecmp

<max-ecmp-routes> : [0..16]

A maximum of 16 ECMP routes can be configured



Module Summary

Label signaling and distribution protocols define a set of procedures and messages by which one LSR informs another of the label bindings it has made

The MPLS architecture allows for manual and dynamic methods of label signaling and distribution

Labels are assigned to packets as they enter the network, get swapped as the packets traverse the network, and are then removed as the packets exit the MPLS portion of the network

Manual LSPs require the labels to be statically configured and does not require a label signaling protocol

Dynamically signaled LSPs require a specific protocol to be configured in order to establish the LSPs

Manual LSP creation requires static label mappings and label actions of pop, swap or push to be defined at each hop




LDP or RSVP-TE may be used as dynamic signaling protocols - each offers multiple options for LSP establishment

LDP signaling informs adjacent nodes of the labels to be used toforward traffic between them

LDP establishes tunnel LSPs with directly attached neighbors or Targeted LDP sessions between non-directly connected peers

There are four types of LDP messages: Discovery, Session, Advertisement and Notification messages

Discovery messages are periodically multicast using LDP port 646over UDP to the 'all routers on this subnet' address

LDP Session, Advertisement and Notification messages use LDP port 646 over TCP




LDP session establishment is a two step process: Transport connection establishment and Session initialization

An LDP identifier is a six octet quantity used to uniquely identify an LSR's label space

An LSR will originate a label for only its system address by default

The Alcatel-Lucent LDP default settings are Downstream Unsolicited label distribution mode, Liberal label retention mode and Ordered Control mode

Each LSR will propagate labels for each FEC for which it is a possible next-hop to its LDP peers

A FEC identifies the set of IP packets which map to an LSP

ECMP LDP enables load balancing of traffic over multiple equal cost path LSPs



Learning Assessment

1. Label Switching is used in the ____________ plane for forwardingpackets from source to destination in an MPLS network.

2. Labels are ________ onto packets as they enter the network, are _________as the packets traverse the network, and are then _________as the packets exit the MPLS portion of the network

3. Transport tunnels or LSPs are established using a signaling protocol such as ________________ or _____________.

4. Dynamic label signaling protocols allows labels to be assigned from the _____________ router to the _______________router.

5. Provide two reasons why an LSR may withdraw a label advertisement.

6. What type of LDP session is formed between two routers sharing acommon data link?



Learning Assessment

7. Static LSPs require that ______ routers that the LSP traverses be configured manually with labels.

8. What type of LSP is supported by LDP?

9. List and define the 4 types of LDP messages.

10. What is the port number used for UDP based LDP messages?

11. What is the port number used for TCP based LDP messages?

12. How is the targeted HELLO packet different from the normal HELLO packet?

13. An LDP identifier is a ______ byte quantity used to identify an LSR's label space.

14. How do you configure Static LSPs?


> Learning Assessment Answers

1. Label Switching is used in the forwarding (data) plane for forwarding packets from source to destination in an MPLS network.

2. Labels are PUSHed onto packets as they enter the network, are SWAPped as the packets traverse the network, and are then POPped as the packets exit the MPLS portion of the network.

3. Transport tunnels or LSPs are established using a label signaling protocol such as LDP or RSVP-TE.

4. Dynamic label signaling protocols allow labels to be assigned from the egress router to the ingress router.

5. An MTU change or issuing the command to clear the labels will cause the labels to be withdrawn.

6. Two routers sharing a common data link form a session referred to as a Link Adjacency.

7. Static LSPs require that all routers that the LSP traverses be configured manually with labels.

8. IGP based dynamic LSPs are supported by LDP.






9. List and define the 4 types of LDP messages.Discovery messages (UDP based) Announces and maintains the presence of an LSR in a networkSession messages (TCP based) Establishes, maintains, and terminates sessions between LDP peersAdvertisement messages (TCP based) Creates, changes, and deletes label mappings for FECsNotification messages (TCP based) Provide advisory information and signals error information

10. Well known port number 646 is used for UDP based LDP messages.11. Well known port number 646 is used for TCP based LDP messages.12. How is the targeted HELLO packet is different from the normal HELLO packet?

A Targeted HELLO is sent to a specific unicast address rather than to the "all routers" group multicast address.

13. An LDP identifier is a six byte quantity used to identify an LSR label space.14. A static LSP is configured manually on every node along the path, where the next-hop IP address and the outgoing

label are explicitly specified.




Module 4 – page 1Alcatel-Lucent Multi-protocol Label Switching v1.3


Module 4 — Implementing LDP

Module 4 – page 2Alcatel-Lucent Multi-protocol Label Switching v1.3 2







This module discusses the configuration and verification of LDP and related topics. This module also presents the configuration of Static LSPs.


Module Objectives

Configure verify and troubleshoot MPLS and LDP including• Neighbor establishment and session maintenance• Message types and Transport protocols • Methods of neighbor discovery• Label signaling operation



Implementing LDP

Section 1 - Provider Core MPLS Pre-Configuration



Provider Core MPLS Pre-Configuration - Section Outline

Configure IOMs and MDAs

Configure System Interfaces

Configure Network Interfaces

Configure the provider core IGP protocol

Verify the network


The flowchart shown here represents a suggested flow for enabling and configuring the LDP protocol on the Alcatel-Lucent 7x50.


Configure a static peer

Configure authentication

Configure TTL security

LDP Configuration Process Flowchart

Start

Configure Targeted LDP

Test and Verify

Configure LDP

Configure Core Network ParametersConfigure ports and interfacesConfigure IP addressingConfigure IGP routing

Enable LDP

Configure Policy

Configure Optional parameters



Core Network Verification

Verify the following configuration prior to enabling LDP• All required physical ports are configured and enabled• The system interface has been assigned an appropriate IP

address• Each network interface has a port associated to it and an IP

address assigned



Initial Router Configuration Requirements

Configure IOMs and MDAs• Configure the IOM• Configure the MDA• Enable the required ports

System interfaces• Configure the system interface of all routers

Configure network interfaces• Name the network interface• Assign a port to the interface• Assign an IP address to the interface

Choose an IGP protocol• Define the IGP protocol instance• Configure the IGP on the system interface and each network interface


The ‘show port’ command displays the routers physical ports associated to any IOMs installed and configured on the router.


show port

Displays the physical ports of the router and their operational status

A:P1# show port 1/1

==============================================================================

Ports on Slot 1

==============================================================================

Port Admin Link Port Cfg Oper LAG/ Port Port Port SFP/XFP/

Id State State MTU MTU Bndl Mode Encp Type MDIMDX

------------------------------------------------------------------------------

1/1/1 Up Yes Up 9212 9212 - netw null gige GIGE SX



1/1/4 Down No Down 9212 9212 - netw null gige





A:P1# show port 1/1

==============================================================================

Ports on Slot 1

==============================================================================

Port Admin Link Port Cfg Oper LAG/ Port Port Port SFP/XFP/

Id State State MTU MTU Bndl Mode Encp Type MDIMDX

------------------------------------------------------------------------------










The ‘show router interface’ command displays the router IP interface table sorted by interface index. The output above shows that the system interface and the network interfaces have IP addresses assigned and are operationally up.

ip-address — Only displays the interface information associated with the specified IP address.

ip-int-name — Only displays the interface information associated with the specified IP interface name.

detail — Displays detailed IP interface information.

summary — Displays summary IP interface information for the router.

exclude-services — Displays IP interface information, excluding IP interfaces configured for customer services. Only core network IP interfaces are displayed.


show router interface

Displays the system and network interfaces and their operational status

A:P1# show router interface

===============================================================================Interface Table (Router: Base)===============================================================================Interface-Name Type IP-Address Adm Opr Mode -------------------------------------------------------------------------------P1-P2 Pri 10.1.2.1/24 Up Up Network P1-P3 Pri 10.1.3.1/24 Up Up Network P1-PE1 Pri 10.16.1.1/24 Up Up Network system Pri 10.10.10.61/32 Up Up Network -------------------------------------------------------------------------------Interfaces : 4===============================================================================A:P1#

A:P1# show router interface

===============================================================================Interface Table (Router: Base)===============================================================================Interface-Name Type IP-Address Adm Opr Mode -------------------------------------------------------------------------------P1-P2 Pri 10.1.2.1/24 Up Up Network P1-P3 Pri 10.1.3.1/24 Up Up Network P1-PE1 Pri 10.16.1.1/24 Up Up Network system Pri 10.10.10.61/32 Up Up Network -------------------------------------------------------------------------------Interfaces : 4===============================================================================A:P1#


The ‘show router status’ command displays the status of the router base instance and any configured routing and signaling protocols of the device.

Ensure that the router operational status ‘Up’. The output also shows that no routing or signaling protocol has yet been configured.


show router status

A:P1# show router status

Router Status (Router: Base)

================================================================

Admin State Oper State

----------------------------------------------------------------

Router Up Up

OSPF Not configured Not configured

RIP Not configured Not configured

ISIS Not configured Not configured

MPLS Not configured Not configured

RSVP Not configured Not configured

LDP Not configured Not configured

BGP Not configured Not configured

IGMP Not configured Not configured

PIM Not configured Not configured

- Output omitted


Router Status (Router: Base)

================================================================

Admin State Oper State

----------------------------------------------------------------

Router Up Up

OSPF Not configured Not configured

RIP Not configured Not configured

ISIS Not configured Not configured

MPLS Not configured Not configured

RSVP Not configured Not configured

LDP Not configured Not configured

BGP Not configured Not configured

IGMP Not configured Not configured

PIM Not configured Not configured

- Output omitted


All provider core facing interfaces should be configured and enabled in the IGP protocol in use. Typically, this will be a Link State protocol such as OSPF or IS-IS. All required network prefixes should be present before continuing with MPLS related configuration.


Enabling the Provider Core IGP

Select and configure the provider core IGP• Ensure all core routers have a complete routing table

— All core router system addresses

— All physical networks

Provider Network

P1

PE-2

IGP Routing

P 3

P 2P 1

PE-3


The example shown above is a sample configuration for the enabling of OSPF in network.


Enabling the Provider Core IGP

A:P1# configure router

A:P1>config>router# ospf

A:P1>config>router>ospf# area 0.0.0.0

A:P1>config>router>ospf>area# interface "P1-PE1"

A:P1>config>router>ospf>area>if# exit

A:P1>config>router>ospf>area# interface "P1-P2"

A:P1>config>router>ospf>area>if# exitA:P1>config>router>ospf>area# interface "P1-P3"A:P1>config>router>ospf>area>if# exit

A:P1>config>router>ospf>area# interface system

A:P1>config>router>ospf>area>if# exit all

A:P1#


A:P1>config>router# ospf

A:P1>config>router>ospf# area 0.0.0.0

A:P1>config>router>ospf>area# interface "P1-PE1"

A:P1>config>router>ospf>area>if# exit

A:P1>config>router>ospf>area# interface "P1-P2"

A:P1>config>router>ospf>area>if# exitA:P1>config>router>ospf>area# interface "P1-P3"A:P1>config>router>ospf>area>if# exit

A:P1>config>router>ospf>area# interface system

A:P1>config>router>ospf>area>if# exit all

A:P1#

The provider core IGP should be configured on• All interfaces of the P routers• All core facing interfaces of the PE routers


The ‘show router route-table’ command displays the active routes in the routing table. The command output shows routes learned via locally attached interfaces and via the configured IGP, in this case the OSPF routing protocol.

Command line options include the following:

ip-address[/mask] — Displays routes only matching the specified ip-address and optional mask.

longer — Displays routes matching the ip-prefix/mask and routes with longer masks.

best — Displays the best route matching the ip-prefix/mask masks.

protocol protocol — Displays routes learned from the specified protocol.

Values bgp, bgp-vpn, isis, local, ospf, rip, static, aggregate

summary — Displays a route table summary information.

Dest Address The route destination address and mask.

Next Hop The next hop IP address for the route destination.

Type Local — The route is a local route.

Remote — The route is a remote route.

Protocol The protocol through which the route was learned.

Age The route age in seconds for the route.

Metric The route metric value for the route.

Pref The route preference value for the route.

No. of Routes: The number of routes displayed in the list.


show router route-table

A:P1# show router route-table ===============================================================================Route Table (Router: Base)===============================================================================Dest Address Next Hop Type Proto Age Metric Pref-------------------------------------------------------------------------------10.1.2.0/24 P1-P2 Local Local 01d10h07m 0 0 10.1.3.0/24 P1-P3 Local Local 01d10h07m 0 0 10.2.3.0/24 10.1.2.2 Remote OSPF 01d10h06m 200 10 10.10.10.60/32 10.1.3.3 Remote OSPF 01d09h50m 201 10 10.10.10.61/32 system Local Local 01d10h07m 0 0 10.10.10.62/32 10.1.2.2 Remote OSPF 01d10h06m 101 10 10.10.10.66/32 10.1.3.3 Remote OSPF 01d10h06m 101 10 10.10.10.67/32 10.16.1.2 Remote OSPF 01d09h47m 101 10 10.10.10.156/32 10.1.2.2 Remote OSPF 01d09h48m 201 10 10.16.1.0/24 P1-PE1 Local Local 01d10h07m 0 0 10.32.1.0/24 10.1.2.2 Remote OSPF 01d09h58m 200 10 10.48.1.0/24 10.1.3.3 Remote OSPF 01d09h53m 200 10

A:P1# show router route-table ===============================================================================Route Table (Router: Base)===============================================================================Dest Address Next Hop Type Proto Age Metric Pref-------------------------------------------------------------------------------10.1.2.0/24 P1-P2 Local Local 01d10h07m 0 0 10.1.3.0/24 P1-P3 Local Local 01d10h07m 0 0 10.2.3.0/24 10.1.2.2 Remote OSPF 01d10h06m 200 10 10.10.10.60/32 10.1.3.3 Remote OSPF 01d09h50m 201 10 10.10.10.61/32 system Local Local 01d10h07m 0 0 10.10.10.62/32 10.1.2.2 Remote OSPF 01d10h06m 101 10 10.10.10.66/32 10.1.3.3 Remote OSPF 01d10h06m 101 10 10.10.10.67/32 10.16.1.2 Remote OSPF 01d09h47m 101 10 10.10.10.156/32 10.1.2.2 Remote OSPF 01d09h48m 201 10 10.16.1.0/24 P1-PE1 Local Local 01d10h07m 0 0 10.32.1.0/24 10.1.2.2 Remote OSPF 01d09h58m 200 10 10.48.1.0/24 10.1.3.3 Remote OSPF 01d09h53m 200 10


The ‘show router status’ is used to verify the active protocols in use on the router. OSPF is enabled for the purposes of provider core IGP routing.


show router status

A:P1# show router status ================================================================Router Status (Router: Base)================================================================

Admin State Oper State ----------------------------------------------------------------Router Up UpOSPF Up UpRIP Not configured Not configured ISIS Not configured Not configured MPLS Not configured Not configuredRSVP Not configured Not configuredLDP Not configured Not configuredBGP Not configured Not configuredIGMP Not configured Not configured PIM Not configured Not configured

A:P1# show router status ================================================================Router Status (Router: Base)================================================================

Admin State Oper State ----------------------------------------------------------------Router Up UpOSPF Up UpRIP Not configured Not configured ISIS Not configured Not configured MPLS Not configured Not configuredRSVP Not configured Not configuredLDP Not configured Not configuredBGP Not configured Not configuredIGMP Not configured Not configured PIM Not configured Not configured


To ensure the IGP is operating as intended, and to help minimize future issues when enabling MPLS configurations, it is recommended to verify that optimal routing exists across the provider core.

Prior to enabling LDP, complete connectivity testing using tools such as ping and traceroute is suggested, as this is the basis for all future configurations.


Ping and Traceroute

Verify that optimal routing exists across the provider core

A:P1# ping 10.10.10.66

PING 10.10.10.66: 56 data bytes

64 bytes from 10.10.10.66: icmp_seq=0 ttl=64 time<10ms.





---- 10.10.10.66 PING Statistics ----

5 packets transmitted, 5 packets received, 0.00% packet loss

round-trip min < 10ms, avg < 10ms, max < 10ms, stddev < 10ms

A:P1# traceroute 10.10.10.156traceroute to 10.10.10.156, 30 hops max, 40 byte packets1 10.16.1.1 10.0 ms <10 ms <10 ms2 10.1.2.2 <10 ms 10.0 ms <10 ms3 10.10.10.156 <10 ms <10 ms <10 ms


Implementing LDP

Section 2 - LDP Configuration



LDP Configuration - Section Outline

Enable LDP

Configure optional parameters

Verify the network




Configure a static peer

Configure authentication

Configure TTL security


Start


Test and Verify

Configure LDP

Configure Core Network ParametersConfigure ports and interfaces

Configure IP addressing

Configure IGP routing

Enable LDPConfigure PolicyConfigure Optional parameters


Context: config>router

Syntax: [no] ldp

Default: This command creates the context to configure an LDP protocol instance. When an LDP instance is created, the protocol is enabled (in the no shutdown state). To suspend the LDP protocol, use the shutdown command. Configuration parameters are not affected.

The no form of the command deletes the LDP protocol instance, removing all associated configuration parameters. The LDP instance must first be disabled with the shutdown command before being deleted.

Default: none (LDP must be explicitly enabled)

When the 7750 SR OS implementation of LDP is instantiated, the protocol is in the no shutdown state. In addition, targeted sessions are then enabled. The default parameters for LDP are set to the documented values for targeted sessions in draft-ietf-mpls-ldp-mib-09.txt.

LDP must be enabled in order for signaling to be used to obtain the ingress and egress labels in frames transmitted and received on the service distribution path (SDP). When signaling is off, labels must be manually configured when the SDP is bound to a service.

LDP signaling works with the MPLS label manager to manage the relationships between labels and the corresponding FEC. Note that the 7750 SR OS implementation of LDP supports only service-based FECs. For service-based FECs, LDP works in tandem with the Service Manager to identify the virtual leased lines (VLLs) and Virtual Private LAN Services (VPLSs) to signal.Note: “Targeted-session” is the CLI syntax for TLDP


Enabling LDP

Only a single command is required to enable LDP on the global level

Targeted session is enabled by default when LDP is enabled

A:P1# configure routerA:P1>config>router# ldpA:P1>config>router>ldp$ info----------------------------------------------

interface-parametersexittargeted-sessionexit

----------------------------------------------A:P1>config>router>ldp$

A:P1# configure routerA:P1>config>router# ldpA:P1>config>router>ldp$ info----------------------------------------------

interface-parametersexittargeted-sessionexit

----------------------------------------------A:P1>config>router>ldp$


The ‘show router status’ command is used to verify the active protocols in use on the router. LDP is enabled to support label signaling in the provider core, while OSPF is enabled for provider core routing. ISIS may be used in place of OSPF if desired.


show router status


================================================================Router Status (Router: Base)================================================================

Admin State Oper State ----------------------------------------------------------------Router Up UpOSPF Up UpRIP Not configured Not configured ISIS Not configured Not configured MPLS Not configured Not configured RSVP Not configured Not configured LDP Up UpBGP Not configured Not configured IGMP Not configured Not configured PIM Not configured Not configured



Admin State Oper State ----------------------------------------------------------------Router Up UpOSPF Up UpRIP Not configured Not configured ISIS Not configured Not configured MPLS Not configured Not configured RSVP Not configured Not configured LDP Up UpBGP Not configured Not configured IGMP Not configured Not configured PIM Not configured Not configured


All provider core facing interfaces must have LDP enabled.

LDP must be enabled on each router’s interface, to allow direct LDP sessions to be established between adjacent routers. Note that LDP is not enabled on the router’s system interface.

Context: config>router>ldp

Syntax: interface-parameters

Description: This command enables the context to configure LDP interfaces and parameters applied to LDP interfaces.

Context: config>router>ldp>if-params

Syntax: [no] interface ip-int-name

Description: This command enables LDP on the specified IP interface.

The no form of the command deletes the LDP interface and all configuration information associated with the LDP interface. The LDP interface must be disabled using the shutdown command before it can be deleted.

Parameters: ip-int-name - The name of an existing interface.


LDP Interfaces

LDP is enabled on all interfaces in the provider core network

Provider Network

PE1

PE2

P 3

P 2P 1

PE-3


A:P1>config>router# ldp

A:P1>config>router>ldp# interface-parametersA:P1>config>router>ldp>if-params$ interface "P1-PE1"A:P1>config>router>ldp>if-params>if$ exitA:P1>config>router>ldp>if-params$ interface "P1-P2"A:P1>config>router>ldp>if-params>if$ exitA:P1>config>router>ldp>if-params$ interface "P1-P3"A:P1>config>router>ldp>if-params>if$ exit all



A:P1>config>router>ldp# interface-parametersA:P1>config>router>ldp>if-params$ interface "P1-PE1"A:P1>config>router>ldp>if-params>if$ exitA:P1>config>router>ldp>if-params$ interface "P1-P2"A:P1>config>router>ldp>if-params>if$ exitA:P1>config>router>ldp>if-params$ interface "P1-P3"A:P1>config>router>ldp>if-params>if$ exit all


Context: config>router>ldp>if-paramsconfig>router>ldp>if-params>if

Syntax: transport-address {interface | system}no transport-address

Description: This command configures the transport address to be used when setting up the LDP TCP sessions. The transport address can be configured as interface or system. The transport address can be configured globally (applies to all LDP interfaces) or per interface. The most specific value is used. With the transport-address command, you can set up the LDP interface to the connection which can be set to the interface address or the system address. However, there can be an issue of which address to use when there are parallel adjacencies. This situation can not only happen with parallel link, it could be a link and a targeted adjacency since targeted adjacencies request the session to be set up only to the system IP address.

Note that the transport-address value should not be interface if multiple interfaces exist between two LDP neighbors. Depending on the first adjacency to be formed, the TCP endpoint is chosen. In other words, if one LDP interface is set up as transport-address interface and another for transport-address system, then, depending on which adjacency was set up first, the TCP endpoint addresses are determined. After that, because the HELLO contains the LSR ID, the LDP session can be checked to verify that it is set up and then match the adjacency to the session.

The no form of the command, at the global level, sets the transport address to the default value.The no form of the command, at the interface level, sets the transport address to the value defined under the global level.

Default: system - The system IP address is used.

Parameters: interface - The IP interface address is used to set up the LDP session between neighbors. The transport address interface cannot be used if multiple interfaces exist between two neighbors, since only one LDP session is set up between two neighbors.

system - The system IP address is used to set up the LDP session between neighbors.





A:P1>config>router>ldp# interface-parameters

A:P1>config>router>ldp>if-params# transport-address systemA:P1>config>router>ldp>if-params# interface "P1-PE1"

A:P1>config>router>ldp>if-params>if$ transport-address interface

A:P1>config>router>ldp>if-params>if$ exit all

A:P1#




A:P1>config>router>ldp>if-params# transport-address systemA:P1>config>router>ldp>if-params# interface "P1-PE1"

A:P1>config>router>ldp>if-params>if$ transport-address interface

A:P1>config>router>ldp>if-params>if$ exit all

A:P1#

The system interface is the default transport address

The system interface should always be used if there are multiple paths between peers

Changing the transport address may be done for interoperability purposes


Context config>router>ldp>if-paramsconfig>router>ldp>if-params>ifconfig>router>ldp>targ-sessionconfig>router>ldp>targ-session>peer

Syntax hello timeout factorno hello

Description: This command configures the time interval to wait before declaring a neighbor down. The factor parameter derives the HELLO interval.

Hold time is local to the system and sent in the HELLO messages to the neighbor. Hold time cannot be less than three times the HELLO interval. The hold time can be configured globally (applies to all LDP interfaces) or per interface. The most specific value is used. When LDP session is being set up, the hold-down time is negotiated to the lower of the two peers. Once a operational value is agreed upon, the HELLO factor is used to derive the value of the HELLO interval.

The no form of the command at the interface-parameters and targeted-session level sets the hello timeout and the hello factor to the default values.

The no form of the command, at the interface level, will set the hello timeout and the hello factor to the value defined under the interface-parameters level.

The no form of the command, at the peer level, will set the hello timeout and the hello factor to the value defined under the targeted-session level.

Parameters: timeout — Configures the time interval, in seconds, that LDP waits before a neighbor down.Values 1 — 65535

factor — Specifies the number of keepalive messages that should be sent on an idle LDP session in the HELLO timeout interval.Values 1 — 255


LDP Hello Timer

Changes the timers for sending HELLO messages to a peer• Both the timeout and the factor are specified• Command is optional

Context Timeout (sec) Factorconfig>router>ldp>if-params# 15 3

config>router>ldp>targ-session# 45 3

config>router>ldp>if-params>if# Inherits value from interface parameters context

config>router>ldp>targ-session>peer# Inherits value from targeted session context




A:P1>config>router>ldp>if-params# hello 10 3

A:P1>config>router>ldp>if-params# exit all

A:P1#




A:P1>config>router>ldp>if-params# hello 10 3


A:P1#


Context: config>router>ldp>if-paramsconfig>router>ldp>if-params>ifconfig>router>ldp>targ-sessionconfig>router>ldp>targ-session>peer

Syntax: keepalive timeout factorno keepalive

Description: This command configures the time interval, in seconds, that LDP waits before tearing down the session. The factor parameter derives the keepalive interval. If no LDP messages are exchanged for the configured time interval, the LDP session is torn down. Keepalive timeout is usually three times the keepalive interval. To maintain the session permanently, regardless of the activity, set the value to zero. When LDP session is being set up, the keepalive timeout is negotiated to the lower of the two peers. Once a operational value is agreed upon, the keepalive factor is used to derive the value of the keepalive interval.

The no form of the command at the interface-parameters and targeted-session levels sets the keepalive timeout and the keepalive factor to the default value. The no form of the command, at the interface level, sets the keepalivetimeout and the keepalive factor to the value defined under the interface-parameters level. The no form of the command, at the peer level, will set the keepalive timeout and the keepalive factor to the value defined under the targeted-session level.

Parameters: timeout - Configures the time interval, expressed in seconds, that LDP waits before tearing down the session.Values 1 — 65535

factor - Specifies the number of keepalive messages, expressed as a decimal integer, that should be sent on an idle LDP session in the keepalive timeout interval.Values 1 — 255


LDP Keepalive Timer

This command configures the time interval that LDP waits before tearing down the session• Command is optional

Context Timeout (sec) Factorconfig>router>ldp>if-params# 30 3

config>router>ldp>targ-session# 40 4

config>router>ldp>if-params>if# Inherits value from interface parameters context

config>router>ldp>targ-session>peer# Inherits value from targeted session context




A:P1>config>router>ldp>if-params# keepalive 45 3


A:P1#




A:P1>config>router>ldp>if-params# keepalive 45 3


A:P1#


The LDP instance may be administratively disabled if required. This is shown here for example purposes only.


Disabling LDP

The LDP instance may be administratively disabled if required

A:P1# configure router A:P1>config>router# ldpA:P1>config>router>ldp# shutdownA:P1>config>router>ldp# info----------------------------------------------

interface-parametersexittargeted-sessionexitshutdown

----------------------------------------------A:P1>config>router>ldp# no shutdown

A:P1# configure router A:P1>config>router# ldpA:P1>config>router>ldp# shutdownA:P1>config>router>ldp# info----------------------------------------------

interface-parametersexittargeted-sessionexitshutdown

----------------------------------------------A:P1>config>router>ldp# no shutdown


The targeted LDP sessions may be administratively disabled if required. The LDP instance must be enabled in order to enable the targeted LDP sessions.

Targeted LDP (T-LDP) will be discussed in detail later in Module 4 of this course.


Disabling Targeted LDP

Targeted sessions may be administratively disabled if required

A:P1# configure routerA:P1>config>router# ldpA:P1>config>router>ldp# targeted-session A:P1>config>router>ldp>targ-session# disable-targeted-session

A:P1# configure routerA:P1>config>router# ldpA:P1>config>router>ldp# targeted-session A:P1>config>router>ldp>targ-session# disable-targeted-session


Implementing LDP

Section 3 - LDP Verification



LDP Verification - Section Outline

Verify LDP• Neighbors• Sessions• Label Exchange• LSPs


CLI command structure for verifying the LDP protocol on the Alcatel-Lucent 7x50.


LDP Verification CLI Structure

The commands to verify LDP are located under the show>router>ldp context

A:P1# show routerA:P1>show>router# ldpA:P1>show>router>ldp# ?

bindings - Display LDP bindings informationdiscovery - Display LDP discovery informationfec-originate - Display LDP static prefix FECsinterface - Display LDP interface informationparameters - Display LDP configured and operation parameterspeer - Display LDP targeted peer informationpeer-parameters - Display LDP peer informationsession - Display LDP session informationstatus - Display LDP operational information

A:P1>show>router>ldp#


The output of the various show commands in this section are based on the above topology.


LDP Verification Reference Topology

Provider Network

PE110.10.10.67

PE210.10.10.156

P310.10.10.66

P210.10.10.62

P110.10.10.61

PE310.10.10.60

1/1/2 1/1/2

1/1/3

1/1/1

1/2/2

1/2/3

1/2/1

1/1/3

1/1/1

1/2/11/2/1


The 'show router ldp status' command displays overall LDP parameters including the administrative and operational state of the protocol, the number of active and inactive neighbor relationships and protocol counter and error statistics.


A:P1# show router ldp status===============================================================================

LDP Status for LSR ID 10.10.10.61===============================================================================

Admin State : Up Oper State : UpCreated at : 12/26/2006 16:26:11 Up Time : 0d 00:02:09

Oper Down Reason : n/a Oper Down Events : 0 Last Change : 12/26/2006 16:26:11 Tunn Down Damp Time : 3 sec

Import Policies : None Export Policies : None Active Adjacencies : 3 Active Sessions : 3 Active Interfaces : 3 Inactive Interfaces : 0

Active Peers : 0 Inactive Peers : 0 Addr FECs Sent : 15 Addr FECs Recv : 11

Serv FECs Sent : 0 Serv FECs Recv : 0 Attempted Sessions : 0

No Hello Err : 0 Param Adv Err : 0 Max PDU Err : 0 Label Range Err : 0

Bad LDP Id Err : 0 Bad PDU Len Err : 0 Bad Mesg Len Err : 0 Bad TLV Len Err : 0

Malformed TLV Err : 0 Keepalive Expired Err: 0 Shutdown Notif Sent: 0 Shutdown Notif Recv : 0





Import Policies : None Export Policies : None Active Adjacencies : 3 Active Sessions : 3 Active Interfaces : 3 Inactive Interfaces : 0

Active Peers : 0 Inactive Peers : 0 Addr FECs Sent : 15 Addr FECs Recv : 11

Serv FECs Sent : 0 Serv FECs Recv : 0 Attempted Sessions : 0




Verifying LDP Status - show router ldp status


The 'show router ldp parameters' command displays a summary of LDP parameters, including the default LDP settings of Downstream Unsolicited label distribution, liberal label retention and Ordered Control Mode.


A:P1# show router ldp parameters ===============================================================================LDP Parameters (LSR ID 10.10.10.61)===============================================================================-------------------------------------------------------------------------------Interface Parameters-------------------------------------------------------------------------------Keepalive Timeout : 30 sec Keepalive Factor : 3 Hold Time : 15 sec Hello Factor : 3Propagate Policy : system Transport Address: system Deaggregate FECs : False Route Preference : 9Label Distribution : downstreamUnsolicited Label Retention : liberalControl Mode : ordered Loop Detection : none -------------------------------------------------------------------------------Targeted Session Parameters-------------------------------------------------------------------------------Keepalive Timeout : 40 sec Keepalive Factor : 4 Hold Time : 45 sec Hello Factor : 3Passive Mode : False Targeted Sessions: Disabled

A:P1# show router ldp parameters ===============================================================================LDP Parameters (LSR ID 10.10.10.61)===============================================================================-------------------------------------------------------------------------------Interface Parameters-------------------------------------------------------------------------------Keepalive Timeout : 30 sec Keepalive Factor : 3 Hold Time : 15 sec Hello Factor : 3Propagate Policy : system Transport Address: system Deaggregate FECs : False Route Preference : 9Label Distribution : downstreamUnsolicited Label Retention : liberalControl Mode : ordered Loop Detection : none -------------------------------------------------------------------------------Targeted Session Parameters-------------------------------------------------------------------------------Keepalive Timeout : 40 sec Keepalive Factor : 4 Hold Time : 45 sec Hello Factor : 3Passive Mode : False Targeted Sessions: Disabled

Verify Default LDP Parameters – show router ldp parameters


The 'show router ldp interface' command displays the interfaces on which LDP has been configured and their state.


A:P1# show router ldp interface

===============================================================================LDP Interfaces===============================================================================Interface Adm Opr Hello Hold KA KA Transport

Factor Time Factor Timeout Address -------------------------------------------------------------------------------P1-P2 Up Up 3 15 3 30 System P1-P3 Up Up 3 15 3 30 System P1-PE1 Up Up 3 15 3 30 System -------------------------------------------------------------------------------No. of Interfaces: 3===============================================================================A:P1#

A:P1# show router ldp interface

===============================================================================LDP Interfaces===============================================================================Interface Adm Opr Hello Hold KA KA Transport

Factor Time Factor Timeout Address -------------------------------------------------------------------------------P1-P2 Up Up 3 15 3 30 System P1-P3 Up Up 3 15 3 30 System P1-PE1 Up Up 3 15 3 30 System -------------------------------------------------------------------------------No. of Interfaces: 3===============================================================================A:P1#

Verifies that LDP has been successfully configured on the required interfaces

show router ldp interface


The 'show router ldp discovery' command displays the status of the Hello adjacency discovery and whether any neighbors have been discovered on those interfaces.

As shown above, the local router has established Hello adjacencies with three LDP peers.


A:P1# show router ldp discovery

===============================================================================LDP Hello Adjacencies===============================================================================Interface Name Local Addr Peer Addr AdjType State -------------------------------------------------------------------------------P1-P2 10.10.10.61 10.10.10.62 Link EstabP1-P3 10.10.10.61 10.10.10.66 Link EstabP1-PE1 10.10.10.61 10.10.10.67 Link Estab-------------------------------------------------------------------------------No. of Hello Adjacencies: 3===============================================================================A:P1#

A:P1# show router ldp discovery

===============================================================================LDP Hello Adjacencies===============================================================================Interface Name Local Addr Peer Addr AdjType State -------------------------------------------------------------------------------P1-P2 10.10.10.61 10.10.10.62 Link EstabP1-P3 10.10.10.61 10.10.10.66 Link EstabP1-PE1 10.10.10.61 10.10.10.67 Link Estab-------------------------------------------------------------------------------No. of Hello Adjacencies: 3===============================================================================A:P1#

Verifies the LDP neighbors Hello adjacency state

show router ldp discovery


The 'show router ldp session' command displays the LDP Identifier, the state of the LDP session with each peer and session related statistics.

A link adjacency type indicates an interface (or direct) based LDP neighbor relationship.


A:P1# show router ldp session

===============================================================================LDP Sessions===============================================================================Peer LDP Id Adj Type State Mesg Sent Mesg Recv Up Time -------------------------------------------------------------------------------10.10.10.62:0 Link Established 254 255 0d 00:11:24 10.10.10.66:0 Link Established 250 251 0d 00:11:11 10.10.10.67:0 Link Established 257 256 0d 00:11:35 -------------------------------------------------------------------------------No. of Sessions: 3===============================================================================A:P1#



Verifies the LDP session state

show router ldp session


The 'show router ldp session' command with an explicit peer specified displays detailed information relating to that peer including the type of neighbor relationship formed.

Link Adjacency indicates interface (or direct) based LDP.


A:P1# show router ldp session 10.10.10.62:0 detail ===============================================================================LDP Sessions (Detail)===============================================================================-------------------------------------------------------------------------------Session with Peer 10.10.10.62:0-------------------------------------------------------------------------------Adjacency Type : Link State : EstablishedUp Time : 0d 00:12:42 Max PDU Length : 4096 KA/Hold Time Remaining: 29Link Adjacencies : 1 Targeted Adjacencies : 0Local Address : 10.10.10.61 Peer Address : 10.10.10.62 Local TCP Port : 646 Peer TCP Port : 49581 Local KA Timeout : 30 Peer KA Timeout : 30Mesg Sent : 283 Mesg Recv : 284 FECs Sent : 5 FECs Recv : 5 ===============================================================================A:P1#

A:P1# show router ldp session 10.10.10.62:0 detail ===============================================================================LDP Sessions (Detail)===============================================================================-------------------------------------------------------------------------------Session with Peer 10.10.10.62:0-------------------------------------------------------------------------------Adjacency Type : Link State : EstablishedUp Time : 0d 00:12:42 Max PDU Length : 4096 KA/Hold Time Remaining: 29Link Adjacencies : 1 Targeted Adjacencies : 0Local Address : 10.10.10.61 Peer Address : 10.10.10.62 Local TCP Port : 646 Peer TCP Port : 49581 Local KA Timeout : 30 Peer KA Timeout : 30Mesg Sent : 283 Mesg Recv : 284 FECs Sent : 5 FECs Recv : 5 ===============================================================================A:P1#

show router ldp session 10.10.10.62:0 detail

Provides details regarding a specified LDP session


The 'show router ldp bindings' command displays the contents of the LIB (Label Information Base) and should contain all labels locally generated and those received from any LDP neighbors, whether they are in use or not.

The local router has three peers (as shown on the previous page) and has generated label 131067 for FEC 10.10.10.60/32. This label is seen as the Ingress Label for the FEC (prefix). It will be sent to all peers except the downstream peer in the LSP, as a label for a FEC should never be advertised to the next-hop of the LSP for that FEC. As a result the label is flagged with an 'N' for that peer.

In the above example, router 10.10.10.66 is the next-hop for the prefix 10.10.10.60/32, therefore router P1 will not use the label it has generated for that prefix for router 10.10.10.66 since packets destined for prefix 10.10.10.60/32 will not be coming from 10.10.10.66 to router P1.

Only one entry shows an egress interface and next-hop since this is the label provided by the same router that provided the active IGP route, and hence is the active label binding.

For FEC 10.10.10.61/32 the router has also generated a label, 131071. Since the FEC is the system address of the local router, the label will be advertised to all peers (and flagged with a 'U'), but none of the entries have any Egress information since the local router is the destination. When the local router receives a packet labeled with 131071 it will POP the label.


show router ldp bindings (LIB)

A:P1# show router ldp bindings ===============================================================================LDP LSR ID: 10.10.10.61===============================================================================Legend: U - Label In Use, N - Label Not In Use

E - Epipe Service, V - VPLS Service, M - Mirror ServiceA - Apipe Service, F - Fpipe Service

===============================================================================LDP Prefix Bindings===============================================================================Prefix Peer IngLbl EgrLbl EgrIntf EgrNextHop-------------------------------------------------------------------------------10.10.10.60/32 10.10.10.62 131067U 131067 -- --10.10.10.60/32 10.10.10.66 131067N 131069 1/1/3 10.1.3.3 10.10.10.60/32 10.10.10.67 131067U 131067 -- --10.10.10.61/32 10.10.10.62 131071U -- -- --10.10.10.61/32 10.10.10.66 131071U -- -- --10.10.10.61/32 10.10.10.67 131071U -- -- --- output omitted -No. of Prefix Bindings: 18

A:P1# show router ldp bindings ===============================================================================LDP LSR ID: 10.10.10.61===============================================================================Legend: U - Label In Use, N - Label Not In Use

E - Epipe Service, V - VPLS Service, M - Mirror ServiceA - Apipe Service, F - Fpipe Service

===============================================================================LDP Prefix Bindings===============================================================================Prefix Peer IngLbl EgrLbl EgrIntf EgrNextHop-------------------------------------------------------------------------------10.10.10.60/32 10.10.10.62 131067U 131067 -- --10.10.10.60/32 10.10.10.66 131067N 131069 1/1/3 10.1.3.3 10.10.10.60/32 10.10.10.67 131067U 131067 -- --10.10.10.61/32 10.10.10.62 131071U -- -- --10.10.10.61/32 10.10.10.66 131071U -- -- --10.10.10.61/32 10.10.10.67 131071U -- -- --- output omitted -No. of Prefix Bindings: 18


The 'show router ldp bindings active' command displays the contents of the LFIB (Label Forwarding Information Base) and should contain all labels used for label switching packets and the associated label action.

For FEC 10.10.10.60/32, two entries exist. The first is associated to a PUSH action, used in the case that an unlabeled packet for this FEC is received at this router, or is locally generated. The unlabeled packet will have label 131069 PUSHed onto it and it will be forwarded via interface 1/1/3 to next-hop 10.1.3.3.

The second entry is the label binding received from the best next-hop for that FEC, as described on the previous page.

For FEC 10.10.10.61/32, the local system address, any packets destined for this FEC will have the label stack POPedand forwarded as unlabeled packets.


show router ldp bindings active (LFIB)

A:P1# show router ldp bindings active ===============================================================================Legend: (S) - Static===============================================================================LDP Prefix Bindings (Active)===============================================================================Prefix Op IngLbl EgrLbl EgrIntf EgrNextHop-------------------------------------------------------------------------------10.10.10.60/32 Push -- 131069 1/1/3 10.1.3.3 10.10.10.60/32 Swap 131067 131069 1/1/3 10.1.3.310.10.10.61/32 Pop 131071 -- -- --10.10.10.62/32 Push -- 131071 1/1/2 10.1.2.2 10.10.10.62/32 Swap 131069 131071 1/1/2 10.1.2.2 -output omitted-===============================================================================A:P1#

A:P1# show router ldp bindings active ===============================================================================Legend: (S) - Static===============================================================================LDP Prefix Bindings (Active)===============================================================================Prefix Op IngLbl EgrLbl EgrIntf EgrNextHop-------------------------------------------------------------------------------10.10.10.60/32 Push -- 131069 1/1/3 10.1.3.3 10.10.10.60/32 Swap 131067 131069 1/1/3 10.1.3.310.10.10.61/32 Pop 131071 -- -- --10.10.10.62/32 Push -- 131071 1/1/2 10.1.2.2 10.10.10.62/32 Swap 131069 131071 1/1/2 10.1.2.2 -output omitted-===============================================================================A:P1#

Displays LDP bindings that are being used by the local LSR


The 'show router tunnel-table' command displays the LSPs that are enabled.

Note: Preference value for tunnel table entries is static and it can not be changed. This preference comes into use only when the application (like L3VPN) wants best-match for a given destination and there are multiple tunnels (SDP, RSVP, LDP).


show router tunnel-table

Displays LSPs established with interface based LDP

A:P1# show router tunnel-table

===============================================================================Tunnel Table (Router: Base)===============================================================================Destination Owner Encap TunnelId Pref Nexthop Metric-------------------------------------------------------------------------------10.10.10.60/32 ldp MPLS - 9 10.1.3.3 201 10.10.10.62/32 ldp MPLS - 9 10.1.2.2 101 10.10.10.66/32 ldp MPLS - 9 10.1.3.3 101 10.10.10.67/32 ldp MPLS - 9 10.16.1.2 101 10.10.10.156/32 ldp MPLS - 9 10.1.2.2 201 ===============================================================================A:P1#

A:P1# show router tunnel-table

===============================================================================Tunnel Table (Router: Base)===============================================================================Destination Owner Encap TunnelId Pref Nexthop Metric-------------------------------------------------------------------------------10.10.10.60/32 ldp MPLS - 9 10.1.3.3 201 10.10.10.62/32 ldp MPLS - 9 10.1.2.2 101 10.10.10.66/32 ldp MPLS - 9 10.1.3.3 101 10.10.10.67/32 ldp MPLS - 9 10.16.1.2 101 10.10.10.156/32 ldp MPLS - 9 10.1.2.2 201 ===============================================================================A:P1#


Verify the path taken by the LDP LSP across the provider core via an Alcatel-Lucent OAM based tool such as 'lsp-ping'and 'lsp-trace'. When using these tools with LDP based LSPs, only 'prefix' is a valid command line option.


OAM Tools - Ping and Traceroute

Verify the LSP across the provider core

A:P1# oam lsp-ping prefix 10.10.10.66/32LSP-PING 10.10.10.66/32: 84 bytes MPLS payloadSeq=1, send from intf P1-P3, reply from 10.10.10.66

udp-data-len=32 ttl=255 rtt<10ms rc=3 (EgressRtr)

---- LSP 10.10.10.66/32 PING Statistics ----1 packets sent, 1 packets received, 0.00% packet lossround-trip min < 10ms, avg < 10ms, max < 10ms, stddev < 10msA:P1#

A:P1# oam lsp-trace prefix 10.10.10.156/32lsp-trace to 10.10.10.156/32: 0 hops min, 0 hops max, 108 byte packets1 10.10.10.61 rtt<10ms, rc=6 (DSRtrMatchLabel) 2 10.10.10.62 rtt<10ms, rc=6 (DSRtrMatchLabel) 3 10.10.10.156 rtt<10ms, rc=3 (EgressRtr)


The 'clear router ldp' commands are used to reset the LDP instance or parameter, or reset the LDP counters and statistics.


clear router ldp

Several commands are available to reset an LDP session or clear LDP related statistics and parameters

A:P1# clear router ldp- ldp

instance - Reset the LDP instanceinterface - Restart or clear statistics for LDP interfacespeer - Restart or clear statistics for LDP targeted peersession - Restart or clear statistics for LDP sessionsstatistics - Clear LDP instance statistics

A:P1# clear router ldp- ldp

instance - Reset the LDP instanceinterface - Restart or clear statistics for LDP interfacespeer - Restart or clear statistics for LDP targeted peersession - Restart or clear statistics for LDP sessionsstatistics - Clear LDP instance statistics



LAB 3.2 Configuring and Verifying the Provider Core for LDP

Pod 1 Pod 2

Pod 3

Core 2 Core 1

Core 3

Edge 1

Edge 3

Edge 2

Pod 4

Core 4

Edge 4

10.48.1.0/24 10.64.1.0/24

10.16.1.0/24 10.32.1.0/24

10.x.y.z/24


LDP


Implementing LDP

Section 3 - Implementing LDP Policy



Implementing LDP Policy- Section Outline

Peer Authentication

LDP Import Policy

LDP Export Policy


Before applying any policy to LDP, it is recommended to verify that the peer is operational prior to the application of the policy. The 'show router ldp session' command, or others, may be used.


LDP Peer Verification

Verify all peer sessions are enabled as required


===============================================================================LDP Sessions===============================================================================Peer LDP Id Adj Type State Mesg Sent Mesg Recv Up Time -------------------------------------------------------------------------------10.10.10.62:0 Link Established 786 785 0d 00:35:46 10.10.10.66:0 Link Established 784 784 0d 00:35:41 10.10.10.67:0 Link Established 760 756 0d 00:34:29-------------------------------------------------------------------------------No. of Sessions: 3===============================================================================A:P1#


===============================================================================LDP Sessions===============================================================================Peer LDP Id Adj Type State Mesg Sent Mesg Recv Up Time -------------------------------------------------------------------------------10.10.10.62:0 Link Established 786 785 0d 00:35:46 10.10.10.66:0 Link Established 784 784 0d 00:35:41 10.10.10.67:0 Link Established 760 756 0d 00:34:29-------------------------------------------------------------------------------No. of Sessions: 3===============================================================================A:P1#


Context: config>router>ldp>peer-parameters>peer

Syntax: authentication-key {authentication-key | hash-key} [hash | hash2]no authentication-key

Description: This command specifies the authentication key to be used between LDP peers before establishing sessions. Authentication uses the MD-5 message-based digest.

The no form of this command disables authentication.

Default: none

Parameters: authentication-key - The authentication key. The key can be any combination of ASCII characters up to 16 characters in length (unencrypted). If spaces are used in the string, enclose the entire string in quotation marks (“ ”).

hash-key - The hash key. The key can be any combination of up 33 alphanumeric characters. If spaces are used in the string, enclose the entire string in quotation marks (“ ”). This is useful when a user must configure the parameter, but, for security purposes, the actual unencrypted key value is not provided.

hash — Specifies the key is entered in an encrypted form. If the hash keyword is not used, the key is assumed to be in a non-encrypted, clear text form. For security, all keys are stored in encrypted form in the configuration file with the hash parameter specified.

hash2 — Specifies the key is entered in a more complex encrypted form. If the hash2 parameter is not used, the less encrypted hash form is assumed.


LDP Peer Authentication

This command specifies the authentication key to be used between LDP peers before establishing sessions• Authentication uses the MD-5 message based digest



A:P1>config>router>ldp# peer-parameters

A:P1>config>router>ldp>peer-params# peer 10.10.10.67

A:P1>config>router>ldp>peer-params>peer$ authentication-key “Alcatel-Lucent"

A:P1>config>router>ldp>peer-params>peer$ exit all

A:P1#



A:P1>config>router>ldp# peer-parameters

A:P1>config>router>ldp>peer-params# peer 10.10.10.67

A:P1>config>router>ldp>peer-params>peer$ authentication-key “Alcatel-Lucent"

A:P1>config>router>ldp>peer-params>peer$ exit all

A:P1#


The 'show router ldp session' command should be reissued after the policy application to verify the session.

In this case, the session shows established, but the policy has not yet been applied since the session had previously established without the authentication in place. LDP will retain the session until the session is dropped, at which point the policy will be in effect.


LDP Session Verification

Verify the session reestablishes after authentication is configured• The session will remain established if it already existed






The 'clear router ldp session' command should be used to force the session to reset and reestablish. This command should be used with caution, and when used, should always be as explicit as possible.


Reset the LDP session

If an LDP session previously existed, the session must be reset to enable the authentication

A:P1# clear router ldp session ?- session <ip-addr[:label-space]> [statistics]

<ip-addr[:label-sp*> : ip-addr - a.b.c.dlabel-space - [0..65535]

<statistics> : keyword - clear statistics only

A:P1# clear router ldp session 10.10.10.67A:P1#

A:P1# clear router ldp session ?- session <ip-addr[:label-space]> [statistics]

<ip-addr[:label-sp*> : ip-addr - a.b.c.dlabel-space - [0..65535]

<statistics> : keyword - clear statistics only

A:P1# clear router ldp session 10.10.10.67A:P1#


The 'show router ldp session' command is again used to verify the session.

In this case, the session shows Unknown since the neighbor session was reset and has not yet reestablished. The router that is taking the Passive role in the LDP session establishment process has the State ‘Unknown’.

This state is commonly seen when authentication has only been configured on one peer or mismatched authentication passwords exist.



Verify the session reestablishes after authentication is configured• Ensure the key is configured on both peers

A:P1# show router ldp session ===============================================================================LDP Sessions===============================================================================Peer LDP Id Adj Type State Mesg Sent Mesg Recv Up Time -------------------------------------------------------------------------------10.10.10.62:0 Link Established 879 876 0d 00:39:54 10.10.10.66:0 Link Established 877 875 0d 00:39:49 10.10.10.67:0 Link Unknown 7 8 0d 00:00:29-------------------------------------------------------------------------------No. of Sessions: 3===============================================================================A:P1#

A:P1# show router ldp session ===============================================================================LDP Sessions===============================================================================Peer LDP Id Adj Type State Mesg Sent Mesg Recv Up Time -------------------------------------------------------------------------------10.10.10.62:0 Link Established 879 876 0d 00:39:54 10.10.10.66:0 Link Established 877 875 0d 00:39:49 10.10.10.67:0 Link Unknown 7 8 0d 00:00:29-------------------------------------------------------------------------------No. of Sessions: 3===============================================================================A:P1#


The 'show router ldp session' command is used on the remote peer to verify the session.

In this case, the session shows Open since the neighbor session was reset and has not yet reestablished. The router that is taking the Active role in the LDP session establishment process has the State ‘Open’.

This state is commonly seen when authentication has only been configured on one peer or mismatched authentication passwords exist.



Verify the session reestablishes after authentication is configured• Ensure the key is configured on both peers


===============================================================================LDP Sessions===============================================================================Peer LDP Id Adj Type State Mesg Sent Mesg Recv Up Time -------------------------------------------------------------------------------10.10.10.61:0 Link Open 11 11 0d 00:00:42-------------------------------------------------------------------------------No. of Sessions: 1===============================================================================


===============================================================================LDP Sessions===============================================================================Peer LDP Id Adj Type State Mesg Sent Mesg Recv Up Time -------------------------------------------------------------------------------10.10.10.61:0 Link Open 11 11 0d 00:00:42-------------------------------------------------------------------------------No. of Sessions: 1===============================================================================


An export policy may be configured to control the set of LDP label bindings advertised by the LSR. The default label generation behavior is to originate label bindings for system address and propagate all FECs received

A 7x50 will only install an active binding with a PUSH operation for a /32 prefix. For non /32 prefixes a 7x50 will only install an active binding with a POP or SWAP operation. The primary purpose of the LDP Export Policy is to interoperate with other routers which may generate labels for non /24 FECs, and to generate labels for /32 loopbacks configured on the 7x50.


LDP Export Policy

The default label generation behavior of the 7x50 is to originate label bindings for system addresses only and propagate all FECs received

LDP Export Policies can be used to distribute labels for prefixes on directly connected interfaces and for other prefixes in the routing table

Export Policies may be configured to control the set of LDP label bindings advertised by the LSR

7x50 only installs active binding with PUSH operation for FECs with /32 prefixes (e.g. loopbacks configured on the router)

For non /32 FECs, 7x50 only installs active binding with a POP or SWAP operation

Used mostly for interoperability



Syntax: export policy-name [policy-name …up to 5 max]

no export

Description: This command specifies the export route policies used to determine which routes are exported to LDP. Policies are configured in the config>router>policy-options context.

If no export policy is specified, non-LDP routes will not be exported from the routing table manager to LDP. LDP-learned routes will be exported to LDP neighbors. If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple export commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.

The no form of the command removes all policies from the configuration.

Default: no export - no export route policies specified

Parameters: policy-name - The export route policy name. Allowed values are any string up to 32 characters long composed of printable, 7-bit ASCII characters excluding double quotes. If the string contains spaces, use double quotes to delimit the start and end of the string. The specified name(s) must already be defined.


LDP Export Policy

Label bindings can be advertised based on:• Direct - all local subnets• Prefix-list - match on bindings with the specified prefix/prefixes

If no match criteria is specified in the policy and the action is accept, a label will be distributed for all local interfaces

A:P1# config router policy-optionsA:P1>config>router>policy-options# beginA:P1>config>router>policy-options# policy-statement LDP-ExportA:P1>config>router>policy-options>policy-statement# entry 10A:P1>config>router>policy-options>policy-statement>entry$ action accept

A:P1>config>router>policy-options>policy-statement>entry>action$ exitA:P1>config>router>policy-options>policy-statement>entry$ exitA:P1>config>router>policy-options>policy-statement# exitA:P1>config>router>policy-options# commitA:P1>config>router>policy-options# exit allA:P1#

A:P1# config router policy-optionsA:P1>config>router>policy-options# beginA:P1>config>router>policy-options# policy-statement LDP-ExportA:P1>config>router>policy-options>policy-statement# entry 10A:P1>config>router>policy-options>policy-statement>entry$ action accept

A:P1>config>router>policy-options>policy-statement>entry>action$ exitA:P1>config>router>policy-options>policy-statement>entry$ exitA:P1>config>router>policy-options>policy-statement# exitA:P1>config>router>policy-options# commitA:P1>config>router>policy-options# exit allA:P1#


In the example the export policy in the previous slide is configured on router P1 and enabled in the LDP context.


LDP Export Policy

The LDP export policy is applied to the LDP instance on the router

A:P1#configure router ldp export LDP-exportA:P1#configure router ldp export LDP-export

P11.1.1.1/32

10.2.3.0/24

P22.2.2.2/32

P33.3.3.3/32

10.1.8.0/24

10.1.3.0/24

10.1.2.0/24


The output of the ‘show router ldp bindings’ command prior to enabling the export policy is shown.


LDP Export Policy – Label Bindings Before

A:P1# show router ldp bindings

====================================================

LDP LSR ID: 1.1.1.1

==============================================================================

Legend: U - Label In Use, N - Label Not In Use, W - Label Withdrawn

S - Status Signaled Up, D - Status Signaled Down

E - Epipe Service, V - VPLS Service, M - Mirror Service

A - Apipe Service, F - Fpipe Service, I - IES Service, R - VPRN service

P - Ipipe Service

==============================================================================

LDP Prefix Bindings

==============================================================================

Prefix Peer IngLbl EgrLbl EgrIntf EgrNextHop

------------------------------------------------------------------------------

1.1.1.1/32 2.2.2.2 131071U -- -- --

1.1.1.1/32 3.3.3.3 131071U -- -- --

2.2.2.2/32 2.2.2.2 -- 131069 1/1/2 10.1.2.2

2.2.2.2/32 3.3.3.3 131070U 131067 -- --

3.3.3.3/32 2.2.2.2 131069U 131067 -- --

3.3.3.3/32 3.3.3.3 -- 131071 1/1/3 10.1.3.3

------------------------------------------------------------------------------

No. of Prefix Bindings: 6


====================================================

LDP LSR ID: 1.1.1.1

==============================================================================





P - Ipipe Service

==============================================================================

LDP Prefix Bindings

==============================================================================


------------------------------------------------------------------------------

1.1.1.1/32 2.2.2.2 131071U -- -- --

1.1.1.1/32 3.3.3.3 131071U -- -- --

2.2.2.2/32 2.2.2.2 -- 131069 1/1/2 10.1.2.2

2.2.2.2/32 3.3.3.3 131070U 131067 -- --

3.3.3.3/32 2.2.2.2 131069U 131067 -- --

3.3.3.3/32 3.3.3.3 -- 131071 1/1/3 10.1.3.3

------------------------------------------------------------------------------



The output of the ‘show router ldp bindings’ command after enabling the export policy on router P1 is shown. There are now label bindings generated for router P1’s three direct interfaces.


LDP Export Policy – Label Bindings After

:P1# show router ldp bindings==============================================================================LDP LSR ID: 1.1.1.1==============================================================================- output omitted -==============================================================================LDP Prefix Bindings==============================================================================Prefix Peer IngLbl EgrLbl EgrIntf EgrNextHop------------------------------------------------------------------------------1.1.1.1/32 2.2.2.2 131071U -- -- --1.1.1.1/32 3.3.3.3 131071U -- -- --2.2.2.2/32 2.2.2.2 -- 131069 1/1/2 10.1.2.2 2.2.2.2/32 3.3.3.3 131070U 131067 -- --3.3.3.3/32 2.2.2.2 131069U 131067 -- --3.3.3.3/32 3.3.3.3 -- 131071 1/1/3 10.1.3.3 10.1.2.0/24 2.2.2.2 131068U -- -- --10.1.2.0/24 3.3.3.3 131068U 131069 -- --10.1.3.0/24 2.2.2.2 131067U 131065 -- --10.1.3.0/24 3.3.3.3 131067U -- -- --10.1.8.0/24 2.2.2.2 131066U 131065 -- --10.1.8.0/24 3.3.3.3 131066U 131065 -- --------------------------------------------------------------------------------No. of Prefix Bindings: 12

:P1# show router ldp bindings==============================================================================LDP LSR ID: 1.1.1.1==============================================================================- output omitted -==============================================================================LDP Prefix Bindings==============================================================================Prefix Peer IngLbl EgrLbl EgrIntf EgrNextHop------------------------------------------------------------------------------1.1.1.1/32 2.2.2.2 131071U -- -- --1.1.1.1/32 3.3.3.3 131071U -- -- --2.2.2.2/32 2.2.2.2 -- 131069 1/1/2 10.1.2.2 2.2.2.2/32 3.3.3.3 131070U 131067 -- --3.3.3.3/32 2.2.2.2 131069U 131067 -- --3.3.3.3/32 3.3.3.3 -- 131071 1/1/3 10.1.3.3 10.1.2.0/24 2.2.2.2 131068U -- -- --10.1.2.0/24 3.3.3.3 131068U 131069 -- --10.1.3.0/24 2.2.2.2 131067U 131065 -- --10.1.3.0/24 3.3.3.3 131067U -- -- --10.1.8.0/24 2.2.2.2 131066U 131065 -- --10.1.8.0/24 3.3.3.3 131066U 131065 -- --------------------------------------------------------------------------------No. of Prefix Bindings: 12


The output of the ‘show router ldp bindings active’ command before enabling the export policy on router P1 is shown.


LDP Export Policy – Active Label Bindings Before

A:P1# show router ldp bindings active==============================================================================Legend: (S) - Static==============================================================================LDP Prefix Bindings (Active)==============================================================================Prefix Op IngLbl EgrLbl EgrIntf EgrNextHop------------------------------------------------------------------------------1.1.1.1/32 Pop 131071 -- -- --2.2.2.2/32 Push -- 131069 1/1/2 10.1.2.2 2.2.2.2/32 Swap 131070 131069 1/1/2 10.1.2.2 3.3.3.3/32 Push -- 131071 1/1/3 10.1.3.3 3.3.3.3/32 Swap 131069 131071 1/1/3 10.1.3.3 ------------------------------------------------------------------------------No. of Prefix Bindings: 5

A:P1# show router ldp bindings active==============================================================================Legend: (S) - Static==============================================================================LDP Prefix Bindings (Active)==============================================================================Prefix Op IngLbl EgrLbl EgrIntf EgrNextHop------------------------------------------------------------------------------1.1.1.1/32 Pop 131071 -- -- --2.2.2.2/32 Push -- 131069 1/1/2 10.1.2.2 2.2.2.2/32 Swap 131070 131069 1/1/2 10.1.2.2 3.3.3.3/32 Push -- 131071 1/1/3 10.1.3.3 3.3.3.3/32 Swap 131069 131071 1/1/3 10.1.3.3 ------------------------------------------------------------------------------No. of Prefix Bindings: 5


The output of the ‘show router ldp bindings active’ command after enabling the export policy on router P1 is shown. There are now entries for the direct connected interfaces, with a POP action, since these FECs are local to P1.


LDP Export Policy – Active Label Bindings After

P1# show router ldp bindings active

==============================================================================

Legend: (S) - Static

==============================================================================

LDP Prefix Bindings (Active)

==============================================================================

Prefix Op IngLbl EgrLbl EgrIntf EgrNextHop

------------------------------------------------------------------------------

1.1.1.1/32 Pop 131071 -- -- --

2.2.2.2/32 Push -- 131069 1/1/2 10.1.2.2

2.2.2.2/32 Swap 131070 131069 1/1/2 10.1.2.2

3.3.3.3/32 Push -- 131071 1/1/3 10.1.3.3

3.3.3.3/32 Swap 131069 131071 1/1/3 10.1.3.3

10.1.2.0/24 Pop 131068 -- -- --

10.1.3.0/24 Pop 131067 -- -- --

10.1.8.0/24 Pop 131066 -- -- --

------------------------------------------------------------------------------


P1# show router ldp bindings active

==============================================================================


==============================================================================


==============================================================================


------------------------------------------------------------------------------

1.1.1.1/32 Pop 131071 -- -- --

2.2.2.2/32 Push -- 131069 1/1/2 10.1.2.2

2.2.2.2/32 Swap 131070 131069 1/1/2 10.1.2.2

3.3.3.3/32 Push -- 131071 1/1/3 10.1.3.3

3.3.3.3/32 Swap 131069 131071 1/1/3 10.1.3.3

10.1.2.0/24 Pop 131068 -- -- --

10.1.3.0/24 Pop 131067 -- -- --

10.1.8.0/24 Pop 131066 -- -- --

------------------------------------------------------------------------------



An LDP Import Policy can be used to control for which FECs a router will generate labels. By default the 7x50 router generates labels for every FEC received from its neighbors. And recall that by default, the only FEC for which every 7x50 router generates a label, is for its own system address prefix. An LDP Import Policy can be applied on a router to restrict it from generating labels for the system address prefixes of other routers.


LDP Import Policy

LDP Import policies allows a route policy to control for which FECs (i.e. routes/prefixes) learned from peer routers, the router will generate labels

An import policy can accept or reject label bindings for FECs received from LDP peers

The default import behavior is to accept all FECs received from peers and generate labels for them

Label bindings for FECs can be filtered based on:• Neighbor - Match on FECs received from the specified peer• Interface - Match on FECs received from a neighbor or

neighbors adjacent over the specified interface• Prefix-list - Match on FECs contained in the specified

prefix/prefixes



Syntax: import policy-name [policy-name …up to 5 max]

no import

Description: This command configures import route policies to determine which routes are accepted from LDP neighbors. Policies are configured in the config>router>policy-options context. If no import policy is specified, LDP accepts all routes from configured LDP neighbors. Import policies can be used to limit or modify the routes accepted and their corresponding parameters and metrics.

If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple import commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.

The no form of the command removes all policies from the configuration.

Default: no import - no import route policies specified

Parameters: policy-name - The import route policy name. Allowed values are any string up to 32 characters long composed of printable, 7-bit ASCII characters excluding double quotes. If the string contains spaces, use double quotes to delimit the start and end of the string. The specified name(s) must already be defined.


LDP Import Policy

If no match criteria is specified in the policy and the action is reject, the router will not generate labels for any FEC received from its peers. It will only generate a FEC for its ownsystem address.

A:P1# config router policy-optionsA:P1>config>router>policy-options# beginA:P1>config>router>policy-options# policy-statement LDP-ImportA:P1>config>router>policy-options>policy-statement# entry 10A:P1>config>router>policy-options>policy-statement>entry$ action rejectA:P1>config>router>policy-options>policy-statement>entry>action$ exitA:P1>config>router>policy-options>policy-statement>entry$ exitA:P1>config>router>policy-options>policy-statement# exitA:P1>config>router>policy-options# commitA:P1>config>router>policy-options# exit allA:P1#

A:P1# config router policy-optionsA:P1>config>router>policy-options# beginA:P1>config>router>policy-options# policy-statement LDP-ImportA:P1>config>router>policy-options>policy-statement# entry 10A:P1>config>router>policy-options>policy-statement>entry$ action rejectA:P1>config>router>policy-options>policy-statement>entry>action$ exitA:P1>config>router>policy-options>policy-statement>entry$ exitA:P1>config>router>policy-options>policy-statement# exitA:P1>config>router>policy-options# commitA:P1>config>router>policy-options# exit allA:P1#


In the example the import policy in the previous slide is configured on router P1 and enabled in the LDP context.


LDP Import Policy

The LDP import policy is applied to the LDP instance on the router

A:P1#configure router ldp import LDP-importA:P1#configure router ldp import LDP-import

P11.1.1.1/32

10.2.3.0/24

P22.2.2.2/32

P33.3.3.3/32

10.1.8.0/24

10.1.3.0/24

10.1.2.0/24


The output of the ‘show router ldp bindings’ command prior to enabling the import policy is shown.

Note that P1 does not advertise a label for a FEC to the peer router who is either the next-hop to the FEC, or whose system address is the FEC.


LDP Import Policy – Label Bindings Before


LDP LSR ID: 1.1.1.1





P - Ipipe Service

==============================================================================

LDP Prefix Bindings


------------------------------------------------------------------------------

1.1.1.1/32 2.2.2.2 131071U -- -- --

1.1.1.1/32 3.3.3.3 131071U -- -- --

2.2.2.2/32 2.2.2.2 -- 131069 1/1/2 10.1.2.2

2.2.2.2/32 3.3.3.3 131070U 131067 -- --

3.3.3.3/32 2.2.2.2 131069U 131067 -- --

3.3.3.3/32 3.3.3.3 -- 131071 1/1/3 10.1.3.3

------------------------------------------------------------------------------



LDP LSR ID: 1.1.1.1





P - Ipipe Service

==============================================================================

LDP Prefix Bindings


------------------------------------------------------------------------------

1.1.1.1/32 2.2.2.2 131071U -- -- --

1.1.1.1/32 3.3.3.3 131071U -- -- --

2.2.2.2/32 2.2.2.2 -- 131069 1/1/2 10.1.2.2

2.2.2.2/32 3.3.3.3 131070U 131067 -- --

3.3.3.3/32 2.2.2.2 131069U 131067 -- --

3.3.3.3/32 3.3.3.3 -- 131071 1/1/3 10.1.3.3

------------------------------------------------------------------------------



The output of the ‘show router ldp bindings’ command after enabling the import policy on router P1 is shown.

P1 no longer generates ingress labels for FECs 2.2.2.2/32 and 3.3.3.3/32. It only generates a label for its own system address.


LDP Import Policy – Label Bindings After


==============================================================================

LDP LSR ID: 1.1.1.1

==============================================================================





P - Ipipe Service

==============================================================================

LDP Prefix Bindings

==============================================================================


------------------------------------------------------------------------------

1.1.1.1/32 2.2.2.2 131071U -- -- --

1.1.1.1/32 3.3.3.3 131071U -- -- --

2.2.2.2/32 2.2.2.2 -- 131069 -- --

2.2.2.2/32 3.3.3.3 -- 131067 -- --

3.3.3.3/32 2.2.2.2 -- 131067 -- --

3.3.3.3/32 3.3.3.3 -- 131071 -- --

------------------------------------------------------------------------------



==============================================================================

LDP LSR ID: 1.1.1.1

==============================================================================





P - Ipipe Service

==============================================================================

LDP Prefix Bindings

==============================================================================


------------------------------------------------------------------------------

1.1.1.1/32 2.2.2.2 131071U -- -- --

1.1.1.1/32 3.3.3.3 131071U -- -- --

2.2.2.2/32 2.2.2.2 -- 131069 -- --

2.2.2.2/32 3.3.3.3 -- 131067 -- --

3.3.3.3/32 2.2.2.2 -- 131067 -- --

3.3.3.3/32 3.3.3.3 -- 131071 -- --

------------------------------------------------------------------------------



The output of the ‘show router ldp bindings active’ command prior to enabling the import policy on router P1 is shown.


LDP Import Policy – Active Label Bindings Before

A:P1# show router ldp bindings active

==============================================================================


==============================================================================


==============================================================================


------------------------------------------------------------------------------

1.1.1.1/32 Pop 131071 -- -- --

2.2.2.2/32 Push -- 131069 1/1/2 10.1.2.2

2.2.2.2/32 Swap 131070 131069 1/1/2 10.1.2.2

3.3.3.3/32 Push -- 131071 1/1/3 10.1.3.3

3.3.3.3/32 Swap 131069 131071 1/1/3 10.1.3.3

------------------------------------------------------------------------------



==============================================================================


==============================================================================


==============================================================================


------------------------------------------------------------------------------

1.1.1.1/32 Pop 131071 -- -- --

2.2.2.2/32 Push -- 131069 1/1/2 10.1.2.2

2.2.2.2/32 Swap 131070 131069 1/1/2 10.1.2.2

3.3.3.3/32 Push -- 131071 1/1/3 10.1.3.3

3.3.3.3/32 Swap 131069 131071 1/1/3 10.1.3.3

------------------------------------------------------------------------------



The output of the ‘show router ldp bindings active’ command after enabling the import policy on router P1 is shown.

The only active binding on P1 is for its own system address, for which there is a POP operation. Hence, the only LSP on P1 is the terminating LSP for the FEC that is its own system address.


LDP Import Policy – Active Label Bindings After


==============================================================================


==============================================================================


==============================================================================


------------------------------------------------------------------------------

1.1.1.1/32 Pop 131071 -- -- --

------------------------------------------------------------------------------



==============================================================================


==============================================================================


==============================================================================


------------------------------------------------------------------------------

1.1.1.1/32 Pop 131071 -- -- --

------------------------------------------------------------------------------




LAB 3.3 and 3.4: ECMP and Export Policy

Pod 1 Pod 2

Pod 3

Core 2 Core 1

Core 3

Edge 1

Edge 3

Edge 2

Pod 4

Core 4

Edge 4

10.48.1.0/24 10.64.1.0/24

10.16.1.0/24 10.32.1.0/24

10.x.y.z/24


LDP


Implementing LDP

Section 4 - Targeted LDP



Targeted LDP - Section Outline

Targeted LDP Operation

Configure T-LDP

Verify T-LDP


Targeted LDP sessions can be used to establish LDP sessions between peers that are not directly connected. Link based sessions may still remain between the directly connected LSRs. T-LDP sessions may also be established between directly connected devices if desired.

Targeted LDP would be configured in the case of a service implementation such as ePipe, VPRN or others.


Targeted LDP sessions can be established between peers that are not directly connected• Provides a tunnel between ingress and egress LERs

Link based sessions may still remain between the directly connected LSRs• Provides the hop by hop tunnel across the core

Targeted LDP (T-LDP) Sessions

MPLS Network

iLER

eLER

T-LDP Session

LSR 3

LSR 2LSR 1


LDP sessions between non-directly connected LSRs are supported by LDP Extended Discovery.

To engage in LDP Extended Discovery, an LSR periodically sends LDP Targeted HELLO messages to a specific configured address. LDP Targeted HELLO messages are sent as UDP packets addressed to the well-known LDP discovery port at the specific address. An LDP Targeted HELLO sent by an LSR carries the LDP Identifier for the label space that the LSR intends to use, and possibly additional optional information.

Extended Discovery differs from Basic Discovery in the following ways:

A Targeted HELLO is sent to a specific address rather than to the "all routers" group multicast address for the outgoing interface.

Unlike Basic Discovery, which is symmetric, Extended Discovery is asymmetric.

One LSR initiates Extended Discovery with another targeted LSR, and the targeted LSR decides whether to respond to or ignore the Targeted HELLO. A targeted LSR that chooses to respond does so by periodically sending Targeted HELLO messages to the initiating LSR.

Receipt of an LDP Targeted HELLO identifies a "Hello adjacency" with a potential LDP peer reachable at the network level and the label space the peer intends to use. This type of adjacency is referred to as a Targeted adjacency.

Note that when an LSR sends a Hello it selects the transport address for its end of the session connection and uses the Hello to advertise the address.


T-LDP Discovery - Non-Directly Connected LSRs

The process is similar to regular neighbor establishment except the Targeted HELLOs are sent via unicast

Receipt of an LDP Targeted HELLO identifies a "Hello adjacency“• Referred to as a Targeted Adjacency

Targeted Adjacency

10.1.1.1 10.1.2.2

10.1.2.110.1.1.2

LDP Targeted HELLO - UnicastTo UDP:646: 10.1.1.1

LDP Targeted HELLO - UnicastTo UDP:646: 10.1.2.2

Unicast Hellos


A label stack consisting of multiple labels may exist in a frame. In the case of two labels, the outer label is the tunnel label and is used to switch the frame hop by hop across the LSRs in the provider backbone from ingress to egress. LDP is used to signal the tunnel label.

The inner label is the Service or Virtual Circuit (VC) label and is used by the egress LER to determine how to process the frame. Targeted LDP is used to signal this Service label.

In the example above, when Targeted LDP is configured between the iLER and the eLER, the eLER signals to the iLERthat there are two separate customers connected to it, and provides the iLER with a label for each.

The iLER would then impose a label stack on packets sent to the eLER. The tunnel label allows the packet to be label switched across the provider MPLS backbone. The Service label in the received frame is used to differentiate between the two customers connected to the eLER, either by egress interface or service.


MPLS Label Stack

An MPLS frame may have one or more labels applied to it

The outer label is the Tunnel label and is used to switch the frame across the provider MPLS backbone

The inner label is the Service label and is used by the egress LER to determine the egress interface or service

Data Link Header

Tunnel Label

Service Label

IP Packet FCS

MPLS Network

iLER

eLER

T-LDP Session

LSR 3

LSR 2LSR 1


The Tunnel (LSP) labels are advertised by LDP and are used to switch the frame across the provider backbone.

At the customer ingress point to the provider network, the iLER encapsulates the customer data in a Service label, then adds the transport label to the MPLS label stack before forwarding the data.

The frame is label switched across the provider domain based on the tunnel label, until it arrives at the eLER and the top label is POPped.


Transport Tunnel (Outer) Label

The Tunnel labels are advertised by LDP and are used to switch the frame across the provider backbone• It is SWAPped at each LSR in the transit LSP• Enables hop by hop label switching to propagate the frame to the

eLER

Data Link Header

Tunnel Label

Service Label

IP Packet FCS

MPLS Network

iLER

eLER

T-LDP Session

LSR 3

LSR 2LSR 1


The Service or (VC) labels are advertised by T-LDP and are used to identify to which service or customer a packet belongs. A tunnel may carry several services at the same time.

At the customer egress point to the provider network, the eLER will POP the tunnel label and expose the Service label in the frame.

Based on this Service label, the eLER is able to determine which customer the frame is destined for, and then will forward an unlabeled packet to that customer.


Service (Inner) Label

The Service labels are advertised by T-LDP and are used to identify to which service or customer a packet belongs• It is PUSHed at the iLER and POPped at the eLER• Creates a per customer tunnel that isolates traffic from other

customers

Data Link Header

Tunnel Label

Service Label

IP Packet FCS

MPLS Network

iLER

eLER

T-LDP Session

LSR 3

LSR 2LSR 1


The Service labels are distributed via Targeted LDP (T-LDP) sessions, typically between LERs. This label is also known as the inner or Virtual Circuit (VC) label. The Virtual Circuit corresponds to the Martini encapsulation discussed in IETF draft-martini-l2circuit-trans-mpls.

The Service labels are exchanged in Downstream Unsolicited (DU) mode and are generated based on the FEC in use, such as an IP address or Virtual Circuit ID.

T-LDP signaled labels are used for services that include:

Virtual Private LAN Service (VPLS)

ePipe

Others


Service Label Signaling

The Service labels are distributed via Targeted LDP (T-LDP)

Labels are exchanged in Downstream Unsolicited (DU) mode

Labels are generated based on the FEC in use such as an IP address or Virtual Circuit ID

T-LDP signaled labels are used for services that include• Virtual Private LAN Service (VPLS)• ePipe




Configure a static peerConfigure authenticationConfigure TTL security


Start


Test and Verify

Configure LDP

Configure Core Network ParametersConfigure ports and interfaces

Configure IP addressing

Configure IGP routing

Enable LDP

Configure Policy

Configure Optional parameters


CLI command structure for configuring Targeted LDP on the Alcatel-Lucent 7x50.


T-LDP Configuration CLI Structure

The configuration commands to provision targeted LDP are located under the config>router>ldp>targeted-session context

A:PE1# configure routerA:PE1>config>router# ldpA:PE1>config>router>ldp# targeted-sessionA:PE1>config>router>ldp>targ-session# ?[no] disable-target* - Enable/disable targeted LDP sessions[no] hello - Configure the hello timeout and factor for targeted LDP sessions[no] keepalive - Configure the keepalive timeout and factor for targeted LDP sessions[no] peer + Configure a targeted peer for LDP


CLI command structure for configuring LDP peer parameters on the Alcatel-Lucent 7x50.

Syntax: config>router>ldp>peer-params$

[no] peer + Configure parameters for an LDP peer

- no peer <ip-address>

- peer <ip-address>

<ip-address> : a.b.c.d

[no] authentication* - Configure the authentication key used for the peer

[no] ttl-security - Configure TTL security parameters for incoming packet


LDP Peer CLI Configuration Command Structure

The configuration commands to provision an LDP peer are located under the config>router>ldp>peer-parameters context

A:PE1>config>router>ldp# peer-parameters A:PE1>config>router>ldp>peer-params# peer - no peer <ip-address>- peer <ip-address>

<ip-address> : a.b.c.d

[no] authentication* - Configure the authentication key used for the peer[no] ttl-security - Configure TTL security parameters for incoming packet



Syntax: targeted-session

Description: This command configures targeted LDP sessions. Targeted sessions are LDP sessions between non-directly connected peers. Hello messages are sent directly to the peer platform instead of to all the routers on this subnet multicast address.

The discovery messages for an indirect LDP session are addressed to the specified peer and not to the multicast address.

Default: enabled

Context: config>router>ldp>targ-session

Syntax: [no] disable-targeted-session

Description: This command disables support for targeted sessions. Targeted sessions are LDP sessions between non-directly connected peers. The discovery messages for an indirect LDP session are addressed to the specified peer and not to the multicast address.

The no form of the command enables the set up of any targeted sessions.

Default: no disable-targeted-session


Enabling Targeted LDP

T-LDP is enabled by default when LDP is enabled

A:PE1# configure routerA:PE1>config>router# ldpA:PE1>config>router>ldp# targeted-session A:PE1>config>router>ldp>targ-session# no disable-targeted-sessionA:PE1>config>router>ldp>targ-session# exit allA:PE1#

A:PE1# configure routerA:PE1>config>router# ldpA:PE1>config>router>ldp# targeted-session A:PE1>config>router>ldp>targ-session# no disable-targeted-sessionA:PE1>config>router>ldp>targ-session# exit allA:PE1#


Context: config>router>ldp>targeted-session

Syntax: [no] peer ip-address

Description: This command configures parameters for an LDP peer.

Default: none

Parameters: ip-address - The IP address of the LDP peer in dotted decimal notation.


T-LDP Peer

To modify attributes of the T-LDP session with a peer enter the peer context

E.g. hello and keepalive timers, authentication

T-LDP peers do not have to be explicitly configured for service labels to be exchanged and services to become operational

Once services are configured, labels will automatically be exchanged via T-LDP

A:PE1# configure routerA:PE1>config>router# ldpA:PE1>config>router>ldp# targeted-sessionA:PE1>config>router>ldp>targ-session# peer 10.10.10.60A:PE1>config>router>ldp>targ-session>peer$ exitA:PE1>config>router>ldp>targ-session# peer 10.10.10.156A:PE1>config>router>ldp>targ-session>peer$ exit allA:PE1#

A:PE1# configure routerA:PE1>config>router# ldpA:PE1>config>router>ldp# targeted-sessionA:PE1>config>router>ldp>targ-session# peer 10.10.10.60A:PE1>config>router>ldp>targ-session>peer$ exitA:PE1>config>router>ldp>targ-session# peer 10.10.10.156A:PE1>config>router>ldp>targ-session>peer$ exit allA:PE1#


CLI Syntax: hello timeout factor

Description: This command configures the time interval to wait before declaring a neighbor down. The factor parameter derives the HELLO interval. Hold time is local to the system and sent in the HELLO messages to the neighbor. Hold time cannot be less than three times the HELLO interval. The hold time can be configured globally (applies to all LDP interfaces) or per interface. The most specific value is used. When LDP session is being set up, the hold down time is negotiated to the lower of the two peers. Once a operational value is agreed upon, the HELLO factor is used to derive the value of the HELLO interval.

The no form of the command at the interface-parameters and targeted-session level sets the hello timeout and the hello factor to the default values. The no form of the command, at the interface level, will set the hello timeout and the hello factor to the value defined under the interface-parameters level.

CLI Syntax: keepalive timeout factor

Description: This command configures the time interval, in seconds, that LDP waits before tearing down the session. The factor parameter derives the keepalive interval. If no LDP messages are exchanged for the configured time interval, the LDP session is torn down. Keepalive timeout is usually three times the keepalive interval. To maintain the session permanently, regardless of the activity, set the value to zero.

Parameters: timeout — Configures the time interval, expressed in seconds, that LDP waits before tearing down the session.

Values 1 — 65535

factor — Specifies the number of keepalive messages, expressed as a decimal integer, that should be sent on an idle LDP session in the keepalive timeout interval.

Values 1 — 255


Configuring a Targeted Session

A:PE1# configure router

A:PE1>config>router# ldp

A:PE1>config>router>ldp# targeted-session

A:PE1>config>router>ldp>targ-session# hello 5000 255

A:PE1>config>router>ldp>targ-session# keepalive 5000 255

A:PE1>config>router>ldp>targ-session# peer 10.10.10.66

A:PE1>config>router>ldp>targ-session>peer# hello 2500 100

A:PE1>config>router>ldp>targ-session>peer# keepalive 15 3

A:PE1>config>router>ldp>targ-session>peer# no shutdown

A:PE1>config>router>ldp>targ-session>peer# exit all

A:PE1#

A:PE1# configure router

A:PE1>config>router# ldp

A:PE1>config>router>ldp# targeted-session

A:PE1>config>router>ldp>targ-session# hello 5000 255

A:PE1>config>router>ldp>targ-session# keepalive 5000 255

A:PE1>config>router>ldp>targ-session# peer 10.10.10.66

A:PE1>config>router>ldp>targ-session>peer# hello 2500 100

A:PE1>config>router>ldp>targ-session>peer# keepalive 15 3

A:PE1>config>router>ldp>targ-session>peer# no shutdown

A:PE1>config>router>ldp>targ-session>peer# exit all

A:PE1#

Individual peer parameters may be configured on the global LDP or individual peer context

The more specific parameter takes precedence


The 'show router ldp peer' command displays the configured Targeted LDP peers and their state.


show router ldp peer

Displays the list of defined Targeted LDP peers

A:P1# show router ldp peer

===============================================================================LDP Peers===============================================================================Peer Adm Opr Hello Hold KA KA Passive Auto

Factor Time Factor Timeout Mode Created -------------------------------------------------------------------------------10.10.10.60 Up Up 3 45 4 40 Disabled No 10.10.10.156 Up Up 3 45 4 40 Disabled No -------------------------------------------------------------------------------No. of Peers: 2===============================================================================A:P1#

A:P1# show router ldp peer

===============================================================================LDP Peers===============================================================================Peer Adm Opr Hello Hold KA KA Passive Auto

Factor Time Factor Timeout Mode Created -------------------------------------------------------------------------------10.10.10.60 Up Up 3 45 4 40 Disabled No 10.10.10.156 Up Up 3 45 4 40 Disabled No -------------------------------------------------------------------------------No. of Peers: 2===============================================================================A:P1#


The 'show router ldp session' command displays the LDP Identifier and session related parameters.

An adjacency type of 'Targeted' indicates a Targeted LDP neighbor relationship, where 'Link' indicates an LDP session.



===============================================================================LDP Sessions===============================================================================Peer LDP Id Adj Type State Mesg Sent Mesg Recv Up Time -------------------------------------------------------------------------------10.10.10.60:0 Targeted Established 264 264 0d 00:23:43 10.10.10.61:0 Link Established 1471 1473 0d 00:53:02 10.10.10.156:0 Targeted Established 264 267 0d 00:23:51 -------------------------------------------------------------------------------No. of Sessions: 3===============================================================================A:P1#


===============================================================================LDP Sessions===============================================================================Peer LDP Id Adj Type State Mesg Sent Mesg Recv Up Time -------------------------------------------------------------------------------10.10.10.60:0 Targeted Established 264 264 0d 00:23:43 10.10.10.61:0 Link Established 1471 1473 0d 00:53:02 10.10.10.156:0 Targeted Established 264 267 0d 00:23:51 -------------------------------------------------------------------------------No. of Sessions: 3===============================================================================A:P1#

Verifies the LDP ID and session related parameters

show router ldp session


The 'show router ldp status' command displays detailed summary information on the LDP protocol, including the number of Link and Targeted sessions.

The Active Interfaces shows the number of direct LDP Hello adjacencies configured on this router.

The Active Peers shows the number of targeted LDP Hello adjacencies configured this router.

The Active Adjacencies shows the total number of direct and targeted LDP Hello adjacencies configured on this router.

The Active Sessions shows the total number of direct and targeted LDP sessions that are up and operational on the router.


show router ldp status

Displays LDP sessions and adjacenciesA:P1# show router ldp status===============================================================================




Import Policies : None Export Policies : None Active Adjacencies : 3 Active Sessions : 3 Active Interfaces : 1 Inactive Interfaces : 0 Active Peers : 2 Inactive Peers : 0

Addr FECs Sent : 1 Addr FECs Recv : 5 Serv FECs Sent : 0 Serv FECs Recv : 0

Attempted Sessions : 3








Import Policies : None Export Policies : None Active Adjacencies : 3 Active Sessions : 3 Active Interfaces : 1 Inactive Interfaces : 0 Active Peers : 2 Inactive Peers : 0

Addr FECs Sent : 1 Addr FECs Recv : 5 Serv FECs Sent : 0 Serv FECs Recv : 0

Attempted Sessions : 3






LAB 3.5 Configuring and Verifying tLDP

Pod 1 Pod 2

Pod 3

Core 2 Core 1

Core 3

Edge 1

Edge 3

Edge 2

Pod 4

Core 4

Edge 4

10.48.1.0/24 10.64.1.0/24

10.16.1.0/24 10.32.1.0/24

10.x.y.z/24


LDP



Module Summary

Basic provider network configuration includes configuring IOMs, MDAs, system interfaces and the core IGP protocol

LDP configuration is only needed on links that need dynamic label signaling functionality

LDP operation begins with a Hello discovery process

LDP builds LSPs on a hop-by-hop basis by exchange of label mappings

LDP is used primarily for best-effort forwarding, typically in non traffic engineered applications

Export policies are used to generate labels for additional FECs

Import policies are used to determine for which FECs received from peers a router should generate labels




LDP associates a Forwarding Equivalence Class (FEC) with each LSP it creates

Targeted sessions are LDP sessions between non-directly connected peers

Targeted HELLOs are sent to a specific address using unicastrather than multicast

VC labels for VPLS, ePipe and other services are signaled using Targeted LDP (TLDP)



Learning Assessment

1. Which command displays the status of any configured routing and signaling protocols of the local device.

2. Targeted sessions are LDP sessions which can be between _______________ connected peers.

3. What triggers LDP session establishment?

4. Which command displays the count of static, dynamic and detour LSPs?

5. What must be done to enable LDP authentication if configured on an existing LDP session?

6. True or False? When the LDP protocol is enabled, targeted sessions are also enabled.

7. What does the ‘show router ldp bindings’ command show?



1. The ‘show router status’ command displays the status of any configured routing and signaling protocols of the local device.

2. Targeted sessions are LDP sessions which can be between non-directly connected peers.

3. The exchange of LDP Hellos triggers LDP session establishment.

4. The 'show router mpls status' command displays the count of static, dynamic and detour LSPs.

5. To enable LDP authentication on an existing LDP session, the LDP session must be reset with the 'clear router ldpsession' command.

6. True, Targeted LDP is enabled by default when LDP is enabled.

7. The ‘show router ldp bindings’ command displays the router’s LIB.






Module 5 — Constraint Based IGP Enhancements








This module discusses Constraint Based IGP Enhancements as implemented in an MPLS enabled network for Traffic Engineering purposes.


Module Objectives

Understand the role of the IGP in an MPLS environment

Describe the operation of the SPF algorithm

Recognize the need for Traffic Engineering

Describe the IGP Traffic Engineering extensions

Understand the relationship of the enhancements to Traffic Engineering

Understand the operation of the CSPF algorithm

Understand the role of the IGP in an MPLS-TE environment



Constraint Based IGP Enhancements

Section 1 - IGP Review



IGP Review - Section Outline

Role of the IGP

Distance Vector Review

Link State Review


The core IGP is responsible for distribution of routing information across the service provider domain. All destinations in the MPLS domain should be reachable in the IGP, and IGP paths should be optimized based on provider requirements to fully leverage any load sharing or redundant links that may be available.

This is required even if MPLS is not present, or as a prerequisite to the configuration of MPLS in the provider network.


MPLS Prerequisites - IGP Routing

The core IGP is responsible for distribution of routing information

Destinations in the MPLS domain must be reachable in the IGP

IGP paths should be optimized based on provider requirements

MPLS Network

iLER/eLER

10.1.1.0/24

10.2.1.0/24

iLER/eLER

LSR 3

LSR 2LSR 1


Distance Vector protocol operation may be summarized by the following points:

1. Routers perform a direct exchange of their routing tables, within the constraints of Split Horizon

2. Via the all hosts broadcast address of 255.255.255.255 (Multicast may be used in selected cases)

3. With direct neighbors only

4. Periodically


Distance Vector Operation

Routers exchange their routing tables

• Within the constraints of Split Horizon

Via the all hosts broadcast address

• Multicast may be used

With direct neighbors only

PeriodicallyRTR-A RTR-B

RTR-C RTR-D


Distance Vector routers build their view of the network by exchanging their routing tables with their direct neighbors. They only receive updates from their direct neighbors, and those updates only contain the paths that were installed in the neighbors routing table, based on the neighbors selection of 'best' route.

Distance Vector routing updates contain two primary parameters used to determine the best path to reach destination networks:

The distance

A measure of how far away a network is located

Typically expressed as a hop count

The vector

A measure of the direction in which the network is reachable

Typically expressed as an egress interface towards the destination network


Distance Vector Topology Viewpoint

Distance Vector routers are only aware of the route table of their direct neighbors

Distance Vector routing updates contain two primary parameters used to determine the best path to reach destination networks

The distance • A measure of how far away a network is located• Typically expressed as a hop count

The vector• A measure of the direction in which the network is reachable• Typically expressed as an interface


Receiving only the neighbors selection of 'best' path limits the perspective of a Distance Vector router. It is not aware of the topology beyond the directly connected neighbor.

This is a notable limitation of Distance Vector routers from the perspective of Traffic Engineering. This lack of visibility to the network topology beyond any directly connected router makes it impossible for them to build an end to end path across a network.

An additional limiting factor is the decision on which the best route selection is made, which is based only on a hop count.

This results in a primary path which will carry all data traffic, while alternate paths may be unused. Further, the best path selected may not accurately reflect the network topology or the administrative preferences.


Distance Vector Limitations

Only are aware of neighbor’s best routes, not the entire topology

Path selection is based on hop count only

Primary path will carry all data traffic• Alternate paths may be unused

100Mbps

1Gbps

1Gbps1Gbps

RTR-A RTR-B

RTR-C RTR-D


Generic Link State protocol operation may be summarized by the following points:

Topology information is exchanged throughout the entire area, potentially the entire routing domain.

Split Horizon is not an issue.

Information is exchanged via multicast, either at Layer 2 for IS-IS or Layer 3 for OSPF.

Topology information is exchanged with selected direct neighbors. Some routers never exchange routing information with each other.

The entire topology database is initially exchanged between adjacent routers.

The SPF algorithm calculates best paths based on the contents of the topology database

Subsequent updates are event driven, resulting in the generation of a Link State packet.


Link State Overview

Topology information is exchanged throughout the entire area, potentially the entire routing domain

• Split Horizon is not an issue

Information is exchanged via multicast

• Either at Layer 2 or Layer 3

With selected direct neighbors

• Some routers never exchange routing information

Entire topology database is initially exchanged

• Subsequent updates are event driven


Link State protocols maintain three separate databases in each router.

The adjacency database, sometimes called the neighbor database, maintains the list of all routers that have exchanged HELLOs with the local router and formed a neighbor relationship. Not all neighbors become adjacent. An adjacency is a special relationship between two neighbor routers for the purpose of exchanging Link State Information. Adjacencies are formed only with the DR and BDR in OSPF, and with the pseudonode in IS-IS.

The Link State Database (LSDB), sometimes called the topology or SPF database, maintains all known paths to each network, learned via information exchange with adjacent routers. It is this database that is used to calculate the Shortest Path First (SPF) tree, that ultimately is used to create the routing table. A router may maintain more than one topology database depending on its role in the Link State hierarchy.

The routing table, sometimes called the Forwarding Database or Forwarding Information Base, is used by the router to accurately forward IP packets towards the destination network.


Link State Overview

Each router maintains three separate databases

The neighbor database maintains a list of all known neighbors

The Link State database maintains a list of all known paths for each destination network

The forwarding database contains the best paths from the Link State database that have been accepted by the RTM

Adjacency Database Link State Database

Forwarding Database


Link State routers are aware of the entire topology of the local area, and perhaps of the entire network infrastructure, depending on the role of the router. For example a Backbone router maintains topology information of the entire routing domain, while a router internal to a non backbone area may have very limited information in their database.

Link State routing updates contain one primary parameter used for best path selection to reach destination networks, called the Cost.

The Cost metric has the following characteristics:

A calculated metric used as a measure of the bandwidth in the path to the destination

Represents the cumulative end to end value.

By default, OSPF and IS-IS use different implementations of the Cost metric.


Link State Topology Viewpoint

The Link State database is populated with the entire topology information received from selected direct neighbors

Link State routers calculate a cost to reach each destination network based on information contained in the Link State database

Cost

• A metric used to measure the bandwidth in the path to the destination

• Represents the cumulative end to end value


The Link State or topology database of each router contains all known paths to each destination in the routing domain and their calculated cost.

For example, Router E above has two known paths to destination network 192.168.2.0/24, one via Router C with a cumulative Cost of 40 and another via Router D with a cumulative Cost of 30.

The preferred path is the path with the lower cost, in this case, via Router D.


Link State Database

The Link State database contains all available paths to each destination in the routing domain and their calculated cost

RTR-A RTR-B

RTR-C RTR-D

RTR-E

RTR-E Topology Table

192.168.2.0/24via RTR-D, Cost 30via RTR-C, Cost 40

RTR-E Topology Table

192.168.2.0/24via RTR-D, Cost 30via RTR-C, Cost 40

192.168.2.0/24

Cost=10

Cost=10

Cost=10 Cost=10

Cost=10


Although Link State routers are aware of far more of the topology than a Distance Vector router, it may not be able to use this information. Path selection is based on one parameter only, the cost.

This results in a primary path which will carry all data traffic, while alternate paths may be unused. Further, the best path selected may not accurately reflect the administratively desired traffic preferences.


Link State Limitations

Path selection is based on cost only

Primary path will carry all data traffic• Alternate paths may be unused

RTR-A RTR-B

RTR-C RTR-D

RTR-E

RTR-E Routing Table

192.168.2.0/24 via RTR-D

RTR-E Routing Table

192.168.2.0/24 via RTR-D

192.168.2.0/24


Link State protocols maintain a complex database of topology information of the entire network, learned from adjacent neighbors.

Link State protocols maintain a full database of distant routers and networks, how they interconnect and the cost between them.

Link State Packets (LSPs) are used to transmit the information necessary to build the topological database.

Unlike Distance Vector protocols, Link State packets are propagated to all routers in a Link State area or routing domain, and not just to the directly connected neighbor.

The Link State topology exchange process can be summarized by the following steps.

1. Each router originates a Link State Packet for each of its directly connected interfaces and for its neighbor routers.

2. Adjacent routers exchange these Link State Packets with adjacent routers.

3. Link State Packets received from other routers are flooded within the domain based on their type

4. Each router populates its topological database with all received Link State Packets.

Once the Topology Database has been populated, an SPF calculation will occur.


Topology Exchange

Topology at RTR-A192.168.2.0/24

via RTR-B, Cost 20via RTR-C, Cost 30

Topology at RTR-A192.168.2.0/24

via RTR-B, Cost 20via RTR-C, Cost 30

192.168.2.0/24

RTR-A

RTR-B

RTR-C

RTR-D

Adjacent neighbors exchange their topology databases in Link State updates• Each router in an area has a complete network topology of the

area

Note: All links have a Cost of 10

Link State updates

Topology at RTR-D192.168.2.0/24

via RTR-A, Cost 30

Topology at RTR-D192.168.2.0/24

via RTR-A, Cost 30Topology at RTR-C192.168.2.0/24

via RTR-B, Cost 20via RTR-A, Cost 30

Topology at RTR-C192.168.2.0/24

via RTR-B, Cost 20via RTR-A, Cost 30

Topology at RTR-B192.168.2.0/24

Direct, Cost 10

Topology at RTR-B192.168.2.0/24

Direct, Cost 10


The SPF algorithm is used to determine the best path through the network to each known destination based on the cost.

All best paths as derived by the SPF calculations are offered to the Routing Table Manager (RTM) for consideration as the active route.

If selected as the active route, the path will be installed in the routing table and used for forwarding data.


Shortest Path First Algorithm Overview

The SPF algorithm calculates the best path for each destination from all entries in the topology database

Routing Table at RTR-A192.168.2.0/24 via RTR-B

Routing Table at RTR-A192.168.2.0/24 via RTR-B

192.168.2.0/24

RTR-A

RTR-B

RTR-C

RTR-D

Routing Table at RTR-D192.168.2.0/24 via RTR-A

Routing Table at RTR-D192.168.2.0/24 via RTR-A

Routing Table at RTR-C192.168.2.0/24 via RTR-B

Routing Table at RTR-C192.168.2.0/24 via RTR-B

Routing Table at RTR-192.168.2.0/24 via Direct

Routing Table at RTR-192.168.2.0/24 via Direct


The table shown above provides a comparison of the types, usage and propagation limitations of common OSPF LSAs.


Link State Packet Types - OSPF

LSA Type

/Number

Advertises Generated By

Propagation

Router - 1 Directly attached links All routers Area of origin

Network - 2 All routers on the network All DRs Area of origin

Summary

Network - 3

Summary of networks within an area

ABR Across backbone to other areas except totally stubby

ASBR - 4 Location of the ASBR ABR Across backbone to other areas except totally stubby

External - 5 Networks outside the Autonomous System

ASBR Across backbone to other non stub areas

NSSA External - 7 Networks of the NSSA NSSA ASBR NSSA Area only

Summary of OSPF LSAs and their characteristics


The table shown above provides a comparison of the types, usage and propagation limitations of the IS-IS Link State packets.


Link State Packet Types - ISIS

TLV Type Propagation

128 IP Internal Reachability Level 1 and Level 2129 Protocols Supported Level 1 and Level 2130 IP External Reachability Level 2 only131 Inter Domain Routing Level 2 only132 IP Interface Address Level 1 and Level 2

Summary of IS-IS TLVs and their characteristics


The comparison above shows the differences, and similarities, in RIPv2, OSPF, and IS-IS based on default behavior. All three protocols are supported on the Alcatel-Lucent 7X50. RIPv1 is not shown as it is not the default implementation of RIP, when configured on the 7X50.

ISIS and OSPF are very similar in ability and operation. The major difference lies in how they are configured and optimized.

Link State protocols maintain a topology database, potentially of the entire domain, and are therefore aware of the end to end network topology, unlike their Distance Vector counterparts.

For the purposes implementing MPLS Traffic Engineering, only protocols that maintain a full network topology can be considered reliable to make routing decisions.


IGP Comparison

Feature RIP v2 OSPF IS-IS

Protocol Category Distance Vector Link State Link State

Updates Periodic Incremental Incremental

Update Mechanism Broadcast/Multicast Layer 3 Multicast Layer 2 Multicast

Authentication Simple and MD5 Simple and MD5 Simple and MD5

Metric Hop Count Cost Cost

VLSM / CIDR Support Yes Yes Yes

Topology Size Small Very Large Very Large

Topology Awareness Direct Neighbors Entire Network Entire Network

Alternate Path Usage No No No

Summarization Manual Manual Manual

Convergence Slow Fast Fast

Suitable for MPLS-TE No Yes Yes



Section 2 - Constraint Based Routing Overview



Constraint Based Routing Overview - Section Outline

Constraint-Based Routing

Constraint-Based Routed LSPs

IGP Traffic Engineering Extensions• OSPF-TE• ISIS-TE

CSPF


Path oriented technologies such as MPLS have made constraint-based routing feasible and attractive in public IP networks.

Constraint-based routing refers to a class of routing systems that compute routes through a network subject to the satisfaction of a set of constraints and requirements.

The constraints and requirements may be imposed by the network itself or by administrative policies

Note: Reference RFC 3272 - Overview and Principles of Internet Traffic Engineering


Constraint-Based Routing (CR)

Constraint-based routing is a general mechanism used to meet Traffic Engineering requirements

CR refers to a routing protocol that computes routes subject to the satisfaction of a set of constraints and requirements

The routing constraints and requirements can be performance based or defined by administrative policy

When a routing protocol calculates a path that is optimal and is within a defined set of constraints, it is referred to as a Constraint-based route


The traditional IGP routing algorithm has calculated a best path through the network, and possibly signaled an LSP via this path.

The Constraint-based routing algorithm independently calculates a best path through the MPLS domain based on the network topology information and additional defined administrative parameters (constraints).

MPLS LSP establishment, typically using RSVP, will signal the LSP using this path provided by the constraint-based algorithm.

This LSP is referred to as the Constraint-Based Routed Label Switched Path (CR-LSP).

As shown above, it is common that the Constraint-based route is a different path across the network than the route that was selected as the IGP's best route.


Constraint-Based (CR) Routing and MPLS

The constraint-based IGP first selects a best path based on the defined parameters

MPLS signals and establishes the LSP using the constraint-based route

This LSP is referred to as a Constraint-Based Routed Label Switched Path (CR-LSP)

MPLS Network

CR-LSP

IGP Best PathConstraint Best Path

IGP based LSP


Like any other LSP, a Constraint-Based Routed Label Switched Path (CR-LSP) is a path through an MPLS network.

The difference is that traditional IGP paths are selected at each hop solely based on information in IGP topology tables, and LSPs are signaled with this information, the Constraint-based path is calculated at one point at the edge of network based on information in IGP topology tables and additional input provided by Traffic Engineering extensions to the IGP protocols.


Constraint-Based Routed LSPs

A CR-LSP is a administratively defined path through an MPLS network

It differs from a traditional LSP in that• IGP based paths are established solely from information contained

in routing tables• The CR path is calculated at the edge of network based on routing

tables and additional criteria


CR LSPs become useful in cases where the IGP routed path is different from the desired path for the LSP, such as cases where the following factors must be considered:

Availability or utilization of bandwidth

QoS characteristics

To ensure that alternative routes use physically separate paths


Constraint Route LSPs

CR-LSPs are useful in cases where the desired path for the LSP is different from the IGP routed pathPath can be based on • Availability or utilization of bandwidth • QoS characteristics • To ensure that alternative routes use physically separate paths

MPLS Network

Backup LSP

Primary LSP


Constraint-based algorithms have been implemented by the following protocols:

Existing IGP Link State routing protocols have been enhanced to provide support for Traffic Engineering capabilities. Protocol extensions have been defined for both OSPF and IS-IS. The version of these standard IGP protocols, when enhanced to support the Traffic Engineering capabilities, are now known by the following names:

OSPF-TE

ISIS-TE

These protocols offer input to a distinct Traffic Engineering database, where the SPF algorithm calculates the best paths.


Constraint Based Routing Protocols

Existing IGP routing protocols have been enhanced to provide support for Traffic Engineering capabilities

Protocol extensions have been defined for both OSPF and IS-IS• OSPF-TE• ISIS-TE

These protocols offer input to another database where the SPF algorithm calculates the best paths


Traffic Engineering extensions to OSPF (OSPF-TE) are implemented using OSPF Opaque LSAs. The Opaque LSA definition originated in RFC 2370 - The OSPF Opaque LSA Option, but this RFC does not define Traffic Engineering capabilities.

The OSPF Opaque LSAs are a generic mechanism that has been used to implement MPLS-TE. These LSAs allow constraint based information to be propagated in LSAs and flooded in traditional Link State fashion.

The Opaque LSAs are collected in a Traffic Engineering Database (TED), separate from the traditional OSPF topology database.


OSPF-TE

Traffic Engineering extensions to OSPF are implemented using OSPF Opaque LSAs

Originated in RFC 2370 - The OSPF Opaque LSA Option

These LSAs allow constraint based information to be propagated to other routers in the MPLS domain

The Opaque LSAs are collected in a Traffic Engineering Database (TED)


Traffic Engineering extensions to IS-IS (ISIS-TE) are implemented using additional IS-IS sub-TLVs defined in RFC 3784 - IS-IS Extensions for Traffic Engineering.

These additional TLVs allow constraint based information to be propagated in IS-IS Link State Packets (LSPs) and flooded to other routers in the MPLS domain.

The TLVs are collected in a Traffic Engineering Database (TED).


IS-IS-TE

Traffic Engineering extensions to IS-IS are implemented using additional Type Length Value fields (TLVs)

Defined in RFC 3784 - IS-IS Extensions for Traffic Engineering

These additional TLVs allow constraint based information to be propagated in IS-IS LSPs and to other routers in the MPLS domain

The TLVs are collected in a Traffic Engineering Database (TED)


A specialized database called the Traffic Engineering Database (TED) of network link attributes and topology information is maintained so that Traffic Engineering computations are 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.


TED

A specialized Traffic Engineering Database (TED) of network link attributes and topology information is maintained

TED contains the topological constraints• Topology Link State information learned from the IGP • Attributes associated with the state of network resources

Administrative policy requirements obtained from user configuration may be used as additional constraints to the TED


Topology information is flooded within the Link State hierarchy.

The IGP topology database is created by the flooding of traditional Link State information, in traditional fashion.

The Traffic Engineering Database (TED) is created by the flooding of the Link State information containing Traffic Engineering extensions.

The standard flooding algorithm used by the Link State IGP ensures that the link attributes are propagated to all routers in the routing domain, based on the message type. The IGP performs a SPF calculation based on the IGP topology database to derive the best routes.

A SPF calculation is performed on the TED exclusively for calculating the Constraint-based paths.


IGP Topology and TED

Topology information is flooded within the Link State hierarchy for both traditional and Traffic Engineering LSAs

The standard flooding algorithm implemented by the Link State IGP is used

The IGP performs a SPF calculation based on the IGP topology database

A SPF calculation is performed on the TED exclusively for calculating the Constraint-based paths• Prune links not meeting administrative constraints• Perform SPF calculation on remaining links


The Constrained Shortest Path First algorithm is used with Link State routing protocols such as OSPF and IS-IS to calculate constraint based routes. It resolves Quality of Service routing queries, finding the best route that meets specified constraints, such as a specified minimum bandwidth and other factors.

CSPF is a SPF (Dijkstra) algorithm whose input is the Traffic Engineering Database (TED) and the LSP constraints.


Constrained Shortest Path First (CSPF)

CSPF performs its route calculations on the Traffic Engineering database (TED) and administrative input

CSPF calculates the shortest path based on the administrative constraints provided in the TE Extensions• Bandwidth• Class of service• Specified hops• Others

Links in the TED that do not meet the constraints are pruned, then the SPF calculation is performed on remaining links


The Constrained Shortest Path First (CSPF) routing algorithm is required to find a path which satisfies the constraints for the LSP.

Once the path is found by CSPF, RSVP uses the path to request the LSP establishment.


CSPF and MPLS

The Constrained Shortest Path First (CSPF) routing algorithm is required to find a path which satisfies the constraints for the LSP

Once the path is found by CSPF, RSVP uses the path to request the LSP establishment

MPLS Network

IGP TED

Topology Databases

TEDBest Path via P 2

P 2

P 1 P 3

IGPBest Path via P 1 RSVP Signaling

SPF CSPF


To maintain scalability and isolation between the topologies, the IGP topology database and the TED are separate data structures. This allows updates or SPF calculations in one database to remain independent of the other.

For example, if a link failure occurs between P1 and P3 above, assuming MPLS and IGP Traffic Engineering have both been enabled, will cause an LSA (in the case of OSPF) to be generated and propagated into the IGP topology database and the TED of the other routers.

A new SPF calculation will be performed on the IGP topology database and a new IGP best route is selected based on the failure. This will cause a convergence issue in the IGP.

A new CSPF calculation will be performed on the TED. However a new TE best route is not required since the existing path did not use the failed link. The result is that there is no change of best route from the perspective of CSPF, and no resulting convergence issue exists.

If TE was not enabled between P1 and P3, the TED would not even require a new CSPF calculation, as an LSA would not be generated outside of the IGP.


IGP Topology and TED Isolation

The IGP topology database and the TED are separate

A link event in one database may be isolated from the other

Convergence may require an SPF calculation in only one database on certain link failures

MPLS Network

IGP TED

Topology Databases

TEDBest Path via P 2

P 2

P 1 P 3

IGPBest Path via P 1

SPF CSPF



Section 3 - OSPF-TE Extensions



OSPF-TE Extensions - Section Outline

OSPF Opaque LSAs

OSPF Traffic Engineering LSA

Opaque LSA CLI Verification


Over the last several years the OSPF routing protocol has been widely deployed throughout the Internet.

As a result of this deployment and the evolution of networking technology, OSPF has been extended to support many options. RFC 2370 defines enhancements to the OSPF protocol to support a new class of Link State advertisements (LSA) called Opaque LSAs.

Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. The information contained in Opaque LSAs may be used directly by OSPF or indirectly by some application wishing to distribute information throughout the OSPF domain.

The exact use of Opaque LSAs is not defined in RFC 2370. MPLS-TE is simply one implementation. The Opaque LSA itself defines the container for the information to be carried within it.


OSPF Opaque LSA Overview

RFC 2370 defines enhancements to the OSPF protocol to support a new class of Link State advertisements (LSA) called Opaque LSAs

Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF

The information contained in Opaque LSAs may be used directly by OSPF or indirectly by some application wishing to distribute information throughout the OSPF domain

The exact use of Opaque LSAs is not defined in the RFC


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.

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 state ExStart state.

A neighbor is opaque capable if and only if it sets the O-bit in the Options field of its Database Description packets; the O-bit is not set in packets other than Database Description packets.

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, receiving LSAs having unknown Link State types.


OSPF Opaque LSA Propagation

OSPF LSAs should only be flooded to those routers that understand them

A neighbor is determined to be opaque capable if it sets the O-bit in the options field of its Database Description packets

Opaque LSAs are included in the database summary list that is sent to the neighbor when the opaque capability is advertised


Opaque LSAs are defined as Link State types 9, 10 and 11 Link State advertisements. Opaque LSAs consist of a standard LSA header followed by a 32-bit aligned application specific information field.

Standard Link State database flooding mechanisms are used for distribution of Opaque LSAs. The range of topological distribution (the flooding scope) of an Opaque LSA is identified by its Link State type.


Opaque LSA Definition

Opaque LSAs are types 9, 10 and 11 Link State Advertisements

Standard Link State database flooding mechanisms are used for distribution of the Opaque LSAs

The flooding scope of an Opaque LSA is identified by its Link State type


Link State type 9 denotes a link-local scope LSA. Type 9 Opaque LSAs are not flooded beyond the local (sub)network.

As a result of this behavior, these LSAs do not permit any Traffic Engineering application external to the local data-link. In other words, they are only applicable between directly connected devices.


Type 9 LSA - Link Local LSA

A Link State Advertisement of type 9 denotes a link-local scope Opaque LSA

Type 9 Opaque LSAs are not flooded beyond the local (sub)network

Area 1

Type 9 LSA


Link State type 10 denotes an area-local scope LSA. Type 10 Opaque LSAs are not flooded beyond the borders of their associated (originating) area.

As a result of this behavior, these LSAs do not permit any inter-area Traffic Engineering application. Therefore at present, any routing domain that will implement traffic engineering should be configured as a single area.


Type 10 LSA - Area Local LSA

A Link State Advertisement of type 10 denotes an area local scope Opaque LSA

Type 10 Opaque LSAs are not flooded beyond the borders of their originating area

Area 1

Type 10 LSA


Link State type 11 denotes that the LSA is flooded throughout the Autonomous System (AS). The flooding scope of type 11 LSAs are equivalent to the flooding scope of AS-External (type 5) LSAs.

Specifically, type 11 Opaque LSAs are:

1. Flooded throughout all transit areas

2. Not flooded into stub areas from the backbone

3. Not originated by routers into their connected stub areas

As with type 5 LSAs, if a type 11 Opaque LSA is received in a stub area from a neighboring router within the stub area, the LSA is rejected.

These LSAs enable inter-area Traffic Engineering applications.


Type 11 LSA - Network LSA

A Link State Advertisement of type 11 denotes that the LSA is flooded throughout the Autonomous System

Flooding behavior is the same as Type 5 AS-External LSAs

Area 1

Type 11 LSA

Area 0

Type 11 LSA

Autonomous System


The comparison above shows the types and usage of the OSPF Opaque LSAs.

These LSAs are used to support protocol extensions defined within OSPF for Traffic Engineering implementations. They are used by protocols such as CSPF to calculate the best path to a destination based upon Traffic Engineering criteria, in order to implement MPLS-TE.

Type 9 LSA – Local-Link LSAs are not flooded beyond the local network they are propagated on.

Type 10 LSA – Intra-area LSAs are not forwarded by the ABR connected to the area they are originated in.

Type 11 LSA – Network LSAs are flooded throughout the entire OSPF Autonomous System.


Opaque Link State Packet Types - OSPF

LSA Type

/Number

Advertises Generated By Propagation

Opaque 9 Not defined in RFC Graceful Restart Local LinkOpaque 10 Not defined in RFC Any TE capable device Area of origin

Opaque 11 Not defined in RFC TBD All non-stub areas

Summary of OSPF Opaque LSAs and their characteristics

Area 1 Area 0

Type 11 LSA

Type 10 LSA

Type 9 LSA Area 2 Stub

Type 9, 10 or 11 LSA


OSPF Traffic Engineering capabilities are defined in RFC 3630 - Traffic Engineering (TE) Extensions to OSPF Version 2. The RFC specifies a method of adding Traffic Engineering capabilities to OSPF Version 2.

The extensions provide a way of describing the Traffic Engineering topology including bandwidth and administrative constraints and distributing this information within a given OSPF area. The Traffic Engineering extensions are applicable in a single area only. No changes have been made to the operation of OSPF v2 flooding process.

If non-TE capable nodes exist in the topology, they MUST none-the-less flood TE LSAs that they receive to their other peers. The non-TE capable nodes will not make use of the TE LSAs themselves.

The mechanisms used for Traffic Engineering across multiple OSPF areas is not defined in RFC 3630.


OSPF Traffic Engineering Implementation

Defined in RFC 3630 - Traffic Engineering (TE) Extensions to OSPF Version 2

The extensions provide a way of describing and distributing the Traffic Engineering topology information

Only applies within a given OSPF area

If non-TE capable nodes exist in the topology, they MUST still flood the Traffic Engineering LSAs they receive, onto their neighbors


Traffic Engineering extensions make use of the Type 10 Area Local Opaque LSA as defined in RFC 2370. One new LSA is defined, the Traffic Engineering LSA.

This LSA describes routers, point-to-point links, and connections to multi-access networks (similar to a Router LSA). For Traffic Engineering purposes, the existing Network LSA is sufficient for describing multi-access links, so no additional LSA is defined for this purpose.

The LSA ID of an Opaque LSA is defined as having eight bits of type data and 24 bits of type specific data. The Traffic Engineering LSA uses type 1.

The Instance field is an arbitrary value used to maintain multiple Traffic Engineering LSAs. A maximum of 16,777,216 Traffic Engineering LSAs may be sourced by a single system. The LSA ID has no topological significance.


Traffic Engineering LSA Structure

This TE extension makes use of the Type 10 Area Local Opaque LSA as defined in RFC 2370

This LSA describes routers, point-to-point links, and connections to multi-access networks

7 31

Type Instance

0


The Traffic Engineering LSA starts with the standard LSA header. The LSA payload consists of one or more nested Type Length Value (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.


Traffic Engineering LSA Structure

The Traffic Engineering LSA starts with the standard LSA header

The LSA payload consists of one or more nested Type Length Value (TLV) triplets for extensibility

The Value field is of variable length

15 31

Type Length

0

Value

OSPF TLV


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.

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.


Traffic Engineering LSA Payload

Two different sub-types of type 10 LSAs• Contain one of two top-level TLVs

Router Address - Type 1• The Router Address TLV specifies a stable IP address of the

advertising router that is always reachable

Link - Type 2• The Link TLV describes a single link• Only one Link TLV is carried in each LSA


There are 9 defined sub-TLVs of the Link TLV:

1. Link type (1 octet)

2. Link ID (4 octets)

3. Local interface IP address (4 octets)

4. Remote interface IP address (4 octets)

5. Traffic Engineering metric (4 octets)

6. Maximum bandwidth (4 octets)

7. Maximum reservable bandwidth (4 octets)

8. Unreserved bandwidth (32 octets)

9. Administrative group (4 octets)


Link TLV Sub Types

The following sub-TLVs of the Link TLV are defined1. Link type (1 octet)2. Link ID (4 octets)3. Local interface IP address (4 octets)4. Remote interface IP address (4 octets)5. Traffic Engineering metric (4 octets)6. Maximum bandwidth (4 octets)7. Maximum reservable bandwidth (4 octets)8. Unreserved bandwidth (32 octets)9. Administrative group (4 octets)


The Link Type sub-TLV defines the type of the link:

Point-to-point

Multi-access

The Link Type sub-TLV is TLV type 1, and is one octet in length. The TLV and is mandatory and must be included in all OSPF Opaque LSAs.


Link Type

The Link Type sub-TLV defines the type of the link• Point-to-point• Multi-access

RTR-A

RTR-B

RTR-C

RTR-D

RTR-E


The Link ID sub-TLV 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 Link ID sub-TLV is TLV type 2, and is four octets in length. The TLV and is mandatory and must be included in all OSPF Opaque LSAs.


Link ID

The Link ID sub-TLV 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 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 Local Interface IP Address sub-TLV is TLV type 3, and is 4N octets in length, where N is the number of local addresses.


Local Interface IP Address

The Local Interface IP Address sub-TLV 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 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; alternatively, an implementation MAY choose not to send this sub-TLV.

The Remote Interface IP Address sub-TLV is TLV type 4, and is 4N octets in length, where N is the number of neighbor addresses.


Remote Interface IP Address

The Remote Interface IP Address sub-TLV 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 is multi-access, the Remote Interface IP

Address is set to 0.0.0.0• Alternatively, an implementation MAY choose not to send this

sub-TLV


The Traffic Engineering metric sub-TLV specifies the link metric for Traffic Engineering purposes. This metric may be different than the standard OSPF link metric. Typically, this metric is assigned by a network administrator. Note that currently on the 7x50 SR/ESS it is not possible to explicitly configure the TE metric. Its value is automatically set to be the same as the regular IGP metric.

The Traffic Engineering metric sub-TLV is TLV type 5, and is four octets in length.


Traffic Engineering Metric

The Traffic Engineering metric sub-TLV specifies the link metric for Traffic Engineering purposes

This metric may be different than the standard OSPF link metric

Typically, this metric is assigned by a network administrator


The Maximum Bandwidth sub-TLV 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 bytes per second.

The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in length.


Maximum Bandwidth

The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that can be used on this link in this direction (from the system originating the LSA to its neighbor)

This is the true link capacity


The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link, in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). This SHOULD be user-configurable; the default value should be the Maximum Bandwidth. The units are bytes per second.

The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four octets in length.


Maximum Reservable Bandwidth

The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link in this direction

This may be greater than the maximum bandwidth in which case the link may be oversubscribed

This value is configurable under the RSVP>Interface context using the subscription value as a percentage.

The default is 100. Can be set to 0-1000.


The Unreserved Bandwidth sub-TLV 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 ReservableBandwidth. 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 TLV type 8, and is 32 octets in length.


Unreserved Bandwidth

The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels

The values correspond to the bandwidth that can be reserved at each priority level of 0 through 7

Each value will be less than or equal to the Maximum Reservable Bandwidth, with the initial value set to the Maximum Reservable Bandwidth


The Administrative Group sub-TLV 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.

The Administrative Group sub-TLV is TLV type 9, and is four octets in length.


Administrative Group

The Administrative Group sub-TLV 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




ISIS-TE Extensions



ISIS-TE Extensions - Section Outline

ISIS Traffic Engineering TLVs• Structure• Payload

Verification


RFC 3784 extends the IS-IS IGP routing protocol by specifying new information that an Intermediate System can place in Link State Protocol Data Units (PDU). It defines the design to include additional information about the characteristics of a particular link in an IS-IS LSP needed for Traffic Engineering.

Traffic engineering is implemented through the introduction of new sub-TLVs to the IS-IS protocol. If an IS receives an unknown sub-TLV, it is to be ignored upon receipt.


ISIS-TE Overview

RFC 3784 extends the IS-IS protocol by specifying new information that an Intermediate System can place in Link State Protocol (LSP) Data Units

Defines the design to include additional information about the characteristics of a particular link in an IS-IS LSP needed for Traffic Engineering

Implemented by the introduction of sub-TLVs to the IS-IS protocol• Unknown sub-TLVs are to be ignored upon receipt15 31

Type Length

0

Value

IS-IS TLV


The Traffic Engineering router ID TLV is TLV type 134.

The router ID TLV contains the 4-octet router ID of the router originating the LSP. This is useful in several regards: For Traffic Engineering, it guarantees that we have a single stable address that can always be referenced in a path that will be reachable from multiple hops away, regardless of the state of the node's interfaces. If OSPF is also active in the domain, Traffic Engineering can compute the mapping between the OSPF and IS-IS topologies.

If a router does not implement Traffic Engineering, it MAY add or omit the Traffic Engineering router ID TLV. If a router implements Traffic Engineering, it MUST include this TLV in its LSP. This TLV SHOULD not be included more than once in an LSP.

If a router advertises the Traffic Engineering router ID TLV in its LSP, and if it advertises prefixes via the Border Gateway Protocol (BGP) with the BGP next hop attribute set to the BGP router ID, the Traffic Engineering router ID SHOULD be the same as the BGP router ID.


Traffic Engineering Router ID TLV

The Traffic Engineering router ID TLV is TLV type 134

The router ID TLV contains the 4-octet router ID of the router originating the Link State Packet (LSP)

For Traffic Engineering, it guarantees that we have a single stable address that can always be referenced in a path that will be reachable from multiple hops away, regardless of the state of the node's interfaces

If a router implements Traffic Engineering, it must include this TLV in its LSP, otherwise it is considered optional

This TLV should not be included more than once in an LSP


The IS Neighbors TLV is TLV type 2 and contains the following structure:

The default metric

The delay

The monetary cost

The reliability

The 7 octet ID of the adjacent neighbor

In most IS-IS implementations, the one octet default metric is the only commonly used field. The other traditional IS-IS IGP metrics are not implemented. The structure of the default metric is as follows.

One bit is used to indicate whether the metric is internal or external

One bit is defined by RFC 2966 to be the up/down bit

The remaining 6 bits are used for the actual metric, resulting in a range of Cost metric values from 0 to 63.


IS Reachability/Neighbors TLV (type 2)

The existing IS Neighbors TLV is TLV type 2

Contains the following structure• The default metric• The delay• The monetary cost• The reliability• The 7 octet ID of the adjacent neighbor

The one octet default metric is the only commonly used field• Only 6 bits are used for the actual IS-IS metric• Allows a cost range of 1-63


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

Thus, if no sub-TLVs are used, the new encoding requires 11 octets and can contain up to 23 neighbors. Please note that while the encoding allows for 255 octets of sub-TLVs, the maximum value cannot fit in the overall IS reachability TLV. The practical maximum is 255 octets minus the 11 octets described above, or 244 octets. Further, there is no defined mechanism for extending the sub-TLV space for a particular neighbor. Thus, wasting sub-TLV space is discouraged. The metric octets are encoded as a 24-bit unsigned integer. Note that the metric field in the new extended IP reachabilityTLV is encoded as a 32-bit unsigned integer. These different sizes were chosen so that it is very unlikely that the cost of an intra-area route has to be chopped off to fit in the metric field of an inter-area route.


Revised Extended IS Reachability/Neighbors TLV (type 22)

The revised extended IS reachability/neighbors TLV contains a new data structure consisting of:• 7 octets of system ID and pseudonode number• 3 octets of default metric

— allows cost range of 1-16777215

• 1 octet of length of sub-TLVs• 0-244 octets of sub-TLVs consisting of

— 1 octet of sub-type

— 1 octet of length of the value field of the sub-TLV

— 0-242 octets of value

The sub-TLVs are used to propagate the TE information


The new IS-IS 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.


IS-IS Sub-TLV Types

Sub-TLV type Length (octets) Name

3 4 Administrative group (color)

6 4 IPv4 interface address

8 4 IPv4 neighbor address

9 4 Maximum link bandwidth

10 4 Reservable link bandwidth

11 32 Unreserved bandwidth

18 3 TE Default metric

250-254 Reserved for vendor specific extensions

255 Reserved for future expansion

IS-IS TE Sub-TLV codes and definitions


The administrative group sub-TLV, also known as color or resource class, contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface.

By convention, the least significant bit is referred to as 'group 0', and the most significant bit is referred to as 'group 31'.

This sub-TLV is OPTIONAL. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.


Administrative Group

The administrative group sub-TLV contains a 4-octet bit mask assigned by the network administrator

The Administrative Group is also known as Resource Class or Color

Each set bit corresponds to one administrative group assigned to the interface

By convention, the least significant bit is referred to as 'group 0', and the most significant bit is referred to as 'group 31'

This sub-TLV is optional and should appear once at most in each extended IS reachability TLV


This sub-TLV contains a 4-octet IPv4 address for the interface described by the (main) TLV. This sub-TLV can occur multiple times.

If a router implements Traffic Engineering, it MUST include this sub-TLV.


IPv4 Interface Address

This sub-TLV contains a 4-octet IPv4 address for the interface described by the main TLV

This sub-TLV can occur multiple times

If a router implements Traffic Engineering, it must include this sub-TLV, otherwise it is considered optional


This sub-TLV contains a single IPv4 address for a neighboring router on this link. This sub-TLV can occur multiple times.

If a router implements Traffic Engineering, it MUST include this sub-TLV on point-to-point adjacencies.


IPv4 Neighbor Address

This sub-TLV contains a single IPv4 address for a neighboring router on this link

This sub-TLV can occur multiple times

If a router implements Traffic Engineering, it must include this sub-TLV on point-to-point adjacencies, otherwise it is optional


This sub-TLV contains the maximum bandwidth that can be used on this link in this direction (from the system originating the LSP to its neighbors). This is useful for Traffic Engineering.

The maximum link bandwidth is encoded in 32 bits in IEEE floating point format. The units are bytes (not bits!) per second. This sub-TLV is optional.

This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.


Maximum Link Bandwidth

This sub-TLV contains the maximum bandwidth that can be used on this link in this direction (from the system originating the LSP to its neighbors)

The value is 32 bits long and is specified in bytes per second



This sub-TLV contains the maximum amount of bandwidth that can be reserved in this direction on this link. Note that for oversubscription purposes, this can be greater than the bandwidth of the link.

The maximum reservable link bandwidth is encoded in 32 bits in IEEE floating point format. The units are bytes (not bits!) per second. This sub-TLV is optional.



Maximum Reservable Link Bandwidth

This sub-TLV contains the maximum amount of bandwidth that can be reserved in this direction on this link• Note that this may be greater than the maximum bandwidth in

which case the link may be oversubscribed

The value is 32 bits long and is specified in kilobits per second


This value is configurable under the RSVP>Interface context using the subscription value as a percentage.

The default is 100. Can be set to 0-1000.


This sub-TLV contains the amount of bandwidth reservable in this direction on this link. Note that for oversubscription purposes, this can be greater than the bandwidth of the link.

Because of the need for priority and preemption, each head end needs to know the amount of reserved bandwidth at each priority level. Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers. The units are bytes (not bits!) per second. 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.

For stability reasons, rapid changes in the values in this sub-TLV SHOULD NOT cause rapid generation of LSPs. This sub-TLV is optional.



Unreserved Bandwidth

This sub-TLV contains the amount of bandwidth reservable in this direction on this link

For oversubscription purposes, this can be greater than the bandwidth of the link

Each head end needs to know the amount of reservablebandwidth at each priority level of 0 through 7

The value is 32 bits long and is specified in bytes per second



This sub-TLV contains a 24-bit unsigned integer. This metric is administratively assigned and can be used to present a differently weighted topology to Traffic Engineering SPF calculations. Note that currently on the 7x50 SR/ESS it is not possible to explicitly configure the TE metric. Its value is automatically set to be the same as the regular IGP metric.

This sub-TLV is optional. This sub-TLV SHOULD appear once at most in each extended IS reachability TLV.

If a link is advertised without this sub-TLV, Traffic Engineering SPF calculations MUST use the normal default metric of this link, which is advertised in the fixed part of the extended IS reachability TLV.


Traffic Engineering Default Metric

This metric is administratively assigned and can be used to present a differently weighted topology to Traffic Engineering SPF calculations


If a link is advertised without this sub-TLV, Traffic Engineering SPF calculations must use the normal default metric of this link• This is advertised in the fixed part of the extended IS

reachability TLV


In all routing protocols, if a link is advertised with the maximum link metric, this link MUST NOT be considered during the normal SPF computation.

All routing protocols ignore links containing an infinite metric.

If an administrator advertises the same link with an infinite metric in the IGP database, but a non-infinite metric in the TED, this will allow advertisement of a link for purposes other than building the normal Shortest Path Tree. As an example, the link would be available for Traffic Engineering purposes, but not for hop-by-hop routing.

This allows an administrator to have non congruent IGP and TE topologies across a given MPLS network infrastructure.


Link Reservation Example

If a link is advertised with a link metric of 'infinity', this link MUST NOT be considered during the normal SPF computation

This will allow advertisement of a link for purposes other than building the normal Shortest Path Tree

An example is a link that is available for Traffic Engineering, but not for hop-by-hop routing



Section 4 - Enabling IGP TE Extensions and CSPF Operation &

Configuration



Enabling IGP TE Extensions - Section Outline

How Traffic Engineering Works

Enabling IGP TE extensions

Verifying the TE Database

CSPF Algorithm

Attributes used as Constraints

Configuring CSPF and attributes


Traffic Engineering requires dynamic and detailed knowledge of the network topology.

The control plane component is implemented by defining IGP extensions so that link attributes are included in each routing update. Opaque Link State Advertisements (LSAs) for OSPF are implemented. Type Length Value (TLV) extensions to IS-IS are required.

Best route selection will be computed via the SPF algorithm based on information contained in the TE extensions stored in the TED and on user defined constraints.


How Traffic Engineering Works

Traffic Engineering requires dynamic and detailed knowledge of the network topology

The control plane is implemented by defining IGP extensions so that link attributes are included in each routing update

• Opaque Link State Advertisements (LSAs) for OSPF are implemented

• Type Length Value (TLV) extensions to IS-IS are required

Best route selection will be computed via a SPF algorithm based on information contained in the TED and user defined constraints


In order to enable support for either the OSPF Opaque LSAs or ISIS TE TLVs, the Traffic Engineering extensions must be enabled for the IGP protocol in use. This is done with the 'traffic-engineering' command configured in the protocol context.

The interfaces specified in the routing protocol context must also be in defined in MPLS in order to generate a complete TE Database.

Without these commands entered there is no way to view the OSPF TE Opaque LSAs or ISIS TE TLVs.


Enabling IGP Extensions

Traffic Engineering extensions must be enabled for the IGP protocol in use

A:PE-1# configure router

A:PE-1>config>router# ospf

A:PE-1>config>router>ospf# traffic-engineering

A:PE-1>config>router>isis# exit all

A:PE-1#


A:PE-1>config>router# ospf

A:PE-1>config>router>ospf# traffic-engineering


A:PE-1#


A:PE-1>config>router# isis

A:PE-1>config>router>isis# traffic-engineering


A:PE-1#


A:PE-1>config>router# isis

A:PE-1>config>router>isis# traffic-engineering


A:PE-1#


This command is used to confirm the parameters configured for ospf. In this example, Traffic Engineering Support is shown as “True”. This is a required configuration in order to enable Opaque LSAs to be created and advertised. Although this command is necessary to allow Opaque LSAs to be maintained by the OSPF database, it is also necessary to configure the necessary interface under the “mpls” syntax in order to originate Opaque LSAs for each interface.


IGP TE Verification

A:P2# show router ospf status============================OSPF Status============================OSPF Router Id : 10.10.10.62OSPF Version : 2OSPF Admin Status : EnabledOSPF Oper Status : EnabledGraceful Restart : DisabledGR Helper Mode : DisabledArea Border Router : FalseAS Border Router : FalseOpaque LSA Support : TrueTraffic Engineering Support : TrueRFC 1583 Compatible : TrueTOS Routing Support : FalseDemand Exts Support : FalseIn Overload State : FalseOSPF Last Enabled : 01/25/2007 23:07:42Export Policies : None

- - some output omitted - -============================


The 'show router ospf opaque-database' command displays the contents of the TED.

Context: show>router>ospf

Syntax: opaque-database [link link-id | area area-id |as] [adv-router router-id] [ls-id] [detail]

Description: Display OSPF opaque database information.

Output: OSPF Opaque Database Output - The following table describes the output fields.

Label DescriptionArea Id A 32-bit integer uniquely identifying an area. Area ID 0.0.0.0 is used for the OSPF backbone.

Type NSSA This area is configured as a NSSA area.

Area This area is configured as a standard area (not NSSA or Stub).

Stub This area is configured as a NSSA area.

Link State Id The Link State Id is an LSA Type Specific field containing either a Router-Id or an IP Address; it identifies the piece of the routing domain being described by the advertisement.

Adv Rtr Id The router identifier of the router advertising the LSA.

Age The age of the Link State advertisement in seconds.

Sequence The signed 32-bit integer sequence number.

Cksum The 32-bit unsigned sum of the Link State advertisements' LS checksums


show router ospf opaque-database

A:PE-1# show router ospf opaque-database

===============================================================================OSPF Opaque Link State Database (Type : All)===============================================================================Type Id Link State Id Adv Rtr Id Age Sequence Cksum-------------------------------------------------------------------------------Area 0.0.0.0 1.0.0.1 10.10.10.67 1112 0x80000001 0x91bf Area 0.0.0.0 1.0.0.2 10.10.10.67 469 0x80000002 0x5fab -------------------------------------------------------------------------------No. of Opaque LSAs: 2===============================================================================A:PE-1#

A:PE-1# show router ospf opaque-database

===============================================================================OSPF Opaque Link State Database (Type : All)===============================================================================Type Id Link State Id Adv Rtr Id Age Sequence Cksum-------------------------------------------------------------------------------Area 0.0.0.0 1.0.0.1 10.10.10.67 1112 0x80000001 0x91bf Area 0.0.0.0 1.0.0.2 10.10.10.67 469 0x80000002 0x5fab -------------------------------------------------------------------------------No. of Opaque LSAs: 2===============================================================================A:PE-1#

Viewing the database of OSPF Opaque LSAs


The 'show router ospf opaque-database detail' command displays details on a specific LSA contained in the TED.

The LSA type is an Area Opaque (Type 10) and only the Router Address TLV is present in the opaque LSA. This would occur if the IGP and Traffic Engineering extensions are enabled, but MPLS is not enabled on the same interfaces.


show router ospf opaque-database detail

A:PE-1# show router ospf opaque-database detail

===============================================================================OSPF Opaque Link State Database (Type : All) (Detailed)===============================================================================-------------------------------------------------------------------------------Opaque LSA-------------------------------------------------------------------------------Area Id : 0.0.0.0 Adv Router Id : 10.10.10.224 Link State Id : 1.0.0.1 LSA Type : Area OpaqueSequence No : 0x80000001 Checksum : 0x91bf Age : 48 Length : 28 Options : E Advertisement :

ROUTER-ID TLV (0001) Len 4 : 10.10.10.67===============================================================================A:PE-1#

A:PE-1# show router ospf opaque-database detail

===============================================================================OSPF Opaque Link State Database (Type : All) (Detailed)===============================================================================-------------------------------------------------------------------------------Opaque LSA-------------------------------------------------------------------------------Area Id : 0.0.0.0 Adv Router Id : 10.10.10.224 Link State Id : 1.0.0.1 LSA Type : Area OpaqueSequence No : 0x80000001 Checksum : 0x91bf Age : 48 Length : 28 Options : E Advertisement :

ROUTER-ID TLV (0001) Len 4 : 10.10.10.67===============================================================================A:PE-1#

Viewing the detail of an LSA in the OSPF Opaque database• Only the Router Address TLV is visible if MPLS is not enabled


The 'show router ospf opaque-database detail' command displays details on a specific LSA contained in the TED.

The LSA type is an Area Opaque (Type 10) and the Router Address TLV is present in the opaque LSA (not shown above). Since MPLS has been enabled on the interfaces, the Link TLV and all sub TLVs containing the Traffic Engineering parameters are now present.

UNRSRVD_CLS0: Sub-TLV 8: This sub-TLV specifies the amount of link bandwidth not yet reserved at each of the available eight priority levels. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7. The initial values are all set to the maximum reservable bandwidth. This function is not supported on the ALU SR as of the writing of this course.


show router ospf opaque-database detail

A:PE-1# show router ospf opaque-database detail-output omitted-Opaque LSA-------------------------------------------------------------------------------Area Id : 0.0.0.0 Adv Router Id : 10.10.10.224 Link State Id : 1.0.0.1 LSA Type : Area Opaque Sequence No : 0x80000001 Checksum : 0x61aa Age : 168 Length : 124 Options : E Advertisement :

LINK INFO TLV (0002) Len 100 :Sub-TLV: 1 Len: 1 LINK_TYPE : 2Sub-TLV: 2 Len: 4 LINK_ID : 10.64.1.2Sub-TLV: 3 Len: 4 LOC_IP_ADDR : 10.64.1.1Sub-TLV: 4 Len: 4 REM_IP_ADDR : 0.0.0.0Sub-TLV: 5 Len: 4 TE_METRIC : 100Sub-TLV: 6 Len: 4 MAX_BDWTH : 1000000 KbpsSub-TLV: 7 Len: 4 RSRVBL_BDWTH : 1000000 KbpsSub-TLV: 8 Len: 32 UNRSRVD_CLS0 :P0: 1000000 Kbps P1: 1000000 Kbps P2: 1000000 Kbps P3: 1000000 Kbps P4: 1000000 Kbps P5: 1000000 Kbps P6: 1000000 Kbps P7: 1000000 Kbps Sub-TLV: 9 Len: 4 ADMIN_GROUP : 0 None

A:PE-1# show router ospf opaque-database detail-output omitted-Opaque LSA-------------------------------------------------------------------------------Area Id : 0.0.0.0 Adv Router Id : 10.10.10.224 Link State Id : 1.0.0.1 LSA Type : Area Opaque Sequence No : 0x80000001 Checksum : 0x61aa Age : 168 Length : 124 Options : E Advertisement :

LINK INFO TLV (0002) Len 100 :Sub-TLV: 1 Len: 1 LINK_TYPE : 2Sub-TLV: 2 Len: 4 LINK_ID : 10.64.1.2Sub-TLV: 3 Len: 4 LOC_IP_ADDR : 10.64.1.1Sub-TLV: 4 Len: 4 REM_IP_ADDR : 0.0.0.0Sub-TLV: 5 Len: 4 TE_METRIC : 100Sub-TLV: 6 Len: 4 MAX_BDWTH : 1000000 KbpsSub-TLV: 7 Len: 4 RSRVBL_BDWTH : 1000000 KbpsSub-TLV: 8 Len: 32 UNRSRVD_CLS0 :P0: 1000000 Kbps P1: 1000000 Kbps P2: 1000000 Kbps P3: 1000000 Kbps P4: 1000000 Kbps P5: 1000000 Kbps P6: 1000000 Kbps P7: 1000000 Kbps Sub-TLV: 9 Len: 4 ADMIN_GROUP : 0 None

Viewing the detail of an LSA in the OSPF Opaque database


The show router isis database level 1 detail ' command displays details on a specific ISIS LSP contained in the TED, including all associated TLVs.


show router isis database level 1 detail

A:P1# show router isis database level 1 detail

===============================================================================ISIS Database===============================================================================

Displaying Level 1 database-------------------------------------------------------------------------------LSP ID : P1 00-00 Level : L1 Sequence : 0x8 Checksum : 0xba54 Lifetime : 1157 Version : 1 Pkt Type : 18 Pkt Ver : 1 Attributes: L1L2 Max Area : 3 SysID Len : 6 Used Len : 160 Alloc Len : 1492

TLVs : Area Addresses :Area Address : (01) 00

Supp Protocols :Protocols : IPv4

IS-Hostname :Hostname : P1

A:P1# show router isis database level 1 detail

===============================================================================ISIS Database===============================================================================

Displaying Level 1 database-------------------------------------------------------------------------------LSP ID : P1 00-00 Level : L1 Sequence : 0x8 Checksum : 0xba54 Lifetime : 1157 Version : 1 Pkt Type : 18 Pkt Ver : 1 Attributes: L1L2 Max Area : 3 SysID Len : 6 Used Len : 160 Alloc Len : 1492

TLVs : Area Addresses :Area Address : (01) 00

Supp Protocols :Protocols : IPv4

IS-Hostname :Hostname : P1

Viewing the detail of a TE TLV in the ISIS database


The show router isis database level 1 detail ' command displays details on a specific ISIS LSP contained in the TED, including all associated TLVs.

Note the TE TLVs that are present including the Interface addresses and Maximum and Reservable bandwidth parameters.

Unresvd BW: This sub-TLV specifies the amount of link bandwidth not yet reserved at each of the available eight priority levels. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7. The initial values are all set to the maximum reservable bandwidth. This function is not supported on the ALU SR as of the writing of this course.


show router isis database level 1 detail (continued)

TE Router ID :Router ID : 10.10.10.61

I/f Addresses :IP Address : 10.10.10.61IP Address : 10.16.1.1

TE IS NBRS. :Neighbor : PE1.01 Metric : 10Intf. Address : 10.16.1.1Max Link BW : 1000000 kbpsReservable BW : 1000000 kbpsUnresvd BW :

Priority 0 : 1000000 kbps Priority 1 : 1000000 kbpsPriority 2 : 1000000 kbps Priority 3 : 1000000 kbpsPriority 4 : 1000000 kbps Priority 5 : 1000000 kbpsPriority 6 : 1000000 kbps Priority 7 : 1000000 kbps

Admin Group : 00000000TE IP Reach. :IP Prefix : 10.10.10.61/32 (Dir. :Up) Metric : 0IP Prefix : 10.16.1.0/24 (Dir. :Up) Metric : 10

TE Router ID :Router ID : 10.10.10.61

I/f Addresses :IP Address : 10.10.10.61IP Address : 10.16.1.1

TE IS NBRS. :Neighbor : PE1.01 Metric : 10Intf. Address : 10.16.1.1Max Link BW : 1000000 kbpsReservable BW : 1000000 kbpsUnresvd BW :

Priority 0 : 1000000 kbps Priority 1 : 1000000 kbpsPriority 2 : 1000000 kbps Priority 3 : 1000000 kbpsPriority 4 : 1000000 kbps Priority 5 : 1000000 kbpsPriority 6 : 1000000 kbps Priority 7 : 1000000 kbps

Admin Group : 00000000TE IP Reach. :IP Prefix : 10.10.10.61/32 (Dir. :Up) Metric : 0IP Prefix : 10.16.1.0/24 (Dir. :Up) Metric : 10

Viewing the detail of a TE TLV in the ISIS database


The Constraint based Shortest Path First, or CSPF, process is an extension to the SPF process performed by link state routing protocols. The CSPF calculation uses constraints, obtained from the traffic engineering database (TED) and local input, to compute the shortest path through the network that matches the configured requirements.

Once a path is found by CSPF, the LSP set up along that path.

Constraints taken into account by CSPF include:

Admin groups, including link colors and resource classes (from TED)

Bandwidth requested (from the TED)

Hop limits (local user input)


Signaled LSPs with CSPF

Signal LSP

Path determinedby CSPF

Constraint Shortest PathFirst (CSPF)

User Requirements

TE Capable IGPOSPF-TEIS-IS-TE

Routing Table Traffic EngineeringDatabase (TED)


Fast Reroute requires CSPF when there are loose hops in the protected LSP. Furthermore, CSPF is required when computing a path based on a specified required bandwidth or where a particular link must be included/excluded (using administrative groups or link coloring) where the path chosen may be a path other than the one chosen as the least cost path by the IGP.

If CSPF is not enabled and an LSP is configured with specific bandwidth requirements, the router will not take the bandwidth into consideration when determining the path, thus the router will attempt to setup the LSP on a path which may not have the required bandwidth and the LSP will not be successfully established.


Constraint-based SPF (CSPF)

CSPF is required for • Finding a constraint based path which is different from the path

an IGP might choose • FRR with loose path LSPs

FRR cannot occur if CSPF is not enabled on the LSP

Bandwidth reservation can still take place without CSPF, however the router will always choose the least cost IGP path and will not take the bandwidth available on the links into consideration



The Alcatel-Lucent CSPF Implementation

Support for CSPF on the 7750 SR is provided by both OSPF and IS-IS

CSPF is configurable on a per LSP basis but is only used by LSPs in which some loose hops are specified

LSPs in which every hop is strictly specified does not use CSPF

CSPF is also required for the set-up of detours in the context of Fast Re-route


The CSPF functionality provided by OSPF and IS-IS provides the capability to traffic engineer LSPs based on the following constraints:

LSP Requirements

Link constraints (include/exclude), a.k.a Link coloring

Bandwidth requirements

Hop count limitations

Link Attributes

Link colors

Reservable bandwidth (per interface)


The Alcatel-Lucent CSPF Implementation (cont’d)

The CSPF functionality provided by OSPF and IS-IS provides the capability to traffic engineer LSPs based on the following constraints:

LSP Requirements (i.e. specified by the user)• Link constraints (include/exclude), a.k.a Link Coloring• Bandwidth requirements• Hop count limitations

Link Attributes (i.e. advertised by the IGP-TE)• Link colors• Reservable bandwidth (per interface)


Context: config>router>mpls>lsp

Syntax: [no] cspf

Description This command enables Constrained Shortest Path First (CSPF) computation for constrained-path LSPs. Constrained-path LSPs are the ones that take configuration constraints into account. CSPF is also used to calculate the detour routes when fast-reroute is enabled.

Explicitly configured LSPs where each hop from ingress to egress is specified do not use CSPF. The LSP will be set up using RSVP signaling from ingress to egress.

The no form of the command disables CSPF computations.

Default: no cspf


Enabling CSPF

This command enables Constrained Shortest Path First (CSPF) computation for constrained-path LSPs


A:PE-1>config>router# mpls

A:PE-1>config>router>mpls# lsp <lsp-name>

A:PE-1>config>router>mpls>lsp# cspf

A:PE-1>config>router>mpls>lsp# exit all

A:PE-1#


This command is used to define administrative groups or link coloring for an interface. The admin group names can signify link colors, such as red, yellow or green. MPLS interfaces advertise the link colors it supports.

CSPF uses the information when paths are computed for constraint-based LSPs. CSPF must be enabled in order for admin groups to be relevant.

Network resources (links) based on zones, geographic location, link location, etc., can be classified using admin groups. MPLS interfaces must be explicitly assigned to a admin group. Admin groups must be defined before they can be assigned to an MPLS interface.

The IGP communicates the information throughout the area. Admin groups can be included or excluded when LSPs are defined. The admin-group names must be identical across all routers in a single domain.


Admin Groups

Admin groups are used to influence path selection with CSPF, by allowing links to be “colored”

MPLS interfaces advertise the link colors it supports

LSP are configured to either require the inclusion or exclusion of certain “colors” or admin groups

CSPF uses the information when paths are computed for constraint-based LSPs

CSPF must be enabled in order for admin groups to be relevant



Syntax: admin-group group-name ...[up to 5 max]no admin-group group-name

Description: This command is used to define administrative groups or link coloring for an interface. The admin group names can signify link colors, such as red, yellow or green. MPLS interfaces advertise the link colors it supports.

CSPF uses the information when paths are computed for constraint-based LSPs. CSPF must be enabled in order for admin groups to be relevant.

Network resources (links) based on zones, geographic location, link location, etc., can be classified using admin groups. MPLS interfaces must be explicitly assigned to a admin group. Admin groups must be defined in the config>router>mplscontext before they can be assigned to an MPLS interface.

The IGP communicates the information throughout the area. Admin groups can included or excluded when LSPs are defined. Up to 32 group names can be defined in the config>router>mpls context. The admin-group names must be identical across all routers in a single domain. The no form of this command deletes the administrative group. All configuration information associated with this LSP is lost.

Default: none

Parameters: group-name - Specify a group name.


Configuring Admin Groups

The admin-group names must be identical across all routers in a single domain

MPLS interfaces must be explicitly assigned to a admin group



A:PE-1>config>router>mpls# admin-group green 15

A:PE-1>config>router>mpls# admin-group yellow 20

A:PE-1>config>router>mpls# admin-group red 25

A:PE-1>config>router>mpls# interface PE1-P1

A:PE-1>config>router>mpls>if# admin-group green

A:PE-1>config>router>mpls>if# exit all

A:PE-1#


Context: show>router>mpls

Syntax: admin-group group-name

Description: This command displays MPLS administrative group information.

Parameters: group-name — Specify a group name up to 32 characters.

Output MPLS Administrative Group Output Fields - The following table describes MPLS administrative group output fields.


Verifying Admin Groups

Displays MPLS administrative group information

A:PE-1# show router mpls admin-group=================================================MPLS Administrative Groups=================================================Group Name Group Value-------------------------------------------------green 15red 25yellow 20-------------------------------------------------No. of Groups: 3=================================================A:PE-1#



Syntax: [no] exclude group-name [group-name...(up to 5 max)]

[no] include group-name [group-name...(up to 5 max)]

Description This command specifies the admin groups to be excluded or included when an LSP is set up. Up to 5 groups can be specified.

The admin groups are defined in the config>router>mpls>admin-group context. Use the no form of the command to remove the exclude or include command.

Defaults: no excludeno include

Parameters: group-name - Specify the existing group-name to be excluded or included when an LSP is set up.


LSPs with Admin-Group Constraint

Specifies the admin groups to be excluded or included when an LSP is set up

Configuration below reads as “Include green OR yellow AND exclude red”



A:PE-1>config>router>mpls# lsp <lsp-name>

A:PE-1>config>router>mpls>lsp# include green yellow

A:PE-1>config>router>mpls>lsp# exclude red

A:PE-1>config>router>mpls>lsp# exit all

A:PE-1#


In this example a path with no hops specified has been defined (path name is “loose”). The LSP will be routed via the path PE1-P1-P2, as this is the only path available that is within 3 hops. If the link between P1 and P2 fails, the LSP will go down, because the path via P3 exceeds the hop limit of 3.


LSPs with Hop Limit Constraint

The number of hops that an LSP can traverse is another constraint that can be specified

The hop limit includes the ingress and egress routers, as well as all intermediate routers

A:PE1# configure router mpls

A:PE1>config>router>mpls# lsp toP2

A:PE1>config>router>mpls>lsp# to 2.2.2.2

A:PE1>config>router>mpls>lsp# primary loose

A:PE1>config>router>mpls>lsp>path# exit

A:PE1>config>router>mpls>lsp# cspf

A:PE1>config>router>mpls>lsp# hop-limit 3

A:PE1>config>router>mpls>lsp# exit all

P11.1.1.1/32

P22.2.2.2/32

P33.3.3.3/32

PE14.4.4.4/32


The following documents provide additional information about MPLS Traffic Engineering:

RFC 2370 - The OSPF Opaque LSA Option

RFC 2702 - Requirements for Traffic Engineering Over MPLS

RFC 3630 - Traffic Engineering (TE) Extensions to OSPF Version 2

RFC 3784 - Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)


References

The following documents provide additional information about MPLS Traffic Engineering

RFC 2370 The OSPF Opaque LSA Option

RFC 2702 Requirements for Traffic Engineering Over MPLS

RFC 3630 Traffic Engineering (TE) Extensions to OSPF Version 2

RFC 3784 Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)



Lab 4 – Enabling Provider Core OSPF-TE and MPLS

•Pod 1 •Pod 2

•Pod 3

•Core 2•Core 1

•Core 3

•Edge 1

•Edge 3

•Edge 2

•Pod 4

•Core 4

•Edge 4

•10.48.1.0/24 •10.64.1.0/24

•10.16.1.0/24 •10.32.1.0/24

•10.x.y.z/24

•Service Provider Network•LDP Enabled Core

•MPLS/RSVP



Module Summary

The core IGP is responsible for distribution of routing information in an MPLS domain

Traditional IGP best path selection is based on a single criteria and often results in unused or underutilized resources

Link State protocols are based on the scalable SPF algorithm

Traffic Engineering is the task of administratively mapping traffic flows over an existing network topology

Constraint based routing refers to a routing protocol that computes routes subject to the satisfaction of a set of administrative constraints and requirements

Both OSPF and IS-IS have Traffic Engineering extensions defined for them



Summary (continued)

OSPF support for Traffic Engineering is implemented via Opaque LSAs

IS-IS support for Traffic Engineering is enabled via the definition of new TLVs

Both Link State protocols support almost identical feature sets for Traffic Engineering purposes

The Traffic Engineering Database (TED) stores the information propagated in the Traffic Engineering IGP extensions



Learning Assessment

1. What limitation is shared by all IGP protocols when selecting best paths?

2. Why are Link State protocols better suited for Traffic Engineering then Distance Vector?

3. What factor determines the extent of propagation for a Link State packet?

4. What is the main reason for the implementation of Traffic Engineering?

5. Define constraint-based routing.

6. What is the TED used for?

7. What is a CR-LSP?

8. Describe the differences between the CSPF calculation and the SPF calculation



Learning Assessment

9. What are Type 9 LSAs used for in a traffic-engineered MPLS network?

10. Which type of LSA is implemented for OSPF-TE?

11. The Maximum Reservable Bandwidth on a link must be less than or equal to the Maximum Bandwidth of the link (T/F?)

12. The Unreserved Bandwidth value for a priority level on a link must be less than or equal to the Maximum Reservable Bandwidth (T/F?)

13. A given link may be assigned to more than one Administrative Group (T/F?)

14. What is the purpose of the Router ID TLV?

15. What are the differences between Administrative Groups assigned in ISIS and OSPF?

16. Which Link State protocol offers more TE features?



1. 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 then Distance Vector?

Link State protocols better suited for Traffic Engineering then Distance Vector because they maintain a database of network topology, which may include the entire domain.

3. What factor determines the extent of propagation for a Link State packet?

The type of Link State packet determines how far it will propagate.

4. What is the main reason for the implementation of Traffic Engineering?

The main reason for implementing Traffic Engineering is to enable the migration of traffic flows away from the IGP selected "best" path onto other network paths based on administrative requirements.

5. Define Constraint based routing.

Constraint based routing is a general mechanism used to meet Traffic Engineering requirements, computing routes subject to the satisfaction of a set of constraints and requirements.

6. What is the TED used for?

The Traffic Engineering Database is used to store the TE extension LSAs or PDUs containing TLVs used for CSPF calculations.

7. What is a CR-LSP?

A Constraint-Based Routed LSP is an LSP whose route has been calculated using a constraint-based routing algorithm

8. Describe the differences between the CSPF calculation and the SPF calculation

In the CSPF calculation, the link state database (or traffic engineering database) is first pruned to remove any links not meeting the constraints of the route. The SPF calculation is then performed on the remaining links.






9. What are Type 9 LSAs used for in a traffic-engineered MPLS network?

Type 9 LSAs are not used in a traffic-engineered MPLS network.

10. Which type of LSA is implemented for OSPF-TE?

The Opaque Type 10 Area local LSA is implemented for OSPF-TE.

11. False. The Maximum Reservable Bandwidth on a link may exceed the Maximum Bandwidth of the link (over-subscription is allowed).

12. True. The Unreserved Bandwidth value for a priority level on a link must be less than or equal to the Maximum Reservable Bandwidth.

13. True. A given link may be assigned to any number of Administrative Groups (up to the maximum number of 32 groups)

14. What is the purpose of the Router ID TLV?

The Router ID TLV, provides a stable, reachable address that can be used to create an explicit route.

15. What are the differences between Administrative Groups assigned in ISIS and OSPF?

Administrative Groups have the same meaning in ISIS as in OSPF.

16. Which Link State protocol offers more TE features?

Both OSPF-TE and ISIS-TE offer equivalent features.






Module 6 — RSVP Implementation








This module discusses Constraint Based IGP Enhancements as used in an MPLS enabled network.


Module Objectives

Demonstrate a good understanding of RSVP and RSVP-TE

Describe and implement multiple methodologies for creating RSVP paths

Describe and implement LSP Traffic Protection

Demonstrate an understanding of link failure protection

Implement FRR in an MPLS domain

Differentiate between the various tunnel selection options and reservation styles

Describe the difference between One-to-One and Facility bypass



RSVP Implementation

Section 1 - RSVP & RSVP-TE



Section Outline

RSVP Overview

RSVP Message Types

RSVP Operation

RSVP Traffic Engineering

Reservation Styles

Explicit-path vs. Loose path LSPs

LSP Route Selection


With this RSVP analogy, a party is being planned and everyone has been invited except for “Kathy”. Susan, the Party Planner, sends out an invitation to Kathy inviting her to the party and adds the acronym “RSVP” to the end of the invitation. The invitation makes its way to Kathy who now reads prepares the reply. Kathy will be happy to attend the party and notices that the letters “RSVP” appear at the bottom of the invitation. These letters, used in this context, come from the French phrase “Répondez S’il Vous Plaît” or Please Reply. Kathy prepares the reply informing the sender, Susan, that she plans to attend and sends the reply back. The reply makes its way back to Susan who now knows that Kathy has received the request and plans to attend the party. This enables Susan to properly plan her party now knowing who is and is not attending.

In the context of this module, RSVP, stands for ReSerVation Protocol, but works the same way as described above. A request is initiated by an originator and makes its way to the destination. Once the destination receives the RSVP request, a reply is prepared (called a Reservation Message) and is sent back to the requesting node. Upon receiving the Reservation Message, the requesting node has now been notified that not only a path exists to the destination, but is also available to accept the requested constrained data.


RSVP Analogy

y

Dear Kathy, Please come to my party

RSVP

SusanJohnFredBobKathy

y


RSVP

y


RSVP

Yes, I will be there

y


RSVP

Yes, I will be there

SusanJohnFredBobKathy


Originally the Resource Reservation Protocol (RSVP) was developed as a network control protocol to be used by a host to request specific qualities of service from the network for particular application data streams or flows. In addition, RSVP has also been defined to be used by routers to deliver quality of service (QoS) requests to all nodes along the path(s) of the flows and to establish and maintain a state to provide the requested service. RSVP requests generally result in resources reserved 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. It requests resources 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. RSVP operates with unicast and multicast routing protocols. Routing protocols determine where packets are forwarded. RSVP consults local routing tables to relay RSVP messages.


RSVP Overview

RSVP is a protocol that defines procedures for signaling requirements and reserving the necessary resources for a router to provide a requested service through all nodes along a data path.

RSVP is not a routing protocol. It works in conjunction with routing protocols.

RSVP requests resources for simplex flows. It requests resources only in one direction (unidirectional)


RSVP uses two message types to set up LSPs, PATH and RESV. The figure above depicts the process to establish an LSP.

The sender iLER sends a PATH message toward the receiver, eLER to indicate the FEC for which a label binding is desired. PATH messages are used to signal and request label bindings required to establish the LSP from ingress to egress. Each router along the path observes the traffic type..

The eLER sends label binding information in the RESV messages in response to PATH messages received. RESV messages allow the routers along the path to make the necessary bandwidth reservations and distribute the label binding upstream to the iLER.

The LSP is considered operational when the iLER receives the label binding information.

The figure above displays an example of an LSP path set up using RSVP. The iLER transmits an RSVP path message downstream to the eLER. The path message contains a label request object that requests intermediate LSRs and the eLER to provide a label binding for this path.

The eLER receives a path message containing a label request object and responds with a RESV message that contains a label object. The label object contains the label binding that the downstream LSR provides to its upstream neighbor. The RESV message is sent upstream towards the iLER, in a direction which is opposite to that followed by the path message. Each LSR in the path that processes the RESV message uses the received label for the outgoing traffic associated with the specific LSP. The LSP is established when the RESV message arrives at the ingress LSR.


RSVP Message Types

RSVP uses two message types for resource reservation

Sender sends PATH message towards receiver indicating characteristics of the traffic

• Each Router along the path makes note of the traffic typeReceiver sends RESV message back towards sender

• Each Router reserves the resources requested (if available) for the micro-flow

Path Refresh and RESV Refresh messages are sent periodically

Path Refresh

Resv Conf

ResV Refresh

Path Tear

Resv Error

ResV Tear

Path Error

ILER

ELER

Path(1)

Path

(2)

Path

(3)

Path(4)

ResV(5)

ResV

(6)

ResV

(7)ResV (8)


The slide above displays an example of an LSP path set up using RSVP. The ingress label edge router (iLER) transmits an RSVP path message (path: 30.30.30.1) downstream to the egress label edge router (eLER). The path message contains a label request object that requests intermediate LSRs and the eLER to provide a label binding for this 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. Labels are allocated downstream and distributed (propagated upstream) by means of the RSVP Resv message. For this purpose, the RSVP Resv message is extended with a special LABEL object.


PATH vs. RESV Messages

10.10.10.1 30.30.30.1PATH:30.30.30.1 PATH:30.30.30.1 PATH:30.30.30.1

RESV:10.10.10.1RESV:10.10.10.1RESV:10.10.10.1

RSVP PATH MessageLabel Request

RSVP RESV MessageLabel Allocation


PathErr (path error) messages report errors in processing Path messages. They travel upstream towards senders and are routed hop-by-hop using the path state. At each hop, the IP destination address is the unicast address of a previous hop. PathErr messages do not modify the state of any node through which they pass; they are only reported to the sender application.


Path Error Message

10.10.10.1 30.30.30.1PATH:30.30.30.1 PATH:30.30.30.1

STOP

Cannot satisfy Path

request

Path ErrorPath Error


ResvErr (reservation error) messages report errors in processing Resv messages, or they may report the spontaneous disruption of a reservation, e.g., by administrative preemption. ResvErr messages travel downstream towards the appropriate receivers, routed hop-by-hop using the reservation state. At each hop, the IP destination address is the unicast address of a next-hop node.


Reservation Error Message

10.10.10.1 30.30.30.1PATH:30.30.30.1 PATH:30.30.30.1 PATH:30.30.30.1

RESV Error RESV ErrorSTOP

Cannot satisfy

reservation

RESV:10.10.10.1RESV:10.10.10.1


PathTear messages are initiated by senders or by path state timeout in any router, and they travel downstream towards all receivers. A PathTear message is routed exactly like the corresponding Path message. Therefore, its IP destination address is the session Destination Address, and its IP source address is the sender address from the path state being torn down.

When a path is deleted as a result of the ParthTear message, the related reservation state is also adjusted to maintain consistency in the local router. This adjustment will depend on the reservation style being used (discussed later in this section). For example, if the style specified is either FF or SE, then any reservation with the corresponding filter specification is also deleted.

Receipt of a ResvTear (reservation teardown) message deletes matching reservation state. ResvTear messages are initiated explicitly by receivers or by any node in which reservation state has timed out, and they travel upstream towards all matching senders. A ResvTear message must be routed like the corresponding Resv message, and its IP destination address will be the unicast address of a previous hop.

A ResvTear message will cease to be forwarded at the node where merging would have suppressed forwarding of the corresponding Resv message. Depending upon the resulting state change in a node, receipt of a ResvTear message may cause a ResvTear message to be forwarded, a modified Resv message to be forwarded, or no message to be forwarded.


Path Tear and Reservation Tear Messages

10.10.10.1 30.30.30.1PATH:30.30.30.1 PATH:30.30.30.1 PATH:30.30.30.1

RESV:10.10.10.1RESV:10.10.10.1RESV:10.10.10.1

(1) Assuming RSVP Tunnel exists

(2) Tunnel needs to be taken down

10.10.10.1 30.30.30.1PATH Tear PATH Tear PATH Tear

RESV TearRESV TearRESV Tear


RSVP takes a "soft state" approach to managing the reservation in routers and hosts. RSVP soft state is created and periodically refreshed by Path and Resv messages. Alcatel-Lucent uses a 30 second default timer on the refresh interval and 90 second for the hold time. The state is deleted if no matching refresh messages arrive before the expiration of a "cleanup timeout" interval. State may also be deleted by an explicit "teardown" message. At the expiration of each "refresh timeout" period and after a state change, RSVP scans its state to build and forward Path and Resv refresh messages to succeeding hops.

Soft state, and hence refresh messages, are used because RSVP does not associate the data path to a static route throughout a network. Since it is possible for a route to change due to the dynamic nature of RSVP, it’s important that the reservation state be periodically refreshed.

Whether a message is "new" or a "refresh" is determined separately at each node, depending upon the existence of the RSVP state at that node. Therefore, if a Path message is received and that node already has an RSVP session established that corresponds to that message, then the Path message is treated as a refresh. The Resv message is treated in the same manner.


Path Refresh & Reservation Refresh

10.10.10.1 30.30.30.1PATH:30.30.30.1 PATH:30.30.30.1 PATH:30.30.30.1

RESV:10.10.10.1RESV:10.10.10.1RESV:10.10.10.1

(1) Assuming RSVP Tunnel has already been created

2) Any future Path/Resv messages will be treated as refresh messages

10.10.10.1 30.30.30.1PATH Message(Refresh)

RESV Message(Refresh)

PATH Message(Refresh)

PATH Message(Refresh)



Refreshing the Path stateRefreshing the Path state

Refreshing the Reservation stateRefreshing the Reservation state


RSVP Traffic Engineering (RSVP-TE) Extensions RSVP-TE is a set of traffic engineering extensions to RSVP intended for use by label switching routers to establish and maintain Transport LSP tunnels and to reserve network resources for such Transport LSP tunnels.

The RSVP-TE specification essentially allows an RSVP session to aggregate traffic between the originating node of an LSP-tunnel and the egress node of the tunnel. Because traffic is aggregated, the number of RSVP sessions does not increase proportionally with the number of flows in the network.

Therefore, the RSVP-TE specification addresses a major scaling issue with the original RSVP protocol, namely the large amount of system resources that would otherwise be required to manage reservations and maintain state for potentially thousands or even millions of RSVP sessions.


RSVP – Traffic Engineering (RSVP-TE) Extensions

A set of traffic engineering extensions to RSVP

RSVP –TE allows RSVP session to aggregate traffic between ingress and egress nodes

Since traffic is aggregated, number of RSVP sessions does not increase with number of flows


RSVP-TE defines a set of traffic engineering extensions to the RSVP standard. RSVP-TE extensions provide a method by which RSVP may be used for traffic engineering in MPLS environments. These extensions add support for assigning MPLS labels and specifying explicit paths as a sequence of loose and strict routes. These extensions are supported by providing a Label Request field and an Explicit Route Objects field in the path message. The destination LSR responds to a label request by providing a label object in its RESV message. Labels are then assigned at each intermediate node which processes the RESV message. RSVP-TE operates in downstream-on-demand (DoD) label advertisement mode with ordered LSP control.

RSVP-TE is an MPLS signaling protocol based on the resource reservation protocol originally used for signaling IP quality of service connections.

Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS. The result is the instantiation of label switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks.


RSVP-TE Overview

RSVP-TE used for establishing LSPs in MPLS networks

RSVP-TE operates in downstream-on-demand (DOD) label advertisement mode with ordered LSP control.

• A request to bind labels to a specific LSP tunnel is initiated by an ingress node through the RSVP Path message

• Labels are generated downstream and distributed upstream by means of the RSVP Resv message

Advantage of using RSVP to establish LSP tunnels is that it enables the allocation of resources along the path.

• For example, bandwidth can be allocated to an LSP tunnel using standard RSVP reservations and Integrated Services service classes


Explicitly Routed LSP : An LSP whose path is established by a means other than normal IP routing.

The signaling protocol model also supports explicit routing capability. This is accomplished by incorporating a simple EXPLICIT_ROUTE object into RSVP Path messages. The EXPLICIT_ROUTE object encapsulates a concatenation of hops which constitutes the explicitly routed path. Using this object, the paths taken by label-switched RSVP-MPLS flows can be pre-determined, independent of conventional IP routing. The explicitly routed path can be administratively specified, or automatically computed by a suitable entity based on QoS and policy requirements, taking into consideration the prevailing network state. In general, path computation can be control-driven or data-driven. The mechanisms, processes, and algorithms used to compute explicitly routed paths are beyond the scope of this specification. One useful application of explicit routing is traffic engineering. Using explicitly routed LSPs, a node at the ingress edge of an MPLS domain can control the path the traffic uses through the MPLS network to the egress node. Explicit routing can be used to optimize the utilization of network resources and enhance traffic oriented performance characteristics.

The concept of explicitly routed label switched paths can be generalized through the notion of abstract nodes. An abstract node is a group of nodes whose internal topology is opaque to the ingress node of the LSP. An abstract node is said to be simple if it contains only one physical node. Using this concept of abstraction, an explicitly routed LSP can be specified as a sequence of IP prefixes.

The signaling protocol model supports the specification of an explicit path as a sequence of strict and loose routes. The combination of abstract nodes, and strict and loose routes significantly enhances the flexibility of path definitions.

Strict routes need to be over adjacent routers.


RSVP-TE Overview (cont..)

RSVP-TE supports:

• Explicitly routed LSPs (with or without resource reservations)

— supports explicit path as a sequence of strict and loose routes

— Resource reservations are not mandatory. LSP can be created without any resource reservations

– For example, can be used to carry best effort traffic• Smooth rerouting of LSPs, and loop detection

— RSVP-TE enables establishment of explicitly routed LSPstunnels which can be routed away from network failures, congestion, and bottlenecks

Explicit routing:• Paths taken by label-switched RSVP-TE flows can be pre-

determined, independent of conventional IP routing• Path can be administratively specified, or automatically

computed by a suitable entity based on QoS and policy requirements


An RSVP PATH message may contain a number of optional objects:

Explicit route object (ERO) — When the ERO is present, the RSVP path message is forced to follow the path specified by the ERO (independent of the IGP shortest path).

Record route object (RRO) — Allows the ILER to receive a listing of the LSRs that the LSP tunnel actually traverses.

A session attribute object controls the path set up priority, holding priority, and local rerouting features.


RSVP Explicit Route Object (ERO)

ERO provides specific path information for the RSVP Path message to follow

If ERO is not present then IGP is used to follow the path

ERO can be manually provided or computed based on RSVP requirements such as QoS


Route RecordingThe route a path takes can be recorded. Routes can be recorded via the RECORD_ROUTE object (RRO). There are three possible uses of RRO in RSVP.

First, an RRO can function as a loop detection mechanism to discover L3 routing loops, or loops inherent in the explicit route.

Second, an RRO collects up-to-date detailed path information hop-by- hop about RSVP sessions, providing valuable information to the sender or receiver. Any path change (due to network topology changes) will be reported.

Third, RRO syntax is designed so that, with minor changes, the whole object can be used as input to the EXPLICIT_ROUTE object. This is useful if the sender receives RRO from the receiver in a Resv message, applies it to EXPLICIT_ROUTE object in the next Path message in order to "pin down session path".

LSP Record Route

RSVP supports the Record Route Object (RRO)

RRO records all hops that the LSP transits

RRO is a useful debugging tool

RRO is enabled by default


RSVP-TE Route Recording (RRO)

Record Route Object (RRO) of RSVP-TE is used for route recording purpose• RRO records the actual route a packet traversed

Recording the path allows the iLER to know, on a hop-by-hop basis, which LSRs the path traverses.

Knowing the actual path of an LSP can be especially useful for diagnosing various network issues.

It is also used by the sender to request notification if there are changes to the routing path.

Intermediate or transit nodes can optionally use the RRO to provide loop detection.


If no ERO is specified, the router will make use of the shortest IGP path from tunnel head to tunnel destination. The diagram above shows an RSVP Path message making use of the IGP to determine the shortest path to network 30.30.30.1. The RSVP Message keeps track of the path used via the RRO. Once the RSVP Path message reaches the destination, the RESV message makes use of the RRO path to follow the same set of hops back to the RSVP originator, reserving resources along the way and confirming the tunnel creation.


RSVP-TE Operation – No ERO Specified

10.10.10.1 30.30.30.1

20.20.20.1

40.40.40.1 50.50.50.1

IGPShortest Path

RSVP PathLSP Tunnel (IPv4)Label_RequestTunnel Destination:30.30.30.1RRO: 10.10.10.1

ShortestIGP Path

RSVP PathLSP Tunnel (IPv4)Label_RequestTunnel Destination:30.30.30.1RRO: 10.10.10.120.20.20.1

ShortestIGP Path

RSVP PathLSP Tunnel (IPv4)Label_RequestTunnel Destination:30.30.30.1RRO: 10.10.10.120.20.20.130.30.30.1


To create an LSP tunnel, the first MPLS node on the path -- that is, the sender node with respect to the path --creates an RSVP Path message with a session type of LSP_TUNNEL_IPv4 and inserts a LABEL_REQUEST object into the Path message. The LABEL_REQUEST object indicates that a label binding for this path is requested and also provides an indication of the network layer protocol that is to be carried over this path. The reason for this is that the network layer protocol sent down an LSP cannot be assumed to be IP and cannot be deduced from the L2 header, which simply identifies the higher layer protocol as MPLS.


RSVP-TE Operation – ERO Specified

10.10.10.1 30.30.30.1

20.20.20.1

40.40.40.1 50.50.50.1

IGPShortest Path

RSVP PathLSP Tunnel (IPv4)Label_RequestERO:10.10.10.1

40.40.40.150.50.50.130.30.30.1


By adding a RECORD_ROUTE object to the Path message, the sender node can receive information about the actual route that the LSP tunnel traverses. The sender node can also use this object to request notification from the network concerning changes to the routing path. The RECORD_ROUTE object is analogous to a path vector, and hence can be used for loop detection.

Finally, a SESSION_ATTRIBUTE object can be added to Path messages to aid in session identification and diagnostics. Additional control information, such as setup and hold priorities, resource affinities, and local-protection, are also included in this object.


RSVP Operation - RRO

10.10.10.1 30.30.30.1

20.20.20.1

40.40.40.1 50.50.50.1

IGPShortest Path

RSVP PathLSP Tunnel (IPv4)Label_RequestERO: 10.10.10.1

40.40.40.150.50.50.130.30.30.1

Session_AttributesRRO: 10.10.10.1


When the EXPLICIT_ROUTE object (ERO) is present, the Path message is forwarded towards its destination along a path specified by the ERO. Each node along the path records the ERO in its path state block. A path state block (PSB) is an internal structure which holds the information necessary to identify a particular RSVP session. Nodes may also modify the ERO before forwarding the Path message. In this case the modified ERO is stored in the path state block in addition to the received ERO. The LABEL_REQUEST object requests intermediate routers and receiver nodes to provide a label binding for the session. If a node is incapable of providing a label binding, it sends a PathErr message with an "unknown object class" error. If the LABEL_REQUEST object is not supported end to end, the sender node will be notified by the first node which does not provide this support.


RSVP Operation – ERO/RRO Operation

10.10.10.1 30.30.30.1

20.20.20.1

40.40.40.1 50.50.50.1

IGPShortest Path


50.50.50.130.30.30.1

Session_AttributesRRO:10.10.10.1


30.30.30.1Session_AttributesRRO:10.10.10.1

40.40.40.1

RSVP PathLSP Tunnel (IPv4)Label_RequestERO: 30.30.30.1Session_AttributesRRO:10.10.10.1

40.40.40.150.50.50.1

RSVP PathLSP Tunnel (IPv4)Label_RequestERO: Session_AttributesRRO:10.10.10.1

40.40.40.150.50.50.130.30.30.1


The destination node of a label-switched path responds to a LABEL_REQUEST by including a LABEL object in its response RSVP Resv message. The Resv message is sent back upstream towards the sender, following the path state created by the Path message, in reverse order. Note that if the path state was created by use of an ERO, then the Resv message will follow the reverse path of the ERO. Each node that receives a Resv message containing a LABEL object uses that label for outgoing traffic associated with this LSP tunnel. If the node is not the sender, it allocates a new label and places that label in the corresponding LABEL object of the Resv message which it sends upstream to the previous hop address. The label sent upstream in the LABEL object is the label which this node will use to identify incoming traffic associated with this LSP tunnel. The node can now update its Label Information Base, which is used to map incoming labeled packets to the next hop label. When the Resv message propagates upstream to the sender node, a label-switched path is effectively established.


RSVP – RESV Message

10.10.10.1 30.30.30.1

20.20.20.1

40.40.40.1 50.50.50.1

IGPShortest Path

RSVP ResvLSP Tunnel (IPv4)Label: 55Session_AttributesRRO:10.10.10.1

40.40.40.150.50.50.130.30.30.1

RSVP ResvLSP Tunnel (IPv4)Label: 45Session_AttributesRRO:10.10.10.1

40.40.40.150.50.50.130.30.30.1

RSVP ResvLSP Tunnel (IPv4)Label: 35 Session_AttributesRRO:10.10.10.1

40.40.40.150.50.50.130.30.30.1

NH

NH

NH

NH (next hop)


RSVP Path messages use a Label request attribute and await a Label reply in the RSVP Resv message. Once the Resv message is received, a label mapping is created in the Label Information Base which provides a POP, SWAP, or Push action. The terminology of Ingress or Egress Label is used with respect to the data plane of the packet flow. Therefore a device advertises an ingress label in the control plane allowing a data packet to make use of that packet in the data plane.

Routers that support both MPLS and RSVP can associate labels with RSVP flows. When MPLS and RSVP are combined, the definition of a flow can be made more flexible. Once an LSP is established, the traffic through the path is defined by the label applied at the ingress node of the LSP, in the diagram above label 55 is used. The set of packets that are assigned the same label value by a specific node are considered to belong to the same FEC which defines the RSVP flow.


RSVP Label Allocation

10.10.10.1 30.30.30.1

20.20.20.1

40.40.40.1 50.50.50.1

IGPShortest Path

iLabel eLabel Action35 --- Pop

354555

iLabel eLabel Action45 35 Swap

iLabel eLabel Action55 45 Swap

iLabel eLabel Action--- 55 Push

iLabel – Ingress LabeleLabel – Egress Label

LSP represented by Label 55


RSVP has been extended for MPLS to support automatic signaling of LSPs. To enhance the scalability, latency, and reliability of RSVP signaling, several extensions have been defined. Refresh messages are still transmitted but the volume of traffic, the amount of CPU utilization, and response latency are reduced while reliability is supported. None of these extensions result in backward compatibility problems with traditional RSVP implementations.

Message ID (supported in future release)

HELLO Protocol


Additional RSVP-TE Extensions

RSVP has been further extended for MPLS to support automatic signaling of LSPs with the addition of:• Message ID• HELLO Protocol

These extensions reduce:• Volume of traffic• CPU utilization• Response latency


The message ID object reduces refresh message processing by allowing the receiver to easily identify a message that contains unchanged state information. When a router transmits a refresh message that contains a message ID object, it transmits the same message ID value that was placed in the RSVP message that originally advertised the state being refreshed. When a node is required to transmit a message that represents a new or modified state, the message ID value is changed to a value that is greater than any other previously used value. An LSR that transmits a refresh message containing a message ID object may elect to set the ACK_Desired bit if it wants a reliable message ID delivery mechanism. Requests are not initiated with ACK_Desired.

When a router receives a refresh message containing a message ID object, it first identifies the RSVP session and then checks the value it previously stored in its local state block for the RSVP session. If local state cannot be found for the message ID value, then the receiver must fully process the message because it represents a new or modified state. However, if the PATH or RESV message contains the same message ID value that was used for the most recently received message for the same session, the receiver assumes that the inbound message is a state refresh.

Message ID ACK Object — The message ID ACK object is transmitted to acknowledge the receipt of messages containing message ID objects that were sent with the ACK desired bit set. ACK messages carry one or more message ID ACK objects but they may not contain any message ID objects. This mechanism can ensure the reliable delivery of error and confirm messages and support rapid refreshes in the face of network loss.


Message ID – Slide 1

Message ID reduced refresh message processing

10.10.10.1

PATH:30.30.30.1Message_ID:1

RESV:10.10.10.1Message_ID : 1 20.20.20.1

PATH:30.30.30.1Messge_ID:1

RESV:10.10.10.1Message_ID : 1 30.30.30.1

40.40.40.1

LSP 1LSP 1

Message_ID:1


When a Path Refresh message is sent it will include the Message ID that was allocated for that specific LSP. When a Resv Refresh is received, it will include the same Message ID for the specified LSP. If the Message ID that is received is the same as the Message ID that was stored for that LSP, then no changes are necessary and the refresh has succeeded.



Message ID reduced refresh message processing

10.10.10.1 20.20.20.1 30.30.30.1

40.40.40.1

LSP 1LSP 1

Message_ID:1

Path RefreshLSP 1

Message_ID: 1

Path RefreshLSP 1

Message_ID: 1

Resv RefreshLSP 1

Message_ID: 1

Resv RefreshLSP 1

Message_ID: 1


A second LSP has been created from Router 40.40.40.40.1 with destination 30.30.30.1. This LSP has influenced the connection between router 20.20.20.1 and 30.30.30.1 which may have an affect on LSP 1. Therefore, when the next Path Refresh is issued, router 30.30.30.1 will change the Message ID for LSP 1. This will indicate to 10.10.10.1 that there has been some change that may affect LSP 1.



10.10.10.1 20.20.20.1 30.30.30.1

40.40.40.1


RESV:40.40.40.1Message_ID : 5


RESV:40.40.40.1Message_ID : 5

LSP 2

LSP 2Message_ID:5

LSP 1LSP 1

Message_ID:1


When router 10.10.10.1 sends the next Path Refresh message, router 30.30.30.1 will respond with a Resv Refresh but the Message ID will be some number greater than the largest number currently used for Message IDs. When router 10.10.10.1 receives the Resv Refresh and determines that the Message ID does not equal the stored Message ID for that LSP, the router will examine the entire Resv Refresh message to determine if the LSP must be recalculated.

These objects support the reliable delivery of RSVP messages by implementing an acknowledgment mechanism. When refresh messages (using PATH and RESV messages) are generated, the message ID object can be used to provide an indication of when the message represents a new state. A receiving node can use this information to reduce the amount of time it spends processing refresh messages.



10.10.10.1 20.20.20.1 30.30.30.1

40.40.40.1

LSP 2

LSP 2Message_ID:5

LSP 1LSP 1

Message_ID:1

Path RefreshLSP 1

Message_ID: 1

Path RefreshLSP 1

Message_ID: 1

Resv RefreshLSP 1

Message_ID: 6

Resv RefreshLSP 1

Message_ID: 6X

Since Message ID of reply does not equal Message ID stored for that LSP, LSP must be reconfirmed and possibly recreated

Since Message ID of reply does not equal Message ID stored for that LSP, LSP must be reconfirmed and possibly recreated


The RSVP HELLO extension enables RSVP nodes to detect when a neighboring node is not reachable. The mechanism provides node to node failure detection. When such a failure is detected it is handled much the same as a link layer communication failure. This mechanism is intended to be used when notification of link layer failures is not available, or when the failure detection mechanisms provided by the link layer are not sufficient for timely node failure detection.

It should be noted that node failure detection is not the same as a link failure detection mechanism, particularly in the case of multiple parallel unnumbered links. When there are multiple links shared between neighbors, each node uses a single HELLO exchange with the neighbor.

HELLO Messages are always sent between two RSVP neighbors. The IP source address is the IP address of the sending node. The IP destination address is the IP address of the neighbor node. The HELLO mechanism is intended for use between immediate neighbors. When HELLO messages are being the exchanged between immediate neighbors, the IP TTL field of all outgoing HELLO messages is set to 1.


RSVP HELLO Protocol Extension

Enables RSVP nodes to detect when a neighbor node is not reachable

Provides node to node failure detection

Used between directly connected neighbors

When multiple parallel links are shared between neighbors, each node uses a single HELLO exchange with its neighbor


Improved Failure DetectionThe Hello protocol detects the loss of a neighbor node or the reset of a neighbor’s RSVP state information. In standard RSVP, neighbor monitoring occurs as part of RSVP’s soft-state model. The reservation state is maintained as cached information that is first installed and then periodically refreshed by the ingress and egress LSRs. If the state is not refreshed within a specified time interval, the LSR discards the state because it assumes that either the neighbor node has been lost or its RSVP state information has been reset.

The HELLO protocol extension is composed of a HELLO message, a HELLO request object and a HELLO ACK object. HELLO processing between two neighbors supports independent selection of failure detection intervals. Each neighbor can automatically issue HELLO request objects. Each HELLO request object is answered by a HELLO ACK object.


RSVP-TE HELLO Protocol

HELLO Message that exchanged between neighbors enables failure detection in seconds instead of potentially minutes

Core Router

Primary LSP

Secondary LSP

HELLO

REQ

HELLO ACKHELLO REQ

HELLO ACK

HELLO ACK

HELLO REQ


hello-intervalSyntax hello-interval milli-seconds

Context config>router>rsvp>interface ip-int-name

Description This command configures the time interval between RSVP HELLO messages. RSVP HELLO packets are used to detect loss of RSVP connectivity with the neighboring node. HELLO packets detect the loss of neighbor far quicker than it would take for the RSVP session to time out based on the refresh interval. After the loss of the of number keep-multiplier consecutive HELLO packets, the neighbor is declared to be in a down state.

The no form of this command reverts to the default value of the hello-interval. To disable sending HELLO messages, set the value to zero.

Default 3000 milliseconds

Parameters milli-seconds — Specifies the RSVP HELLO interval in milliseconds, in multiples of 1000. A 0 (zero) value disables the sending of RSVP HELLO messages.

Values 0 - 60000 milliseconds (in multiples of 1000)


RSVP HELLO Interval

Syntax: hello-interval milli-seconds

Context: config>router>rsvp>interface ip-int-name

This command configures the time interval between RSVP HELLO messages.HELLO packets detect loss of neighbor quicker than RSVP session timeouts


A reservation request includes a set of options that are collectively called the reservation "style". Alcatel-Lucent supports two different styles Fixed Filter (FF) and Shared Explicit (SE)

One reservation option concerns the treatment of reservations for different senders within the same session: establish a "distinct" reservation for each upstream sender, or else make a single reservation that is "shared" among all packets of selected senders.

Another reservation option controls the selection of senders. With this reservation style, an "explicit" list of all selected senders is used to define a filter spec which must match exactly each sender.


RSVP Reservations Styles

LSPs can be signalled with explicit reservation styles. The Alcatel-Lucent 7X50 supports two different reservation styles:

– Fixed filter (FF)

– Shared explicit (SE)


Fixed Filter (FF) StyleThe FF reservation style specifies an explicit list of senders and a distinct reservation for each of them. Each sender has a dedicated reservation that is not shared with other senders. Each sender is identified by an IP address and a local identification number, the LSP_ID. Because each sender has their own reservation, a unique label and a separate LSP can be constructed for each sender-receiver pair. For traditional RSVP applications, the FF reservation style is ideal for a video distribution application in which each channel (or source) requires a separate pipe for each of the individual video streams.

The total amount of reserved bandwidth on a link for sessions using FF is the sum of the reservations for the individual senders. Because each sender has its own reservation, a unique label is assigned to each sender. This can result in a point-to-point LSP between every sender/receiver pair.


Shared Link - Fixed Filter

Fixed Filter (FF) StyleThe FF reservation style specifies an explicit list of senders and a distinct reservation for each of them. Each unique sender ID has a dedicated reservation that is not shared with other senders.

LSP 1 – SecondaryStandby

5 Mb/s

Total amount of BW reserved on shared link equals sum of individual reservations

Total amount of BW reserved on shared link equals sum of individual reservations

High probability that flows will be used simultaneously

LSP 1 - Primary10 Mb/s

Shared Link15Mb/s


Shared Explicit (SE) Style (or Aggregation )The SE reservation style creates a single reservation over a link that is shared by an explicit list of senders. Because each sender is explicitly listed in the RESV message, different labels can be assigned to different sender receiver pairs, thereby creating separate LSPs.

SE style reservations can be provided using multipoint-to-point label-switched-path or LSP per sender. Multipoint-to-point LSPs may be used when path messages do not carry the EXPLICIT_ROUTE object, or when Path messages have identical EXPLICIT_ROUTE objects. In either of these cases a common label may be assigned.

Binding a single label to a union of FECs and of applying that label to all traffic in the union, is known as “Aggregation“ or “Shared Explicit”

Aggregation (Shared Explicit) may reduce the number of labels which are needed to handle a particular set of packets, and may also reduce the amount of label distribution control traffic needed.


Shared Link - Shared Explicit

Shared Explicit (SE) Style (also called Aggregation)The SE reservation style creates a single reservation over a link that is shared by an explicit list of senders. This is the default behaviour on the 7x50

Total amount of BW reserved on shared link equals BW of largest reservation request

Total amount of BW reserved on shared link equals BW of largest reservation request

Assumes not all flows will be used simultaneously

LSP 1 – SecondaryStandby

5 Mb/s

LSP 1 - Primary10 Mb/s

Shared Link10Mb/s


With Fixed Filter reservation style, when the bandwidth of an existing LSP is changed, this new requested bandwidth, is added to the total bandwidth already reserved on a particular interface when the router determines whether it has enough bandwidth to support the bandwidth change. Therefore, if the link capacity is 100Mbps, and the existing LSP has a bandwidth reservation of 60Mbps, when the LSP’s bandwidth is changed to 70Mbps, the routers will decide whether or not to accept the new bandwidth requirement by verifying that the sum of the existing bandwidth and the new requested bandwidth does not exceed the link’s capacity.

In the example above, the bandwidth of the existing LSP is to be increased from 60Mbps to 70Mbps. The sum of the existing and new bandwidth requirement is 130Mbps (60Mpbs + 70Mbpsl) and since the link’s capacity is only 100Mbps, the routers will not accept the bandwidth change, and will not resignal the LSP. The existing LSP will remain UP with its original bandwidth reservation of 60Mbps.


Increasing BW with Fixed Filter

Increasing BW reservation is impossible if the sum of existing and new LSP BW requirement is greater than maximum BW of

link

*All links are 100 Mb/s

Existing Primary LSP60 Mb/s

Primary LSP with New bandwidth70 Mb/s

(Existing Primary LSP) + (Primary LSP with new BW) > (Link Capacity)Therefore, cannot increase reservation without first taking down existing LSP

(Existing Primary LSP) + (Primary LSP with new BW) > (Link Capacity)Therefore, cannot increase reservation without first taking down existing LSP


With SE, the difference in the new bandwidth requirement is added to the total bandwidth already reserved on a particular interface when the router determines whether it has enough bandwidth to support the bandwidth change. Therefore, if the link capacity is 100Mbps, and the existing LSP has a bandwidth reservation of 60Mbps, when the LSP’s bandwidth is changed to 70Mbps, the routers will decide whether or not to accept the new bandwidth requirement by verifying that the sum of the existing bandwidth and the incremental bandwidth requested does not exceed the link’s capacity.

In the example above, the bandwidth of the existing LSP is to be increased from 60Mbps to 70Mbps. The sum of the existing and incremental bandwidth requirement is 70Mbps (60Mpbs + 10Mbpsl) and since the link’s capacity is 100Mbps, the routers will accept the bandwidth change, and will resignal the LSP. The existing LSP will be resignaled with the new bandwidth reservation of 70Mbps.


Increasing BW with Shared Explicit

*All links are 100 Mb/s

Existing Primary LSP60 Mb/s

Primary LSP with new bandwidth70 Mb/s

Since total amount of BW reserved equals BW of largest reservation request, then Primary LSP with new bandwidth will be able to be re-signaled with bandwidth

requirement

Since total amount of BW reserved equals BW of largest reservation request, then Primary LSP with new bandwidth will be able to be re-signaled with bandwidth

requirement


RSVP Implementation

Section 2 - MPLS/RSVP-TE Label Signaling Configurations



MPLS Configuration - Section Outline

Enable MPLS

Configure Paths

Configure LSPs

Verify the network

Configure optional parameters



MPLS/RSVP-TE Label Signaling Configurations

1. Ensure that Traffic Engineering is enabled on the IGP

CSPF must be enabled if FRR is to be used, otherwise the configuration of CSPF is unnecessary (this step was covered in a previous section)

2. Enable MPLS on the router

System address gets added into the MPLS instance

the no shutdown command is not required since MPLS is administratively enabled upon creation.

3. Configure MPLS on the network interfaces

Interfaces must already be configured before they can be specified in MPLS or RSVP

Must add at least one interface into MPLS protocol instance to enable MPLS

RSVP gets enabled by default with MPLS

RSVP is used to set up LSPs.

• 7750 SR OS automatically manages label values. • Labels that are automatically assigned have values ranging from 32,768

through 131,071



MPLS/RSVP-TE Label Signaling Configurations (cont..)

4. Create an MPLS Path

Path is a list of constraints that are applied to an LSP

— Configure Strict MPLS Path and/or

— Configure Loose MPLS Path

A path specifies some or all hops from ingress to egress.

• LSP forwarding path can be constrained or influenced by specifying the IP address of the hops that it should traverse on its way to the egress router

A path can be used by multiple LSPs.

5. Configure MPLS LSP

To configure signaled LSPs, you must first have created one or more named paths on the ingress router

Creation of an LSP:

• Must specify the IP address of the egress router• Must specify the primary path to be used.• Secondary paths can be explicitly configured or signaled upon the

failure of the primary path.



MPLS CLI Command Structure- LSP with RSVP Signaling

2

3

4

5

3


Interface — Enables MPLS protocol support on an IP interface.

LSP — A label switched path is sequence of hops that a packet travels from the source to a destination by means of label switching mechanisms. A label-switched path can be dynamically selected or be configured manually (static LSP). To — Specifies the system IP address of the egress router for the LSP. This command is mandatory to create an LSP.

Primary — Specifies the preferred path for the LSP.

Secondary — Specifies an alternative path that the LSP should use if the primary path is not available.

PATH — Sent by an ILER, PATH messages specify to indicate the FEC for which label bindings are desired.

RSVP — RSVP messages with label binding information are sent by the ELER in response to receiving PATH messages.

Interface — Enables RSVP protocol support on an IP interface.

Message pacing — Enable RSVP message pacing which, on an outgoing interface basis, counts the messages it has dropped because the output queue for the interface used for message pacing was full.


CLI Syntax:

config>router> MPLS

INTERFACE

LSP

PRIMARY

SECONDARY

PATH

HOP

config>router> RSVP

INTERFACE

MPLS/RSVP-TE Configuration Components

2

3

4

5


Configure an LSP path to use in MPLS. When configuring an LSP, you must specify the IP address of the egress router in the to statement. Specify the primary path to be used. Secondary paths can be explicitly configured or signaled upon the failure of the primary path. All other statements are optional.


Detail CLI Syntax

CLI Syntax: config>router>mpls

lsp lsp-nameadaptiveadspeccspfexclude group-namefast-reroute [frr-method]

bandwidth rate-in-mbpshop-limit limitnode-protect

from ip-addrhop-limit numberinclude group-nameprimary path-name

adaptivebandwidth ratein-mpbsexclude group-namehop-limit numberinclude group-namerecordno shutdown

retry-timer secondsretry-limit number

rsvp-resv-style [se | ff]secondary path-name

adaptiverecordbandwidth rate-in-mbpsexclude group-namehop-limit numberinclude group-namestandbyno shutdown

to ip-addrno shutdown

MPLS Syntax is a feature rich syntax providing configuration

options for multiple paths

MPLS Syntax is a feature rich syntax providing configuration

options for multiple paths


MPLS is first enable by creating an MPLS protocol instance in the global context, which can then be verified by usage of the 'info' command.

As shown above, the system interface is enabled for MPLS by default.


Enable MPLS


A:P1>config>router# mpls

A:P1>config>router>mpls$ info

----------------------------------------------

interface "system"

exit

no shutdown

----------------------------------------------

A:P1>config>router>mpls

Enable MPLS on each provider core router • When MPLS is first configured, the system interface is

automatically enabled for MPLS


Using the help character of '?' from the Alcatel-Lucent SR OS provides a context specific listing of available commands.


MPLS Configuration Parameters

A:P1>config>router>mpls$ ?

[no] admin-group - Define an administrative group

[no] frr-object - Enable/disable signalling with fast-reroute object

[no] interface + Configure MPLS on an IP interface

[no] lsp + Creates an LSP that will be signaled dynamically

[no] path + Configure the path to be used for a LSP

[no] resignal-timer - Configure the resignal timer for the MPLS instance

[no] shutdown - Administratively enable/disable the MPLS instance

[no] static-lsp + Configure a static LSP on the ingress router

A:P1>config>router>mpls$

MPLS configuration options are shown from the global MPLS context


All provider core facing interfaces are required to be defined under the MPLS context once MPLS based configuration or services are required.

In the earlier case of LDP only signaling, MPLS was not required. In order to configure a static LSP however, MPLS must now be enabled on all interfaces that will support the static configuration.


Configure Interfaces for MPLS


A:P1>config>router# mpls

A:P1>config>router>mpls$ interface "P1-PE1"

A:P1>config>router>mpls>if$ exit

A:P1>config>router>mpls# interface "P1-P2"


A:P1>config>router>mpls# interface "P1-P3"


MPLS is required to be enabled on all network facing interfaces in order to support MPLS• The system interface is enabled by default


The 'info' command may be used to verify that all required interfaces are present in the MPLS configuration.


Configure an Interface for MPLS

A:P1>config>router>mpls# info

----------------------------------------------

interface "system"

exit

interface "P1-P2"

exit

interface "P1-P3"

exit

interface "P1-PE1"

exit

no shutdown

----------------------------------------------

A:P1>config>router>mpls#

Verify the MPLS interface configuration


The ‘show router status’ command is used to verify the active protocols in use on the router. OSPF is enabled for provider core IGP routing. LDP was enabled in the previous exercise for label exchange.

RSVP is automatically enabled when MPLS is enabled.


show router status



Admin State Oper State ----------------------------------------------------------------Router Up UpOSPF Up UpRIP Not configured Not configured ISIS Not configured Not configured MPLS Up UpRSVP Up UpLDP Up UpBGP Not configured Not configured IGMP Not configured Not configured PIM Not configured Not configured


The ‘show router mpls status’ command is used to verify the administrative and operational status of MPLS. In this case both should indicate up.



Verifies the administrative and operational status of MPLS

A:P1# show router mpls status

===============================================================================

MPLS Status

===============================================================================




-------------------------------------------------------------------------------

Static LSPs 0 0 0

Dynamic LSPs 0 0 0

Detour LSPs 0 0 0

===============================================================================

A:P1#


The ‘show router mpls interface’ command is used to verify the interfaces on which MPLS has been configured. The system interface is automatically enabled when MPLS is first configured, the core interfaces must be explicitly defined.

All provider core facing interfaces should be enabled for MPLS.


show router mpls interface

Verifies the interfaces on which MPLS has been configured

A:P1# show router mpls interface===============================================================================MPLS Interfaces===============================================================================Interface Port-id Adm Opr -------------------------------------------------------------------------------system system Up Up Admin Groups None

P1-P2 1/1/2 Up Up Admin Groups None

P1-P3 1/1/3 Up Up Admin Groups None

P1-PE1 1/1/1 Up Up Admin Groups None

-------------------------------------------------------------------------------Interfaces : 4


The 'clear router mpls' commands may be used to reset an MPLS interface or an LSP.


clear router mpls

Several commands are available to reset an MPLS interfaces or LSPs

A:P1# clear router mpls- mpls

interface - Reset or clear statistics for MPLS interfaceslsp - Reset and restart LSPs

A:P1#

A:P1# clear router mpls- mpls

interface - Reset or clear statistics for MPLS interfaceslsp - Reset and restart LSPs

A:P1#


The “mpls” command is necessary for several reasons. First, all interfaces listed under the “mpls” syntax will originate opaque ospf LSAs. Secondly, the “mpls” syntax enables RSVP as a label signaling protocol for the interfaces listed under this context. Both of these conditions are necessary for Traffic Engineering.


Enable MPLS on all Interfaces

config>router# mpls

config>router>mpls# interface “to-100”

config>router>mpls>if# exit

config>router>mpls# interface “system”

config>router>mpls>if#exit

config>router>mpls# no shutdown

config>router>mpls# exit all

10.10.10.103

10.10.10.10210.10.10.101

10.10.10.10010.10.10.99

RSVP LSPinterface “to-100”

��


Show router mpls interfaceSyntax interface [ip-int-name | ip-address] [label-map label] statistics

interface [ip-int-name | ip-address] [label-map label]

interface [ip-int-name | ip-address] statisticsContext show>router>mpls

Description This command displays MPLS interface information.

Parameters ip-int-name — The name of the network IP interface. An interface name cannot be in the form of an IP address.

ip-address — The system or network interface IP address.

label-map label — The MPLS label on which to match.

Values 16 to 1048575

statistics — Displays IP address and the number of packets and octets sent and received on an interface-basis.


Verifying MPLS Interface Configuration

A:P1# show router mpls interface

===============================================================================

MPLS Interfaces

===============================================================================

Interface Port-id Adm Opr

-------------------------------------------------------------------------------

system system Up Up

Admin Groups None

to-101 1/1/2 Up Up

Admin Groups None

-------------------------------------------------------------------------------

Interfaces : 2

The “show router mpls interface” command can be used to verify that mpls is operational on the selected interfaces.

The “show router mpls interface” command can be used to verify that mpls is operational on the selected interfaces.


Syntax interface [ip-int-name | ip-address] statistics [detail]Context show>router>rsvp

Description This command shows RSVP interfaces.

ip-int-name — The name of the network IP interface. An interface name cannot be in the form of an IP address.

ip-address — The system or network interface IP address.

statistics — Displays IP address and the number of packets and octets sent and received on an interface-basis.

detail — Displays detailed information.


show router rsvp interface

Command shows RSVP interfaces.

A:# show router rsvp interface

=================================================RSVP Interfaces=================================================Interface Total Active Total BW Resv BW Adm Opr

Sessions Sessions (Mbps) (Mbps)--------------------------------------------------------------------------------------------------------------System - - - - Up UpTo-100 1 1 1000 0 Up Up-------------------------------------------------------------------------------------------------------------Interfaces : 2=================================================A:#



Primary and Secondary Path Configurations

Example: config>router# mplsconfig>router>mpls# path “via-R43”config>router>mpls>path$ hop 1 10.10.42.3 strictconfig>router>mpls>path$ hop 2 10.10.43.3 strictconfig>router>mpls>path# hop 3 10.10.44.3 strictconfig>router>mpls>path# hop 4 10.10.10.103 looseconfig>router>mpls>path# no shutdownconfig>router>mpls>path# exit

10.10.10.103

10.10.10.10210.10.10.101

10.10.10.10010.10.10.99

10.10.43.3 10.10.44.3

RSVP PATH“via-R43”

10.10.42.3

interface “to-100”

config>router>mpls# path “via-R33"config>router>mpls>path$ hop 1 10.10.42.3 strictconfig>router>mpls>path# hop 2 10.10.33.3 strictconfig>router>mpls>path# hop 3 10.10.34.3 strictconfig>router>mpls>path# hop 4 10.10.10.103 looseconfig>router>mpls>path# no shutdownconfig>router>mpls>path#

10.10.33.3

10.10.34.3

10.10.45.3

“via-R33”4


Syntax: show>router>mpls path [path-name] [lsp-binding]

Parameters path-name — The unique name label for the LSP path.

lsp-binding — Keyword to display binding information.


show router mpls path

Display status of MPLS paths.

show router mpls path

==============================================MPLS Path:==============================================Path Name Adm Hop Index IP Address Strict/Loose--------------------------------------------------------------------------------------------------------Via-R43 Up 1 10.10.42.3 Strict

2 10.10.43.3 Strict3 10.10.44.3 Strict4 10.10.10.103 Loose

Via-R33 Up 1 10.10.42.3 Strict2 10.10.33.3 Strict3 10.10.34.3 Strict4 10.10.10.103 Loose

--------------------------------------------------------------------------------------------------------Paths : 2==============================================



show router rsvp session

Command shows RSVP session information.

A:# show router rsvp session

===================================================RSVP Sessions===================================================From To Tunnel LSP Name State

ID ID-------------------------------------------------------------------------------------------------------------------10.10.10.99 10.10.10.103 1 1 LSP_99_103::via-R43 Up-------------------------------------------------------------------------------------------------------------------Sessions : 1===================================================A:#

The command “show router rsvp session” can be used to show which paths are currently active. Since the only session being shown is the Primary Path, this again demonstrates that the Secondary path is not active.



show router mpls lsp detail

Show router mpls lsp detail====================================================MPLS LSPs (Originating) (Detail)====================================================----------------------------------------------------------------------------------------------------------------------Type : Originating----------------------------------------------------------------------------------------------------------------------LSP Name : “LSP_99_103” LSP Tunnel ID : 1From : 10.10.10.99 To : 10.10.10.103Adm State : Up Oper State : UpLSP Up Time : 0d 00:01:34 LSP Down Time : 0d 00:02:19Transitions : 1 Path Changes : 0Retry Limit : 0 Retry Timer : 30 sSignaling : RSVP Resv. Style : SEHop Limit : 255 Negotiated MTU : 1500Fast Reroute : Enabled FR Hop Limit : 4ADSPEC : DisabledPrimary(a) : Primary_Path Up Time : 0d 00:01:34Bandwidth : 0Standby : Secondary_Path Down Time : 0d 00:01:34Bandwidth : 0=====================================================

The command "show router mpls lsp detail" is used to verify that the lsp is established.The command "show router mpls lsp detail" is used to verify that the lsp is established.

The command “show router mpls lsp detail” can be used to determine that the LSP is both administratively and operational “up”. Also, this command can be used to determine which path is in active state. The arrow in this diagram shows that the “Primary” field has an “(a)” indicator. This indicates that the primary path is active. Furthermore it can be seen that the Primary path has been active for a period of time, while the Secondary path has been down for a period of time.

Label Description LSP Name The name of the LSP used in the path. To The system IP address of the egress router for the LSP. Adm/Adm State Down — The path is administratively disabled.

Up — The path is administratively enabled. Opr/Oper State Down — The path is operationally down.

Up — The path is operationally up. LSPs The total number of LSPs configured. From The IP address of the ingress router for the LSP LSP Up Time The length of time the LSP has been operational. Transitions The number of transitions that have occurred for the LSP. Retry Limit The number of attempts software should make to re-establish the LSP after it has failed LSP Signaling Specifies the signalling style. Hop Limit The maximum number of hops that an LSP can traverse, including the ingress and egress routers. Fast Reroute/FastFail Config enabled — Fast reroute is enabled. In the event of a failure, traffic is immediately rerouted on the pre-

computed detour LSP, thus avoid-ing packet-loss. disabled — There is no detour LSP from each node on the primary path.

ADSPEC enabled — The LSP will include advertising data (ADSPEC) objects in RSVP messages. disabled — The LSP will not include advertising data (ADSPEC) objects in RSVP messages.

Primary The preferred path for the LSP. Secondary The alternate path that the LSP will use if the primary path is not available.


The output of the ‘show router mpls lsp <lsp-name> path detail’ shows the status and parameters associated with the configured LSP, as well as the hop specified in the configuration, the actual hop taken by the LSP and the labels at each hop.

The output shown above only shows the information for the Primary path of the LSP named ‘LSP_99_103’.


show router mpls lsp path detail

A:P99# show router mpls lsp LSP_99_103 path detail===============================================================================MPLS LSP LSP_99_103 Path (Detail)===============================================================================Legend :

@ - Detour Available # - Detour In Useb - Bandwidth Protected n - Node Protected

===============================================================================-------------------------------------------------------------------------------LSP LSP_99_103 Path via-R43-------------------------------------------------------------------------------LSP Name : LSP_99_103 Path LSP ID : 1From : 10.10.10.99 To : 10.10.10.103Adm State : Up Oper State : UpPath Name : via-R43 Path Type : PrimaryPath Admin : Up Path Oper : UpOutInterface: 1/1/3 Out Label : 131063Path Up Time: 0d 00:12:51 Path Dn Time : 0d 00:00:00Retry Limit : 0 Retry Timer : 30 secRetryAttempt: 0 Next Retry In : 0 secBandwidth : 256 Mbps Oper Bandwidth : 256 MbpsHop Limit : 4Record Route: Record Record Label : RecordOper MTU : 9198 Negotiated MTU : 9198 Adaptive : Enabled MBB State : N/AInclude Grps: Exclude Grps :None NonePath Trans : 1 CSPF Queries : 1Failure Code: noError Failure Node : n/aExplicitHops:

10.10.42.3 -> 10.10.43.3 -> 10.10.44.3 ->10.10.45.3Actual Hops :

10.10.42.2(10.10.10.99)-> 10.10.42.3(10.10.10.100) Record Label : 131063-> 10.10.43.3(10.10.10.101 Record Label : 131068-> 10.10.44.3(10.10.10.102) Record Label : 131063-> 10.10.45.3 (10.10.10.103) Record Label : 131064

ComputedHops:10.10.42.2 -> 10.10.42.3 -> 10.10.43.3 -> 10.10.44.3 -> 10.10.45.3

- output continued on next slide -


The output of the ‘show router mpls lsp <lsp-name> path detail’ shows the status and parameters associated with the configured LSP, as well as the hop specified in the configuration, the actual hop taken by the LSP and the labels at each hop.

The output shown above only shows the information for the Secondary path of the LSP named ‘LSP_99_103’. The secondary path is operationally down because it has not been configured in ‘standby’ mode, therefore, it has not yet been signaled and established. It will only be signaled if the primary path fails.


show router mpls lsp path detail (cont’d)

A:P99# show router mpls lsp LSP_99_103 path detail===============================================================================MPLS LSP LSP_99_103 Path (Detail)===============================================================================Legend :


===============================================================================- Output continued from previous slide -

-------------------------------------------------------------------------------LSP LSP_99_103 Path via-R33-------------------------------------------------------------------------------LSP Name : LSP_99_103 Path LSP ID : 1 From : 10.10.10.99 To : 10.10.10.103 Adm State : Up Oper State : Up Path Name : via-R33 Path Type : Secondary Path Admin : Up Path Oper : Down OutInterface: n/a Out Label : n/a Path Up Time: 0d 00:00:06 Path Dn Time : 0d 00:00:00 Retry Limit : 0 Retry Timer : 30 sec RetryAttempt: 0 Next Retry In : 0 sec Bandwidth : 128 Mbps Oper Bandwidth : 0 Mbps Hop Limit : 255 Record Route: Record Record Label : Record Oper MTU : 9198 Negotiated MTU : 9198 Adaptive : Enabled MBB State : N/A Include Grps: Exclude Grps : None NonePath Trans : 1 CSPF Queries : 0 Failure Code: noError Failure Node : n/a ExplicitHops: 10.10.42.3 -> 10.10.33.3 -> 10.10.34.3 ->10.10.45.3Hops SpecifiedActual Hops :

No Hops Specified===============================================================================

•When secondary path is not in standby, its operational state is Down•When secondary path is in standby, its operational state is Up


The command “show router mpls status” command is a very important command showing the number of LSPs this router is part of. Furthermore this command will show the role this router plays in the LSP. This diagram shows that this router is originating 1 Dynamic LSP, which makes this router the Head of an LSP.

Admin Status Down — MPLS is administratively disabled. Up — MPLS is administratively enabled.

Oper StatusDown — MPLS is operationally down. Up — MPLS is operationally up.

LSP CountsStatic LSPs — Displays the count of static LSPs that originate, transit, and terminate on or through

the router. Dynamic LSPs — Displays the count of dynamic LSPs that originate, transit, and terminate on or

through the router. Detour LSPs — Displays the count of detour LSPs that originate, transit, and terminate on or throughthe router.

FR ObjectEnabled — Specifies that Fast reroute is enabled for the LSP. Disabled — Specifies that Fast reroute is disabled for the LSP.

Resignal TimerEnabled — Specifies that the resignal timer is enabled for the LSP. Disabled — Specifies that the resignal timer is disabled for the LSP.



Command displays MPLS operation information.

A:# show router mpls status

=================================================MPLS Status=================================================Admin Status : Up Oper Status : UpFR Object : Enabled Resignal Timer : Disabled

LSP Counts Originate Transit Terminate--------------------------------------------------------------------------------------------------------------Static LSPs 0 0 0Dynamic LSPs 1 0 0Detour LSPs 0 0 0=================================================A:#


This command can be used to identify the names of the LSPs configured for this router and the address of the tunnel destination. In this example the LSP name is “LSP_99_103” and the termination node of this LSP has address 10.10.10.103.

Syntax: show router mpls __________lsp lsp-name [status {up|down}] [from ip-address | to ip-address] [detail]lsp {transit | terminate} [status {up | down}] [from ip-address | to ip-address | lsp-name name] [detail]lsp count

lsp lsp-name activepathlsp lsp-name path [path-name] [status {up|down}] [detail]

lsp lsp-name — The name of the LSP used in the path.

status up — Displays an LSP that is operationally up.

status down — Displays an LSP that is operationally down.

from ip-address — Displays the IP address of the ingress router for the LSP.

to ip-address — Displays the IP address of the egress router for the LSP.

transit — Displays the number of static LSPs that transit through the router.

terminate — Displays the number of static LSPs that terminate at the router.

lsp count — Displays the total number of LSP.

activepath — Specifies to display the number of packets that have been forwarded over the current LSP active path.



show router mpls lsp

Command displays LSP details.

A:P3# show router mpls lsp

===============================================MPLS LSPs (Originating)===============================================LSP Name To Fastfail Adm Opr

Config---------------------------------------------------------------------------------------------------------LSP_99_103 10.10.10.103 No Up Up---------------------------------------------------------------------------------------------------------LSPs : 1===============================================A:P3#



Lab 5.1 and 5.2 – CSPF Based LSPs and LSP Establishment

•Pod 1 •Pod 2

•Pod 3

•Core 2•Core 1

•Core 3

•Edge 1

•Edge 3

•Edge 2

•Pod 4

•Core 4

•Edge 4

•10.48.1.0/24 •10.64.1.0/24

•10.16.1.0/24 •10.32.1.0/24

•10.x.y.z/24

•Service Provider Network•RSVP-TE Enabled Core

•LSPs from P-P

•LSPs from PE-PE


RSVP Implementation

Section 3 - LSP Traffic Protection



Section Outline

Secondary Paths

Fast Reroute• One-to-One Method• Facilities Backup Method

LSP Revertive Behaviour


RSVP-TE Traffic Protection Terminology

LSR: Label-Switch Router.

LSP: An MPLS Label-Switched Path.

Local Repair: Techniques used to repair LSP tunnels quickly when a node or link along the LSP's path fails.

PLR: Point of Local Repair. The head-end LSR of a backup tunnel or a detour LSP.

One-to-One Backup: A local repair method in which a backup LSP is separately created for each protected LSP at a PLR.

Facility Backup: A local repair method in which a bypass tunnel is used to protect one or more protected LSPs that traverse the PLR, the resource being protected, and the Merge Point in that order.

Protected LSP: An LSP is said to be protected at a given hop if it has one or multiple associated backup tunnels originating at that hop.

Detour LSP: The LSP that is used to re-route traffic around a failure in one-to-one backup.

Bypass Tunnel: An LSP that is used to protect a set of LSPs passing over a common facility.

Backup Tunnel: The LSP that is used to backup up one of the many LSPs in many-to-one backup.

NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel that bypasses a single link of the protected LSP.

NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel that bypasses a single node of the protected LSP.

Backup Path: The LSP that is responsible for backing up one protected LSP. A backup path refers to either a detour LSP or a backup tunnel.

MP: Merge Point. The LSR where one or more backup tunnels rejoin the path of the protected LSP downstream of the potential failure. The same LSR may be both an MP and a PLR simultaneously.

DMP: Detour Merge Point. In the case of one-to-one backup, this is an LSR where multiple detours converge. Only one detour is signaled beyond that LSR.

Reroutable LSP: Any LSP for which the head-end LSR requests local protection.

CSPF: Constraint-based Shortest Path First.


A common problem with relying on the IGP re-convergence is the restoration time after a link or node failure. With traditional routing protocols, it can take anywhere from several seconds up to nearly a minute for a failure to be bypassed.

There are multiple problems with traditional IP routing protocols when it comes to fast restoration of connectivity: Detecting the failure quickly, performing time consuming Dijkstra computations to find an alternative route, signaling an LSP when using MPLS, and installing new information in the forwarding table.

MPLS Secondary path enables a faster recovery of failed LSPs by allowing the LSP to be configured with a backup path which can optionally be pre-signaled and established.

MPLS Fast Reroute further enhances recovery times of failed LSPs by defining ways of pre-computing and signaling backup paths before a failure, so that traffic can immediately be switched over to the backup path by the nearest node upon a failure. This allows traffic to flow almost continuously, without waiting for routing protocol convergence and signaling overhead.

It must be noted these two protection mechanisms do not reduce failure detection times but does greatly reduce traffic restoration times once the failure is detected.


Problems with Traditional Routing Protocols

Difficult to quickly restore connectivity relying only on traditional IP protocols because:

• Failures are not detected quickly

• Takes time to compute an alternate route

• Takes time to signal an alternate LSP and update forwarding tables



MPLS/RSVP-TE LSP Protection

Path Protection• Primary LSP with Secondary LSP• Primary LSP with Secondary Standby LSP

Fast Reroute• One-to-One Backup• Facilities Backup


Primary Path LSP: Only one primary path can be defined for an LSP.

Secondary Path LSP not in standbyThe secondary path is not signaled until a network failure causes the primary path to fail, and the Head-end node is made aware of the failure.

An alternative path that the LSP uses if the primary path is not available.

After the switch over from the primary to the secondary, the software continuously tries to revert to the primary path.

Up to eight secondary paths can be specified. All the secondary paths are considered equal and the first available path is used. The software will not switch back among secondary paths.

The Primary and Secondary paths can be configured with strict or loose hops, or with no hops specified.


Backup LSP - LSPs with Secondary Path Non-Standby

Primary Path LSP: One primary path

Secondary Path LSP

— Alternative path that is used if the primary path is not available.

— Continuously tries to revert back to the primary path.

— Up to eight secondary paths can be specified.

— All the secondary paths are considered equal and the first available path is used.

— The software will not switch back among secondary paths.

R1

R2R3

R4

R5R6R7

R8

R9

Primary LSP: R1->R2->R3->R4->R5

Secondary LSP: R1->R6->R7->R8->R9->R5

X

Failure in primary path triggers secondary LSP Secondary Path initiates signaling to bring up Secondary LSP


Standby LSPThe secondary path LSP is normally signaled once the primary path LSP fails. The standby keyword ensures that the secondary path LSP is signaled and maintained indefinitely in a hot-standby state. When the primary path is re-established then the traffic is switched back to the primary path LSP.


Backup LSP - Secondary Path Standby

Primary LSP

Secondary Standby LSP— A CLI option that available only for Secondary LSP

— Ensures that the secondary path LSP is signaled and maintained indefinitely in a hot-standby state.

— When the primary path is re-established then the traffic is switched back to the primary path LSP.

— Multiple standby paths can be signaled per LSP.

R1

R2R3

R4

R5R6R7

R8

R9

Primary LSP: R1->R2->R3->R4->R5

Secondary LSP with standby : R1->R6->R7->R8->R9->R5

X

Failure in primary path triggers secondary LSP Hot Standby LSP – Signaled and Maintained Always


In general, when an LSP is configured with a Secondary path, the head-end node will switch the LSP to the Secondary path when the Primary path fails. However, there are some exceptions,

When the Primary path is loose and the Secondary path is not in standby, the head-end node will try to find another path for the Primary path and resignal the LSP onto that path. If it cannot find a new Primary path, it will try to switch to the Secondary path, provided it can be established.

When the Primary path is loose and the Secondary path is in standby, the head-end node will switch the LSP to the Secondary path, but if it is able to find a new path for the Primary path, it will revert the LSP to the Primary path.

After a switchover from the primary to the secondary path, the system continuously tries to revert to the primary path. The switch back to the primary path is based on either the retry-timer interval or the refresh-timer, depending on where the failure occurs.

The retry-timer will be used to try and resignal the LSP when the RSVP session is down and no PATH message can be sent (either because there is no IGP next-hop or there is a CSPF computation failure). If for example the path specifies an explicit 1st hop and that link remains up but a failure occurs multiple hops away the retry timer will not be activated to try and resignal the LSP. This is because the 7x50 will be able to resolve a next hop based on the explicit hop and send a PATH message. In this case the head-end node will try to resignal the LSP based on the RSVP Refresh-Timer (Every 30 seconds by default).

There can be multiple Secondary paths configured (up to 8 can be configured) to protect an LSP. If after the LSP is switched to one of the Secondary paths (after failure of the Primary path) another failure occurs which affects the active Secondary path, the head-end node will switch the LSP to another of the Secondary paths. Subsequently, if the failure that affected the previously used Secondary path is restored, the head-end node will not switch the LSP back to that Secondary path. That is, the system will not switch back among secondary paths. The system starts the signaling of all non-standby secondary paths at the same time. Retry counters are maintained for each unsuccessful attempt. Once the retry limit is reached on a path, the system will not attempt to signal the path and administratively shuts down the path. The first successfully established path is made the active path for the LSP.


LSP Switch-over Behavior with Secondary Path

Primary path is loose, Secondary path is not in standby mode

• when failure affects Primary path, head-end node determines a new Primary path and resignals the LSP on that path. The Secondary path is not signaled and used.

Primary path is loose, Secondary path is in standby mode

• when failure affects Primary path, head-end node switches the LSP to the Secondary path, and determines a new path for the Primary. If it finds a new Primary path, it switches the LSP back onto the Primary

Primary path is strict, Secondary path in not in standby mode

• When failure affects the Primary path, head-end node signals the Secondary path and switches the LSP to it. When failure is restored LSP reverts to Primary path.

Primary path is strict, Secondary is in standby mode

• Behavior is the same as non-standby mode, except that the Secondary path is already signaled and established.


Primary and Secondary paths, when statically configured, are deterministic and will allow specific path protection as configured. The benefit to configuring Primary and Secondary paths is that path protection is guaranteed regardless of the location of the failure or if multiple failures exist. When statically configuring the Primary and Secondary paths, it is not advisable to configure common links since the failure of the common link will result in the failure of both LSPs. However, if the Primary and Secondary LSP are created using a Loose path, or if portions of the LSPs are making use of Loose path then it is entirely possible that the IGP path chosen will cause both LSPs to make use of a common link.

Primary and Secondary paths do indeed protect the entire path. However a failure anywhere along the path requires the LSP head end to be notified that a failure has occurred. Its only the LSP head end that can signal the activation of the Secondary LSP. It might take some time for the head of the LSP to be notified that a failure has occurred downstream. Furthermore, by creating Primary and Secondary paths, network resources are being reserved for each LSP. This results in “double booking” the resources and overstating the actual resource utilization for the network. If selective protection is required for a specific link or node, path protection such as the one being described will not suffice. For link or node protection Fast Reroute is required. FRR is described in the following section.


LSP Protection with Secondary Path

Pros• Deterministic data flow during any point in primary path• Multiple failures along the primary path can be handled by the

same secondary path• When statically configured, no nodes or links should be shared by

the Primary and Secondary paths (otherwise if that link or node goes down, both are lost)

• Entire path is protected

Cons• Failure of a link or node might take a while to reach head of

tunnel• Full path resources are reserved over both Primary and Secondary

paths, therefore “double booking”• Selective protection of link or node is not possible


The “primary” lsp command will create an LSP, “LSP_99_103” in this case, with a primary path from the Head of the LSP to the LSP end point. In this example, 10.10.10.99 is the LSP head while, 10.10.10.103 is the LSP end point. Note that, although the to-address can be any interface on the end system, in the Alcatel-Lucent Service environment, the to-address must be the system address of the destination node. (required to bind the path to a Service Distribution Point).

cspfSyntax [no] cspfContext config>router>mpls>lspDescription This command enables Constrained Shortest Path First (CSPF) computation for constrained-path LSPs. Constrained-path LSPs are the ones that take configuration constraints into account. CSPF is also used to calculate the detour routes when fast-reroute is enabled. Explicitly configured LSPs where each hop from ingress to egress is specified do not use CSPF. The LSP will be set up using RSVP signaling from ingress to egress.

The no form of the command disables CSPF computations.

Default no cspf


LSP Primary Path Configuration

config>router# mpls

config>router>mpls#lsp “LSP_99_103”

config>router>mpls>lsp# to 10.10.10.103

config>router>mpls>lsp# cspf

config>router>mpls>lsp# primary “via-R43"

config>router>mpls>lsp>primary# hop-limit 4

config>router>mpls>lsp>primary# bandwidth 256

config>router>mpls>lsp>primary# no shutdown

10.10.10.103

10.10.10.10210.10.10.101

10.10.10.10010.10.10.99

10.10.43.3 10.10.44.3


10.10.42.3

10.10.33.3

10.10.34.3

10.10.45.3

“via-R33”

Primary LSP_99_103


5


The “secondary” command specifies an alternative path that the LSP should use if the primary path is not available.

Syntax [no] secondary path-nameContext config>router>mpls>lspDescription This command specifies an alternative path that the LSP uses if the primary path is not available. This command is optional and is not required if the config router mpls lsp lsp-name primary path-name command is specified. After the switch over from the primary to the secondary, the software continuously tries to revert to the primary path. The switch back to the primary path is based on the retry-timer interval.

Up to eight secondary paths can be specified. All the secondary paths are considered equal and the first available path is used. The software will not switch back among secondary paths. Software starts the signaling of all non-standby secondary paths at the same time. Retry counters are maintained for each unsuccessful attempt. Once the retry limit is reached on a path, software will not attempt to signal the path and administratively shuts down the path. The first successfully established path is made the active path for the LSP.

The no form of this command removes the association between this path-name and lsp-name. All specific configurations for this association are deleted. The secondary path must shutdown first in order to delete it. The no secondary path-name command will not result in any action except a warning message on the console indicating that the secondary path is administratively up. Primary and Secondary Path CommandsDefault noneParameters path-name — The case-sensitive alphanumeric name label for the LSP path up to 32 characters in length.


LSP Secondary Path Configuration

config>router>mpls>lsp# secondary “via-R33"

config>router>mpls>lsp>secondary$ bandwidth 128

config>router>mpls>lsp>secondary$ no shutdown

config>router>mpls>lsp>secondary# exit

config>router>mpls>lsp# no shutdown

config>router>mpls>lsp# exit

10.10.10.103

10.10.10.10210.10.10.101

10.10.10.10010.10.10.99

10.10.43.3 10.10.44.3


10.10.42.3

10.10.33.3 10.10.34.3

10.10.45.3

“via-R33”

Secondary LSP_99_103


Secondary Path is configured but not activeSecondary Path is configured but not active


The “show router mpls path lsp-binding” command can be used to find which paths are up and which paths are down. Furthermore this command identifies which path has been defined as a primary path and which as a secondary path. In this case the secondary path, named “Secondary_Path” is in a Down state since the secondary path is not configured in Standby mode. Therefore the Secondary path is not a “hot standby”secondary path. Upon failure of the Primary path the secondary path will have to be signaled which will enable the secondary path.


show router mpls path lsp-binding

Display MPLS paths with binding information.

A:# show router mpls path lsp-binding

===================================================MPLS Path:===================================================Path Name Opr LSP Name Binding---------------------------------------------------------------------------------------------------------------Via-R43 Up LSP_99_103 PrimaryVia-R33 Down LSP_99_103 Secondary---------------------------------------------------------------------------------------------------------------Paths : 2===================================================A:#


A secondary path, when configured, remains in a down state by default. That means when the primary path fails, the Head end router must signal the secondary path to become active. While saving on “double counting” resources, this has the unfortunate affect of increasing the latency associated with recovering a failed path. By using the “standby”command within the secondary syntax, the secondary path becomes active in a “hot standby” mode. While this reduces the latency associated with a failed path, there is a “double counting” of resources. Furthermore, the worst case scenario is that the double counting occurs on the same link on links which are shared between the primary and secondary links.

standbySyntax [no] standbyContext config>router>mpls>lsp>secondary path-name

Description The secondary path LSP is normally signaled once the primary path LSP fails. The standby keyword ensures that the secondary path LSP is signaled and maintained indefinitely in a hot-standby state. When the primary path is re-established then the traffic is switched back to the primary path LSP.

The no form of this command specifies that the secondary LSP is signaled when primary path LSP fails.

Default none


LSP Secondary Standby Path Configuration

config>router>mpls>lsp# secondary “via-R33“

config>router>mpls>lsp>secondary$ standby

config>router>mpls>lsp>secondary$ bandwidth 128

config>router>mpls>lsp>secondary$ no shutdown

config>router>mpls>lsp>secondary# exit

config>router>mpls>lsp# no shutdown

config>router>mpls>lsp# exit

10.10.10.103

10.10.10.10210.10.10.101

10.10.10.10010.10.10.99

10.10.43.3 10.10.44.3


10.10.42.3

10.10.33.3 10.10.34.3

10.10.45.3

“via-R33”

Secondary LSP_99_103


Secondary Path is signaled and maintained indefinitely in a hot-standby stateSecondary Path is signaled and maintained indefinitely in a hot-standby state

Primary LSP_99_103


This command was shown prior to the “standby” command being applied to the Secondary path. It is repeated here to show that once the “standby” command has been added, the Secondary path is now in “standby” mode and is Operationally “up”.


show router mpls path lsp-binding

Display MPLS paths with binding information.

A:# show router mpls path lsp-binding=================================================MPLS Path:=================================================Path Name Opr LSP Name Binding--------------------------------------------------------------------------------------------------------------Via-R43 Up LSP_99_103 PrimaryVia-R33 Up LSP_99_103 Standby--------------------------------------------------------------------------------------------------------------Paths : 2=================================================A:#


This command was shown previously but is now repeated to show that once the “standby” command has been configured for the secondary path, 2 rsvp sessions exist. Prior to the “standby” command being applied to Secondary path, this command only showed one rsvp path, the Primary path. This command shows that the “standby” command created a hot standby path which is operational active.


show router rsvp session

Command shows RSVP session information.

A:# show router rsvp session

===================================================RSVP Sessions===================================================From To Tunnel LSP Name State

ID ID-------------------------------------------------------------------------------------------------------------------10.10.10.99 10.10.10.103 1 1 LSP_99_103::via-R43 Up10.10.10.99 10.10.10.103 1 2 LSP_99_103::via-R33 Up-------------------------------------------------------------------------------------------------------------------Sessions : 2===================================================A:#


This command was shown previously, prior to the “standby” command being applied to the secondary path. Once the “standby” command is used, the “show router mpls lsp detail” command can be used to show that both the primary and the secondary paths are “up”. Although only the Primary path is active, both the primary and secondary paths are operationally up.

Label Description LSP Name The name of the LSP used in the path. To The system IP address of the egress router for the LSP. Adm/Adm State Down — The path is administratively disabled.

Up — The path is administratively enabled. Opr/Oper State Down — The path is operationally down.

Up — The path is operationally up. LSPs The total number of LSPs configured. From The IP address of the ingress router for the LSP LSP Up Time The length of time the LSP has been operational. Transitions The number of transitions that have occurred for the LSP. Retry Limit The number of attempts software should make to re-establish the LSP after it has failed LSPSignaling Specifies the signalling style. Hop Limit The maximum number of hops that an LSP can traverse, including the ingress and egress

routers.Fast Reroute/FastFail Config enabled — Fast reroute is enabled. In the event of a failure, traffic is

immediately rerouted on the pre-computed detour LSP, thus avoiding packet-loss.disabled — There is no detour LSP from each node on the primary path.

ADSPEC enabled — The LSP will include advertising data (ADSPEC) objects in RSVP messages. disabled — The LSP will not include advertising data (ADSPEC) objects in RSVP messages.

Primary The preferred path for the LSP. Secondary The alternate path that the LSP will use if the primary path is not available.


show router mpls lsp detail

Show router mpls lsp detail====================================================MPLS LSPs (Originating) (Detail)====================================================----------------------------------------------------------------------------------------------------------------------Type : Originating----------------------------------------------------------------------------------------------------------------------LSP Name : “LSP_99_103” LSP Tunnel ID : 1From : 10.10.10.99 To : 10.10.10.103Adm State : Up Oper State : UpLSP Up Time : 0d 00:01:34 LSP Down Time : 0d 00:02:19Transitions : 1 Path Changes : 0Retry Limit : 0 Retry Timer : 30 sSignaling : RSVP Resv. Style : SEHop Limit : 255 Negotiated MTU : 1500Fast Reroute : Enabled FR Hop Limit : 4ADSPEC : DisabledPrimary(a) : Primary_Path Up Time : 0d 03:49:34Bandwidth : 256 MbpsStandby : Secondary_Path Up Time : 0d 00:01:42Bandwidth : 128 Mbps=====================================================

The command "show router mpls lsp detail" is used to verify that the lsp is established.The command "show router mpls lsp detail" is used to verify that the lsp is established.


The “show router mpls status” command shows that once the “standby” command has been configured on the secondary path, this router now has 2 dynamic LSPs, the Primary and the Secondary.



Command displays MPLS operation information.

A:# show router mpls status

=================================================MPLS Status=================================================Admin Status : Up Oper Status : UpFR Object : Enabled Resignal Timer : Disabled

LSP Counts Originate Transit Terminate--------------------------------------------------------------------------------------------------------------Static LSPs 0 0 0Dynamic LSPs 2 0 0Detour LSPs 0 0 0=================================================A:#


The 7750 SR OS LSP diagnostics are implementations of LSP ping and LSP traceroute based on Internet Draft draft-ietf-mpls-lsp-ping-xx.txt. LSP ping, as described in the draft, provides a mechanism to detect data plane failures in MPLS LSPs. LSP ping and LSP traceroute are modeled after the ICMP echo request/reply used by ping and traceroute to detect and localize faults in IP networks.

For a given FEC, LSP ping verifies whether the packet reaches the egress label edge router (LER), while in LSP traceroute mode, the packet is sent to the control plane of each transit label switched router (LSR) which performs various checks to see if it is actually a transit LSR for the path.

oam lsp-traceSyntax lsp-trace {lsp-name [path path-name]} | {prefix ip-prefix/mask}} [size octets] [min-ttl minlabel-

ttl] [max-ttl max-label-ttl] [max-fail no-response-count] [send-count send-count]

[timeout timeout] [interval interval] [fc fc-name [profile {in | out}]]Description Displays the hop-by-hop path for an LSP.

The lsp-trace command performs an LSP traceroute using the protocol and data structures defined in the IETF draft (draft-ietf-mpls-lsp-ping-02.txt). The LSP traceroute operation is modeled after the IP traceroute utility which uses ICMP echo request and reply packets with increasing TTL values to determine the hop-by-hop route to a destination IP. In an LSP traceroute, the originating device creates an MPLS echo request packet for the LSP to be tested with increasing values of the TTL in the outermost label. The MPLS echo request packet is sent through the data plane and awaits a TTL exceeded response or the MPLS echo reply packet from the device terminating the LSP. The devices that reply to the MPLS echo request packets with the TTL exceeded and the MPLS echo reply are displayed.


oam lsp-trace

A:# oam lsp-trace LSP_99_103lsp-trace to LSP_99_103: 0 hops min, 0 hops max, 116 byte packets1 10.10.10.100 rtt<10ms, rc=6 (DSRtrMatchLabel)2 10.10.10.101 rtt<10ms, rc=6 (DSRtrMatchLabel)3 10.10.10.102 rtt<10ms, rc=6 (DSRtrMatchLabel)4 10.10.10.103 rtt<10ms, rc=3 (EgressRtr)A:#



Lab 6 - Enabling Primary and Secondary LSP Tunnels

•Pod 1 •Pod 2

•Pod 3

•Core 2•Core 1

•Core 3

•Edge 1

•Edge 3

•Edge 2

•Pod 4

•Core 4

•Edge 4

•10.48.1.0/24 •10.64.1.0/24

•10.16.1.0/24 •10.32.1.0/24

•10.x.y.z/24


•Primary Path for LSP P3-P2 •Secondary Path for LSP P3-P2

•Primary Path for LSP PE3-P2 •Secondary Path for LSP PE3-P2


RSVP Implementation

Section 4 – Fast Reroute


Fast Reroute

MPLS Fast Reroute addresses these issues by defining ways of pre-computing and signaling backup paths before a failure, so that traffic can immediately be switched over to the backup path by the nearest node upon a failure. This allows traffic to flow almost continuously, without waiting for routing protocol convergence and signaling overhead.

MPLS Fast Reroute depends on LSPs being established using the RSVP-TE. Using RSVP-TE, it is possible to predetermine the path an LSP should take by specifying an explicit path for the LSP. This allows for the creation of alternative LSPs that do not depend on the same link or node as the LSP being protected.

Fast Reroute is described in RFC 4090 “Fast Reroute Extensions to RSVP-TE for LSP Tunnels.


Fast Reroute Overview

MPLS Fast Reroute (FRR) defines ways of pre-configuring and signaling backup paths before a failure

Allows for sub-50ms failover from link failure detection

Uses LSPs established using RSVP-TE

Allows protection to be applied as close to point of failure as possible


Fast-rerouteCreates a pre-computed backup LSP from each node in the path of the LSP. In case of failure of a link or LSP between two nodes, traffic is immediately rerouted on the pre-computed backup LSP, thus minimize packet-loss.

When fast-reroute is enabled, each node along the path of the LSP tries to establish a backup LSP as follows:Each upstream node sets up a backup LSP that avoids only the immediate downstream node. If it is not possible to set up a backup LSP that avoids the immediate downstream node, a backup can be set up to the downstream node on a different interface.The backup LSP may take one or more hops before merging back on to the protected LSP path, and may only merge to the protected LSP at the eLER.

When the upstream node is informed that a downstream router is using its backup LSP, the iLER switches traffic to a standby path if one was set up for the LSP. Fast reroute is available only for the primary path. No configuration is required on the transit hops of the LSP. The iLER will signal all intermediate routers using RSVP to set up their backup LSPs.


Fast Re-Route (FRR)

In case of failure of a link or LSP between two nodes, traffic is immediately rerouted on the pre-computed backup LSP, thus minimizing packet-loss

• Each upstream node sets up a backup LSP that avoids only the immediate downstream node, and merges back on to the actual path of the LSP

• The backup LSP may take one or more hops before merging back on to the main LSP path, and may only merge at the eLER

• When the upstream node is informed that a downstream router is using its backup LSP, the ingress router switches traffic to a standby path if one was set up for the LSP

No configuration is required on the transit hops of the LSP

The ingress router will signal all intermediate routers using RSVP to set up their backup LSPs

CSPF must be enabled for fast-reroute to work


For several years the industry had deployed two independent methods of doing fast reroute; these methods have become known as one-to-one backup and facility backup. Vendors trying to support both methods experienced compatibility problems in attempting to produce a single implementation capable of interoperating with both methods. There are technical tradeoffs between the methods. These tradeoffs are so topologically dependent that the community has not converged on a single approach.

Attempts have been made to rationalize the RSVP signaling for both methods so that any implementation can recognize all fast reroute requests and clearly respond. The response may be positive if the method can be performed, or it may be a clear error to inform the requester to seek alternate backup means. Industry standards have been written to allow a single implementation to support both methods, thereby providing a range of capabilities. The described behavior and extensions to RSVP allow LERs and LSRs to implement either method or both.

While the two methods could in principle be used in a single network, it is expected that operators will continue to deploy either one or the other. Standards have been developed to standardize the RSVP signaling so that a network composed of LSRs that implement both methods or a network composed of some LSRs that support one method and others that support both can properly signal among those LSRs to achieve fast restoration.


FRR Evolution

Resource that is protected• Link• Node

Methods of performing the LSP protection• One-to-one backup• Facility backup

Extensions to RSVP allow LERs and LSRs to implement either/both methods


The primary or main path, in the diagram above the path formed by routers R1-R2-R3-R4-R5 is called the Protected LSP. The path created to protect a specific link, the backup LSP, is made up of the LSP using routers R2-R7-R8-R3 and is called either a Detour in the case of One-to-One protection or a Bypass in the case of Many to One protection(more later). The point at which the backup LSP deviates from the Protected LSP is knows as the Point of Local Repair (PLR) while the point at which the backup LSP rejoins the Protected LSP is known as the Merge Point (MP).

To ensure the fastest possible failover, the backup path must already be created, signaled, and prepared to accept traffic before the failure occurs. Therefore the PLR, the MP, and all transit routers must be prepared to accept traffic from the Primary LSP in the event of a failure.


Link Protection

R1R2

R3

R4

R5

R7 R8

PLR

Protected LSP: R1->R2->R3->R4->R5

Backup LSP: R2->R7->R8->R4

PLR – Point of Local RepairMP – Merge Point

MP

Detour or Bypass

The backup must be created and signaled before the failure occursThe PLR must be prepared to forward data from the primary path, and the MP must be ready to deliver the data back to the primary LSP


In order for the backup path to be created, R2 must be told that it is protecting the link between R2 and R3. R2 must also be told which LSP to protect. Conceivably there might be several LSPs from R1 moving through R2, not all of which need to be protected. For example, a Primary LSP used for data might not need to be protected while an LSP used for voice might require protection.

Since the Primary LSP is configured at the head-end of the path, R1, there must be protection information passeddown from the Primary LSP head to the PLR, in this case from R1 to R2. This information is carried in the LSP Path message for the LSP. Two objects of the Path message are used to accomplish this task, the Local Protection Desired flag in the Session Attribute object and the Fast Reroute Object.

When the PLR receives the notification that a particular LSP needs protection, it calculates a CSPF path around the link. Since this backup is protecting a specific LSP, other constraints might be required during the computation such as maximum number of hops, bandwidth reservation, and setup or hold priorities. These constraints are propagated to the PLR in the Fast Reroute Object.

In the diagram above, LSP1 is a protected LSP while LSP2 is an unprotected LSP. LSP1 will use the Path message to propagate information to the PLR that a link protection is necessary for this LSP around the link between R2-R3 link.


FRR Signaling

R1R2

R3

R4

R5

R7 R8

PLR MP

Detour or Bypass

R10

Protected LSP1: R1->R2->R3->R4->R5

Backup LSP: R2->R7->R8->R4

Unprotected LSP2: R1->R2->R3->R4->R10

1. LSP1 is a protected LSP whereas LSP2 is an unprotected LSP2. LSP1 propagates protection information in the LSP Path message using:

i) Local Protection Desired flag of Session Attribute Objectii) Fast Reroute Object

3. All transit routers (R2 for this example), the PLR, receives information that a particular LSP needs protection and begins a CSPF calculation to R3 avoiding the R2-R3 link

LSP1

LSP2


RFC 4090 defines two additional objects, FAST_REROUTE and DETOUR, to extend RSVP-TE for fast-reroute signaling. These new objects are backward compatible with LSRs that do not recognize them. Both objects can only be carried in RSVP Path messages.

The Fast Reroute Object is used to specify the requirements for the backup tunnel to be established for the protected LSP.

The Detour Object is used with the one-to-one backup method to identify the detour LSPs.


RSVP Extensions

RSVP extensions have been defined which enable the One-to-One or Facility Backup FRR functionality• Fast_Reroute Object• Detour Object (only for one-to-one method)

These additional RSVP extensions are carried in RSVP Path messages

Backward compatible with RSVP implementation that do not support them


The FAST_REROUTE object is used to control the backup used for the protected LSP. This specifies the setup and hold priorities, session attribute filters, and bandwidth to be used for protection. It also allows a specific local protection method to be requested. This object is inserted into the PATH message by the head-end LER and is not changed by downstream LSRs.

The two high-order bits of the Class-Num (11) cause nodes that do not understand the object to ignore it and pass it forward unchanged.

Setup Priority

The priority of the backup path with respect to taking resources, in the range 0 to 7. The value 0 is the highest priority. Setup Priority is used in deciding whether this session can preempt another session. See [RSVP-TE] for the usage on priority.

Holding Priority

The priority of the backup path with respect to holding resources, in the range 0 to 7. The value 0 is the highest priority. Holding Priority is used in deciding whether this session can be preempted by another session. See [RSVP-TE] for the usage on priority.

Hop-limit

The maximum number of extra hops the backup path is allowed to take, from current node (a PLR) to an MP, with PLR and MP excluded from the count. For example, hop-limit of 0 means that only direct links between PLR and MP can be considered.

Flags

0x01 One-to-One Backup Desired Requests protection via the one-to-one backup method.

0x02 Facility Backup Desired Requests protection via the facility backup method.


RSVP Extension - Fast Reroute Object

0 1 2 3

Length (Bytes)Class-Num

205C-Type

1

SetupPriority

HoldPriority

HopLimit

Flags

Bandwidth

Include-any

Exclude-any

Include-all

205=(11001101)

Pass unchanged if this class number unknown

Class Number=13

Fast Reroute Object

Backup path priority(0-highest, 7-lowest)

Preempt Priority(0-highest, 7-lowest)

0x01 One-to-One Backup0x02 Facility Backup


Bandwidth - Bandwidth required in bytes per second.

Include-any – IP addresses, any of which renders a link acceptable. A null set (all bits set to zero) automatically passes.

Exclude-any - IP addresses of unacceptable links

Include-all – IP addresses, all of which must be present for a link to be acceptable. A null set (all bits set to zero) automatically passes.


RSVP Extension - Fast Reroute Object (Cont’d)

0 1 2 3


205C-Type

1

SetupPriority

HoldPriority

HopLimit

Flags

Bandwidth

Include-any

Exclude-any

Include-all

Required BW (Bytes/sec)

List of IP AddressesAny of which may

be in pathList of IP AddressesNOT to be included

in path

List of IP AddressesAll of which must

be in path


PLR_ID (1-n)

IPv4 address identifying the Point of Local Repair (PLR) that is the beginning point of the detour. Any local address on the PLR can be used.

Avoid_Node_ID (1 - n)

IPv4 address identifying the immediate downstream node that the PLR is trying to avoid. Any local address of the downstream node can be used. This field is mandatory and is used by the Merge Point (MP).

As the diagram above suggests, there can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in a DETOUR object. If detour merging is desired, after each merging operation, the Detour Merge Point will combine all the merged detours in subsequent Path messages.

The high-order bit of the Class-Num is zero; LSRs that do not support the DETOUR objects will reject any Path message containing a DETOUR object and send a PathErr to notify the PLR.


RSVP Extension – Detour Object

0 1 2 3


63C-Type

7

Avoid_Node_ID 1

PLR_ID n

Avoid_Node_ID n

PLR_ID 1

63=(0111111)

Reject Path message if do not support Detour

Class Number=63

Detour Object

IP address ofPoint of Local Repair

IP address of routerPLR is trying to avoid


Local protection desired

This flag permits transit routers to use a local repair mechanism that may result in violation of the explicit route object. When a fault is detected on an adjacent downstream link or node, a transit node will reroute traffic for fast service restoration.

Label recording desired:

This flag indicates that label information should be included when doing a route record.

SE Style desired:

This flag indicates that the tunnel ingress node may choose to reroute this tunnel without tearing it down. A tunnel egress node will use the SE Style when responding with a Resv message. When requesting fast reroute, the head-end LSR will set this flag; this is not necessary for the path-specific method of the one-to-one backup method.

Bandwidth protection desired:

This flag indicates to the PLRs along the protected LSP path that a backup path with a bandwidth guarantee is desired. The bandwidth to be guaranteed is that of the protected LSP, if no FAST_REROUTE object is included in the PATH message; if a FAST_REROUTE object is in the PATH message, then the bandwidth specified therein is to be guaranteed.

Node protection desired:

This flag indicates to the PLRs along a protected LSP path that a backup path that bypasses at least the next node of the protected LSP is desired.


Session Attribute Flags

Session Attribute flags are used to request bandwidth and node protection explicitly• Local protection desired• Label recording desired• SE Style desired• Bandwidth protection desired• Node protection desired


FRR Methods

One-to-one Backup - A local repair technique where a backup LSP is separately created for each protected LSP at a PLR.

Facility Backup - A local repair technique where a bypass tunnel is used to protect one or more protected LSPs which traverse the PLR, the resource being protected and the Merge Point in that order.

A Bypass Tunnel is an LSP that is used to protect a set of LSPs passing over a common facility. Whereas a Backup Tunnel is the LSP that is used to backup up one of the many LSPs in many-to-one backup.

The fast reroute (facility backup) extensions to RSVP-TE enable you to create a single LSP, known as a bypass tunnel, to back up a set of LSPs by bypassing specific links in the LSP. In the event of a failure in any link of the protected RSVP-TE LSP (the primary LSP), MPLS redirects traffic to the associated bypass tunnel in tens of milliseconds .


Fast Re-Route (FRR) Methods

Directing traffic from protected path to backup

The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair.

The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of protected LSPs that have similar backup constraints.

With both methods, backup LSPs can either be established to provide link or node protection


One-to-one backup: Each router along the LSP path establishes a detour LSP that is the best path to the destination node, that avoids the node and/or link at the point of failure. For each LSP which is backed up, a separate backup LSP is established.

In the above Example, the protected LSP runs from R1 to R5. R1 can provide user traffic protection by creating a partial backup LSP which is the best path to R5 that avoids the link between R1 & R2 (in case of link protection) and the node R2 (in case of node protection). The partial one-to-one backup LSP [R2->R7->R8->R9->R5] is referred as a detour.

To fully protect an LSP that traverses N nodes, there could be as many as (N - 1) detours. The paths for the detours necessary to fully protect the LSP in above example are shown.

Note that assuming all links have equal costs, the detour LSP for R1 and R2 as PLR with either link or node protection could be via path [R6-R7-R8-R4-R5] and [R7-R8-R4-R5] respectively. As well, the detour LSP for R3 as PLR with link protection could be via path [R8-R4-R5].


One-to-one Backup Method – Path Setup

R1R2

R3

R4

R5

R6R7 R8

R9


R1’s backup: R1->R6->R7->R8->R9->R5

R2’s backup: R2->R7->R8->R9->R5

R3’s backup: R3->R8->R9->R5

R4’s backup: R4->R9->R5

PLR

PLRPLR

PLR

(1) (2)(3)

(4)

(1)

(2)

(3)

(4)

Detour Tunnel


To minimize the number of LSPs in the network, it is desirable to merge a detour back to its protected LSP when feasible. When a detour LSP intersects its protected LSP at an LSR with the same outgoing interface, it will be merged. When a failure occurs along the protected LSP, the PLR ( Point of Local Repair) redirects traffic onto the local detour. For instance, if the link [R2->R3] fails in the above example, R2 will switch traffic received from R1 onto the protected LSP along link [R2->R7] using the label received when R2 created the detour. At no point does the depth of the label stack increase as a result of taking the detour. While R2 is using its detour, traffic will take the path [R1->R2->R7->R8->R9->R5].

Note: Detour path does not require any additional CLI configuration


One-to-one Backup Method – Link Protection

R1R2

R3

R4

R5

R6

R7 R8

R9

PLR

If the link [R2->R3] fails:R2 switch traffic received from R1 LSP along link [R2->R7] using the label received when R2 created the detour. The detour is calculated based on the shortest IGP path from the PLR (R2) to the router that is the termination of the protected LSP (R5), while avoiding the failed link (R2-R3)

At no point does the depth of the label stack increase as a result of taking the detour. While R2 is using its detour, traffic will take the path [R1->R2->R7->R8->R9->R5]

X

Failure occurred along the protected LSP, the PLR redirects traffic into the local detour.

MP


The difference with node protection is that the PLR attempts to compute a detour LSP that avoids the next hop node in the protected LSP path.


One-to-one Backup Method – Node Protection

R1R2 R3

R4

R5

R6

R7 R8

R9

PLR

If the router R3 fails:R2 switch traffic received from R1 LSP along link [R2->R7] using the label received when R2 created the detour. The detour is calculated based on the shortest IGP path from the PLR (R2) to the router that is the termination of the protected LSP (R5), while avoiding the failed router (R3)At no point does the depth of the label stack increase as a result of taking the detour. While R2 is using its detour, traffic will take the path [R1->R2->R7->R8->R9->R5]

Failure occurred along the protected LSP, the PLR redirects traffic into the local detour.

MPX


Labels along the Protected LSP path are advertised along the control plane according to common label propagation rules. Similarly labels are propagated along the backup path in the same manner. Therefore, the backup path is signaled, and established and prepared for the eventuality of a failed link. The only difference between the Protected LSP and the backup LSP is that the Protected LSP is being used in the data plane while the backup LSP is not.

If the link R2-R3 fails or if the node R3 fails, the PLR (R2) will swap incoming packets that have label 21 with label 172 and send it out the interface to R7. The MP (R5) will recognize that the packets arriving on its interface to R9 with label 159 must be POPed since it is the termination point of the protected LSP.


One-to-One Backup Method – Label Exchange

R1R2

R3

R4

R5

R7 R8

5443

3221

172187

198

Control Plane(label propagation)



21Innerlabel 32Inner

label 43Innerlabel 54Inner

label

R9

159


During a link failure, the PLR needs to signal the data plane that a failure has occurred and must swap the new backup tunnel labels for the older Protected LSP labels. In the case of One-to-One backup, the PLR makes use of the label leading to the downstream transit router, in this case R7. The depth of the label stack is unchanged. The label emerging at the MP is different during the backup than it was before the link failure.


One-to-One Backup Method – Link/Node Failure




21Innerlabel

172Innerlabel

187Innerlabel

198Innerlabel

R1R2

R3

R4

R5

R8

544321

172187

198

R9

159

159Innerlabel

R7

X


This slide demonstrates that in the case of a one-to-one backup, two protected LSPs, one originating at R1 and one originating at R10, will each have their own set of detour LSPs to protect them. In the example, only the detour LSPs for R2 as PLR are shown, but keep in mind that R3 and R4 will also have computed their detour LSPs for each of the two protected LSPs.


One-to-one Backup Method – Multiple LSPs

R1R2

R3

R4

R5

R6R7 R8

R9

Protected LSP 1: R1->R2->R3->R4->R5

R2’s backup for Protected LSP 1R2->R7->R8->R9->R5

PLR

(1)

(1)

R10

R2’s backup for Protected LSP 2R2->R7->R8->R9->R5

(2)

(2)

PLR


MP

MP



One-to-one Backup Method – Multiple LSPs Link Failure Example

R1R2

R3

R4

R5

R6R7 R8

R9

PLR

(1)

R10

(2)

PLRX

If the link [R2->R3] fails:R2 switch traffic received from R1 LSP and from R10 LSP along link [R2->R7] using the label received when R2 created each of the detours respectively. R7 will use the shortest IGP path to route the detour to the final destination, in this example R5 At no point does the depth of the label stack increase as a result of taking the detour.


Facility backup: Each router along the LSP path establishes a bypass LSP (tunnel) that is the best path to the next-hop or next-next-hop node, that avoids the link or next-hop node at the point of failure. LSPs that traverse the same link or node for which a bypass tunnel has been created to avoid, can all be protected by this bypass tunnel.

In the above example, the protected LSP runs from R1 to R5. R2 can provide user traffic protection against either the failure of the next-hop node R3 (in the case of node protection) or the next-hop link R2-R3 (in the case of link protection) by creating a partial backup LSP which is determined as the best path to R3 (in case of link protection) or to R4 (in case of node protection). The partial facilities backup LSP [R2->R7->R8->R4>R5] is referred as a bypass tunnel.

To fully protect an LSP that traverses N nodes, there could be as many as (N - 1) bypass tunnels.


Facility Backup Method – Path Setup

R1R2

R3

R4

R5

R6R7 R8

R9


R1’s backup: R1->R6->R7->R8->R3->R4->R5

R2’s backup: R2->R7->R8->R4->R5


R4’s backup: R4->R9->R5

PLR

PLR

PLR PLR

(1) (2)

(3)

(4)

(1)

(2)

(3)

(4)

Bypass Tunnel for Node Protection


Facility backup with Link ProtectionThe facility backup technique takes advantage of the MPLS label stack. Instead of creating a separate LSP for every backed-up LSP, a single LSP is created which serves to backup up a set of LSPs. We call such an LSP tunnel a bypass tunnel.

The bypass tunnel must intersect the path of the original LSP(s) somewhere downstream of the PLR. Naturally, this constrains the set of LSPs being backed-up via that bypass tunnel to those that pass through some commondownstream node. All LSPs which pass through the point of local repair and through this common node which do not also use the facilities involved in the bypass tunnel are candidates for this set of LSPs. In the above example, R2 has built a bypass tunnel which protects against the failure of link [R2->R3]. The doubled lines represent this tunnel. The scalability improvement this technique provides is that the same bypass tunnel can also be used to protect LSPs which traverse the link R2-R3, regardless of their source and destination endpoints.

As with the one-to-one technique, to fully protect an LSP that traverses N nodes, there could be as many as (N-1) bypass tunnels. However, each of those bypass tunnels could protect a set of LSPs.


Facility Backup Method – Link Protection

R1R2

R3

R4

R5

R6R7 R8

R9


R10

Bypass tunnelR2->R7->R8->R4

PLR


MP


Facility backup with Link ProtectionIf link [R2->R3] fails in above example, R2 (the PLR) will switch traffic received from R1 on the protected LSP onto link [R2->R7]; the label will be switched for one which will be understood by R3 to indicate the protected LSP and then the bypass tunnel's label will be pushed onto the label-stack of the redirected packets.

If penultimate-hop-popping is used, then the merge point in above example, R3, will receive the redirected packet with a label indicating the protected LSP that the packet is to follow.

If penultimate-hop-popping is not used, then R3 will pop the bypass tunnel's label and examine the label underneath to determine the protected LSP that the packet is to follow. When R2 is using the bypass tunnel for protected LSP 1, the traffic takes the path [R1->R2->R7->R8->R3->R4->R5]; the bypass tunnel is the connection between R2 and R3.


Facility Backup Method – Link Protection (cont’d)

If link [R2->R3] fails; traffic takes the path

• For Protected LSP 1: [R1->R2->R7->R8->R3->R4->R5]• For Protected LSP 2: [R10->R2->R7->R8->R3->R4->R5]

the label will be switched for one which will be understood by R3 to indicate the protected LSP and then the bypass tunnel's label will be pushed onto the label-stack of the redirected packets

R1R2

R3

R4

R5

R6

R7 R8

R9

R10

PLR MPXLSP1

LSP2


The data plane functions the same way in the stable LSP scenario as it did during the One-to-One backup method. The control plane however works slightly differently with the MP advertising a POP label to its backup neighbor. As will be seen in the next few slides, the Facilities backup label exchange differs from the One-to-One backup method significantly.


Facility Backup – Link Protection Label Exchange

R1R2

R3

R4

R5

R7 R8

5443

3221

172

187

138




21 32 43 54Innerlabel

Innerlabel

Innerlabel

Innerlabel


With the Facilities backup method, the PLR pushes the label received form the neighbor who is now no longer available due to the failed link. In the diagram above, R3 was propagating label 32 to R2 before the link failed. This label 32 is now pushed onto the label stack of the packet in addition to the label obtained from the upstream backup neighbor, in this case R7. The result is a deeper label stack. The MP, R3 in this case, removes the topmost label and examines the next label (now the topmost label). The next label is the same label it would have received directly from R2 had the link not failed. The only difference is that it received the label from a different interface. Otherwise the packet looks as if it arrived from R2.

This method allows the “tunneling” of multiple LSPs through the bypass and improves the scalability of the Protected paths.


Facility Backup – Link Failure

R1

R2R3

R4

R5

R7 R8

544321

172

187

138




X

21Innerlabel

54Innerlabel

172Innerlabel 32

187Innerlabel 32

43Innerlabel

MP receives same label from backup link as it would from Primary LSPMP receives same label from backup link as it would from Primary LSP

138Innerlabel 32

32Innerlabel

32


Node Protection works similarly to link protection but there are a few more obstacles that must be addressed since the MP is not the router whose link has failed.

In order for node protection to function correctly, the backup tunnel must be able to span multiple hops along the Protected path, and signal appropriate knowledge throughout the new LSP. Therefore there are 2 values that must be known in order to establish the node protected backup path. First, the PLR must know the address of the MP in order to establish the backup path. This address is obtained from the RRO. The RRO collects information about the path traversed and keeps a complete record of all hops along the path of the LSP. Second, the PLR must know the label propagated by MP upstream to the protected node. This is also learned from the RRO. However, the RRO typically does not store labels. A new flag, “label recording desired”, has been introduced to ensure that the RRO starts collecting label information for this purpose.


Facility Backup - Node Protection

R1R2

R3

R4

R5

R7 R8



PLRMP

Node protection requires that:

1. The PLR knows the address of the MP — obtained from RRO

2. The PLR knows the Label propagated by MP upstream to protected node — obtained from the RRO with the use of the “label recording desired” flag

Node protection requires that:

1. The PLR knows the address of the MP — obtained from RRO

2. The PLR knows the Label propagated by MP upstream to protected node — obtained from the RRO with the use of the “label recording desired” flag


The RRO is populated on the upstream RSVP Path Message until it reaches the LSP tail end. The tail end then replies with an RSVP Resv Message. Since the “label recording desired” flag was set in the Session Attribute Object, the labels are stored in the RRO during the Resv Message. The net result is that the LSP Head end now knows that in order to protect node R3, the address for node R4 (the MP) is “R4” and the label that this MP expects is 43.


Facility Backup - Node Protection RSVP Signaling

R1R2

R3

R4

R5

5443

3221

Path MsgRRO:R1

Path MsgRRO:R1R2

Path MsgRRO:R1R2R3

Path MsgRRO:R1R2R3R4

Resv MsgRRO:R1R2R3R4R5 (54)

Path MsgRRO:R1R2R3R4R5

Resv MsgRRO:R1R2R3R4 (43)R5 (54)

Resv MsgRRO:R1R2R3 (32)R4 (43)R5 (54)

Resv MsgRRO:R1R2 (21)R3 (32)R4 (43)R5 (54)

Resv MsgRRO:R1 (--)R2 (21)R3 (32)R4 (43)R5 (54)

The LSP Head End has now learned the address of R4 (the MP) and the label that the MP expects, in this example 43

The LSP Head End has now learned the address of R4 (the MP) and the label that the MP expects, in this example 43

MPPLR


The label exchange mechanism to establish the bypass tunnel when node protection is used, proceeds the same way as with link protection, except that the bypass tunnel’s termination point is the next-next-hop node.


Facility Backup – Node Protection Label Exchange

R1R2

R3

R4

R5

R7 R8

5443

3221

172

187

148




21Innerlabel 32Inner

label 43Innerlabel 54Inner

label


With the Facilities backup method in node protection mode, the PLR pushes the label which the next-next-hop node would expect to receive for the protected LSP. In the diagram above, R4 was propagating label 43 to R3 before the node failed. The PLR, R2, pushes this label 43 onto the label stack of the packet in addition to the label obtained from the upstream backup neighbor, in this case R7. The result is a deeper label stack. The MP, R4 in this case, removes the topmost label and examines the next label (now the topmost label). The next label is the same label it would have received directly from R3 had the node R3 not failed. The only difference is that it received the label from a different interface. Otherwise the packet looks as if it arrived from R3. The net result is that the LSP Head end now knows that in order to protect node R3, the address for node R4 (the MP) is “R4” and the label that this MP expects is 43.


Facility Backup - Node Failure

R1R2

R4

R5

R7 R8

5421

172

187

148




43

21Innerlabel

54Innerlabel

172Innerlabel 43

187Innerlabel 43

148Innerlabel 43

43Innerlabel

R3

X


Local RevertiveThe head-end LER will not attempt to re-optimize the LSP when it knows the PLR has activated local protection. Re-optimization will be attempted at the next expiry of the system MPLS re-signal timer, i.e., within 30 minutes, if it is enabled.

If a Secondary standby path is configured and is up, the 7x50 head-end LER will switch the LSP from the detour/bypass onto the Secondary path. If the Secondary path is not in standby mode, the LSP remains on the detour/bypass tunnel and the Secondary path is not signaled and used. Only if the detour/bypass tunnel fails does the LSP switch to the Secondary path.

When the failed resource (node or link) is restored, the Point of Local Repair (PLR) resignals the LSP over the restored resource. At that point in time, the PLR switches the protected LSP from the detour/bypass to the Primary path over the restored resource. If the LSP was on a Secondary path, the headend will switch the LSP to the Primary path over the restored resource as soon as it is notified by the PLR of the successful local reverting.


Local Revertive Behavior with FRR

Local revertive mode

• Head-end LER does not try to re-optimize LSP once it learns that PLR is using the detour/bypass tunnel (default SR behaviour)

• Head-end LER only tries to re-optimize the LSP when the resignal-timer expires (if it is enabled), otherwise LSP is left on the detour/bypass tunnel until the failure is restored

• Secondary path is only used if configured as standby or there is a failure in the detour path.

• When failure is restored, PLR switches LSP back to Primary path over restored resource.

• Make-before-break


Global RevertiveThe headend LER will attempt a re-optimization of the LSP shortly after it knows the PLR has activated local protection. If CSPF finds a path, the headend LER will switch the LSP to the new optimized path. If CSPF fails to find a path, the LSP stays on the detour/bypass or standby path until the next re-optimization attempt upon the expiry of the LSP retry–timer, i.e., in 30 seconds by default. If while waiting for the next re-optimization the failed resource is restored, the PLR will revert to the original path over the restored resource. This provides backward compatibility with the local revertive mode behaviour of the PLR and Merge Point of releases of the 7x50 that do not support global revertive mode. However, the 7x50 headend LER will continue global revertive re-optimization attempts even after a successful local reverting. It does so until a new path is found or the LSP is torn down.

When the Primary path is fully strict, the re-optimization attempts will fail until the failed resource is restored. Thus in this case, the end result is similar to local revertive mode, whereby the LSP remains on the detour/bypass tunnel until the failed resource is restored, and the PLR reverts the LSP to the original path.

Note: Global revertive mode is supported as of 7x50 4.0R5.


Global Revertive Behavior with FRR

Global revertive mode

• Head-end LER tries to re-optimize LSP once it learns that PLR is using the detour/bypass tunnel

• If new path is found, head-end LER switches LSP to it, otherwise LSP remains on detour/bypass tunnel

• Head-end LER re-tries to find new path each time the retry-timer expires (every 30 seconds by default)

• If failure is restored before new path is found, LSP reverts to original path

• Make-before-break


Once the global revert is triggered for this LSP, the headend 7x50 follows the following steps to attempt to re-optimize the LSP path:

1.It starts a delay timer to schedule a new computation of the Primary path. This delay is to let the routing protocol to converge. The delay timer value is internally set to the same as the user entered value for the LSP retry-timer. The value of the retry-timer is user configurable on a LSP basis. The default value is 30 seconds.

2.Upon expiry of the delay timer, the 7x50 schedules a CSPF computation.

3.The 7x50 will check the result of the CSPF computation every second after it is scheduled. If the CSPF computation is successful, the 7x50 attempts to establish the LSP in a Make-Before-Break. If the CSPF computation is a failure, another CSPF is scheduled and steps (a) though (c) are re-executed.

4.On a successful Make-Before-Break, the original LSP is torn down. Protection LSP’s are established based on the new path of the LSP. Note that if CSPF finds a new path that is hop-by-hop identical to the original primary path that has now been locally restored, the 7x50 headend will still perform a make-before-break into this path with a higher LSP ID value.

Note that this process will continue to run until it is successful or the LSP is torn down.


Global Revertive Triggers

The headend 7x50 triggers global revert for an LSP when any of the following events occurs:• A local link failure or a control plane failure (hello timeout etc.). • Receipt of a Path Error message with a notification of a

protection becoming active downstream • Receipt of a RESV with a ‘Local-Protection-In-Use’ flag set. This

trigger is used when a protection becomes active downstream but global revert for the LSP has not yet been triggered. This could be due for example to a loss of the Path Error message.


The PLR notifies the Head end, in this case R1, that a failure has occurred, and switches the LSP to the detour/bypass tunnel.

Upon receiving notification that the backup LSP has been activated, the LSP Head-end LER switches the LSP to the Secondary standby path if one has been configured and is available. Otherwise, the LSP remains on the detour/bypass tunnel.

If the resignal-timer is enabled, after it expires, the Head-end LER tries to re-optimize the LSP onto another path. If a new path is found, (which may or may not make use of the path currently being used by the backup LSP) the LSP is set up in a “make-before-break” fashion so that data can share the older and now newer LSPs. In order to satisfy this characteristic, Protected LSPs must be setup in a Shared Explicit fashion allowing the new LSP to share resources with the old LSP. Once the new LSP is established, the existing LSP and the backup tunnel are torn down and the new LSP is used as the main LSP. New detour/bypass tunnels are computed for the new LSP.

If a new path is not found, the LSP remains on the detour/bypass tunnel until the next expiry of the resignal-timer, or until the failed resource is restored.

If the failed resource is restored before the resignal-timer expires, the PLR switches the LSP back onto the original path.

If the resignal-timer is not enabled, the LSP remains on the detour/bypass tunnel until the failed resource is restored.


LSP Switch-over Behavior with Local Revertive

R1

R2R3

R4

R5

R8

RSVP Path Error Message1) Failure “Notify” error code2) “Tunnel Locally Repaired” subcodePLR switches LSP to detour/bypass tunnel

PLR

LSP Head

LSP Head-end mustcontinue data flow

(1)

(2)

LSP Head-end switches to SecondaryStandby Path if available(3)

If resignal-timer is enabled, Head-end re-optimizes Primary path after timer expiresIf failed resource restored before resignal-timer expires (or when resignal-timer disabled), PLR switches LSP back to original path

(4)

R7


The PLR notifies the Head end, in this case R1, that a failure has occurred. The LSP Head end must be notified about the failure since the LSP Head end must try to find an alternate path around the failed link. Furthermore, when the LSP Head end finally does learn the failed link through the IGP, it must not tear down the LSP as it normally would.

Upon receiving notification that the backup LSP has been activated, the LSP Head end LER re-computes a new LSP, which may or may not make use of the path currently being used by the backup LSP. The new LSP is set up in a “make-before-break” fashion so that data can share the older and now newer LSPs. In order to satisfy this characteristic, Protected LSPs must be setup in a Shared Explicit fashion allowing the new LSP to share resources with the old LSP. If a Secondary standby path is configured and available, the Head-end LER switches the LSP to the Secondary path, while it tries to re-optimize the Primary path.

Once the new LSP is completed, the existing LSP and the backup tunnel are torn down and the new LSP is used as the main LSP. New detour/bypass tunnels are computed for the new LSP. If the LSP was on the Secondary path, the Head-end LER switches it to the new LSP.

If the Head-end LER cannot find a new path the LSP remains on the detour/bypass tunnel or on the Secondary path until the next path computation occurs when the retry-timer expires.


LSP Switch-over Behavior with Global Revertive

R1

R2R3

R4

R5

R8

RSVP Path Error Message1) Failure “Notify” error code2) “Tunnel Locally Repaired” subcode

PLR

LSP Head

LSP Head mustcontinue data flow

(1)

(2)

LSP Head re-computesa new LSP(3)

Bypass is torn down whennew LSP is signaled and activated(4)

R7


The retry-timer specifies the frequency with which the iLER will re-attempt to establish an LSP, when it has previously failed to do so.

retry-timerSyntax retry-timer secondsContext config>router>mpls>lspDescription This command configures the time, in seconds, for LSP re-establishment attempts after it has failed.Default 30Parameters seconds — The amount of time, in seconds, between attempts to re-establish the LSP after it has failed. Allowed values are integers in the range of 1 to 600.Values 1 - 600

retry-limitSyntax retry-limit numberContext config>router>mpls>lspDescription This optional command specifies the number of attempts software should make to re-establish the LSP after it has failed LSP. After each successful attempt, the counter is reset to zero. When the specified number is reached, no more attempts are made and the LSP path is put into the shutdown state. Use the config router mpls lsp lsp-name no shutdown command to bring up the path after the retrylimit is exceeded.Default 0 (no limit, retries forever)Parameters number — The number of times software will attempt to re-establish the LSP after it has failed. Allowed values are integers in the range of 0 to 10000 where 0 indicates to retry forever.Values 0 - 10000


Stop

Retry Timer & Retry Limit


Syntax: retry-timer seconds

Context: config>router>mpls>lspSyntax: retry-limit number

Wait “retry-timer”

seconds

Try to re-establish LSP

LSP has failedHas retry limit been exceeded

?

Succeeded?

Put LSP into shutdown

state

No

YesYes

No


By default, once every 30 seconds (the refresh-time), a Path and Resv refresh message will be sent. If the Path or Resv message fails to reach its intended destination and the hold down timer (keep-multiplier) expires (by default 3 missed updates, or 90 seconds), then the head-end node will attempt to re-signal a secondary LSP if one is defined. If no secondary LSP is defined then the head-end node simply terminates its Primary LSP session and drops the RSVP connection sending a Path tear down message along the path.

This animated slide shows the Resv message being somehow dropped and therefore never reaching the tunnel head. After a hold down timer (90 seconds), the router will tear down the primary path and use a secondary if one is available. If no secondary path is available, then the primary path is torn down and then attempted to be re-signaled. If that is not possible then the path remains down.

refresh-timeSyntax refresh-time secondsContext config>router>rsvpDescription The refresh-time controls the interval, in seconds, between the successive Path and Resv refresh messages. RSVP declares the session down after it misses keep-multiplier number consecutive refresh messages.Default 30 secondsParameters seconds — The refresh time in seconds.Values 1 – 65535

keep-multiplierSyntax keep-multiplier numberContext config>router>rsvpDescription The keep-multiplier number is an integer used by RSVP to declare that a reservation is down or the neighbor is down.Default 3Parameters number — The keep-multiplier value.Values 1 - 255


Refresh Time & Keep Multiplier

10.10.10.1 30.30.30.1

RESV Message(Refresh – 30 sec)

RESV Message(Refresh – 30 sec))

If periodic refresh Path or Resvmessage is not received, Primary path is torn down

Secondary path becomes active (if one exists)

Keep-multiplier (3 updates)

Context: config>router>rsvpSyntax: refresh-time seconds

Context: config>router>rsvpSyntax: keep-multiplier number


This slide shows the effect of the resignal timer. The resignal timer attempts to optimize a Loose path LSP every “n”number of minutes where 30<n<10080. The diagram above shows the steps taken when attempting to signal a new LSP.

(1) Lets assume that an LSP exists which makes use of the bottom (“longer”) path. It could be that the top (“shorter”) path was either not available at the time the existing LSP was originally signaled, or that it physically existed but was constrained in some manner which prevented it from being selected as the preferred path.

(2) Assuming the resignal timer has been configured, once the timer expires, the LSP head will try to find an optimum path to the LSP destination.

(3) Once a path is discovered, the metric of that path will be compared to the metric of the existing path. If that newly found path has a “better” metric than the existing path, then the router attempts to signal the new LSP in a “make-before-break” fashion so as to minimize the impact of a switch to the new LSP.

(4) Once the new LSP has been signaled and is enabled, the head end signals the switch from the existing LSP to the new LSP

(5) The head end router tears down the existing LSP session.

resignal-timerSyntax resignal-timer minutes

Context config>router>mpls

Description This command specifies the value for the LSP resignal timer. The resignal timer is the time, in minutes, the software waits before attempting to resignal the LSPs. When the resignal timer expires, if the new recorded hop list (RRO) for an LSP has a better metric than the current recorded hop list, an attempt is made to resignal that LSP using the make-before-break mechanism. If the attempt to resignal an LSP fails, the LSP will continue to use the existing path and a resignal will be attempted the next time the timer expires.

Default no resignal-timerParameters minutes — The time the software waits before attempting to resignal the LSPs.

Values 30— 10080 (one week)


Resignal Timer (Optimization timer)


Syntax: resignal-timer minutes

Attempt to optimize a Loose path LSPAttempt to optimize a Loose path LSP

Existing LSP

Resignal TimerExpires

New Shorter Path LSP is found

(3)

(1)

(2)

Build new LSP(make-before-break)

(4)

Tear down LSPOnce new LSP is enabled

(5)


RSVP Implementation

Section 5 - Implementing Fast Reroute



FRR Configuration - Section Outline

Enable FRR with One-to-One Backup Method

Enable FRR with Facility Backup Method

Verify Behavior of LSPs with FRR enabled


This command creates a pre-computed detour LSP from each node in the path of the LSP. In case of failure of a link or LSP between two nodes, traffic is immediately rerouted on the pre-computed detour LSP, thus avoiding packet-loss.

When fast-reroute is enabled, each node along the path of the LSP tries to establish a detour LSP as follows:

Each upstream node sets up a detour LSP that avoids only the immediate downstream node, and merges back on to the actual path of the LSP as soon as possible. If it is not possible to set up a detour LSP that avoids the immediate downstream node, a detour can be set up to the downstream node on a different interface.

The detour LSP may take one or more hops before merging back on to the main LSP path.

When the upstream node detects a downstream link or node failure, the ingress router switches traffic to a standby path if one was set up for the LSP.

Fast reroute is available only for the primary path. No configuration is required on the transit hops of the LSP. The ingress SR will signal all intermediate SRs using RSVP to set up their detours. CSPF must be enabled for fast-reroute to work.

For fast detour and non-path-sharing secondary paths, CSPF is enabled automatically and hence the explicit command to enable CSPF will not be required at FCS.

This command configures one of the two methods to be used for the LSP. Executing this command will enable the config>router>mpls>lsp>frr context where there are additional commands to configure various parameters for use with fast-reroute.


Fast-ReRoute (FRR) CLI Command

Context config>router>mpls>lsp

Syntax fast-reroute frr-method

Command gets implemented on Tunnel head end – no commands necessary on transit routers, or Tunnel termination router

By default this command requests that each node will create a Node protect detour LSP, if Node protect is not feasible then the router will attempt Link protect

FRR is available only for the primary path

CSPF must be pre-enabled


fast-rerouteSyntax fast-reroute frr-method

Context config>router>mpls>lspDescription This command creates a pre-computed detour LSP from each node in the path of the LSP. In case of failure of a link or LSP between two nodes, traffic is immediately rerouted on the pre-computed detour LSP, thus avoiding packet-loss.

When fast-reroute is specified, the default fast-reroute method is one-to-one.

one-to-one — In the one-to-one technique, a label switched path is established which intersects the original LSP somewhere downstream of the point of link or node failure. For each LSP which is backed up, a separate backup LSP is established.

facility — This option, sometimes called many-to-one, takes advantage of the MPLS label stack. Instead of creating aseparate LSP for every backed-up LSP, a single LSP is created which serves to backup up a set of LSPs. This LSP tunnel is called a bypass tunnel.

The bypass tunnel must intersect the path of the original LSP(s) somewhere downstream of the point of local repair (PLR). Naturally, this constrains the set of LSPs being backed-up via that bypass tunnel to those that pass through a common downstream node. All LSPs which pass through the PLR and through this common node which do not also use the facilities involved in the bypass tunnel are candidates for this set of LSPs.


Implementing FRR Protection – One to One Backup

Primary LSP_99_103

PE3:# configure router mplsPE3:>config>router>mpls# lsp LSP_99_103PE3:>config>router>mpls>lsp# fast-reroute one-to-onePE3:>config>router>mpls>lsp>frr# exit allPE3:#

10.10.10.103

10.10.10.99

1/2/110.48.1.1

10.48.1.210.2.3.2

1/2/3

1/2/2

10.1.3.1

PE3 P3

10.10.10.100

10.10.10.101

10.10.10.10210.1.2.2

10.32.1.1

10.32.1.2


The “show router mpls lsp path detail” command executed on the tunnel head end, provides detailed information on the LSP path available. This command can be used to determine the path name used, the path type (Primary/Secondary) and if the LSP is administratively and operationally up. The command also provides the explicit hops defined and the actual hops used.

Of great importance is the “@” and “n” symbols next to the Actual Hops list. These symbols provide information on the devices along the path that have identified themselves as being available for detour by using the symbol “@”. The symbol “n” also provides information on which device has identified itself as a candidate for node protection. In the example above, nodes 10.10.10.100 and 10.10.10.101 have identified themselves as devices along the specified path able to provide a detour.

Node 10.10.10.100, i.e. P3, will provide node protection for node P1. Node 10.10.10.101, i.e. P1, will provide link protection for the link between P1 and P2.


Confirming the Detour for the LSP path

PE3# show router mpls lsp path detail=====================================MPLS LSP Path (Detail)=====================================Legend :


=====================================-------------------------------------------------------------------------------------LSP LSP_99_103 Path via-R43--------------------------------------------------------------------------------------LSP Name : LSP_99_103 Path LSP ID : 3From : 10.10.10.99 To : 10.10.10.103Adm State : Up Oper State : UpPath Name : via-R43 Path Type : PrimaryPath Admin : Up Path Oper : UpOutInterface : 1/2/1 Out Label : 131067Path Up Time : 0d 01:17:13 Path Dn Time : 0d 00:00:00Retry Limit : 0 Retry Timer : 30 secRetryAttempt : 0 Next Retry In : 0 secBandwidth : No Reservation Oper Bandwidth : 0 Mbps

Hop Limit : 255Record Route : Record Record Label : RecordOper MTU : 9198 Negotiated MTU : 9198Adaptive : Enabled MBB State : SuccessInclude Grps : Exclude Grps :None NonePath Trans : 4 CSPF Queries : 265Failure Code : noError Failure Node : n/aExplicitHops :

10.48.1.1 -> 10.1.3.1 -> 10.1.2.2 -> 10.32.1.2Actual Hops :

10.48.1.2(10.10.10.90)-> 10.48.1.1(10.10.10.100) @ n Record Label : 131067-> 10.1.3.1(10.10.10.101) @ Record Label : 131066-> 10.1.2.2(10.10.10.102) Record Label : 131066-> 10.32.1.2(10.10.10.103) Record Label : 131071

ComputedHops:10.48.1.2 -> 10.48.1.1 -> 10.1.3.1 -> 10.1.2.2

-> 10.32.1.2=====================================

10.10.10.10310.10.10.99

1/2/110.48.1.1

1/2/110.48.1.2

10.2.3.21/2/3

1/2/2

10.1.3.1

PE3

P310.10.10.100

10.10.10.101

10.10.10.10210.1.2.2

10.32.1.1

10.32.1.2P1

P2


The command “show router mpls status” can be used to determine if the node is part of a detour LSP. If the node originates a Detour LSP, then that node is a Point of Local Repair (PLR). If the node Terminates a detour LSP, then that node is a Merge Point (MP). However, which is also an MP may receive multiple Path messages from different interfaces with identical Session identifiers. In this case, Path state merging is performed.

For all the Path messages that share the same outgoing interface and next-hop LSR, the MP is known as a Detour Merge Point (DMP). In the case of one-to-one backup, this is an LSR where multiple detours converge. Only one detour is signaled beyond that LSR.

In the example above There is on detour from P1 to P3 and another detour from P3 to P2 (see next page). Since these 2 detours are part of the same LSP detour set, then P3 merges the two detours making P3 a DMP instead of an MP. In this case P2 is the MP of the merged detour path.


Confirming PLR/MP – Link Protection

P3

PLR

DMP

P1:# show router mpls status==================================MPLS Status==================================Admin Status : Up Oper Status : UpFR Object : Enabled Resignal Timer : Disabled

LSP Counts Originate Transit Terminate-----------------------------------------------------------------------------Static LSPs 0 0 0Dynamic LSPs 0 1 0Detour LSPs 1 0 0==================================P1:#

P1



X

Detour

Data Flow

P2

MP


The command “show router mpls status” can be used to determine if the node is part of a detour LSP. If the node originates a Detour LSP, then that node is a Point of Local Repair (PLR). If the node Terminates a detour LSP, then that node is a Merge Point (MP).


Confirming PLR/MP – Node Protection

P3

DMP

MP



P1



XDetour

Data Flow

P2


The “show router rsvp session detour detail” command displays a separate section for each role this device plays both in the primary path as well as in the detour path. This diagram shows the first part of this command. This router, P3, is a transit device in the LSP from 10.10.10.99 to 10.10.10.103. The data path is ingress from port 1/2/1 and egress out port 1/2/2. This is the data flow of the primary path.


Confirming Detour LSP – Slide 1 (Primary Path)

P3:# show router rsvp session detour detail==========================================------------------------------------------------------------------------------------------------LSP : LSP_99_103::via-R43------------------------------------------------------------------------------------------------From : 10.10.10.99 To : 10.10.10.103Tunnel ID : 3 LSP ID : 3Style : SE State : UpSession Type : TransitIn Interface : 1/2/1 Out Interface : 1/2/2In Label : 131067 Out Label : 131065Previous Hop : 10.48.1.2 Next Hop : 10.1.3.1

Path Recd : 0 Path Sent : 34Resv Recd : 38 Resv Sent : 38===========================================

10.10.10.103

10.10.10.99

1/2/110.48.1.1

10.48.1.210.2.3.2

1/2/3

1/2/2

10.1.3.1

PE3 P3

10.10.10.101

10.10.10.10210.1.2.2

10.32.1.1

10.32.1.2

Commandcontinues……


This second part of the “show router rsvp session detour detail” command shows that P3 is acting as a PLR (originator) for the detour path. Traffic ingressing port 1/2/1 is forwarded to the output port 1/2/3 thereby avoiding the failed device, in this example P1. In this example P3 is the PLR, while P2 is the MP. Node protection is activated by default on all nodes within the path that can provide that functionality.


Confirming Detour LSP – Slide 2 (Detour Path)

-------------------------------------------------------------------------------------------------------LSP : LSP_99_103:via-R43_detour--------------------------------------------------------------------------------------------------------From : 10.10.10.99 To : 10.10.10.103Tunnel ID : 3 LSP ID : 3Style : SE State : UpSession Type : Originate (Detour)In Interface : 1/2/1 Out Interface : 1/2/3In Label : 131067 Out Labe l : 131065Previous Hop : 10.48.1.2 Next Hop : 10.2.3.2

Path Recd : 0 Path Sent : 95Resv Recd : 106 Resv Sent : 105--------------------------------------------------------------------------------------------------------

10.10.10.103

10.10.10.99

1/2/110.48.1.1

10.48.1.210.2.3.2

1/2/3

1/2/2

10.1.3.1

PE3 P3

10.1.2.2

10.32.1.1

10.32.1.2

CommandContinues…..

Detour Data Flow

Node Protection

XP1

P2

Same as nextpage


This third part of the “show router rsvp session detour detail” command displays the link protection for the path between P1 and P2. In this example data is forwarded from input interface 1/2/2 and forwarded to interface 1/2/3 towards the destination PE2 which is the LSP tail. As can be seen by this example, this part of the output shows that P3 is acting as a Session Type of “Terminate” for the detour, which means that in this case P3 is the MP for the detour while P1 is the PLR.


Confirming Detour LSP – Slide 3 (Detour Path)

-------------------------------------------------------------------------------------------------------LSP : LSP_99_103:via-R43_detour--------------------------------------------------------------------------------------------------------From : 10.10.10.99 To : 10.10.10.103Tunnel ID : 3 LSP ID : 3Style : SE State : UpSession Type : Terminate (Detour)In Interface : 1/2/2 Out Interface : 1/2/3In Label : 131067 Out Labe l : 131065Previous Hop : 10.1.3.1 Next Hop : 10.2.3.2

Path Recd : 0 Path Sent : 95Resv Recd : 106 Resv Sent : 105--------------------------------------------------------------------------------------------------------

10.10.10.10310.10.10.99

1/2/110.48.1.1

10.48.1.210.2.3.2

1/2/3

PE3 P3

10.1.2.2

10.32.1.1

10.32.1.2

Detour Data Flow

Link Protection

X1/2/2

10.1.3.1

P1P2


If fast reroute is enabled on an LSP and the facility method is selected, instead of creating a separate LSP for every LSP that is to be backed up, a single LSP is created which serves as a backup for a set of LSPs. Such an LSP tunnel is called a 'bypass tunnel'.


Implementing FRR Protection – Facility Backup

10.10.10.103

10.10.10.10210.10.10.101

10.10.10.10010.10.10.99

Primary LSP-to-PE2

A:# configure router mplsA:>config>router>mpls# lsp LSP-to-PE2A:>config>router>mpls>lsp# fast-reroute facilityA:>config>router>mpls>lsp# exitA:>config>router>mpls# lsp LSP-to-P2A:>config>router>mpls>lsp# fast-reroute facilityA:>config>router>mpls>lsp>frr# exit allA:#

Primary LSP-to-P2

P2P1

P3

PE3

PE2


The “show router mpls lsp detail” command can be used to show that this LSP uses the Facility Fast Reroute method. This command can also be used to show the LSP Name as well a the path used.


Confirming Facility Backup configuration (LSP 1)

PE3# show router mpls lsp detail=========================================MPLS LSPs (Originating) (Detail)=========================================---------------------------------------------------------------------------------------------Type : Originating---------------------------------------------------------------------------------------------LSP Name : LSP-to-PE2 LSP Tunnel ID : 3From : 10.10.10.99 To : 10.10.10.103Adm State : Up Oper State : UpLSP Up Time : 0d 00:17:12 LSP Down Time : 0d 00:00:00Transitions : 5 Path Changes : 2Retry Limit : 0 Retry Timer : 30 secSignaling : RSVP Resv. Style : SEHop Limit : 255 Negotiated MTU : 9198Adaptive : EnabledFastReroute : Enabled Oper FR : EnabledFR Method : Facility FR Hop Limit : 6FR Bandwidth : 0 Mbps FR Node Protect : EnabledFR Object : EnabledCSPF : Enabled ADSPEC : DisabledInclude Grps : Exclude Grps :None None

Primary(a) : Primary_Path Up Time : 0d 00:22:17Bandwidth : 0 Mbps


This slide shows the continuation of the previous show command. For this example 2 LSPs have been configured. This slide shows the second LSP status and shows that the FR Method is also Facility just as the first LSP, show on the previous slide.


Confirming Facility Backup configuration (LSP 2)

----------------------------------------------------------------------------------------------Type : Originating----------------------------------------------------------------------------------------------LSP Name : LSP-to-P2 LSP Tunnel ID : 4From : 10.10.10.99 To : 10.10.10.102Adm State : Up Oper State : UpLSP Up Time : 0d 00:45:59 LSP Down Time : 0d 00:00:00Transitions : 3 Path Changes : 1Retry Limit : 0 Retry Timer : 30 secSignaling : RSVP Resv. Style : SEHop Limit : 255 Negotiated MTU : 9198Adaptive : EnabledFastReroute : Enabled Oper FR : EnabledFR Method : Facility FR Hop Limit : 6FR Bandwidth : 0 Mbps FR Node Protect : EnabledFR Object : EnabledCSPF : Enabled ADSPEC : DisabledInclude Grps: Exclude Grps :None None

Primary(a) : to-P2 Up Time : 0d 00:47:19Bandwidth : 0 Mbps===========================================


Syntax bypass-tunnel [to ip-address] [protected-lsp [lsp-name]] [detail]Context show>router>mpls

Parameters ip-address — Specify the IP address of the egress router.

lsp-name — Specify the name of the LSP protected by the bypass tunnel.


The slide above shows that details associated with the bypass tunnel created in the previous set of slides. This show command provides information the bypass tunnel such as the destination of the bypass (the MP) as well as the number of LSPs that are being protected, in this case 2.


show router mpls bypass-tunnel detail

A:P3# show router mpls bypass-tunnel detail=========================================MPLS Bypass Tunnels (Detail)=========================================--------------------------------------------------------------------------------------------Bypass-Tunnel-Avoid-Node10.10.10.101--------------------------------------------------------------------------------------------To : 10.2.3.2 State : UpOut I/F : 1/2/3 Out Label : 131065Up Time : 0d 01:03:24 Active Time : n/aReserved BW : 0 Kbps Protected LSP Count : 2Actual Hops :

10.2.3.3 -> 10.2.3.2=========================================

10.10.10.103

10.10.10.10210.10.10.101

10.10.10.10010.10.10.99

P2P1

P3

PE3

PE2


As before, this command shows all the LSPs currently being supported by this device. This is the first of a series of slides which show this routers participation in the network LSP. This slide shows LSP LSP-to-PE2 and shows that it is acting as a transit device for this LSP.


show router rsvp session detail (slide 1)

10.10.10.103

10.10.10.99

P2P1

P3

PE3

PE2

A:P3# show router rsvp session detail======================================RSVP Sessions (Detailed)======================================--------------------------------------------------------------------------------------LSP : LSP-to-PE2::to-PE2--------------------------------------------------------------------------------------From : 10.10.10.99 To : 10.10.10.103Tunnel ID : 3 LSP ID : 5Style : SE State : UpSession Type : TransitIn Interface : 1/2/1 Out Interface : 1/2/2In Label : 131062 Out Label : 131064Previous Hop : 10.48.1.2 Next Hop : 10.1.3.1

Path Recd : 157 Path Sent : 157Resv Recd : 157 Resv Sent : 157

CommandContinues……

1/2/1

1/2/210.48.1.2

10.1.3.1

LSP-to-PE2

LSP-to-P2


As before, this command shows all the LSPs currently being supported by this device. This is the second of a series of slides which show this routers participation in the network LSP. This slide shows LSP LSP-to-P2 and shows that it is acting as a transit device for this LSP.


show router rsvp session detail (slide 2)

10.10.10.103

10.10.10.99

P2P1

P3

PE3

PE2


1/2/1

1/2/210.48.1.2

10.1.3.1

LSP-to-PE2

LSP-to-P2

---------------------------------------------------------------------------------------LSP : LSP-to-P2::to-P2---------------------------------------------------------------------------------------From : 10.10.10.99 To : 10.10.10.102Tunnel ID : 4 LSP ID : 6Style : SE State : UpSession Type : TransitIn Interface : 1/2/1 Out Interface : 1/2/2In Label : 131067 Out Label : 131066Previous Hop : 10.48.1.2 Next Hop : 10.1.3.1


10.10.10.102


This is the third of a series of slides which show this routers participation in the network LSP. This slide shows the Bypass tunnel which in this case will provide node protection by avoiding node 10.10.10.101 (P1).


show router rsvp session detail (slide 3) – Node Protection

10.10.10.103

10.10.10.99

P2P1

P3

PE3

PE2


1/2/1

1/2/210.48.1.2

10.1.3.1

LSP-to-PE2

LSP-to-P2

10.10.10.102

-------------------------------------------------------------------------------LSP : Bypass-Tunnel-Avoid-Node10.10.10.101-------------------------------------------------------------------------------From : 10.10.10.100 To : 10.2.3.2Tunnel ID : 2 LSP ID : 5Style : FF State : UpSession Type : Bypass TunnelIn Interface : n/a Out Interface : 1/2/3In Label : n/a Out Label : 131065Previous Hop : n/a Next Hop : 10.2.3.2


10.10.10.101

10.2.3.2

1/2/3

10.10.10.100


This slide makes use of the same command, show router rsvp session detail, but the command is being issued on router P1. This router has a link that is being protected by the Bypass Tunnel. The link is between P1 and P2. The Session Type is “Bypass Tunnel” which represents the head of the backup tunnel, or the PLR. Also note that there is no In Interface, In label, or Previous Hop. This is because router 10.10.10.101 is the head of the bypass tunnel. This can also be seen by the “From” address which represents the sytsem address of this router. The following slide shows the “transit” and “termination” of this tunnel.


show router rsvp session detail (slide 4) – Link Protection

10.10.10.103

10.10.10.99

P2P1

P3

PE3

PE21/2/1

1/2/210.1.3.3

10.48.1.2

1/1/310.1.3.1

10.10.10.102

10.10.10.101

1/1/310.2.3.2

1/2/310.2.3.3

10.1.2.2

-------------------------------------------------------------------------------LSP : Bypass-Tunnel-Avoid-Link10.1.2.2-------------------------------------------------------------------------------From : 10.10.10.101 To : 10.2.3.2Tunnel ID : 1 LSP ID : 1Style : FF State : UpSession Type : Bypass TunnelIn Interface : n/a Out Interface : 1/1/3In Label : n/a Out Label : 131065Previous Hop : n/a Next Hop : 10.1.3.3

Path Recd : 0 Path Sent : 234Resv Recd : 235 Resv Sent : 0===================================


This slide is a continuation of the previous slide which shows P3 as the bypass tunnel transit device, while P2 is the termination point of the bypass tunnel. In all 3 cases the bypass tunnel is avoiding link 10.1.2.2 which is the link between P1 and P2.


show router rsvp session detail (slide 5) – Link Protection

10.10.10.103

10.10.10.99

P2P1

P3

PE3

PE21/2/1

1/2/210.48.1.2

10.1.3.1 10.10.10.102

10.10.10.101

1/2/310.2.3.3

---------------------------------------------------------------------------LSP : Bypass-Tunnel-Avoid-Link10.1.2.2---------------------------------------------------------------------------From : 10.10.10.101 To : 10.2.3.2Tunnel ID : 1 LSP ID : 1Style : FF State : UpSession Type : TransitIn Interface : 1/2/2 Out Interface : 1/2/3In Label : 131065 Out Label : 131064Previous Hop : 10.1.3.1 Next Hop : 10.2.3.2

Path Recd : 223 Path Sent : 224Resv Recd : 224 Resv Sent : 224=================================

10.1.2.2

------------------------------------------------------------------------------LSP : Bypass-Tunnel-Avoid-Link10.1.2.2------------------------------------------------------------------------------From : 10.10.10.101 To : 10.2.3.2Tunnel ID : 1 LSP ID : 1Style : FF State : UpSession Type : TerminateIn Interface : 1/1/3 Out Interface : n/aIn Label : 131064 Out Label : n/aPrevious Hop : 10.2.3.3 Next Hop : 10.2.3.2

Path Recd : 238 Path Sent : 0Resv Recd : 0 Resv Sent : 238==================================

BypassTunnel

1/1/310.2.3.2


References:

RFC 2205 - Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification

RFC 3209 – RSVP-TE: Extensions to RSVP for LSP Tunnels

Reference RFC 3210 - Applicability Statement for Extensions to RSVP for LSP-Tunnels

RFC 4090 - Fast Reroute Extensions to RSVP-TE for LSP Tunnels

RFC 4094 - Analysis of Existing Quality-of-Service Signaling Protocols

draft-ietf-mpls-rsvp-lsp-fastreroute - Fast Reroute Extensions to RSVP-TE for LSP Tunnels


References and Relevant RFCs

RFC 2205 - Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification

RFC 3209 - RSVP-TE: Extensions to RSVP for LSP Tunnels

RFC 3210 - Applicability Statement for Extensions to RSVP for LSP-Tunnels

RFC 4090 - Fast Reroute Extensions to RSVP-TE for LSP Tunnels

RFC 4094 - Analysis of Existing Quality-of-Service Signaling Protocols

draft-ietf-mpls-rsvp-lsp-fastreroute - Fast Reroute Extensions to RSVP-TE for LSP Tunnels



Lab 7 and 8 – Fast Reroute One-to-One and Facility

•Pod 1 •Pod 2

•Pod 3

•Core 2•Core 1

•Core 3

•Edge 1

•Edge 3

•Edge 2

•Pod 4

•Core 4

•Edge 4

•10.48.1.0/24 •10.64.1.0/24

•10.16.1.0/24 •10.32.1.0/24

•10.x.y.z/24


•LSP P3-P2•LSP PE3-PE2



Module Summary

RSVP is a protocol that defines procedures for signaling requirements and reserving the necessary resources for a router to provide a requested service to all nodes along a data path.

RSVP makes use of two main message types to establish tunnel reservations, the Path Message and the Resv Message

Traffic extensions enable RSVP to interwork with MPLS, this is called RSVP-TE

RSVP can work either with explicit paths or with paths discovered by CSPF and IGP



Module Summary (Cont’d)

RSVP-TE provides two different reservation styles, Fixed Filter and Shared Explicit

MPLS Fast Reroute (FRR) defines ways of pre-configuring and signaling backup paths before a failure

FRR allows traffic to flow almost continuously

The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair.

The facility backup method creates a bypass tunnel to protect a potential failure point



Learning Assessment

1. What are the two message types used by RSVP to establish a tunnel reservation?

2. What label advertisement mode does RSVP-TE use?

3. Which RSVP object reduces refresh message processing by allowingthe receiver to easily identify a message that contains unchanged state information?

4. What two RSVP reservation styles are supported by Alcatel-Lucent?

5. Which reservation style provides each sender with a dedicated reservation that is not shared with other senders?

6. Which reservation style creates a single reservation over a link that is shared by an explicit list of senders?

7. Define the term “Fast Reroute”



Learning Assessment (Cont’d)

8. How many Primary LSP paths can be configured?

9. How many Secondary LSP paths can be configured?

10. What is the term used for an LSP with one or multiple associatedbackup tunnels originating at that hop.

11. What is the term used for the LSP that is used to re-route traffic around a failure in one-to-one backup?

12. What is the term used for the techniques to repair LSP tunnels quickly when a node or link along the LSPs path fails?

13. What is the name of the head-end LSR of a backup tunnel or a detour LSP?

14. What are the two methods used in FRR to protect links and nodes during network failure?

15. What reservation style does Facility Bypass support?


1. What are the two message types used by RSVP to establish a tunnel reservation? Path Message and Resv Message2. What label advertisement mode does RSVP-TE use? Downstream on Demand3. The message ID object reduces refresh message processing by allowing the receiver to easily identify a message

that contains unchanged state information4. What two RSVP reservation styles are supported by Alcatel-Lucent? Fixed Filter and Shared Explicit5. Which reservation style provides each sender with a dedicated reservation that is not shared with other senders?

Fixed Filter6. Which reservation style creates a single reservation over a link that is shared by an explicit list of senders? Shared

Explicit7. Define the term “Fast Reroute”. Fast Reroute defines way of pre-computing and signaling backup paths before a

failure, so that traffic can immediately be switched over to the backup path by the nearest node upon a failure8. How many Primary LSP paths can be configured? 19. How many Secondary LSP paths can be configured? 810. What is the term used for an LSP with one or multiple associated backup tunnels? Protected LSP11. What is the term used for the LSP that is used to re-route traffic around a failure in one-to-one backup? Detour

LSP12. What is the term used for the techniques to repair LSP tunnels quickly when a node or link along the LSPs path

fails? Local Repair13. What is the name of the head-end LSR of a backup tunnel or a detour LSP? Point of Local Repair (PLR)14. What are the two methods used to protect links and nodes during network failure? One-to-one Backup, Facility

Backup15. What reservation style does Facility Bypass support? SE ONLY



alcatel-lucent multi protocol label switching student guide v1-3

Documents