There are three ways to protect a MPLS TE LSP:
Node and Link protection scale very well because they are local repair and protect multiple LSPs that the LSR is a midpoint.
Path protection does not scale well because for a one to one path protection, the number of path increases at the same rate the number of LSP increases.
Forward Traffic to a TE tunnel
There are many techniques available to forward traffic to a TE tunnel:
- static route
- policy route
- forward adjacency
The main different between autoroute and forward adjacency are:
- both enable the TE tunnel to be considered in SPF, however forward adjacency tunnel is treated as a regular interface, but autoroute tunnel is given a special treatment as follow: SPF built the tree as usual, however when the tail end TE router and all the routers behind the tail end routers is added into the tree (PATH list), the regular next hop is replaced with the tunnel interface.
- Autoroute only affects the headend router, forward adjacency affect all routers in the same SPF domain.
- Forward adjacency does not scale well because every forward adjacency enable tunnel adds an additional link into the IGP topology. For a large network, the number of links could hurt the converge time for IGP or even worse, could be more then the IGP can handle. For a 100 node fully mesh MPLS TE network with forward adjacency, the total number of additional links for the IGP is 100 * 99 = 9,900
Forwarding adjacency is the feature that has the IGP advertise TE tunnels as links.
P routers are able to run IGP adjacencies over these TE tunnels, and thus able to direct packets to these TE tunnels.
Forwarding adjacency allows all nodes in IGP domains too see the TE tunnels and use them in the SPF calculation.
“Autoroute announce” is another method to forward packets into the TE Tunnels. However “Autoroute Announce” only affect the local LSR. It does not announce the TE Tunnels into IGP as links.
You do not want to use “forwarding adjacency” or “autoroute announce” all the time. For example when you want to control exactly what kind of traffic will be routed over the TE tunnel, you do not want to let’s IGP to decide which packets will be routed to the TE tunnel, and thus you do not want to configure “forwarding adjacency”.
Fast ReRoute (FRR)
Fast ReRoute is basically a backup path (LSP) for MPLS TE links and nodes (LSR). It is meant as a temporary solution until a new LSP is built. However if the TE Tunnel has explicit path, the FRR is used until the failed link is repaired.
FRR is fast because the route has been pre-calculated using Constraint SPF. Normally 50mc is used as the standard FRR reroute time, mainly because it is associated with SONET switchover time.
The Head End LSR needs has the option to select whether it desires a local backup using FRR or not.
FRR has two modes:
- FRR Link Protection
- FRR Node Protection
FRR Link Protection
- Next-Hop (NHOP) bypass tunnel: the name of the backup tunnel. It always start from Point of Local Repair (PLR), and always end on the next-hop router, using an alternate path, which is a LSP. As with TE Tunnels (LSP), RSVP TE is used to assigned labels for the NHOP bypass tunnel.
- Merge Point (MP): This is the name of the next-hop router, the remote router at the end of the link on the PLR. It is called MP because it is where the TE protected tunnel and the backup tunnel merge.
- Normally TE Tunnel only has One label. In the event of link failure, the packets that rerouted to the FRR NHOP bypass tunnel will have two labels, the bottom label is for the original TE Tunnel, and a top label is added for the FRR LSP
- When a link failed, the FRR NHOP is meant to be a temporary solution, until the Head End LSR calculates a backup TE Tunnel to replace the original TE Tunnel. The Head End LSP knows about the link failure because the PLR sends a PathErr to the Head End router. Normally when the Head End LSR receives a PathErr message, it would tear down the TE Tunnel and rebuilt a new one. However in the case of FRR, the PathErr went from the PLR also has a message indicating a local repair (FRR) is active.
- The NHOP bypass tunnel becomes the backup for all TE Tunnels that use the link it intended to backup.
- The NHOP bypass tunnel does NOT actually reserve bandwidth. It is possible that not enough bandwidth is available to switch all traffic. Traffic might be dropped as a result.
FRR Node Protection
- FRR Node Protection provide alternate path for a node failure instead of link failure.
- Instead of creating a Backup Tunnel to NHOP LSP, the PLR creates a Backup Tunnel to the Next-Next-Hop LSP (NNHOP). The NNHOP LSP became to Merge-Pointe (MP).
- The PLR needs to know the remote label of NNHOP so that when NNHOP receives the MPLS packet, it know how to switch it. PLR learned these labels from NNHOP because NNHOP would send its labels using RSVP RESERVE message.
Resource Reservation Protocol (RSVP) is a signaling protocol that is used to reserve resource on a network. RSVP with TE Extensions is an enhanced version of RSVP with added feature to work in a MPLS TE network.
Head End LSR uses CSPF to calculation the SPF based on certain constrains, and then use RSVP TE to generate RSVP PATH message to the LSRs that are in the LSP it intends to build all the way to the tail end LSR. The RSVP PATH message job is to check the availability of resources on each hop, and store the information in the packet. It also functions as a label request message. The label request is thus a Downstream-on-Demand (DoD) label distribution model. RSVP PATH message only signal a demand of label, it does not actually map label to LSP, it is the job of RSVP RESERVATION message.
When the Tail End LSR received the RSVP PATH message, it will response with a RSVP RESERVATION message and send it upstream along the LSP to the Head End LSR. The RSVP RESERVATION message job is to actually reverse the LSP (aka TE Tunnel). It also assign label hop by hop until it reaches the Head End LSR.
RSVP TE actually does NOT reserve bandwidth on the data plane. In another word, it does not configure QoS policy on the interface. What it does is keep track of how much bandwidth the TE tunnels have reserved on each interface in the control pane. RSVP TE communicates with IOS Link Manager to keep track of bandwidth reserved for each interface on the router.