Fast Reroute
MPLS TE supports local repair of TE LSPs using FRR. Traffic protection in case of a network failure is critical for real-time traffic or any other traffic with strict packet-loss requirements. In particular, FRR uses a local protection approach that relies on a presignaled backup TE LSP to reroute traffic in case of a failure. The node immediately next to the failure is responsible for rerouting the traffic and is the headend of the backup TE LSP. Therefore, no delay occurs in the propagation of the failure condition, and no delay occurs in computing a path and signaling a new TE LSP to reroute the traffic. FRR can reroute traffic in tens of milliseconds. RFC 4090 describes the operation and the signaling extensions that MPLS TE FRR requires.
Figure 2-8 shows an example of an MPLS network using FRR. In this case, node E signals a TE LSP toward node H. The network protects this TE LSP against a failure of the link between nodes F and G. Given the local protection nature of FRR, node F is responsible for rerouting the traffic into the backup TE LSP in case the link between nodes F and G fails. This role makes node F the point of local repair (PLR). It has presignaled a backup TE LSP through node I toward node G to bypass the potential link failure. The PLR is always the headend of the backup TE LSP. Node G receives the name of merge point (MP) and is the node where the protected traffic will exit the backup TE LSP during the failure and retake the original path of the protected TE LSP.
)
Figure 2-8 MPLS Network Using FRR
MPLS TE FRR introduces a few RSVP extensions for the signaling of the protected TE LSP, as follows:
- A new FAST_REROUTE object defines the characteristics for the backup TE LSP. These characteristics include priorities (setup and holding), hop limit, bandwidth, and attributes. The FAST_REROUTE object also specifies whether nodes should use facility backup or one-to-one backup to protect the TE LSP.
- The extended RECORD_ROUTE object indicates protection availability at each hop and its type (link, node, or bandwidth protection).
- The extended SESSION_ATTRIBUTE object signals whether the TE LSP desires protection and its type (link, node, or bandwidth protection).
Table 2-12 summarizes these extensions.
Table 2-12. RSVP Objects Used for MPLS TE FRR
|
RSVP Object |
RSVP Message |
FRR Function |
|
FAST_REROUTE |
Path |
Specifies the desired FRR technique (facility backup or one-to-one backup) and the desired characteristics (priority, bandwidth, attributes, and so on) of the backup TE LSP |
|
RECORD_ROUTE |
Path, Resv |
Records a list of hops/labels for the protected TE LSP, including protection status and type at each hop |
|
SESSION_ATTRIBUTE |
Path |
Indicates whether the TE LSP requires protection and the type of protection |
MPLS TE FRR can use global or local restoration of the protected TE LSP as a result of a network failure. The global restoration approach relies on the headend rerouting the protected TE LSP. When the failure of a protected facility occurs, the PLR sends a PathErr message toward the headend of the protected TE LSP. In addition to the RSVP notification, the headend may also learn about the failure condition from IGP updates if the failure happens in the same IGP area. When the headend receives the failure notification, it can reroute the protected TE LSP permanently around the failure. When a PLR uses local restoration instead, it reroutes the protected TE LSPs through the backup while the failure persists. When the facility is back in service, the PLR resignals the protected TE LSP through its original path. Global restoration is more desirable as it relies on the headend to re-optimize the protected TE LSP. That node typically has a more complete view of the network resources and TE LSP constraints.
Link Protection
Link protection uses a backup TE LSP destined to the PLR next hop (NHOP). When a node signals a TE LSP with link protection desired, nodes along the path attempt to associate the TE LSP with a backup TE LSP to the NHOP downstream. The backup TE LSP could exist already, or the node may attempt to compute a suitable path and signal it. Any node that finds a TE backup LSP becomes a potential PLR and signals back to the protected TE LSP headend the protection availability at that location using the RECORD_ROUTE object. When a link fails, the PLR reroutes all the identified TE LSPs using the backup TE LSP. The rerouting process involves pushing the protected TE LSP label (as done before the failure) and then stacking the backup TE LSP label on top.
Figure 2-9 illustrates the operation of link protection. Node E signals a TE LSP toward node H, indicating in the SESSION_ATTRIBUTE that the TE LSP desires protection for link failures. When node F processes the object, it finds a suitable backup to the NHOP (node G) through node I. When the link between nodes F and G fails, node F detects the failure locally and modifies the output encapsulation of the protected TE LSP. It continues to push label 35 as expected by the NHOP and, in addition, it pushes label 16 to reroute the traffic through the backup TE LSP. Node I switches the backup TE LSP packets without any knowledge of the protected TE LSP. In this case, node I performs a PHP operation and the packets finally arrive at the MP (node G) with label 35 to continue toward node H.
)
Figure 2-9 MPLS TE FRR Link Protection Operation
Link protection can also protect against the failure of shared-risk link groups (SLRG). In some cases, multiple links in a network have a high probability of failing at the same time. Generally, these SRLGs are the result of multiple links sharing the same underlying infrastructure (Layer 2, Layer 1, or actual physical facilities). The path computation for the backup TE LSP should take into account these SLRGs to avoid using links that could fail at the same time as the protected link. PLRs can learn about SRLGs dynamically from IGP extensions or through local configuration. SRLGs affect the path computation that the PLR may perform the backup TE LSP. However, they do not impact the operation of link protection.
Node Protection
Node protection uses a backup TE LSP destined to the PLR next-next hop (NNHOP). When a node signals a TE LSP with node protection desired, nodes along the path attempt to associate it with a backup TE LSP to the NNHOP downstream. The backup TE LSP could exist already, or the node may attempt to compute a suitable path and signal it. Nodes that find a TE backup LSP become a potential PLR and signal back to the protected TE LSP headend the protection availability at their location using the RECORD_ROUTE object. When the NHOP fails, the PLR reroutes all the identified TE LSPs using the backup TE LSP. The rerouting process involves pushing the protected TE LSP label expected by the NNHOP and then stacking the TE backup LSP label on top. The PLR learns the NNHOP label from the RECORD_ROUTE object in Resv messages. Node protection can also protect against SRLG failures. As described in the previous section, SRLGs affect backup path computation but have no impact on the operation FRR, and in this case, node protection.
Figure 2-10 shows the operation of node protection. Node E signals a TE LSP toward node H, this time indicating in the SESSION_ATTRIBUTE that the TE LSP desires node protection. In this case, node E itself finds a suitable backup to the NNHOP (node G) through nodes B and I. When node F fails, node E detects the failure locally and modifies the output encapsulation of the protected TE LSP. Instead of pushing label 20 as performed before the failure, node E now pushes label 35 as expected by the node G and, in addition, it pushes label 16 to reroute the traffic through the backup TE LSP. Node B and I switch the backup TE LSP packets without any awareness of the protected TE LSP. Packets finally arrive at the MP (node G) with label 35 to continue toward node H.
)
Figure 2-10 MPLS TE FRR Node Protection Operation