Label Distribution Protocol

In This Chapter
This chapter provides information to enable the Label Distribution Protocol (LDP).

Topics in this chapter include:

• Label Distribution Protocol

• LDP Process Overview
• Configuration Notes
• Configuring LDP with CLI
• LDP Command Reference

7705 SAR OS MPLS Guide 171

Label Distribution Protocol

Label Distribution Protocol

Label Distribution Protocol (LDP) is used to distribute labels in non-traffic-engineered
applications. LDP allows routers to establish LSPs through a network by mapping
network-layer routing information directly to data link LSPs.

An LSP is defined by the set of labels from the ingress LER to the egress LER. LDP
associates a Forwarding Equivalence Class (FEC) with each LSP it creates. An FEC is a
collection of common actions associated with a class of packets. When an ingress LER
assigns a label to an FEC, it must let other LSRs in the path know about the label. LDP helps
to establish the LSP by providing a set of procedures that LSRs can use to distribute labels.

The FEC associated with an LSP specifies which packets are mapped to that LSP. LSPs are
extended through a network by each LSR, where each LSR splices incoming labels for the
FEC to the outgoing label assigned to the next hop for the FEC.

LDP allows an LSR to request a label from a downstream LSR so it can bind the label to a
specific FEC. The downstream LSR responds to the request from the upstream LSR by
sending the requested label.

LSRs can distribute an FEC label binding in response to an explicit request from another
LSR. This is known as Downstream On Demand (DOD) label distribution. LSRs can also
distribute label bindings to LSRs that have not explicitly requested them. This is called
Downstream Unsolicited (DU). For LDP on the 7705 SAR, Downstream Unsolicited (DU)
mode is implemented.

This section contains the following topics:

• LDP and MPLS

• LDP Architecture
• LDP Subsystem Interrelationships
• Execution Flow
• Label Exchange
• LDP Filters
• Multi-area and Multi-instance Extensions to LDP
• ECMP Support for LDP
• Graceful Restart Helper

172 7705 SAR OS MPLS Guide

 Label Distribution Protocol

LDP and MPLS

LDP performs dynamic label distribution in MPLS environments. The LDP operation begins
with a Hello discovery process network to form an adjacency with an LDP peer in the
network. LDP peers are two MPLS routers that use LDP to exchange label/FEC mapping
information. An LDP session is created between LDP peers. A single LDP session allows
each peer to learn the other's label mappings and to distribute its own label information (LDP
is bidirectional), and exchange label binding information.

LDP signaling works with the MPLS label manager to manage the relationships between
labels and the corresponding FEC. For service-based FECs, LDP works in tandem with the
Service Manager to identify the virtual leased lines (VLLs) and pseudowires (PWs) to signal.

An MPLS label identifies a set of actions that the forwarding plane performs on an incoming
packet before discarding it. The FEC is identified through the signaling protocol (in this case
LDP), and is allocated a label. The mapping between the label and the FEC is communicated
to the forwarding plane. In order for this processing on the packet to occur at high speeds,
optimized tables that enable fast access and packet identification are maintained in the
forwarding plane.

When an unlabeled packet ingresses the 7705 SAR, classification policies associate it with an
FEC, the appropriate label is imposed on the packet, and then the packet is forwarded. Other
actions can also take place on a packet before it is forwarded, including imposing additional
labels, other encapsulations, or learning actions. Once all actions associated with the packet
are completed, the packet is forwarded.

When a labeled packet ingresses the router, the label or stack of labels indicates the set of
actions associated with the FEC for that label or label stack. The actions are performed on the
packet and then the packet is forwarded.

The LDP implementation provides support for DU, ordered control, and liberal label
retention mode.

For LDP label advertisement, DU mode is supported. To prevent filling the uplink bandwidth
with unassigned label information, Ordered Label Distribution Control mode is supported.

A PW/VLL label can be dynamically assigned by targeted LDP operations. Targeted LDP
allows the inner labels (that is, the VLL labels) in the MPLS headers to be managed
automatically. This makes it easier for operators to manage the VLL connections. There is,
however, additional signaling and processing overhead associated with this targeted LDP
dynamic label assignment.

