Associated Bidirectional CR-LSP

Associated bidirectional CR-LSPs provide bandwidth protection for bidirectional services. Bidirectional switching can be performed for associated bidirectional CR-LSPs if faults occur.

Background

MPLS networks face the following challenges:

RSVP tunnels that transmit TE services are unidirectional. The ingress forwards services to the egress along an MPLS TE tunnel. The egress forwards services to the ingress over IP routes. As a result, the services may be congested because IP links do not reserve bandwidth for these services.
Two MPLS TE tunnels in opposite directions are established between the ingress and egress. If a fault occurs on an MPLS TE tunnel, a traffic switchover can only be performed for the faulty tunnel, but not for the reverse tunnel. As a result, traffic is interrupted.

If a pair of MPLS TE CR-LSPs in opposite directions is established between two nodes and each CR-LSP is bound to the ingress of its reverse LSP, the two LSPs form an associated bidirectional CR-LSP. The associated bidirectional LSP is configured to prevent traffic congestion. If a fault occurs on one end, the other end is notified of the fault so that both ends trigger traffic switchovers, preventing service interruptions.

Implementation

Figure 1 shows how an associated bidirectional CR-LSP is established. Tunnel 1 and Tunnel 2 are established in opposite directions and bound to each other. The implementation of an associated bidirectional CR-LSP is as follows:

Tunnel 1 and Tunnel 2 must both be MPLS-TE tunnels. They can be either dynamic LSPs established using RSVP-TE or static LSPs manually configured.
The tunnel ID and ingress LSR ID of the reverse CR-LSP are specified on each tunnel interface so that the forward and reverse CR-LSPs are bound to each other. A reverse LSP must be specified for both the ingress and egress of a tunnel. In addition, the binding relationships must match each other. For example, in Figure 1, set the reverse tunnel ID to 200 and ingress LSR ID to 4.4.4.4 on Tunnel 1 so that the reverse tunnel is bound to Tunnel 1.

The ingress LSR ID of the reverse CR-LSP is the same as the egress LSR ID of the forward CR-LSP.
Penultimate hop popping (PHP) is not supported on associated bidirectional CR-LSPs.

The forward and reverse CR-LSPs can be established over the same path or over different paths. Establishing the forward and reverse CR-LSPs over the same path is recommended to implement the consistent delay time.

Figure 1 Associated bidirectional CR-LSP

Application Scenarios

An associated bidirectional static CR-LSP transmits services and returned OAM packets on MPLS-TP networks.
An associated bidirectional dynamic CR-LSP is used on an RSVP-TE network when bit-error-triggered switching is used.