This module describes how to implement MPLS transport profile (MPLS-TP) on the router. MPLS-TP supported by IETF enables the migration of transport networks to a packet-based network that efficiently scale to support packet services in a simple and cost-effective way. MPLS-TP combines the necessary existing capabilities of MPLS with additional minimal mechanisms in order that it can be used in a transport role.
MPLS transport profile enables you to create tunnels that provide the transport network service layer over which IP and MPLS traffic traverse.
Feature History for Implementing MPLS Transport Profile
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:
Figure 1. MPLS Transport Profile 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-TP tunnels have these characteristics:
An MPLS-TP tunnel can be associated with working LSP, protect LSP, or both LSP
1:1 path protection with revertive mode for MPLS-TP LSP with
revertive mode for MPLS-TP LSP
Use of Generic Alert Label (GAL) and Generic Associated Channel Header (G-ACH) to transport control packets; for example, BFD packets and pseudowire OAM packets
BFD is used as a continuity check (CC) mechanism over MPLS-TP LSP
Remote Defect Indication (RDI) based on BFD
Fault OAM functions
These services are supported over MPLS-TP tunnels:
Dynamic spoke pseudowire (for H-VPLS) over static MPLS-TP tunnels.
Static spoke pseudowire (for H-VPLS) over static MPLS-TP tunnels.
MS-PW services where static and dynamic pseudowire segments can be concatenated.
MPLS ping and traceroute over MPLS TP LSP and PW.
Static routes over MPLS-TP tunnels.
Pseudowire redundancy for static pseudowire.
VPWS using static or dynamic pseudowire pinned down to MPLS-TP tunnels.
VPLS and H-VPLS using static or dynamic pseudowire pinned down to MPLS-TP tunnels.
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.
MPLS-TP Path Protection
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).
Fault OAM Support
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
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:
Fault Management: Alarm Indication Signal (AIS), Link Down Indication
(LDI), and Lock Report (LKR)
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
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
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.
MPLS-TP IP-less support
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.
MPLS-TP LSP Wrapping
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
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
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.
Figure 2. MPLS-TP LSP Wrapping Mechanism
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.
How to Implement MPLS Transport Profile
MPLS Transport Profile (MPLS-TP) supported by IETF enables the migration of transport networks to a packet-based network that efficiently scale to support packet services in a simple and cost effective way.
Exits from working LSP interface configuration mode.
Specifies 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.
Configures an interface type and path ID to be associated with a MPLS TE mode.
You must provide the next-hop IP address.
You can define a link ID once. If you attempt to use the same MPLS-TP link ID with different interface or next-hop address, the configuration gets rejected. You have to remove the existing link ID configuration before using the same link ID with a different interface or next-hop address.
commit—Saves the configuration changes and remains
within the configuration session.
end—Prompts user to take one of these actions:
Yes— Saves configuration changes and exits the
No—Exits the configuration session without
committing the configuration changes.
Cancel—Remains in the configuration session,
without committing the configuration changes.
Configuring MPLS-TP LSP Wrapping
Perform this task to configure the MPLS-TP LSP wrapping.
When configuring the LSPs at the midpoint routers, make sure that the configuration does not reflect traffic back to the originating node.