MPLS FRR Protection Overview > MPLS Protection Background

During network failure, MPLS FRR protects against link or node failure in the path of an RSVP-signaled LSP with local protection at the level of the link or node, and path protection at the level of the entire LSP.

Local Protection

Local protection includes two methods:

• One-to-one (fast reroute) backup is one dedicated detour that protects one LSP.
• Many-to-one (facility) backup is one bypass path that protects many LSPs.

In the Juniper Networks implementation, one-to-one backup corresponds to the fast-reroute statement, while many-to-one (facility) backup corresponds to the link-protection and node-link-protection statements. This implementation is based on RFC 4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels. Local protection is included at the MPLS and RSVP hierarchy levels, as illustrated in the sample output below. It is not recommended that you configure both types of local protection (fast reroute and facility backup) together. They are included together for illustration purposes only.

The following sample output shows the configuration of the fast-reroute statement:

[edit]

protocols {

    mpls {

        label-switched-path lsp-path-name {

            fast-reroute ;

        }

    }

}

The following sample output shows the configuration of link protection (many-to-one or facility backup):

[edit]

protocols {

    rsvp {

        interface type-fpc/pic/port {

            link-protection;

        }

    }

    mpls {

        label-switched-path lsp-path-name {

            link-protection;

        }

    }

}

The following sample output shows the configuration of node-link protection (many-to-one or facility backup):

[edit]

protocols {

    rsvp {

        interface type-fpc/pic/port {

            link-protection;

        }

    }

    mpls {

        label-switched-path lsp-path-name {

            node-link-protection;

        }

    }

}

Local protection in the JUNOS software is described as follows:

• One-to-one (fast reroute) backup—A router upstream from a failure quickly builds a detour LSP around the failure to the router downstream from the failure, providing protection against link or node failure. The upstream router then signals the outage to the ingress router, thereby maintaining connectivity before a new LSP is established. You can configure one-to-one backup by including the fast-reroute statement at the [edit protocols mpls label-switched-path path-name] hierarchy level. For more information about configuring and verifying one-to-one backup, see Configuring and Verifying One-to-One Backup.
• Link protection (many-to-one or facility backup)—Each router establishes a bypass LSP to its neighbor, avoiding the link connecting them, and ensuring traffic flow for the LSP when a link connecting two nodes fails. You can configure many-to-one backup by including the link-protection statement at the [edit protocols mpls label-switched-path path-name] hierarchy level. For more information about configuring and verifying link protection, see Configuring and Verifying Link Protection.
• Node-link protection (many-to-one or facility backup)—Each router dynamically signals a bypass LSP and determines if the protected LSP needs a node bypass or a link bypass, thereby ensuring traffic flow when a node or link in the LSP fails. You can configure node-link protection by including the node-link-protection statement at the [edit protocols mpls label-switched-path path-name] hierarchy level. To enable node-link protection, you must also include the link-protection statement at the [edit protocols rsvp interface interface-name] hierarchy level. For more information about configuring and verifying node-link protection, see Node-Link Protection Overview.

The important difference between using the fast-reroute statement and either of the link-protection statements is that the fast-reroute statement, regardless of whether a link or node fails, always protects one LSP with one detour path. The link-protection and node-link-protection statements always protect any LSPs crossing the node with one bypass path.

There are a couple of things to consider when deciding to configure fast reroute or link protection. The first is interoperability with equipment from other vendors, for example, Cisco Systems supports FRR, but does not support one-to-one backup. The second is that protection paths consume forwarding resources. In this regard, facility backup has better scaling because the protection paths are shared.

Path Protection

Complementary to local protection methods, JUNOS software supports the configuration of path protection with primary and secondary paths. By configuring path protection together with local protection, you can obtain minimum packet loss for an LSP while at the same time maintaining control over the path after the failure.

In the JUNOS software, path protection is included at the MPLS hierarchy level, as illustrated in the sample output below. The sample output shows the primary, secondary, and path statements you must include to an MPLS LSP configuration.

[edit]

protocols {

    mpls {

        label-switched-path lsp-path-name {

            primary path-name;

            secondary path-name {

                standby;

            }

        }

        path path-name {

        }

        path path-name {

        }

    }

}

Path protection in the JUNOS software is described as follows:

• Primary paths—Dictate the physical path for the LSP and are used in normal operations. When not configured and when Constrained Shortest Path First (CSPF) is used, the label-switched router (LSR) determines the path to reach the egress router based on user constraints, such as LSP bandwidth, link color, or other constraints. You can configure primary paths by issuing the primary path-name statement at the [edit protocols mpls label-switched-path path-name] hierarchy level. For an example and more information about configuring and verifying primary paths, see Configuring and Verifying a Primary Path.
• Secondary paths—Become operational when the primary path fails. There are two types of secondary paths: standby and non-standby. A standby secondary path is precomputed and pre-signaled while a non-standby secondary path is precomputed but is not pre-signaled. You can configure secondary paths by issuing the secondary path-name statement at the [edit protocols mpls label-switched-path path-name] hierarchy level. To configure a standby secondary path, include the standby statement at the [edit protocols mpls label-switched-path lsp-path-name secondary] hierarchy level. For an example and more information about configuring and verifying secondary paths, see Configuring and Verifying a Secondary Path.