Graceful Restart Mechanism for Label Distribution Protocol
Extracted elements (24)
An alternative restart procedure (Section 3.2) is described for LSRs that have at least as many unallocated as allocated labels. During restart, these LSRs create new label bindings via normal LDP, potentially holding two bindings per FEC simultaneously (old stale + new); both share the same outgoing label and next hop, and the stale one is deleted on restart completion.
LSRs that cannot preserve MPLS forwarding state across restart still benefit from implementing a subset of this mechanism, because their neighbors who can preserve state will be able to minimize traffic disruption. Supporting the mechanism is thus useful even for non-preserving LSRs.
The mechanism makes minimalistic assumptions: only the actual MPLS forwarding state (incoming label to outgoing label/next-hop mappings) must be preserved across restart; no LDP-related state needs to be preserved. This is the minimum required not to perturb LSPs traversing a restarting LSR.
The procedures in this document apply only to downstream unsolicited label distribution. Extending these graceful restart procedures to downstream on-demand label distribution is explicitly left for further study.
After releasing a label, an LSR SHOULD NOT re-use that label for advertising a <label, FEC> binding to a graceful-restart-capable neighbor for at least the sum of the FT Reconnect Timeout plus Recovery Time as advertised by that neighbor. This prevents mis-routing from premature label reuse.
After restarting, an LSR MUST check whether it was able to preserve its MPLS forwarding state. If not, the LSR sets Recovery Time to 0 in the FT Session TLV sent to neighbors.
If a session is re-established and the neighbor indicates it did not preserve forwarding state (Recovery Time = 0), the LSR SHOULD immediately delete all stale label-FEC bindings received from that neighbor. If forwarding state was preserved (non-zero Recovery Time), the LSR SHOULD keep stale bindings for the lesser of the Recovery Time and the local Maximum Recovery Time.
Once an LSR creates a <label, FEC> binding, it SHOULD keep that label value as long as it has a route to the FEC. To minimize mis-routing from label reuse, when assigning a new label the LSR SHOULD pick the least recently used label.
The L (Learn from Network) flag in the FT Session TLV MUST be set to 1 to indicate that the LDP Graceful Restart procedures defined in this document are in use. All other FT flags are set to 0 by the sender and ignored on receipt.
The LSR SHOULD complete the exchange of label mapping information with a restarted neighbor within 1/2 of the Recovery Time advertised in the neighbor's FT Session TLV.
The MPLS Forwarding State Holding timer value SHOULD be configurable. At expiration, all entries still marked as stale SHOULD be deleted.
The Recovery Time SHOULD be long enough to allow neighboring LSRs to re-sync all LSPs in a graceful manner without creating congestion in the LDP control plane.
When an LSR detects that an LDP session with a neighbor went down, and the neighbor had advertised FT capability, the LSR SHOULD retain the label-FEC bindings received over that session (marking them stale) rather than discarding them immediately, to allow graceful re-synchronization.
An LSR signals LDP Graceful Restart capability by including the Fault Tolerant (FT) Session TLV as an Optional Parameter in the LDP Initialization message. The TLV carries two key fields: FT Reconnect Timeout and Recovery Time, both in milliseconds.
For a non-egress restarting LSR receiving a Label Mapping message with a non-Implicit-NULL label, the LSR searches for a forwarding state entry with matching outgoing label and next hop. If found, the entry is un-marked as stale and the incoming label is re-associated with the received FEC and re-advertised to neighbors.
For a restarting egress LSR configured to generate a non-NULL label, the LSR searches for a Label-pop forwarding entry with a next hop matching the FEC's next hop. If found, the entry is un-marked as stale and the incoming label is re-advertised. If the LSR generates a NULL label for a FEC, it simply re-advertises that NULL label via LDP.
For a restarting LSR acting as penultimate hop (Implicit NULL received), the LSR searches for a forwarding entry indicating Label pop with matching next hop. If found, the entry is un-marked as stale, the incoming label is associated with the FEC, and advertised to neighbors.
The FT Reconnect Timeout specifies how long (in ms) the receiver of the TLV should wait after detecting LDP communication failure before discarding preserved MPLS forwarding state for LSPs traversing the link. A value of 0 means the sender will not preserve forwarding state but still supports Section 3.3 procedures.
The Neighbor Liveness Timer is a local, configurable timer started when an LDP session with a neighbor goes down. Stale label-FEC bindings are kept for the lesser of the FT Reconnect Timeout advertised by the neighbor and the Neighbor Liveness Timer; if no session is re-established in this window, stale bindings SHOULD be deleted.
The Recovery Time field in the FT Session TLV specifies how long (in ms) a restarting LSR will retain its preserved MPLS forwarding state after sending the post-restart Initialization message. A value of 0 means forwarding state was not preserved (or is no longer available).
When handling Label Mapping messages from a restarted neighbor, the LSR treats stale LIB entries as if received over the new session. If the received binding matches a stale entry exactly, the stale mark is cleared. If the label differs from the stale entry, the LIB is updated with the new label.
An intruder impersonating an LDP peer can force TCP session failure and reconnect with Recovery Time set to 0, causing all previously received labels to be released. Similarly, an intruder intercepting traffic between peers can override Recovery Time to 0 in the FT Session TLV. Both attacks are countered by MD5-based or other peer authentication as outlined in the base LDP specification.
Continuing to use labels after session expiry creates a mis-routing risk: if the upstream LSR detects session failure after the downstream LSR has released and re-used the label, traffic may be sent to unintended destinations. This vulnerability is exacerbated by the Reconnect Timeout, which extends the period of valid-but-stale label use. To reduce this risk, the document requires labels not be re-used for at least Reconnect Timeout plus Recovery Time.
Upon preserving forwarding state, the restarting LSR starts an MPLS Forwarding State Holding timer and marks all forwarding state entries as 'stale'. The LSR is 'in the process of restarting' while the timer runs; it 'completes restart' when the timer expires. At expiry, all entries still marked stale SHOULD be deleted.