Static Bidirectional Co-Routed LSPs
A static bidirectional co-routed LSP is used on transport networks to transmit services and provide a return path for LSP ping/tracert and OAM packets when IGP is not configured.
Background
Service packets exchanged by two nodes must travel through the same links and nodes on a transport network without running a routing protocol. In this context, the static bidirectional co-routed LSP is proposed to ensure that MPLS technology can still be used.
Related Concepts
A static bidirectional co-routed LSP is a type of manually configured LSP over which two flows are transmitted in opposite directions by the same nodes over the same links.
A static bidirectional co-routed CR-LSP is one LSP and corresponds to two forwarding entries. It can go up only when the conditions for forwarding traffic in both directions are met. If the conditions for forwarding traffic in one direction are not met, the LSP is in the Down state. In addition, the forwarding entries in both directions are associated with each other. When IP forwarding capabilities are unavailable, any transit node can send back a response packet along the original path. Compared with two independent LSPs in opposite directions, a static bidirectional co-routed LSP has the same delay and jitter in both directions, which guarantees QoS for bidirectional services.
Implementation
A static bidirectional co-routed LSP is established by manually assigning forward and reverse labels and forwarding entries to forwarding equivalence classes. When manually allocating labels, ensure that the outgoing label value of the upstream node is equal to the incoming label value of the downstream node.
A static bidirectional co-routed LSP is meaningful only to the local node, and the local node cannot be aware of the entire LSP. As shown in Figure 1, you need to select the direction from the ingress to the egress as the forward direction, and the other direction becomes the reverse direction.
- On the ingress of the static bidirectional co-routed LSP, configure a tunnel interface and enable MPLS TE on the outbound interface. If the outbound interface is up and has available bandwidth greater than or equal to the LSP bandwidth, the static bidirectional co-routed LSP is up after being bound to the tunnel interface, regardless of whether a transit node or the egress exists.
- On each transit node of the static bidirectional co-routed LSP, enable MPLS TE on the outbound interface. If the outbound interface is up and the available bandwidth in both directions is greater than or equal to the LSP bandwidth, the static bidirectional co-routed LSP is up, regardless of whether the ingress, egress or other transit nodes exist.
- On the egress of the static bidirectional co-routed LSP, enable MPLS TE on the inbound interface. If the inbound interface is up and has available bandwidth greater than or equal to the LSP bandwidth, the static bidirectional co-routed LSP is up after being bound to the tunnel interface, regardless of whether the ingress or a transit node exists.
Loopback Detection for a Static Bidirectional Co-Routed CR-LSP
On a network with a static bidirectional co-routed CR-LSP used to transmit services, if a few packets are dropped or bit errors occur on links, no alarms indicating link or LSP failures are generated, which poses difficulties in locating the faults. To locate the faults, loopback detection can be enabled for the static bidirectional co-routed CR-LSP.
Loopback detection for a static bidirectional co-routed CR-LSP locates faults if a few packets are dropped or bit errors occur on links along the CR-LSP. To implement loopback detection for a specified static bidirectional co-routed CR-LSP, a transit node temporarily connects the forward CR-LSP to the reverse CR-LSP and generates a forwarding entry for the loop so that the transit node can loop all traffic back to the ingress. A professional monitoring device connected to the ingress monitors data packets that the ingress sends and receives and checks whether a fault occurs on the link between the ingress and transit node.
The dichotomy method is used to perform loopback detection by reducing the range of nodes to be monitored before locating a faulty node. For example, in Figure 2, loopback detection is enabled for a static bidirectional co-routed CR-LSP established between PE1 and PE2. The process of using loopback detection to locate a fault is as follows:
Loopback is enabled on P1 to loop data packets back to the ingress. The ingress checks whether the sent packets match the received ones.
If the packets do not match, a fault occurs on the link between PE1 and P1. Loopback detection can then be disabled on P1.
If the packets match, the link between PE1 and P1 is working properly. Go to Step 2 to continue fault locating.
Loopback is disabled on P1 and enabled on P2 to loop data packets back to the ingress. The ingress checks whether the sent packets match the received ones.
If the packets do not match, a fault occurs on the link between P1 and P2. Loopback detection can then be disabled on P2.
If the packets match, a fault occurs on the link between P2 and PE2. Loopback detection can then be disabled on P2.
Loopback detection information is not saved in a configuration file after loopback detection is enabled. A loopback detection-enabled node loops traffic back to the ingress through a temporary loop. Loopback alarms can then be generated to prompt users that loopback detection is performed. After loopback detection finishes, it can be manually or automatically disabled. Loopback detection configuration takes effect only on a main control board. After an active/standby main control board switchover is performed, loopback detection is automatically disabled.