7705 SAR OS MPLS Guide 173

Label Distribution Protocol

BFD for T-LDP

BFD is a simple protocol for detecting failures in a network. BFD uses a “hello” mechanism
that sends control messages periodically to the far end and receives periodic control messages
from the far end. BFD is implemented in asynchronous mode only, meaning that neither end
responds to control messages; rather, the messages are sent in the time period configured at
each end.

A T-LDP session is a session between either directly or non-directly connected peers and
requires that adjacencies be created between two peers. BFD for T-LDP sessions allows
support for tracking of failures of nodes that are not directly connected. BFD timers must be
configured under the system router interface context before being enabled under T-LDP.

BFD tracking of an LDP session associated with a T-LDP adjacency allows for faster
detection of the status of the session by registering the loopback address of the peer as the
transport address.

LDP Architecture
LDP comprises a few processes that handle the protocol PDU transmission, timer-related
issues, and protocol state machine. The number of processes is kept to a minimum to simplify
the architecture and to allow for scalability. Scheduling within each process prevents
starvation of any particular LDP session, while buffering alleviates TCP-related congestion
issues.

The LDP subsystems and their relationships to other subsystems are illustrated in Figure 11.
This illustration shows the interaction of the LDP subsystem with other subsystems,
including memory management, label management, service management, SNMP, interface
management, and RTM. In addition, debugging capabilities are provided through the logger.

Communication within LDP tasks is typically done by interprocess communication through

the event queue, as well as through updates to the various data structures. The following list
describes the primary data structures that LDP maintains:

• FEC/label database — this database contains all the FEC-to-label mappings,

including both sent and received. It also contains both address FECs (prefixes and
host addresses) as well as service FECs (L2 VLLs).
• Timer database — this database contains all the timers for maintaining sessions and
adjacencies
• Session database — this database contains all the session and adjacency records, and
serves as a repository for the LDP MIB objects

174 7705 SAR OS MPLS Guide

 Label Distribution Protocol

LDP Subsystem Interrelationships

Figure 11 shows the relationships between LDP subsystems and other 7705 SAR OS
subsystems. The following sections describe how the subsystems work to provide services.

Memory Manager and LDP

LDP does not use any memory until it is instantiated. It pre-allocates some amount of fixed
memory so that initial startup actions can be performed. Memory allocation for LDP comes
out of a pool reserved for LDP that can grow dynamically as needed.

Fragmentation is minimized by allocating memory in large chunks and managing the memory
internally to LDP. When LDP is shut down, it releases all memory allocated to it.

Label Manager

LDP assumes that the label manager is up and running. LDP will abort initialization if the
label manager is not running. The label manager is initialized at system bootup; hence
anything that causes it to fail will likely indicate that the system is not functional. The
7705 SAR uses a label range from 28 672 (28K) to 131 071 (128K-1) to allocate all dynamic
labels, including VC labels.

7705 SAR OS MPLS Guide 175

Label Distribution Protocol

Figure 11: LDP Subsystem Interrelationships

Memory
Mgr

LDP MIB Session DB Label

Mgr

Send/
Timer Protocol Receive

Send/
Config Receive

(CLI/SNMP) Timer DB FEC/

Label DB

Logger
Event
Queue

Interface RTM
Mgr
Service
Mgr

Event
Queue
Event
Queue

19692

LDP Configuration

The 7705 SAR uses a single consistent interface to configure all protocols and services. CLI
commands are translated to SNMP requests and are handled through an agent-LDP interface.
LDP can be instantiated or deleted through SNMP. Also, targeted LDP sessions can be set up
to specific endpoints. Targeted session parameters are configurable.

176 7705 SAR OS MPLS Guide

 Label Distribution Protocol

Logger

LDP uses the logger interface to generate debug information relating to session setup and
teardown, LDP events, label exchanges, and packet dumps. Per-session tracing can be
performed. Refer to the 7705 SAR OS System Management Guide for logger configuration
information.

