Head-End FIGURE 13.15 RSVP signaled tunnels. Network Core Traffic moved initially to backup tunnel (FRR) Head-End Point of Local Repair Later moved to Optimized tunnel FIGURE 13.16 FRR and hitless rearrangement. tables instructing each node to perform a label push, swap, or pop function. The specific label bind- ings to be used by each node are communicated in the RSVP signaling messages. Each node in the core is instructed to create backup tunnels for each link. A link is an adjacency between a pair of nodes. In Figure 13.15, we show a backup tunnel created for the link between B and C. It is not shown, but there would be other tunnels also using the link between B and C-for example, the tunnel from E to D would also use this link. The backup tunnel protects all of the tun- nels that are using a given link. The backup tunnel is created automatically by the node using its routing protocol and RSVP. Each node finds the lowest cost alternate path (that obviously excludes the link being protected) with the con- straint that none of the fiber supporting the links in the backup tunnel share common resources* with the fiber supporting the link being protected. Through an offline process that draws on detailed fiber routing databases, we define shared risk link groups (SRLGs) to identify the pools of links that have diversity violations and we download that information into each core router. In the example, the link B-X-C would have been lower cost but was not chosen to avoid the possibility of coincident failures. With node B having established the backup tunnel using RSVP signaling messages, nodes E, F, and C create label bindings in their forwarding tables that implement the backup LSP. The rules are active, but as long as B is forwarding traffic to C they sit quietly unused. Node B creates the binding to direct traffic to E but for now while the link between B and C is healthy, it sits idle. Figure 13.16 illustrates the responses of the network to a link failure. When the link between nodes B and C is lost, node B d