Preservation Of An Established Lsp Label; Rsvp-Te Hellos Based On Node Ids Overview - Juniper JUNOSE 11.2.X BGP AND MPLS Configuration Manual

For e series broadband services routers - bgp and mpls configuration
Table of Contents

Advertisement

Preservation of an Established LSP Label

Related Topics

RSVP-TE Hellos Based on Node IDs Overview

Copyright © 2010, Juniper Networks, Inc.
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 298
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
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
Chapter 3: MPLS Overview
265

Advertisement

Table of Contents
loading

This manual is also suitable for:

Junose 11.2.x

Table of Contents