Service Manager

All interaction occurs between LDP and the service manager, since LDP is used primarily to
exchange labels for Layer 2 services. In this context, the service manager informs LDP when
an LDP session is to be set up or torn down, and when labels are to be exchanged or
withdrawn. In turn, LDP informs the service manager of relevant LDP events, such as
connection setups and failures, timeouts, and labels signaled or withdrawn.

Execution Flow
LDP activity in the 7705 SAR is limited to service-related signaling. Therefore, the
configurable parameters are restricted to system-wide parameters, such as hello and keepalive
timeouts.

Initialization

MPLS must be enabled when LDP is initialized. LDP makes sure that the various
prerequisites are met, such as ensuring that the system IP interface and the label manager are
operational, and ensuring that there is memory available. It then allocates a pool of memory
to itself and initializes its databases.

Session Lifetime

In order for a targeted LDP session to be established, an adjacency has to be created. The LDP
extended discovery mechanism requires hello messages to be exchanged between two peers
for session establishment. Once the adjacency is established, session setup is attempted.

7705 SAR OS MPLS Guide 177

Label Distribution Protocol

Adjacency Establishment

In the 7705 SAR, adjacency management is done through the establishment of a Service
Destination Point (SDP) object, which is a service entity in the Alcatel-Lucent service model.

The Alcatel-Lucent service model uses logical entities that interact to provide a service. The
service model requires the service provider to create and configure four main entities:

• customers
• services
• Service Access Points (SAPs) on local 7705 SAR routers
• SDPs that connect to one or more remote 7705 SAR routers or 77x0 SR routers

An SDP is the network-side termination point for a tunnel to a remote 7705 SAR or 77x0 SR
router. An SDP defines a local entity that includes the system IP address of the remote
7705 SAR routers and 77x0 SR routers, and a path type.

Each SDP comprises:

• the SDP ID
• the transport encapsulation type, MPLS
• the far-end system IP address

If the SDP is identified as using LDP signaling, then an LDP extended hello adjacency is
attempted.

If another SDP is created to the same remote destination and if LDP signaling is enabled, no
further action is taken, since only one adjacency and one LDP session exists between the pair
of nodes.

An SDP is a unidirectional object, so a pair of SDPs pointing at each other must be configured
in order for an LDP adjacency to be established. Once an adjacency is established, it is
maintained through periodic hello messages.

Session Establishment

When the LDP adjacency is established, the session setup follows as per the LDP
specification. Initialization and keepalive messages complete the session setup, followed by
address messages to exchange all interface IP addresses. Periodic keepalives or other session
messages maintain the session liveliness.

Since TCP is back-pressured by the receiver, it is necessary to be able to push that

back-pressure all the way into the protocol. Packets that cannot be sent are buffered on the
session object and reattempted as the back-pressure eases.

178 7705 SAR OS MPLS Guide

 Label Distribution Protocol

Label Exchange
Label exchange is initiated by the service manager. When an SDP is attached to a service (that
is, once the service gets a transport tunnel), a message is sent from the service manager to
LDP. This causes a label mapping message to be sent. Additionally, when the SDP binding
is removed from the service, the VC label is withdrawn. The peer must send a label release
to confirm that the label is not in use.

Other Reasons for Label Actions

Label actions can also occur for the following reasons:

• MTU changes — LDP withdraws the previously assigned label and resignals the
FEC with the new Maximum Transmission Unit (MTU) in the interface parameter
• clear labels — when a service manager command is issued to clear the labels, the
labels are withdrawn and new label mappings are issued
• SDP down — when an SDP goes administratively down, the VC label associated
with that SDP for each service is withdrawn
• memory allocation failure — if there is no memory to store a received label, the
received label is released
• VC type unsupported — when an unsupported VC type is received, the received label
is released

Cleanup

LDP closes all sockets, frees all memory, and shuts down all its tasks when it is deleted, so
that it uses no memory (0 bytes) when it is not running.

LDP Filters
The 7705 SAR supports both inbound and outbound LDP label binding filtering.

