Link Protection for FRR

A Label Switched Path (LSP) set up across a MPLS network is used to switch traffic across MPLS network. The path used by an LSP across the network is based upon network resources or any other traffic engineering constraints provided by the user. Based on TE-constraints, the ingress MPLS router computes the path to be taken by LSP and signals it using RSVP protocol.

By nature, nodes and links in a MPLS network are prone to failure. It is likely that the link or the nodes through which LSP is traversing can fail. In the event of a failure of a node or link, RSVP protocol has mechanisms that inform the ingress node about the failure the to ingress node. On receipt of failure message for LSP across the path, the ingress router re-signals the LSP using a new path.

Due to messaging and other network delays, the ingress router cannot respond fast enough to minimalize the loss of traffic. Traffic is lost from the moment the failure occurs and until the new path is setup for the LSP, which is quite large in quantum for service provider networks.

To avoid loss of traffic, Fast Reroute (FRR) protects the LSP and allows a broken LSP to be repaired immediately at the point of failure. The point of failure is termed as "Point of local repair" (PLR), where the LSP can be repaired locally without intimating or waiting for the ingress router. PLR is the MPLS router which detects the failure and redirects the traffic appropriately to its backup path with minimal loss.

Typically at the PLR, two type of protection can be provided to LSP:

Link Protection: In this protection, the backup is selected in such a way that it avoids the failed link which was used earlier by the LSP. Traffic merges back to the main stream from the backup on the very next MPLS router. Refer to following Link protection for FRR illustrating link protection provided at R2 to LSP ingressing from R1 to R4.

Link protection

Node Protection: In this protection, backup is selected in such a way that it avoids the failed link along with router to which this link connects. The node which was responsible for link failure is avoided altogether in its entirety, which was used earlier by the LSP. Traffic merges back to main stream from backup on somewhere downstream from the node, which is being avoided. Refer to Link protection for FRR illustrating node protection provided at R1 to LSP ingressing from R1 to R4.

Node protection

As part of link protection for FRR, ingress routers are allowed to expose this property of MPLS RSVP LSP to the user and lets the user choose between link protection or node protection. Once the node protection is chosen, PLR first tries to establish a backup LSP, which provides node protection. When node protection is not possible, it attempts to fall back to link protection.

When the user chooses link protection over node protection, this is communicated to all routers participating in LSP. Each PLR. in this case. limits its search for backup LSP, which provides link protection. In cases where link protection cannot be offered, PLR falls back to node protection.

Link protection for FRR applies to both one to one protection and many to one FRR protection.

Link protection for FRR provides options to the user to set a preferential method requested for local protection. When RSVP LSP is enabled with FRR (local protection), the user would be able to configure either link protection or node protection. Node protection remains the default.

Configuration steps for adaptive and non-adaptive LSPs have inherent differences on their make-before-break capabilities. The default behavior for both types of LSPs remains node protection.

Configuring protection type preference for Adaptive LSPs

Because adaptive LSPs TE-property can be changed without restarting LSP and changed values takes effect through the make-before-break process, you are allowed to change the protection type preference (node protection to link protection or link protection to node protection) at any point of time during life cycle of adaptive LSPs, irrespective of its administrative or operational state. When you change the preferential protection type and it commits to the configuration, configuration takes effect. Signaling of the changed property depends on the state of LSP. For example, when the administrator is UP or DOWN, it is operationally UP or DOWN. There is no change in the MBB trigger because of link protection for FRR. All MBB aspects including, but not limited to, implicit and explicit commits remain unchanged.

Table 1. Protection types for adaptive LSPs

Requesting Node Protection			Requesting Link Protection
	Earlier Request: Link protection.	Earlier Request: Node protection.	Earlier Request: Link protection.	Earlier Request: Node protection.
Adaptive LSP	LSP requests node protection on next commit operation.	No change	No change	LSP requests link protection on next commit operation.
Non-Adaptive disabled LSP	LSP requests node protection once the user enables LSP.	No change	No change	LSP requests link protection once the user enables LSP.

Note

If the user tries to configure link protection for FRR on a non-adaptive enabled LSP, the following error is displayed:

Error: Must disable lsp before changing parameters