Creating an ME Instance and Binding It to a Tunnel Interface

Resource Reservation Protocol (RSVP) tunnels for transmitting traffic engineering (TE) services are unidirectional, and TE services are transmitted only from the ingress to the egress of a tunnel. To transmit TE services from the egress to the ingress of an RSVP tunnel, you can only use a route to forward the services, but that may cause network congestion. Additionally, if a path from the egress to the ingress is also configured as an RSVP tunnel, two tunnels are established between the ingress and egress. When a tunnel fails, the other tunnel cannot be notified of the fault. As a result, services will be interrupted. To resolve the preceding issue, configure a bidirectional LSP. Static bidirectional LSPs are supported.

Static bidirectional LSP: A static bidirectional LSP is similar to two LSPs in opposite directions. A static bidirectional LSP, however, is only one LSP. It is mapped to two forwarding entries for traffic in opposite directions and goes Up only when both forwarding entries are available. If the LSP is Down in one direction, the LSP is in the Down state. The two forwarding entries are associated with each other. When the IP forwarding capability is unavailable, any intermediate node can send back a response packet along the original path.

Static bidirectional LSPs supported by MPLS-TP can be monitored using MPLS-TP OAM. A MEG corresponds to a static bidirectional LSP and includes only one ME. The ingress and egress of the LSPs are configured as MEPs.

Two P2P LSPs in opposite directions are set up over a bidirectional co-routed transport path in a MEG. This means that there is a single LSP in both directions between a MEP and its RMEP. A single ME operates along this P2P LSP.

Perform the following steps on a MEP and its RMEP: