Fast Reroute Overview
Fast rerouting is accomplished by precomputing and preestablishing a number of detours along the LSP.
When you enable fast reroute for an LSP, a number of detours along the LSP are precomputed and preestablished. In case of a network failure on the current LSP path, the traffic is quickly routed to one of the detours. Figure 16 illustrates an LSP from Router A to Router F, showing some of the detours that are established for the LSP. Each detour is established by an upstream node with the intent of avoiding the link toward the immediate downstream node and the immediate downstream node itself. Each detour might traverse through one or more label-switched routers that are not shown in the figure.
If a node detects that a downstream link has failed (using a link-layer-specific liveness detection mechanism) or that a downstream node has failed (for example, using the RSVP neighbor hello protocol), the node quickly switches the traffic to the detour and, at the same time, signals the ingress router about the link or node failure. Figure 17 illustrates the detour taken when the link between Router B and Router C fails.
If the network topology is not rich enough (insufficient routers with insufficient links to other routers), some of the detours might not succeed. For example, the detour from Router A to Router C in Figure 16 cannot traverse link A-B and Router B. If such a path is not possible, the detour does not occur.
Note that after the node switches traffic to the detour, it might switch the traffic again to a newly calculated detour soon after. The initial detour route might not be the best route. Rather than verifying whether it is currently valid, the node simply switches traffic onto that route. After the node switches traffic to the initial detour, it recomputes the detour. If the node determines that the initial detour is still valid, traffic continues to flow over this detour. If the node determines that the initial detour is no longer valid, it again switches the traffic to the newly computed detour.
The time required for a fast-rerouting detour to take effect depends on two independent time intervals:
- Amount of time to detect that there is a link or node failure—This interval depends greatly on the link layer in use and the nature of the failure. For example, failure detection on an SDH/SONET link typically is much faster than on a Gigabit Ethernet link, and both are much faster than detection of a router failure.
- Amount of time required to splice the traffic onto the detour—This operation is performed by the Packet Forwarding Engine (PFE), which requires little time to splice traffic onto the detour. The time needed can vary depending on the number of LSPs being switched to detours.
Fast reroute is a short-term patch to reduce packet loss. Because detour computation might not reserve adequate bandwidth, the detours might introduce congestion on the alternate links. The ingress router is the only router that is fully aware of LSP policy constraints and, therefore, is the only router able to come up with adequate long-term alternate paths.
Fast reroute protects traffic against any single point of failure between the ingress and egress routers. If there are multiple failures along an LSP, it is possible that fast reroute itself might fail. Also, fast reroute does not protect against failure of the ingress or egress routers.
Detours are created by use of RSVP and, like all RSVP sessions, they require extra state and overhead in the network. For this reason, each node establishes at most one detour for each LSP that has fast reroute enabled. Creating more than one detour for each LSP increases the overhead, but serves no practical purpose.
To reduce network overhead further, each detour attempts to merge back into the LSP as soon as possible after the failed node or link. If you can consider an LSP that travels through n router nodes, it is possible to create n - 1 detours. For instance, in Figure 18, the detour tries to merge back into the LSP at Router D instead of at Router E or Router F. Merging back into the LSP makes the detour scalability problem more manageable. If topology limitations prevent the detour from quickly merging back into the LSP, detours merge with other detours automatically.
