LDP Overview

The Label Distribution Protocol (LDP) is a protocol for distributing labels in non-traffic-engineered applications. LDP allows routers to establish label-switched paths (LSPs) through a network by mapping network-layer routing information directly to data link layer-switched paths.

These LSPs might have an endpoint at a directly attached neighbor (comparable to IP hop-by-hop forwarding), or at a network egress node, enabling switching through all intermediary nodes. LSPs established by LDP can also traverse traffic-engineered LSPs created by RSVP.

LDP associates a forwarding equivalence class (FEC) with each LSP it creates. The FEC associated with an LSP specifies which packets are mapped to that LSP. LSPs are extended through a network as each router chooses the label advertised by the next hop for the FEC and splices it to the label it advertises to all other routers. This process forms a tree of LSPs that converge on the egress router.

Understanding the LDP Signaling Protocol

LDP is a signaling protocol that runs on a device configured for MPLS support. The successful configuration of both MPLS and LDP initiates the exchange of TCP packets across the LDP interfaces. The packets establish TCP-based LDP sessions for the exchange of MPLS information within the network. Enabling both MPLS and LDP on the appropriate interfaces is sufficient to establish LSPs.

LDP is a simple, fast-acting signaling protocol that automatically establishes LSP adjacencies within an MPLS network. Routers then share LSP updates such as hello packets and LSP advertisements across the adjacencies. Because LDP runs on top of an IGP such as IS-IS or OSPF, you must configure LDP and the IGP on the same set of interfaces. After both are configured, LDP begins transmitting and receiving LDP messages through all LDP-enabled interfaces. Because of LDP's simplicity, it cannot perform the true traffic engineering which RSVP can perform. LDP does not support bandwidth reservation or traffic constraints.

When you configure LDP on a (LSR), the router begins sending LDP discovery messages out all LDP-enabled interfaces. When an adjacent LSR receives LDP discovery messages, it establishes an underlying TCP session. An LDP session is then created on top of the TCP session. The TCP three-way handshake ensures that the LDP session has bidirectional connectivity. After they establish the LDP session, the LDP neighbors maintain, and terminate, the session by exchanging messages. LDP advertisement messages allow LSRs to exchange label information to determine the next hops within a particular LSP. Any topology changes, such as a router failure, generate LDP notifications that can terminate the LDP session or generate additional LDP advertisements to propagate an LSP change.

Starting in Junos OS Release 20.3R1, support for MPLS to provide LDP signaling protocol configuration with the control plane functionality.

Example: Configuring LDP-Signaled LSPs

This example shows how to create and configure LDP instances within an MPLS network.

Requirements

Before you begin:

Note: Because LDP runs on top of an IGP such as IS-IS or OSPF, you must configure LDP and the IGP on the same set of interfaces.

Overview

To configure LDP-signaled LSPs, you must enable the MPLS family on all transit interfaces in the MPLS network and include all the transit interfaces under the [ protocols mpls ] and [ protocols ldp ] hierarchy levels.

In this example, you enable the MPLS family and create an LDP instance on all the transit interfaces. Additionally, you enable the MPLS process on all the transit interfaces in the MPLS network. In this example, you configure a sample network as shown in Figure 1.

Figure 1: Typical LDP-Signaled LSP

Configuration

Procedure

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level and then enter commit from configuration mode.

R1

set interfaces ge-0/0/0 unit 0 family mpls set protocols mpls ge-0/0/0 unit 0 set protocols ldp interface ge-0/0/0 unit 0

R2

set interfaces ge-0/0/0 unit 0 family mpls set protocols mpls ge-0/0/0 unit 0 set protocols ldp interface ge-0/0/0 unit 0 set interfaces ge-0/0/1 unit 0 family mpls set protocols mpls ge-0/0/1 unit 0 set protocols ldp interface ge-0/0/1 unit 0

R3

set interfaces ge-0/0/0 unit 0 family mpls set protocols mpls ge-0/0/0 unit 0 set protocols ldp interface ge-0/0/0 unit 0
Step-by-Step Procedure

To enable LDP instances within an MPLS network:

    Enable the MPLS family on the transit interface on Router R1.

[edit] user@R1# set interfaces ge-0/0/0 unit 0 family mpls 
[edit] user@R1# set protocols mpls interface ge-0/0/0 unit 0 
[edit] user@R1# set protocols ldp interface ge-0/0/0 unit 0
Results

Confirm your configuration by entering the show command from configuration mode. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

For brevity, this show output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (. ).

user@R1# show . interfaces < ge-0/0/0 < unit 0 < family inet < address 10.100.37.20/24; >family mpls; > > > . protocols < mpls < interface all; >ldp < interface ge-0/0/0.0; >>

