LDP GR Mechanism for Downstream On-Demand Mode 213
LDP GR Mechanism for Downstream On-Demand Mode
The previous section described LDP GR mechanism for the downstream unsolicited label
distribution mode.
This section describes the LDP GR mechanism for downstream on-demand
label distribution by drawing on the concepts of the previous section.
To avoid repetition of information already described in the previous section, the following
discussion first summarizes LDP GR procedures that are common to both modes. It then
describes those procedures that are specific to the downstream on-demand label distribution
LDP GR Common Procedures
During the initial LDP session establishment (before the LDP control-plane restart), an LSR
that supports LDP GR downstream on-demand procedures advertises its NSF capability to its
peers by setting the appropriate fields in the FT Session TLV. For example, the sender sets the
L (learn from network) flag to 1 to select the LDP GR mechanism and sets the FT Reconnection
Timeout to the estimated time that is required for the LSR to reestablish an LDP session with
the peer.
When the LDP control-plane component on an LSR restarts, the restarting LSR loses LDP
sessions with its peers and the associated LDP state, but the LSR preserves the MPLS
forwarding state across the restart. The restarting LSR continues to forward data traffic using
the preserved MPLS forwarding state across the restart. After restarting, the restarted LSR
checks whether it has preserved the MPLS forwarding state across the restart. If so, the
restarting LSR starts the MPLS Forwarding State Holding Timer and marks the preserved
MPLS forwarding state information as stale. If the stale MPLS forwarding state is not refreshed
before the MPLS Forwarding State Holding Timer expires, it is removed. While its MPLS
forwarding state is running, the restarting LSR recovers the required LDP state and updates the
stale MPLS forwarding state. Therefore, the recovery period begins when the MPLS Holding
Timer starts and ends when it expires. This means that the restarting LSR must be able to
recover the required LDP state and update the stale MPLS forwarding state within the recovery
period. The exact behavior of a restarting LSR depends on whether the LSR is an ingress,
transit, or egress LSR for the LSP (as described later).
Following LDP control-plane restart in a peer, a nonrestarting LSR detects failure of an LDP
downstream on-demand session with the restarting peer. If the restarting peer has advertised a
nonzero value for the FT Reconnect Timeout (indicating that it is NSF-capable), the nonre-
starting LSR starts the Neighbor Liveness Timer, marks LDP state for established LSPs as stale,
and waits for the session reestablishment. While waiting, the peer continues to retain and use
stale forwarding state information. The nonrestarting LSR is expected to retain its stale MPLS
forwarding information for a minimum duration equal to lesser of Neighbor Liveness Timer and
the FT Reconnect Timeout advertised by the restarting neighbor.

Get Fault-Tolerant IP and MPLS Networks now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.