Cisco Cisco IOS Software Release 12.2(33)SRE

You must configure RSVP on one or more interfaces on at least two neighboring routers that share a link 
within the network.

RSVP FLR applies only when RSVP is used to set up resource reservations for IPv4 unicast flows; 
IPv4 multicast flows are not supported.

RSVP FLR does not apply to traffic engineering (TE) tunnels and, therefore, does not affect TE 
sessions.

RSVP FLR does not support message bundling.

To use the RSVP FLR feature, you should understand the following concepts:

RSVP FLR provides for dynamic adaptation when routing changes occur. When a route changes, the 
next PATH and RESV message refreshes establish path and reservation states along the new route.  
Depending on the configured refresh interval, this reroute happens in tens of seconds. However, during 
this time, the QoS of flows is not guaranteed because congestion may occur while data packets travel 
over links where reservations are not yet in place.

In order to provide faster adaptation to routing changes, without the overhead of a refresh period, RSVP 
registers with the routing information base (RIB) and receives notifications when routes change, thereby 
triggering state refreshes for the affected destinations. These triggered refreshes use the new route 
information and, as a result, install reservations over the new path.

When routes change, RSVP has to reroute all affected paths and reservations. Without FLR, the reroute 
happens when refresh timers expire for the path states. With real time applications such as VoIP and VoD, 
the requirement changes and the reroute must happen quickly, within three seconds from the triggering 
event such as link down or link up.

 illustrates the FLR process.