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

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.

Preservation of an Established LSP Label

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.

RSVP-TE Hellos Based on Node IDs

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
software.
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
sending router uses its local node ID as the source address and the remote node ID
of the receiving router as the destination address.
RSVP-TE uses the configured IGP, IS-IS or OSPF, to learn the local and remote node
IDs. In IS-IS, the node ID is the TE router ID as defined in the traffic engineering
router ID TLV for IPv4 addresses and in the IPv6 TE Router_ID for IPv6 addresses.
In OSPF, the node ID is the TE router ID as defined in the router address TLV for
IPv4 addresses and in the Router_IPv6_Address for IPv6 addresses. Only one
node-based RSVP-TE hello session can be established for each instance of an IGP
adjacency with a peer.
When a router receives a hello message where the destination address is set to the
receiving router's local node ID, the router verifies that the node ID is the ID that the
IGP advertises. This router must then use its local node ID as the source address
when it replies to the sending router.
Chapter 2: MPLS Overview
RSVP-TE Hellos Based on Node IDs
251