If you are done configuring the device, enter the commit command from the configuration mode to activate the configuration.

Junos OS LDP Protocol Implementation

The Junos OS implementation of LDP supports LDP version 1. The Junos OS supports a simple mechanism for tunneling between routers in an interior gateway protocol (IGP), to eliminate the required distribution of external routes within the core. The Junos OS allows an MPLS tunnel next hop to all egress routers in the network, with only an IGP running in the core to distribute routes to egress routers. Edge routers run BGP but do not distribute external routes to the core. Instead, the recursive route lookup at the edge resolves to an LSP switched to the egress router. No external routes are necessary on the transit LDP routers.

LDP Operation

You must configure LDP for each interface on which you want LDP to run. LDP creates LSP trees rooted at each egress router for the router ID address that is the subsequent BGP next hop. The ingress point is at every router running LDP. This process provides an inet.3 route to every egress router. If BGP is running, it will attempt to resolve next hops by using the inet.3 table first, which binds most, if not all, of the BGP routes to MPLS tunnel next hops.

Two adjacent routers running LDP become neighbors. If the two routers are connected by more than one interface, they become neighbors on each interface. When LDP routers become neighbors, they establish an LDP session to exchange label information. If per-router labels are in use on both routers, only one LDP session is established between them, even if they are neighbors on multiple interfaces. For this reason, an LDP session is not related to a particular interface.

LDP operates in conjunction with a unicast routing protocol. LDP installs LSPs only when both LDP and the routing protocol are enabled. For this reason, you must enable both LDP and the routing protocol on the same set of interfaces. If this is not done, LSPs might not be established between each egress router and all ingress routers, which might result in loss of BGP-routed traffic.

You can apply policy filters to labels received from and distributed to other routers through LDP. Policy filters provide you with a mechanism to control the establishment of LSPs.

For LDP to run on an interface, MPLS must be enabled on a on that interface. For more information, see the Logical Interfaces.

LDP Message Types

LDP uses the message types described in the following sections to establish and remove mappings and to report errors. All LDP messages have a common structure that uses a type, length, and value (TLV) encoding scheme.

Discovery Messages

Discovery messages announce and maintain the presence of a router in a network. Routers indicate their presence in a network by sending hello messages periodically. Hello messages are transmitted as UDP packets to the LDP port at the group multicast address for all routers on the subnet.

LDP uses the following discovery procedures:

Session Messages

Session messages establish, maintain, and terminate sessions between LDP peers. When a router establishes a session with another router learned through the hello message, it uses the LDP initialization procedure over TCP transport. When the initialization procedure is completed successfully, the two routers are LDP peers and can exchange advertisement messages.

Advertisement Messages

Advertisement messages create, change, and delete label mappings for forwarding equivalence classes (FECs). Requesting a label or advertising a label mapping to a peer is a decision made by the local router. In general, the router requests a label mapping from a neighboring router when it needs one and advertises a label mapping to a neighboring router when it wants the neighbor to use a label.

Notification Messages

Notification messages provide advisory information and signal error information. LDP sends notification messages to report errors and other events of interest. There are two kinds of LDP notification messages:

Tunneling LDP LSPs in RSVP LSPs

You can tunnel LDP LSPs over RSVP LSPs. The following sections describe how tunneling of LDP LSPs in RSVP LSPs works:

Tunneling LDP LSPs in RSVP LSPs Overview

If you are using RSVP for traffic engineering, you can run LDP simultaneously to eliminate the distribution of external routes in the core. The LSPs established by LDP are tunneled through the LSPs established by RSVP. LDP effectively treats the traffic-engineered LSPs as single hops.

When you configure the router to run LDP across RSVP-established LSPs, LDP automatically establishes sessions with the router at the other end of the LSP. LDP control packets are routed hop-by-hop, rather than carried through the LSP. This routing allows you to use simplex (one-way) traffic-engineered LSPs. Traffic in the opposite direction flows through LDP-established LSPs that follow unicast routing rather than through traffic-engineered tunnels.

If you configure LDP over RSVP LSPs, you can still configure multiple OSPF areas and IS-IS levels in the traffic engineered core and in the surrounding LDP cloud.

Beginning with Junos OS Release 15.1, multi-instance support is extended to LDP over RSVP tunneling for a virtual router routing instance. This allows splitting of a single routing and MPLS domain into multiple domains so that each domain can be scaled independently. BGP labeled unicast can be used to stitch these domains for service forwarding equivalence classes (FECs). Each domain uses intra-domain LDP-over-RSVP LSP for MPLS forwarding.

