Fault-Tolerant IP and MPLS Networks

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.

7

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

mode.

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.