MPLS Fast Reroute

MPLS fast reroute (FRR) involves the following:

• FRR link protection enables you to preconfigure a backup LSP at any point along a tunnel path, which the traffic will use if a link failure occurs on the protected LSR. Without FRR, in case of a link failure, the tunnel headend must learn of the problem, run a new CBR calculation, and provision a new tunnel using RSVP before traffic can be forwarded again.

• Figure B-5 shows FRR in operation. The primary tunnel Tu0 is between R1 and R5. Suppose a link failure occurs between R2 and R3. R2 implements FRR by imposing a new label, 17, that corresponds to backup tunnel, Tu10, which goes through R4. Just as with a normal tunnel, the label is popped at the penultimate LSR, thus revealing the original label and allowing the packet to be threaded back into the original LSP, as shown in Figure B-5. R1 is notified of the failure by R2 and can provision a new LSP along an alternative path. If it does not, traffic is forwarded along the backup LSP. Note that R3 is unaware of the entire FRR operation.

  Figure B-5. FRR Link Protection

  

FRR also offers node protection, which is more complex. Look at Figure B-6 and imagine that node R3 fails. Node R2 detects this and forwards traffic across the backup LSP, Tu10. However, the subtlety is that router R5 needs to see the same label as before the failure so that it can forward traffic along the correct LSP. R2 has to know which label R5 was expecting (16 in the case of Figure B-6) and push that value on the label stack as it sends the packet across the backup tunnel. In either case, if failure detection is quick enough, FRR can allow subsecond network reconvergence.

Figure B-6. FRR Node Protection

Note

Figure B-6 is a modification from the "Advanced Topics in MPLS-TE Deployment" white paper at http://www.cisco.com/.

Although we did not go into detail here, MPLS-TE supports the notion of priority and preemption. Low-priority tunnels can be removed to free up bandwidth for higher-priority tunnels.