Inbound filtering (import policy) allows the user to configure a policy to control the label
bindings an LSR (Label Switch Router) accepts from its peers.

Import policy label bindings can be filtered based on the following:

• neighbor — match on bindings received from the specified peer

7705 SAR OS MPLS Guide 179

Label Distribution Protocol

• prefix-list — match on bindings with the specified prefix/prefixes

The default import behavior is to accept all FECs received from peers.

Outbound filtering (export policy) allows the user to configure a policy to control the set of
LDP label bindings advertised by the LSR (Label Switch Router).

Because the default behavior is to originate label bindings for the system IP address only,
when a non-default loopback address is used as the transport address, the 7705 SAR will not
advertise the loopback FEC automatically. With LDP export policy, the user is now able to
explicitly export the loopback address in order to advertise the loopback address label and
allow the node to be reached by other network elements.

Export policy label bindings can be filtered based on the following:

• all — all local subnets by specifying “direct” as the match protocol

• prefix-list — match on bindings with the specified prefix/prefixes

Note: In order for the 7705 SAR to consider a received label to be active, there must be an
exact match to the FEC advertised together with the label found in the routing table, or a
longest prefix match (if the aggregate-prefix-match option is enabled; see Multi-area and
Multi-instance Extensions to LDP). This can be achieved by configuring a static route
pointing to the prefix encoded in the FEC.

Multi-area and Multi-instance Extensions to LDP

When a network has two or more IGP areas, or instances, inter-area LSPs are required for
MPLS connectivity between the PE devices that are located in the distinct IGP areas. In order
to extend LDP across multiple areas of an IGP instance or across multiple IGP instances, the
current standard LDP implementation based on RFC 3036, LDP Specification, requires that
all /32 prefixes of PEs be leaked between the areas or instances. IGP route leaking is the
distribution of the PE loopback addresses across area boundaries. An exact match of the
prefix in the routing table (RIB) is required to install the prefix binding in the FIB and set up
the LSP.

180 7705 SAR OS MPLS Guide

 Label Distribution Protocol

This behavior is the default behavior for the 7705 SAR when it is configured as an Area
Border Router (ABR). However, exact prefix matching causes performance issues for the
convergence of IGP on routers deployed in networks where the number of PE nodes scales to
thousands of nodes. Exact prefix matching requires the RIB and FIB to contain the IP
addresses maintained by every LSR in the domain and requires redistribution of a large
number of addresses by the ABRs. Security is a potential issue as well, as host routes leaked
between areas can be used in DoS and DDoS attacks and spoofing attacks.

To avoid these performance and security issues, the 7705 SAR can be configured for an
optional behavior in which LDP installs a prefix binding in the LDP FIB by performing a
longest prefix match with an aggregate prefix in the routing table (RIB). This behavior is
described in RFC 5283, LDP Extension for Inter-Area Label Switched Paths. The LDP prefix
binding continues to be advertised on a per-individual /32 prefix basis.

When the longest prefix match option is enabled and an LSR receives a FEC-label binding
from an LDP neighbor for a prefix-address FEC element, FEC1, it installs the binding in the
LDP FIB if:

• the routing table (RIB) contains an entry that matches FEC1. Matching can either be
a longest IP match of the FEC prefix or an exact match.
• the advertising LDP neighbor is the next hop to reach FEC1

When the FEC-label binding has been installed in the LDP FIB, LDP programs an NHLFE
entry in the egress data path to forward packets to FEC1. LDP also advertises a new
FEC-label binding for FEC1 to all its LDP neighbors.

When a new prefix appears in the RIB, LDP checks the LDP FIB to determine if this prefix
is a closer match for any of the installed FEC elements. If a closer match is found, this may
mean that the LSR used as the next hop will change; if so, the NHLFE entry for that FEC must
be changed.

When a prefix is removed from the RIB, LDP checks the LDP FIB for all FEC elements that
matched this prefix to determine if another match exists in the routing table. If another match
exists, LDP must use it. This may mean that the LSR used as the next hop will change; if so,
the NHLFE entry for that FEC must be changed. If another match does not exist, the LSR
removes the FEC binding and sends a label withdraw message to its LDP neighbors.

