Preservation Of An Established Lsp Label; Rsvp-Te Hellos Based On Node Ids Overview - Juniper JUNOSE SOFTWARE FOR E SERIES 11.3.X - BGP AND MPLS CONFIGURATION GUIDE 2010-10-12 Configuration Manual

Preservation of an Established LSP Label

Related
Documentation

RSVP-TE Hellos Based on Node IDs Overview

Copyright © 2010, Juniper Networks, Inc.
the path message as usual. Otherwise, the restarting router examines the path message
for the recovery_label object. If the recovery_label object is not found, the restarting router
treats the path message as a setup request for a new LSP and handles the path message
as usual.
If the recovery_label object is found, the restarting router searches for the outgoing label
based on the incoming interface and incoming label that are specified in the recovery_label
object. If the restarting router does not find a match for the forwarding entry, the restarting
router treats the path message as a setup request for a new LSP. If the restarting router
finds a match, it conveys to the downstream neighbors the outgoing label associated
with the forwarding entry in the suggested_label object in the path message and it
continues normal operations.
The helper router removes the stale flag for the RSVP-TE state when it receives the
corresponding state in path or resv messages sent by the restarting router. When the
recovery period expires, the helper router deletes any RSVP-TE states that still have a
stale flag. Graceful restart is considered to be complete when the recovery period expires
or when the last LSP needing recovery is recovered.
Labels used for an established LSP are preserved through the graceful restart by means
of the recovery_label object and the suggested_label object in the path messages. The
recovery_label object conveys the incoming label of the restarting LSR that the restarting
LSR passed to the upstream helper before the restart. The suggested_label object includes
the outgoing label that the restarting LSR used before the restart. The suggested_label
object conveys the outgoing label from the restarting LSR to its downstream neighbor.
Configuring RSVP-TE Graceful Restart on page 299
For interoperability with routers that cannot support RSVP-TE graceful restart with
link-based hellos, you can use the mpls rsvp signalling node-hello command to configure
the exchange of node-ID–based RSVP-TE hellos (node hellos). E Series routers use node
hellos only to support their graceful restart capabilities.
NOTE: Node hellos are not required for RSVP-TE graceful restart support
between routers running JunosE Software or for interoperability with routers
running Junos OS.
Graceful restart must be enabled for node hellos to advertise graceful restart. Link-based
hellos are not required for graceful restart when you have configured node hellos. However,
you might still use link-based hellos to monitor RSVP-TE links and detect link failures.
The node hello sessions are established by the exchange of hello messages in which
node IDs are used for the source and destination addresses in the hello packets. The
Chapter 3: MPLS Overview
265