Juniper LDP Overview
Juniper LDP Overview
Juniper LDP Overview
LDP Overview
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.
295
JUNOS 7.0 MPLS Applications Configuration Guide
LDP Standards
LDP is described in the following RFC and Internet draft:
The JUNOS software supports the required elements of RFC 3036, except the
following:
loop detection
CR-LDP
The RFC establishes three modes that the JUNOS software only partially
supports:
To access Internet RFCs and drafts, go to the IETF Web site at http://www.ietf.org/.
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 Border Gateway Protocol (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.
For LDP to run on an interface, MPLS must be enabled on a logical interface on that
interface. For more information, see the JUNOS Netw ork Interf aces and Class of
Service Configur ation Guide .
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 Open Shortest
Path First (OSPF) areas and Intermediate System-to-Intermediate System (IS-IS)
levels in the traffic engineered core and in the surrounding LDP cloud.
Label Operations
Figure 23 depicts an LDP LSP being tunneled through an RSVP LSP. (For definitions
of label operations, see “Label Description” on page 26.) The shaded inner oval
represents the RSVP domain, whereas the outer oval depicts the LDP domain. RSVP
establishes an LSP through routers B, C, D, and E, with the sequence of labels L3,
L4. LDP establishes an LSP through routers A, B, E, F, and G, with the sequence of
labels L1, L2, L5. LDP views the RSVP LSP between routers B and E as a single hop.
When the packet arrives at Router A, it enters the LSP established by LDP, and a
label (L1) is pushed onto the packet. When the packet arrives at router B, the label
(L1) is swapped with another label (L2). Because the packet is entering the
traffic-engineered LSP established by RSVP, a second label (L3) is pushed onto the
packet.
This outer label (L3) is swapped with a new label (L4) at the intermediate router (C)
within the RSVP LSP tunnel, and when the penultimate router (D) is reached, the
top label is popped. Router E swaps the label (L2) with a new label (L5), and the
penultimate router for the LDP-established LSP (F) pops the last label.
Figure 23: Swap and Push When LDP LSPs Are Tunneled through RSVP LSPs
F
LDP
E
C (no label)
L4 L2 IP L5 IP G
A B
D
L2 IP
L1 IP L3 L2 IP L2 IP
RSVP
1402
Figure 24 depicts double push label operation (L1L2), which is used when the
ingress router (A) of the LDP and the RSVP are the same router. Note that router D is
the penultimate hop for the LDP-established LSP, so L2 is popped from the packet
by router D.
Figure 24: Double Push When LDP LSPs Are Tunneled through RSVP LSPs
B RSVP D
A L3 L2 IP (no label) E
L1 L2 IP L2 IP
C
1403
LDP
Discovery Messages
Discovery messages announce and maintain the presence of a router in a network.
Routers indicate their presence in a network by sending the hello message
periodically. This hello message is transmitted as a UDP packet to the LDP port at
the group multicast address for all routers on the subnet.
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 Transmission Control Protocol
(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 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:
During session initialization, a router advertises its ability to perform LDP graceful
restart or to take advantage of a neighbor performing LDP graceful restart by
sending the graceful restart type length value (TLV). This TLV contains two fields
relevant to LDP graceful restart: the reconnect time and the recovery time. The
values of the reconnect and recovery times indicate the graceful restart capabilities
supported by the router.
The reconnect time is configured in the JUNOS software as 60 seconds and is not
user-configurable. When a router discovers that a neighboring router is restarting, it
waits until the end of the recovery time before attempting to reconnect. The
recovery time is the amount of time a router waits for LDP to restart gracefully. The
recovery time period begins when an initialization message is sent or received. This
time period is also typically the amount of time that a neighboring router maintains
its information about the restarting router, allowing it to continue to forward traffic.
You can configure LDP graceful restart in both the master instance for the LDP
protocol and for a specific routing instance. You can disable graceful restart at the
global level for all protocols, at the protocol level for LDP only, and on a specific
routing instance. LDP graceful restart is disabled by default, because at the global
level graceful restart is disabled by default. However, helper mode (the ability to
assist a neighboring router attempting a graceful restart) is enabled by default.
The following are some of the behaviors associated with LDP graceful restart:
Outgoing labels are not maintained in restarts. New outgoing labels are
allocated.
Helper mode and graceful restart are independent. You can disable graceful
restart in the configuration, but still allow the router to cooperate with a
neighbor attempting to restart gracefully.