MPLS-TP overview
Overview
MPLS-TP is a set of MPLS protocol functions that enables the use of MPLS in transport networks and applications. MPLS-TP provides in-band proactive OAM and protection mechanisms that do not rely on a control plane, such as RSVP-TE, to operate. MPLS-TP enables MPLS to be deployed in a statically configured transport network without the need for a dynamic control plane.
Supporting NEs have two primary roles in an MPLS-TP network:
The NFM-P can configure LSR NEs even when LERs are not configured, or when the LERs or LSRs are not supporting NEs. See the specific NE documentation for more information about MPLS-TP.
The NFM-P provides simple provisioning for MPLS-TP management in a transport network. MPLS-TP relies on static configuration, rather than a control plane, to ensure end-to-end path configuration and consistency. The NFM-P support of MPLS-TP includes:
-
linear protection for MPLS-TP LSPs with working and protection paths for each LSP
-
on-demand CV for MPLS-TP LSPs and PWs using LSP ping and trace and VCCV ping and trace diagnostics
-
static PW status signaling, with support for PW redundancy, MC-LAG, MC-APS, BGP multi-homing and active and standby dual-homing into IES, VPRN, or VPLS
-
stitching of static MPLS-TP PWs to T-LDP dynamically signaled PWs (LDP, RSVP, and BGP) on Epipe, Apipe, and Cpipe VLL switching sites
Proactive OAM templates
A proactive continuity check detects a loss of continuity defect between two MEPs in a MEG. Proactive connectivity verification detects an unexpected connectivity defect between two MEPs, and unexpected connectivity within the MEG with an unexpected MEP. The NFM-P implements both tests with a proactive OAM template.
Proactive OAM templates are based on BFD. BFD packets are sent using configurable timers. Continuity check packets contain a BFD control packet, while connectivity verification packets also include an identifier for the source MEP. The destination MEP can detect a connectivity defect if it is receiving packets from an incorrect peer MEP. When a defect is detected, the NFM-P generates an alarm.
MPLS-TP LSP provisioning
The NFM-P significantly simplifies the provisioning process of bidirectional MPLS-TP LSPs, where using CLI can be cumbersome and prone to error. Using the NFM-P, all of the components of an end-to-end bidirectional MPLS-TP LSP are automatically configured. Using CLI, all of the components of a bidirectional MPLS-TP LSP, including interfaces and labels, must be configured. The NFM-P automatically creates opposite interfaces based on the physical links between NEs, and assigns in and out labels across all of the interfaces. However, if a physical link does not exist between NEs, the NFM-P cannot auto-create the interfaces. The NFM-P prompts you to manually create the interfaces.
Consider the following when you create a bidirectional MPLS-TP LSP using NFM-P simplified provisioning:
-
MPLS-TP tunnels that are created on the NEs using CLI are discovered by the NFM-P
Note:
The NFM-P does not create the bidirectional MPLS-TP LSP when all of the MPLS-TP LSP endpoints (LERs) are not managed by the NFM-P. However, cross-connections (on LSRs) appear in the NFM-P database if the LSRs are managed.
In the example in the following figure, you configure the LER A and LER B using the NFM-P. For the bidirectional MPLS-TP LSP path, you identify the hops by specifying the interfaces. In this example, the interfaces are A1 on LER A and C1 on LSR C. Since MPLS-TP is co-routed, the other interfaces (B1 and C2) are determined by the NFM-P based on the link between the two NEs. The NFM-P automatically chooses all of the labels, in both directions, based on the available labels on the two adjacent NEs. The NFM-P also creates the LSR C object. You must configure proactive OAM on LER NEs.
Figure 32-1: Sample bidirectional MPLS-TP LSP