With the introduction of the multi-instance support for LDP-over-RSVP LSPs, you cannot enable MPLS on an interface that is already assigned to another routing instance. Adding an interface that is part of another routing instance at the [edit protocols mpls] hierarchy level, throws a configuration error at the time of commit.

Benefits of Tunneling LDP LSPs in RSVP LSPs

Tunneling LDP LSPs in RSVP LSPs provides the following benefits:

Tunneling LDP over SR-TE

Learn about the benefits and get an overview of tunneling LDP over SR-TE.

Benefits of Tunneling LDP over SR-TE

Tunneling LDP over SR-TE Overview

It’s common for service providers to use the LDP signaling protocol with MPLS transport at the edges of their networks. LDP offers the advantage of being simple, but LDP lacks traffic engineering (TE) and sophisticated path repair capabilities that are often desired in the network’s core. Many service providers are migrating from RSVP to segment routing traffic engineering (SR-TE) in the core. SR-TE is also referred to as source routing in packet networks (SPRING).

It’s possible that the routers running LDP at the edge may not support SR capabilities. The service provider may wish to continue using LDP on these routers to avoid the need for an upgrade. In such scenarios, the LDP over SR-TE tunneling feature provides the ability to integrate routers that are not SR capable (running LDP) with routers that are SR capable (running SR-TE).

The LDP LSPs are tunneled through the SR-TE network, enabling interworking of LDP LSPs with SR-TE LSPs. For example, if you have LDP domains on the provider edge network and SR-TE in the core network, then you can connect the LDP domains over SR-TE, as shown in Figure 2.

Tunneling LDP over SR-TE supports co-existence of both LDP LSPs and SR-TE LSPs.

Interconnect LDP Domains over SR-TE in the Core Network

Figure 2: Interconnect LDP Domains over SR-TE in the Core Network

You can also tunnel LDP over SR-TE between LDP domains connected to inter-region core networks. For example, if you have multiple regional LDP domains connected to the inter-region SR-TE core networks, you can tunnel LDP across the inter-region SR-TE core network, as shown in Figure 3.

LDP over SR-TE between Inter-region Core Networks

Figure 3: LDP over SR-TE between Inter-region Core Networks

In Figure 3, you have three regional networks (A, B, and C) running LDP. These regional LDP domains are connected to their respective regional core networks running SR-TE. The regional SR-TE core networks are further interconnected to other regional SR-TE core networks (inter-region core network). You can tunnel LDP over these inter-region SR-TE core networks and deploy services, such as Layer 3 VPNs, seamlessly. This scenario could be used in a mobile backhaul network, where the core aggregation layer runs LDP tunneled over SR-TE while the access layer runs LDP only.

To enable LDP tunneling over SR-TE in IS-IS networks, you need to configure the following configuration statements:

To enable LDP tunneling over SR-TE in OSPF networks, you need to configure the following configuration statements:

You can configure more than one tunnel source protocol for IGPs (IS-IS and OSPF) to create shortcut routes. When more than one tunnel source protocol is configured and if the tunnels from more than one protocol are available to a destination, the tunnel with the most preferred route is established. For example, if the core network has both RSVP LSPs and SR-TE LSPs and LDP tunneling is enabled for both RSVP and SR-TE LSPs, then the tunnel-source-protocol configuration selects the tunnel based on the preference value. The tunnel with the lowest preference value is most preferred. You can override this route preference with a specific protocol for all destinations by configuring the preference value, as shown in the following example:

[edit] user@host#set protocols isis traffic-engineering tunnel-source-protocol spring-te preference 2 user@host#set protocols isis traffic-engineering tunnel-source-protocol rsvp preference 5 
[edit] user@host#set protocols ospf traffic-engineering tunnel-source-protocol spring-te preference 2 user@host#set protocols ospf traffic-engineering tunnel-source-protocol rsvp preference 5

In this example, you can see the preference value configured for the SR-TE tunnel source protocol is 2 and the preference value for RSVP tunnel source protocol is 5. In this case, the SR-TE tunnel are preferred because they have the lowest preference value as compared to RSVP tunnel source protocol.

It is not mandatory to configure the tunnel source protocol preference value. If more than one tunnel source protocol has the same preference value, then the tunnel is established based on the preferred route to the destination.

The targeted LDP session is established and is triggered when the SR-TE LSP comes up. The LSP session remains established until the LDP tunneling ( ldp-tunneling ) configuration is removed, or the SR-TE LSP is removed from the configuration.

Junos OS currently does not support LDP over colored SR-TE LSPs.

Example: Tunneling LDP over SR-TE in IS-IS Network

Use this example to learn how to tunnel LDP LSPs over SR-TE in your core network.

Our content testing team has validated and updated this example.

Requirements

This example uses the following hardware and software components: