RSVP FLR provides for dynamic adaptation when routing changes occur in global or VRF routing domains. 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.
The figure below illustrates the FLR process.
Figure 1. Overview of RSVP FLR
Initial RSVP states are installed for an IPv4 unicast flow over devices A, B, C, D, and E. Device A is the source or headend, while device E is the destination or tailend. The data packets are destined to an address of device E. Assume that a route change occurs, and the new path taken by the data packets is from device A to device B to device F to device D to device E; therefore, the old and new paths differ on the segments between device B and D. The device B to device C to device D segment is the old segment, while the device B to device F to device D segment is the new segment.
A route may change because of a link or node failure, or if a better path becomes available.
RSVP at device B detects that the route change affects the RSVP flow and initiates the FLR procedure. The node that initiates an FLR repair procedure, device B in the figure above, is the point of local repair (PLR). The node where the new and old segments meet, device D in the figure above, is the merge point (MP). The interfaces at the PLR and the MP that are part of the old segment are the old interfaces, while the interfaces that are part of the new segment are the new interfaces.
If a route has changed because of a failure, the PLR may not be the node that detects the failure. For example, it is possible that the link from device C to device D fails, and although device C detects the failure, the route change at device B is the trigger for the FLR procedure. device C, in this case, is also referred to as the node that detects the failure.
The support for FLR in VRF domains means that RSVP can get a route change notification, even if there is a route change in any VRF domains, as RSVP FLR was previously supported only in the global routing domain.