If the next hop for a routing prefix changes, LDP updates the LDP FIB entry for the FEC
elements that matched this prefix. It also updates the NHLFE entry for the FEC elements.

7705 SAR OS MPLS Guide 181

Label Distribution Protocol

ECMP Support for LDP

Equal-Cost Multipath Protocol (ECMP) support for LDP performs load balancing for
VLL-type and VPRN services that use LDP-based LSPs as transport tunnels, by having
multiple equal-cost outgoing next hops for an IP prefix.

There is only one next-hop peer for a network link. To offer protection from a network link
or next-hop peer failure, multiple network links can be configured to connect to different
next-hop peers, or multiple links to the same peer. For example, an MLPPP link and an
Ethernet link can be connected to two peers, or two Ethernet links can be connected to the
same peer. ECMP occurs when the cost of each link reaching a target IP prefix is equal.

The 7705 SAR uses a liberal label retention mode, which retains all labels for an IP prefix
from all next-hop peers. A 7705 SAR acting as an LSR load-balances the MPLS traffic over
multiple links using a hashing algorithm.

The 7705 SAR uses the following fields in the hashing algorithm:

• system IP address
• global IP ifindex (interface identifier)
• MPLS label stack (up to six labels)
• (optional) IPv4 source and destination addresses

The default behavior is the label-only hashing option; hashing is performed on the system IP
address, global IP ifindex, and MPLS label stack. To include hashing on the IPv4 source and
destination addresses, the system must be configured for the label-IP hashing option.With this
option, the IP header is assumed to be the next header after the last label. LSR considers a
packet to be an IP packet if the first nibble after the last label in the label stack is 4 (indicating
IPv4). The 7705 SAR does not check to ensure that this is the case.

Load balancing can be configured at the system level or interface level. Configuration at the
interface level overrides the system-level settings for the specific interface. Configuration
must be done on the ingress network interface (that is, the interface on the LDP LSR node
that the packet is received on).

Configuration of load balancing at the interface level provides some control to the user as the
label-IP option can be disabled on a specific interface if labeled packets received on the
interface include non-IP packets that can be confused by the hash routine for IP packets. For
example, there could be cases where the first nibble of a non-IP packet is a 4, which would
result in the packet being hashed incorrectly if the label-IP option was enabled.

182 7705 SAR OS MPLS Guide

 Label Distribution Protocol

If ECMP is not enabled, the label from only one of the next-hop peers is selected and installed
in the forwarding plane. In this case, the algorithm used to distribute the traffic flow looks up
the route information, and selects the network link with the lowest IP address. If the selected
network link or next-hop peer fails, another next-hop peer is selected, and LDP reprograms
the forwarding plane to use the label sent by the newly selected peer.

ECMP is supported on all Ethernet ports in network mode (with the exception of Ethernet
ports on the 7705 SAR-F), and is also supported on the 4-port OC3/STM1 Clear Channel
Adapter card when it is configured for POS (ppp-auto) encapsulation and network mode.

For information on configuring the 7705 SAR for LSR ECMP, refer to the
lsr-load-balancing commands in the 7705 SAR OS Basic System Configuration
Guide, “System Information and General Commands” and the 7705 SAR OS Router
Configuration Guide, “Router Interface Commands”.

For information on LDP treetrace commands for tracing ECMP paths, refer to the
7705 SAR OS OAM and Diagnostics Guide.

Note: LDP treetrace works best with label-IP hashing (lbl-ip) enabled, rather than
label-only (lbl-only) hashing. These options are set with the lsr-load-balancing
command.

Note:

• Because timeout is built into dynamic ARP, the MAC address of the remote peer needs
to be renewed periodically. The flow of IP traffic resets the timers back to their maximum
values. In the case of LDP ECMP, one link could be used for transporting user MPLS
(pseudowire) traffic but the LDP session could possibly be using a different equal-cost
link. For LDPs using ECMP and for static LSPs, it is important to ensure that the remote
MAC address is learned and does not expire. Configuring static ARP entries or running
continuous IP traffic ensures that the remote MAC address is always known. Running
BFD for fast detection of Layer 2 faults or running any OAM tools with SAA ensures that
the learned MAC addresses do not expire.
• ARP entries are refreshed by static ARP and BFD, SAA, OSPF, IS-IS, or BGP.
• For information on configuring static ARP and running BFD, refer to the 7705 SAR OS
Router Configuration Guide.

7705 SAR OS MPLS Guide 183

Label Distribution Protocol

Label Operations

If an LSR is the ingress router for a given IP prefix, LDP programs a PUSH operation for the
prefix in the IOM. This creates an LSP ID to the Next Hop Label Forwarding Entry (NHLFE)
mapping (LTN mapping) and an LDP tunnel entry in the forwarding plane. LDP will also
inform the Tunnel Table Manager (TTM) about this tunnel. Both the LSP ID to NHLFE
(LTN) entry and the tunnel entry will have an NHLFE for the label mapping that the LSR
received from each of its next-hop peers.

If the LSR is to behave as a transit router for a given IP prefix, LDP will program a SWAP
operation for the prefix in the IOM. This involves creating an Incoming Label Map (ILM)
entry in the forwarding plane. The ILM entry might need to map an incoming label to multiple
NHLFEs.

If an LSR is an egress router for a given IP prefix, LDP will program a POP entry in the IOM.
This too will result in an ILM entry being created in the forwarding plane, but with no
NHLFEs.

When unlabeled packets arrive at the ingress LER, the forwarding plane consults the LTN
entry and uses a hashing algorithm to map the packet to one of the NHLFEs (PUSH label)
and forward the packet to the corresponding next-hop peer. For a labeled packet arriving at a
transit or egress LSR, the forwarding plane consults the ILM entry and either uses a hashing
algorithm to map it to one of the NHLFEs if they exist (SWAP label) or routes the packet if
there are no NHLFEs (POP label).

Graceful Restart Helper

Graceful Restart (GR) is part of the LDP handshake process (that is, the LDP peering session
initialization) and needs to be supported by both peers. GR provides a mechanism that allows
the peers to cope with a service interruption due to a CSM switchover, which is a period of
time when the standby CSM is not capable of synchronizing the states of the LDP sessions
and labels being advertised and received.

Graceful Restart Helper (GR-Helper) decouples the data plane from the control plane so that
if the control plane is not responding (that is, there is no LDP message exchange between
peers), then the data plane can still forward frames based on the last known (advertised)
labels.

184 7705 SAR OS MPLS Guide

 Label Distribution Protocol

Because the 7705 SAR supports non-stop services / high-availability for LDP (and MPLS),
the full implementation of GR is not needed. However, GR-Helper is implemented on the
7705 SAR to support non-high-availability devices. With GR-Helper, if an LDP peer of the
7705 SAR requests GR during the LDP handshake, the 7705 SAR agrees to it but does not
request GR. For the duration of the LDP session, if the 7705 SAR LDP peer fails, the
7705 SAR continues to forward MPLS packets based on the last advertised labels and will
not declare the peer dead until the GR timer expires.

7705 SAR OS MPLS Guide 185

LDP Process Overview

LDP Process Overview

Figure 12 displays the process to provision basic LDP parameters.

Figure 12: LDP Configuration and Implementation

START

ENABLE LDP

APPLY IMPORT AND EXPORT POLICIES

CONFIGURE LDP INTERFACE PARAMETERS

CONFIGURE TARGETED SESSION PARAMETERS

CONFIGURE PEER PARAMETERS

TURN UP

21820

186 7705 SAR OS MPLS Guide

 Label Distribution Protocol

Configuration Notes
Refer to the 7705 SAR OS Services Guide for information about signaling.

Reference Sources
For information on supported IETF drafts and standards, as well as standard and proprietary
MIBs, refer to Standards and Protocol Support.

7705 SAR OS MPLS Guide 187

Configuration Notes

188 7705 SAR OS MPLS Guide