Bfd Protocol And Rsvp-Te Overview - Juniper JUNOSE SOFTWARE FOR E SERIES 11.3.X - BGP AND MPLS CONFIGURATION GUIDE 2010-10-12 Configuration Manual

JunosE 11.3.x BGP and MPLS Configuration Guide
Related
Documentation

BFD Protocol and RSVP-TE Overview

266
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.
Node-based hellos are an attractive alternative to link-based hellos for graceful restart
when you use bidirectional forwarding detection (BFD) for link monitoring and you have
configured node-based hellos on all RSVP-TE peers.
Link-based RSVP-TE hellos are used for monitoring RSVP-TE adjacencies with neighboring
routers and for providing RSVP-TE graceful restart. However, the BFD protocol is more
effective at monitoring RSVP-TE adjacencies than are link-based hellos.
Link-based RSVP-TE hellos for graceful restart are more resource-intensive option than
node-based RSVP-TE hellos when your configuration has several interfaces enabled
with MPLS RSVP-TE and carrying RSVP-TE data traffic. Link-based hellos generate a
volume of network traffic and processing overhead that is directly proportional to the
number of interfaces that are carrying active RSVP-TE tunnels.
Node-based hellos require less messaging and processing overhead in these
circumstances. Node hellos require only a single hello session between the two node IDs,
compared to link-based hellos that have hello sessions between all interface pairs. Less
traffic and overhead result in a lesser impact on scaling.
Node-based hellos can therefore be advantageous even when you are interoperating
with routers that are running JunosE Software or Junos OS, if you are using BFD to monitor
your RSVP-TE links. If you are not using BFD, then you must use link-based hellos for link
monitoring, and link-based hellos then become more practical for graceful restart.
Configuring RSVP-TE Hellos Based on Node IDs on page 299
The Bidirectional Forwarding Detection (BFD) protocol uses control packets and shorter
detection time limits to more rapidly detect failures in a network. Also, because they are
adjustable, you can modify the BFD timers for more or less aggressive failure detection.
Without BFD, RSVP-TE can learn about adjacency failures by either of two methods. If
RSVP-TE hellos are configured, then hello message timeouts indicate a failure. If hellos
are not configured, then RSVP-TE learns about failures from resv and path messages.
Copyright © 2010, Juniper Networks, Inc.