MPLS Transport Profile (TP) enables you to create tunnels that provide the transport network service layer over which IP and MPLS traffic traverse. MPLS-TP tunnels enable a transition from Synchronous Optical Networking (SONET) and Synchronous Digital Hierarchy (SDH) time-division multiplexing (TDM) technologies to packet switching, to support services with high bandwidth utilization and low cost. Transport networks are connection oriented, statically provisioned, and have long-lived connections. Transport networks usually avoid control protocols that change identifiers like labels. MPLS-TP tunnels provide this functionality through statically provisioned bidirectional label switched paths (LSPs). This figure shows the MPLS-TP tunnel:

MPLS-TP combines the necessary existing capabilities of MPLS with additional minimal mechanisms in order that it can be used in a transport role. You can set up MPLS-TP through a CLI or a network management system.

MPLS transport profile (MPLS-TP) LSPs are bidirectional and congruent where LSPs traverse the same path in both directions. An MPLS-TP tunnel can be associated with either working MPLS-TP LSP, protect MPLS-TP LSP, or both. The working LSP is the primary LSP backed up by the protect LSP. When a working LSP goes down, protect LSP is automatically activated. In order for an MPLS-TP tunnel to be operationally up, it must be configured with at least one LSP.

Path protection provides an end-to-end failure recovery mechanism (that is, full path protection) for MPLS-TP tunnels. MPLS-TP LSPs support 1:1 path protection. You can configure the working and protect LSPs as part of configuring the MPLS-TP tunnel. The working LSP is the primary LSP used to route traffic, while the protect LSP is a backup for a working LSP. If the working LSP fails, traffic is switched to the protect LSP until the working LSP is restored, at which time traffic forwarding reverts back to the working LSP (revertive mode).

The fault OAM protocols and messages support the provisioning and maintenance of MPLS-TP tunnels and bidirectional LSPs:

• Generic Associated Channel

  Generic Associated Channel (G-ACh) is the control channel mechanism associated with MPLS LSPs in addition to MPLS pseudowire. The G-ACh Label (GAL) (Label 13) is a generic alert label to identify the presence of the G-ACh in the label packet. It is taken from the reserved MPLS label space.

  G-ACh or GAL is used to support in-band OAMs of MPLS-TP LSPs and pseudowires. The OAM messages are used for fault management, connection verification, continuity check and other functions.

  These messages are forwarded along the specified MPLS LSP:

  • OAM Fault Management: Alarm Indication Signal (AIS), Link Down Indication (LDI), and Lock Report (LKR) messages (GAL with fault-OAM channel)

  • OAM Connection Verification: Ping and traceroute messages (GAL with IP channel)

  • BFD messages (GAL with BFD channel)

  These messages are forwarded along the specified pseudowire:

  • Static pseudowire OAM messages (static pseudowire status)

  • Pseudowire ping and traceroute messages

• Fault Management: Alarm Indication Signal (AIS), Link Down Indication (LDI), and Lock Report (LKR) messages

  LDI messages are generated at midpoint nodes when a failure is detected. The midpoint sends the LDI message to the endpoint that is reachable with the existing failure. The midpoint node also sends LKR messages to the reachable endpoint, when an interface is administratively down. AIS messages are not generated by Cisco platforms, but are processed if received. By default, the reception of LDI and LKR on the active LSP at an endpoint will cause a path protection switchover, while AIS will not.

• Fault Management: Emulated Protection Switching for LSP Lockout

  You can implement a form of Emulated Protection Switching in support of LSP Lockout using customized fault messages. When a Cisco Lockout message is sent, it does not cause the LSP to be administratively down. The Cisco Lockout message causes a path protection switchover and prevents data traffic from using the LSP. The LSP's data path remains up so that BFD and other OAM messages can continue to traverse it. Maintenance of the LSP can take place such as reconfiguring or replacing a midpoint LSR. BFD state over LSP must be up and MPLS ping and traceroute can be used to verify the LSP connectivity, before the LSP is put back into service by removing the lockout. You cannot lockout working and protect LSPs simultaneously.

• LSP ping and traceroute

  For MPLS-TP connectivity verification, you can use ping mpls traffic-eng tunnel-tp and traceroute mpls traffic-eng tunnel-tp commands. You can specify that the echo requests be sent along the working LSP or the protect LSP. You can also specify that the echo request be sent on a locked out MPLS-TP tunnel LSP (either working or protect) if the working or protect LSP is explicitly specified.

