This section provides an overview of the association signaling methods for the bidirectional LSPs. Two unidirectional LSPs can be bound to form an associated bidirectional LSP in the following scenarios:

• No unidirectional LSP exists, and both must be established.

• Both unidirectional LSPs exist, but the association must be established.

• One unidirectional LSP exists, but the reverse associated LSP must be established.

This section provides an overview of associated bidirectional co-routed LSPs. Establishment of MPLS TE-LSP involves computation of a path between a head-end node to a tail-end node, signaling along the path, and modification of intermediate nodes along the path. The signaling process ensures bandwidth reservation (if signaled bandwidth is lesser than 0 and programming of forwarding entries).

Path computation is performed by the head-end nodes of both the participating LSPs using Constrained Shortest Path First (CSPF). CSPF is the 'shortest path (measured in terms of cost) that satisfies all relevant LSP TE constraints or attributes, such as required bandwidth, priority and so on.

Associated Bidirectional Co-routed LSPs: A co-routed bidirectional TE LSP denotes a bidirectional tunnel where the forward direction LSP and reverse direction LSP must follow the same path, for example, the same nodes and paths. Here is an illustration.

In the above topology:

• Paths at the top of the figure (in green) indicate working co-routed LSP pairs.

• Paths at the bottom of the figure (in red) indicate protecting co-routed LSP pairs.

• Router 1 sets up working LSP to Router 3 (in green) after performing bidirectional CSPF and sends reverse explicit route object (ERO) to Router 3. Node Router 3 uses the received reverse ERO to set up reverse green working LSP to Router 1.

• Router 3 sets up protecting LSP to Router 1 (in red) after performing bidirectional CSPF and sends reverse ERO to Router 1. Node Router 1 uses the received reverse ERO to set up reverse red protecting LSP to Router 3.

• Exp-null over Flex-LSP is not supported.

• 50 msec convergence is not guaranteed without WRAP protection. WRAP protection is mandatory to achieve 50 msec convergence for remote failures.

• TE NSR and IGP NSR are mandatory for RSP switchover.

• VPLS over Flex-LSP is not supported.

• Non-co routed Flex LSP is not supported.

• Sub interface shut will not guarantee 50 msec convergence.

• MPLS forwarding table stats is not supported.

• 1000 tunnels are supported with wrap protection and path protection.

Following list outlines key features supported:

• Protection -

  Following Protection features are supported:

  • Lockout: Using Lockout feature, user can perform lockout protection on a selected LSP and can switch traffic to protecting LSP, if the selected LSP carries the traffic. LSP on locked out interface remains up but no traffic flows on the locked out path. To configure lockout under an MPLS-TE enabled interface:

    
    RP/0/RP0/CPU0:router# configure
    RP/0/RP0/CPU0:router(config)# mpls traffic-eng
    RP/0/RP0/CPU0:router(config-mpls-te)# interface tenGigE0/1/0/1
    RP/0/RP0/CPU0:router(config-mpls-te-if)# fault-oam lockout

  • Wrap Protection: Using Wrap Protection, each LSP signals unique wrap label for head-end to identify lookback traffic and sends it over protect LSP. To configure Wrap Protection:

    
    RP/0/RP0/CPU0:router# configure
    RP/0/RP0/CPU0:router(config)# interface tunnel-te1
    RP/0/RP0/CPU0:router(config-if)# ipv4 unnumbered Loopback0
    RP/0/RP0/CPU0:router(config-if)# destination 49.49.49.2
    RP/0/RP0/CPU0:router(config-if)# path-option 10 explicit name PATH1-2-3 
    RP/0/RP0/CPU0:router(config-if)# bidirectional association id 100 source-address 49.49.49.2
    RP/0/RP0/CPU0:router(config-if)# bidirectional association association type co-routed
    RP/0/RP0/CPU0:router(config-if)# wrap-protection
    RP/0/RP0/CPU0:router(config-if)# fault-oam 
    

• MPLS-OAM: MPLS-OAM supports single segment pseudowire going over the associated bidirectional TE tunnels. This support includes pseudowires signaled dynamically, statically, or using a mix of both modes. To configure MPLS-OAM, use the following command:

  
  RP/0/RP0/CPU0:router# configure
  RP/0/RP0/CPU0:router(config)# mpls oam
  RP/0/RP0/CPU0:router(config-oam)# echo reply-mode control-channel allow-reverse-lsp
  

  Following features are supported:

  • LSP Ping: Using LSP ping, use can enable on demand ping. It supports IP encapsulation for both request and reply messages. It also performs reverse path verification.

    Following is the example of LSP Ping configuration:

    
    RP/0/RP0/CPU0:router# ping mpls traffic-eng tunnel-te 1 reply mode control-channel
    
    Tue May 21 11:04:12.211 EDT
    Sending 5, 100-byte MPLS Echos to tunnel-te1,
          timeout is 2 seconds, send interval is 0 msec:
    
    Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
      'L' - labeled output interface, 'B' - unlabeled output interface,
      'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
      'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
      'P' - no rx intf label prot, 'p' - premature termination of LSP,
      'R' - transit router, 'I' - unknown upstream index,
      'X' - unknown return code, 'x' - return code 0
    
    Type escape sequence to abort.
    
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/5 ms

  • Traceroute: Traceroute supports IP-encapsulation but not for echo reply. Following is the example of Traceroute configuration:

    
    RP/0/RP0/CPU0:router# traceroute mpls traffic-eng tunnel-te 1
    
    Tue May 21 11:06:16.056 EDT
    Tracing MPLS TE Label Switched Path on tunnel-te1, timeout is 2 seconds
    
    Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
      'L' - labeled output interface, 'B' - unlabeled output interface,
      'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
      'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
      'P' - no rx intf label prot, 'p' - premature termination of LSP,
      'R' - transit router, 'I' - unknown upstream index,
      'X' - unknown return code, 'x' - return code 0
    
    Type escape sequence to abort.
    
      0 10.10.10.1 MRU 1500 [Labels: 16005 Exp: 0]
    L 1 10.10.10.2 MRU 1500 [Labels: implicit-null Exp: 0] 11 ms
    ! 2 13.13.13.4 4 ms
    

Scale details for Flex LSP:

A co-routed bidirectional packet LSP is a combination of two LSPs (one in the forward direction and the other in reverse direction) sharing the same path between a pair of ingress and egress nodes. It is established using the extensions to RSVP-TE. This type of LSP can be used to carry any of the standard types of MPLS-based traffic, including Layer 2 VPNs.

The configuration includes the following steps:

1. Enable basic MPLS Traffic Engineering on hostname PE1 and RSVP Configuration.

2. Configure Flex LSP.

3. Enable Wrap Protection.

4. Enable Fault OAM.

5. Map pseudowire to a specific Flex LSP tunnel.

RSVP-TE (Resource Reservation Protocol-Traffic Engineering) is a protocol used to reserve resources across an MPLS (Multiprotocol Label Switching) network to ensure Quality of Service (QoS) for specific traffic flows.

Flex LSP (Flexible Label Switched Path) is an enhancement of RSVP-TE that allows for more flexible and efficient selection of co-routed bidirectional LSP path selection.

Co-routed bidirectional LSP paths refer to LSP paths where traffic flows from headend to tailend and vice versa over the same physical path.

You can enable the router to configure these co-routed bidirectional LSP paths:

• Primary flex LSP path: This is an explicit path computed by the router between a headend node and a tailend node. This path serves as the main route for traffic.

• Secondary flex LSP path: In addition to the primary path, the router computes a secondary flex LSP path. This path acts as a backup to the primary path.

• Dynamic restore paths:

  • Primary backup: The headend router computes a dynamic LSP path using Constrained Shortest Path First (CSPF). This path serves as a backup to the primary flex LSP path.

  • Secondary backup: Another dynamic restore path is configured as a backup for the secondary flex LSP path. It provides additional redundancy and ensures continuous traffic flow even if the secondary path becomes unavailable.

For more information, see RSVP-TE Transport Solution with Flex LSP.

Once the failure is resolved, the router restores the previously used primary or secondary LSP paths.

Before Release 24.4.1, you can enable the router to configure

• a secondary LSP path as a backup to the primary LSP path, and

• dynamic restore path as a backup to the secondary LSP path.

From Release 24.4.1 onwards, you can enable the router to configure

• a secondary LSP path and a dynamic restore primary path as backups to the primary LSP path, and

• a dynamic restore path as a backup to the secondary LSP path.

From Release 25.1.1 onwards, you can configure a centralized PCE server to perform flex LSP path computation for primary, secondary, and restore paths. For more information, see RSVP-TE transport solution using PCE.

How flex LSP headend traffic flow works

Summary

The key components that are involved in flex LSP headend traffic flow are:

• R1: Headend router

• R2: Tailend router

• R3, R4, R5, R6, and R7: Transit routers

• Path 10 (Link 1-2-3): Primary LSP path or Working or Active path

• Path 20 (Link 4-5-6): Secondary LSP path or Protecting path

• Path 30 (Link 1-9-10-3): Dynamic restore primary path

• Path 40 (Link 4-11-12-6): Dynamic restore path

• Path 50 (Link 7-8): Dynamic LSP path

• All links are 100G

• Weight:

  • Link 1 to Link 6: 10000 weights

  • Link 7 to Link 12: 100 weights

Workflow

These stages describe how flex LSP headend traffic flow works.

Before Release 24.4.1,

When	Then...
Link 2 of the primary LSP path is broken	the headend router activates the secondary LSP Path 20.
both primary and secondary LSP paths are broken	the headend router computes a new dynamic path using CSPF, without prioritizing the primary or secondary paths.
for example, Link 2 and Link 5 are broken	the headend router computes a new dynamic LSP Path 50, selecting the shortest path compared to Path 30 or Path 40.

From Release 24.4.1 onwards,

When	Then...
Link 2 of the primary LSP path is broken	the headend router activates the secondary LSP Path 20.
both primary and secondary LSP paths are broken	the headend router computes a new dynamic restore primary path, prioritizing the primary LSP path.
for example, Link 2 and Link 5 are broken	the headend router prioritizes Link 1 and assigns a new dynamic primary Path 30.
primary, secondary, and dynamic primary LSP paths are broken	the headend router computes a new dynamic restore path, prioritizing the secondary LSP path.
for example, Link 2, Link 5, and Link 10 are broken	the headend router prioritizes Link 4 and assigns a new dynamic restore Path 40.

MPLS Traffic Engineering Path Computation Element (TE-PCE) extends the existing IOS XR Path Computation Element Protocol (PCEP) functionality to provide stateless PCE capabilities, supporting operations on both the MPLS data plane and the IPv4 control plane. For more information, see RFC 5440.

PCE characteristics:

• Stateless operation: The PCE operates in a stateless manner, meaning it does not maintain ongoing state information about the LSPs or paths it computes. It provides paths on demand based on real-time network conditions.

• Request and reply Model: The headend router sends a Path Computation Request (PCReq) to the PCE and receives a Path Computation Reply (PCRep) in return, containing the computed path details.

• Topology learning: The PCE learns about the network topology from the Interior Gateway Protocol (IGP).

• Bandwidth management: The PCE maintains information on in-progress bandwidth to reduce the need for computing the path again in the network.

• Path disjointness: The PCE can compute disjoint paths, ensuring that two or more LSPs do not share the network resources. This capability enhances network resilience by providing diverse path options that can originate from the same or different headend routers.

The Cisco IOS XRv 9000 is the recommended platform to act as the TE-PCE. For more information, see Cisco IOS XRv 9000 Router Installation and Configuration Guide.

Path definition

• Explicit path: A manually configured path that specifies a predetermined sequence of nodes or links for traffic passage from the headend to the tailend node.

• Dynamic path: A path automatically computed by either the PCE server or headend router using routing protocols and algorithms to adapt to real-time network conditions.

Before Release 25.1.1, the headend router were used to perform flex LSP path computation for these paths:

• Primary path: Depending on network requirements, you could configure an explicit path or enable the headend router to compute a dynamic path.

• Secondary path: Depending on network requirements, you could configure an explicit path or enable the headend router to compute a dynamic path.

• Restore path for primary: Headend router computes a new dynamic path by reusing the links from the failed primary path.

• Restore path for secondary: Headend router computes a new dynamic path by reusing the links from the failed secondary path.

For more information, see RSVP-TE Transport Solution with Flex LSP Headend.

From Release 25.1.1, a centralized TE-PCE is introduced to perform the flex LSP paths computation for these paths:

• Primary path: Depending on network requirements, you can configure an explicit path or enable the PCE or headend router to compute a dynamic path.

• Secondary path: Depending on network requirements, you can configure an explicit path or enable the PCE or headend router to compute a dynamic path.

• Restore path for primary: The PCE server computes a new dynamic path by reusing links from the failed primary path.

• Restore path for secondary: The PCE server computes a new dynamic path by reusing links from the failed secondary path.

If the PCE connection is broken, the headend router performs flex LSP path computation.