• Continuity Check through BFD

  BFD session is automatically created on MPLS-TP LSPs with default parameters. You can override the default BFD parameters either through global commands or per-tunnel commands. Furthermore, you can optionally specify different BFD parameters for standby LSPs. For example, when an LSP is in standby, BFD hello messages can be sent at smaller frequency to reduce line-card CPU usage. However, when a standby LSP becomes active (for example, due to protection switching), nominal BFD parameters are used for that LSPs (for example, to run BFD hello messages at higher frequency).

MPLS-TP link IDs may be assigned to physical interfaces only. Bundled interfaces and virtual interfaces are not supported for MPLS-TP link IDs.

The MPLS-TP link is used to create a level of indirection between the MPLS-TP tunnel and midpoint LSP configuration and the physical interface. The MPLS-TP link-id command is used to associate an MPLS-TP link ID with a physical interface and next-hop node address.

Multiple tunnels and LSPs may then refer to the MPLS-TP link to indicate they are traversing that interface. You can move the MPLS-TP link from one interface to another without reconfiguring all the MPLS-TP tunnels and LSPs that refer to the link.

Link IDs must be unique on the router or node. For more information, see the Configuring MPLS-TP Links and Physical Interfaces section.

Tunnel LSPs, whether endpoint or midpoint, use the same identifying information. However, it is entered differently.

• A midpoint consists of a forward LSP and a reverse LSP. A MPLS-TP LSP mid point is identified by its name, and forward LSP, reverse LSP, or both are configured under a submode.

• At the midpoint, determining which end is source and which is destination is arbitrary. That is, if you are configuring a tunnel between your router and a coworker's router, then your router is the source. However, your coworker considers his or her router to be the source. At the midpoint, either router could be considered the source. At the midpoint, the forward direction is from source to destination, and the reverse direction is from destination to source. For more information, see the Configuring MPLS-TP LSPs at Midpoints section.

• At the midpoint, the LSP number does not assume default values, and hence must be explicitly configured.

• At the endpoint, the local information (source) either comes from the global node ID and global ID, or from locally configured information using the source command after you enter the interface tunnel-tp number command, where number is the local or source tunnel-number.

• At the endpoint, the remote information (destination) is configured using the destination command after you enter the interface tunnel-tp number command. The destination command includes the destination node ID, optionally the global ID, and optionally the destination tunnel number. If you do not specify the destination tunnel number, the source tunnel number is used.

Generally, MPLS-TP functionality can be deployed with or without an IP address. However, the main motivation for the IP-less model is this: an LSR can be inserted into an MPLS-TP network without changing the configurations on adjacent LSRs. In the past Cisco IOS-XR MPLS-TP release, if an interface does not have a valid IP address, BFD packets cannot be transmitted over that link, and hence MPLS-TP LSP cannot be brought up on that link. In this release, the IP-less TP link operates only in a point-to-point mode.

This feature, therefore, makes the need for an IP address on a TP link optional. You may deploy LSRs running Cisco IOS-XR in MPLS-TP networks with or without an IP address. With such extra flexibility, LSRs running Cisco IOS-XR can be easily deployed not only with LSRs running IOS, but with LSRs from other vendors too.

In the MPLS-TP LSP Wrapping protection scheme, a protected MPLS-TP tunnel is associated with a working LSP and protect LSP. This helps to prevent traffic loss as soon as a mid-point LSR detects a failure at physical layer rather than waiting for BFD to time-out. Also, a delay in activating protection switch due to mid-point failure does not further increase the traffic loss.

MPLS-TP LSP wrapping has to enabled only on the MID node. MPLS-TP LSP wrapping helps in detecting mid-link failure scenarios; other failures and failures on end node is detected by BFD timeout and TP-OAM message.

As shown in the figure below, when an LSR (e.g., Router B) detects a failure, it forwards the incoming traffic over an impacted LSP onto the reverse LSP, if it exists. The traffic re-directed into the reverse LSP is loopback traffic. Looping back traffic is carried out by the forwarding engine without control plane's involvement. The label stack of a loopback packet will be modified such that the source of the traffic identifies the packet.

When the forwarding engine at an end-point recognizes a packet from loopback traffic, it sforwards the packet on protect LSP. As BFD packets over impacted LSPs are also looped-back, the end-point will drop such BFD packets so that BFD sessions over the impacted LSPs is timed-out and protection switching is activated. Optionally, when an end-point receives the first looped-back packet, it activates protection switching.

A working LSP remains wrapped until protection switching is activated. Once activated, protect LSP will carry traffic as usual. When failure is removed and BFD session comes back up resulting in activation of working LSP.