LSPs

Overview

An LSP is a path through an MPLS network that is set up based on criteria in a forwarding equivalency class (FEC). An FEC is a set of characteristics that define how NEs in an MPLS network forward packets that are bound to an MPLS label. An FEC includes specifications such as the destination IP address and QoS parameters. An FEC is associated with a specific LSP, but an LSP may be used for multiple FECs.

An LSP begins at a PE device called an LER, which is the ingress NE that prepends a label to a packet based on an FEC and sends the packets to the next transit NE in the path. The transit NE swaps the packet label for a new one, and sends the packet to the next NE. The LER that acts as the egress PE NE removes the label and forwards the packet according to the header of the next layer, for example, IP.

LSPs are unidirectional; they enable the label switching of a packet through an MPLS network from one endpoint to another. Bidirectional communication through an MPLS network requires the configuration of an LSP in the opposite direction.

The NFM-P supports the following types of LSPs:

• Static LSPs specify a static path through an MPLS network. All transit NEs require manual configuration with LSP labels and require no signaling protocol, such as LDP or RSVP.

• Bypass-only LSPs are LSPs with manually configured bypass tunnels on Point-of-Local-Repair (PLR) NEs. Such LSPs are used exclusively for the purpose of bypass protection.

• Dynamic, or signaled LSPs, use a protocol such as LDP or RSVP. The signaling protocol allows an ingress NE to dynamically assign labels to an egress NE. You must configure the ingress NE, but not the transit NEs in an LSP. LDP LSPs are not explicitly defined. The downstream unsolicited (DU) method configures them automatically through the network.

• Segment Routing TE LSPs (SR-TE LSPs) are established with traffic engineering and protection requirements based on different parameters, such as hop limit, IGP shortcut, BGP shortcut and maximum segment routing labels.

• Point-to-Multipoint LSPs allow the source of multicast traffic to forward packets to one or many multicast receivers over a network without requiring a multicast protocol, such as PIM, to be configured in the network.

You can apply a metric value to a Dynamic LSP or a Point-to-Multipoint LSP that determines which LSP the NFM-P uses when multiple LSPs lead to the same destination. The metric value for a static route is set to 1 and cannot be configured.

You can list and view detailed information on LSPs, templates, cross connections, service tunnels, and detour and bypass information on the LSP (Edit) forms.

Dynamic LSPs

A Dynamic LSP uses a signaling protocol such as LDP or RSVP-TE and an MPLS path between two NEs. You can then create an LSP between the two NEs and bind it to an MPLS path. An LSP-MPLS path binding is called an LSP path. You can configure the LSP path after the MPLS path and the LSP are bound.

Dynamic LSPs are categorized as follows:

• Explicit-path LSPs resemble static LSPs when all hops are strict; each hop in the LSP requires explicit configuration. MPLS uses RSVP-TE to set up an explicit-path LSP. Transit NE hops can be strict, and use a direct path between NEs, or loose, and include other NEs in the path between NEs.

• Constrained-path LSPs have dynamically assigned intermediate NE hops that rely on CSPF to find a path that satisfies the LSP constraints. CSPF is a routing algorithm that takes different LSP constraints, such as the available bandwidth and MPLS administrative groups, into account to balance the network load. When the CSPF path is found, RSVP uses the path to request the LSP setup. If Fast Reroute is enabled, the ingress NE signals the downstream NEs to set up a detour configuration for the LSP.

When an LSP is established, the reserved bandwidth is controlled by the bandwidth parameter at the primary path level, regardless of whether the LSP has auto-bandwidth enabled. When auto-bandwidth is enabled and a trigger occurs, the NE attempts to change the bandwidth of the LSP to a value between the minimum and maximum bandwidth, which are configurable at the LSP level. Automatic bandwidth allocation is supported on RSVP LSPs that have both CSPF and MBB enabled. If an RSVP LSP is configured for auto-bandwidth, the ingress LER determines, at every adjust interval, whether to attempt an auto-bandwidth adjustment. You can change the minimum bandwidth, maximum bandwidth, or threshold parameters on an operational LSP, however, the changes do not take effect until the next auto-bandwidth trigger, for example, an adjust interval expiry. If the bandwidth adjustment fails, for example, the CSPF cannot find a path, the existing LSP is maintained with its existing bandwidth reservation. See To create a Dynamic LSP for more information.

The NFM-P provides OAM tools for troubleshooting service and network transport issues. You can run an OAM validation test for the Dynamic LSP by clicking on the One Time Validation button. If a check mark appears beside the OAM Validation Failed state cause indicator, the test has failed. The One Time Validation Result tab on the Tests tab displays detailed information about the OAM test result. See To run a one-time validation test on a service for information on how to use the One Time Validation function.

You can manually switch away or switch back to the primary path for a RSVP-TE using the Manual Switch Path button on the Tunnels tab of the Dynamic LSP form. Selecting the Switch Away option will degrade the primary path, switching to a standby path, and selecting the Switch Back option will restore the primary path.

Static LSPs

A static LSP uses an IGP instead of a signaling protocol, such as LDP or RSVP-TE. The NFM-P attempts to derive the hop configurations based on the hop labels in the path. You must use an ingress label that is unique within an NE when you create a new static hop; otherwise, the NFM-P rejects the new hop.

You can assign static label mappings for LSP cross-connections on an MPLS interface during interface creation or modification. A static label map is used only for intervening unmanaged NEs. The NFM-P attempts to derive the interface and label values from the swap egress label of the previous hop. The Static Label Maps form lists the static label maps for an interface whether they are created using the NFM-P client GUI, an OSS client, or CLI.

The NFM-P does not raise an alarm against an unmanaged NE.

The NFM-P raises an alarm against a static LSP under the following conditions when the LSP destination is managed by the NFM-P:

• No hops are configured for the static LSP.

• The last hop does not match the LSP destination.

• The label action specified for the last hop is not a pop action.

SR-TE LSPs

You can configure a Segment Routing Traffic Engineered (SR-TE) LSP using the Manage→MPLS→Segment Routing LSPs option. You can associate an empty path or a path with strict or loose explicit hops with the primary path of the SR-TE LSP.

The SR-TE LSP has the following characteristics:

• Static route tunnel binding configuration allows the forwarding of packets of a static route to an indirect next-hop over an SR-TE LSP.

• BGP shortcut tunnel binding configuration allows the forwarding of packets of BGP prefixes over an SR-TE LSP.

• The BGP transport tunnel can be enabled so that the SR-TE LSP can resolve the next-hop of a BGP IPv4 or IPv6 (6PE) label route.

• An SDP sub-type of the MPLS encapsulation type allows service binding to a SR-TE LSP.

• The support of SR-TE LSP in the data path requires that the ingress LER pushes a label stack where each label represents a hop, a TE link, or an NE, in the ERO for the LSP path computed by the PCE.

An SR-TE LSP is configured on the NE, but its path can be computed by the NE or by an external Traffic Engineering controller referred to as a Path Computation Element (PCE). This feature works with the Nokia stateful PCE, which is part of the NSP. Three modes of operations can be configured for an SR-TE LSP:

• When the path of the SR-TE LSP is computed by the NE acting as a PCC, the LSP is referred to PCC-initiated and PCE-controlled.

• When the path of the SR-TE LSP is computed by the PCE at the request of the PCC, it is referred to as PCC-initiated and PCE-computed.

• When the path of the SR-TE LSP is computed and updated by the PCE following a delegation from the PCC, it is referred to as PCC-initiated and PCE-controlled.

You can manually switch away or switch back to the primary path for a SR-TE using the Manual Switch Path button on the Tunnels tab of the Segment Routing LSP form. Selecting the Switch Away option will degrade the primary path, switching to a standby path, and selecting the Switch Back option will restore the primary path.

Point-to-Multipoint LSPs

A Point-to-Multipoint (P2MP) MPLS LSP allows the source of multicast traffic to forward packets to one or many multicast receivers over a network without requiring a multicast protocol, such as PIM, to be configured in the network. A P2MP LSP tree is established in the control plane for which the path consists of a head-end NE, one or many branch NEs, and multiple leaf NEs. Packets that are injected by the head-end NE are replicated in the data plane at the branching NEs before they are delivered to the leaf NEs.

The P2MP LSP has a source IP address but does not a have a destination address. Instead, you must create S2L leaf NEs for each destination in the P2MP LSP tree. The P2MP LSPs are not supported in SDP bindings.

Each P2MP LSP object has one P2MP LSP instance object. This is the primary instance, and can contain multiple child S2L path objects. Just as the P2MP LSP can appear as a tree, each S2L path object represents a root-to-leaf (S2L) sub-LSP path for the primary instance. The S2L paths can be empty paths or can specify a list of explicit hops. The same path can be used by more than one S2L of the instance. However the destination IP address must have a unique argument per S2L, because it corresponds to the address of the egress LER NE.

PIM tunnel interfaces are associated with a P2MP LSP. The tunnel interfaces are needed at both the ingress LER and the egress LER NEs. You must also associate static multicast groups with the tunnel interfaces that are associated with the P2MP LSPs.

On the ingress side, you can create one or more tunnel interfaces in PIM and associate each with a different RSVP P2MP LSP. The tunnel interface is associated with the P2MP LSP name. You can then assign static multicast group joins to each tunnel interface using an IGMP configuration. A specific <*,G> or <S,G> can only be associated with a single tunnel interface. A multicast packet which is received on an interface and matches the <*,G> or <S,G> specified in the IGMP join for the tunnel interface is replicated and forwarded to all branches of the P2MP LSP.

On the egress side, the PIM tunnel interface is associated with both the P2MP LSP name and the system address of the ingress LER. You must define a multicast info policy to associate specific multicast groups, or a specific <S,G>, to the primary tunnel interface on each egress LER leaf NE. The multicast info policy must then be applied to the router. A multicast packet synced from a tunnel interface associated with a P2MP LSP on the egress leaf NE can then be forwarded over a PIM or IGMP interface, which can be an access interface or a network interface, including a spoke SDP-based IES interface. You may create multiple tunnel interfaces per NE, where each interface is associated with a different P2MP LSP. The P2MP LSP association to a multicast group can be applied at the bundle, channel, and/or source channel level in the policy.

You can create a P2MP, one-hop P2P, or mesh P2P LSP using the LSP template for MVPN from the Policies→MPLS→LSP Template MVPN menu option. You can configure the scope as either local or global. The global template can be modified and multiple local versions can exist on the NEs. You must assign a default MPLS path to the template on the local definition before the template is turned up. If you modify the template, you must shut down the local policy first. When you turn up the local policy, all previously created P2MP LSP parameters are synchronized with the new template. See To create an LSP template MVPN policy for more information.

Bypass LSPs and manual bypass tunnels

You can create manual bypass tunnels and dynamic (or automatic) bypass tunnels on the SR/ESS, 7705 SAR, and 7210 SAS. You can manually configure an LSP to be bypass-only on a PLR NE. The LSP is then used exclusively for the purpose of bypass protection.

You can use manual bypass alone or with dynamic bypass. When used with the dynamic bypass, the manual bypass has precedence over the dynamic bypass for the path selection.

Dynamic bypass tunnels can be disabled on a per-NE basis. They are enabled by default. If dynamic bypass is disabled on a network element while dynamic bypass tunnels are active, traffic loss occurs. Furthermore, if no suitable manual bypass LSPs are found, the protected LSP remains without protection.

A bypass-only LSP does not have all the configurable attributes of a regular dynamic LSP. The main differences include:

• Manual bypass LSPs only support primary path. Secondary or standby paths cannot be created.

• Manual bypass LSPs do not support bandwidth or fast-reroute.

• Path monitoring is not available for manual bypass LSPs.

• Manual bypass LSPs cannot be assigned to a service tunnel, or be added to an LDP targeted peer as the LDP tunneling LSP.

• There is no rule-based topology support available for manual bypass LSPs.

• There is no network-wide LSP view (the physical map LSP view) support available for manual bypass LSPs,

• You cannot create a static LSP using a tunnel template.

The following additional characteristics also apply to a manual bypass:

• The default protection level for a bypass tunnel is “node-protect”.

• CSPF is supported for the manual bypass tunnel. When CSPF is enabled, loose path and hop-less path are allowed on a manual bypass tunnel. The CSPF calculation is performed when the manual bypass tunnel is first set up.

Administrative groups with facility bypass backup LSPs

Administrative group constraints configured on an LSP primary path are used for signaling of bypass LSPs. The NFM-P supports P2P LSP and P2MP S2L path bypass LSPs. Administrative groups with one-to-one detour LSPs are not supported.

You can enable the use of administrative group constraints in the association of a manual or dynamic bypass LSP with the primary LSP path on the MPLS instance of the NE. When constraints are enabled, each PLR NE reads the constraints in the FAST_REROUTE object in the path message of the primary path LSP. If the FAST_REROUTE object is not included in the path message, the PLR NE reads the constraints from the session attribute object in the path message. The PLR NE uses the administrative group constraints and other constraints, such as the hop limit and SRLG, to choose a manual or dynamic bypass LSP from the LSPs that are in use.

You can enable the use of the administrative group constraints on FRR backup LSP on the P2P and the P2MP LSP configuration forms, and in the LSP template MVPN policy. The constraints apply only to new attempts to find a valid bypass.

Automatic ABR selection and dynamic ABR bypass protection

The ABR selection for the inter-area RSVP P2P LSP path computation by CSPF is automatic at the ingress LER. You do not need to include the ABR as a loose-hop in the LSP path definition. On the LSP path binding configuration form, you can view whether:

• the operational path is inter-area or intra-area

• the current CSPF hop is an ABR (on the CSPF Path tab)

Dynamic bypass LSP for ABR NE protection

The NFM-P provides dynamic bypass computation, signaling, and association with the primary path of an inter-area P2P LSP to provide ABR NE protection. For a PLR NE within the local area of the ingress LER to provide ABR NE protection, the NE must dynamically signal a bypass LSP and associate it with the primary path of the inter-area LSP. You can view the address of the NE that must be bypassed along the path in the RSVP session tab on the Dynamic LSP properties form.

FRR protection

Fast reroute protection is a MPLS and IP resiliency technology that provides fast traffic recovery upon link or router failures for mission critical services. FRR allows a user to provide local protection for an LDP FEC by pre-computing and downloading to the IOM both primary and backup next hops for the FEC.

FRR provides for the use of the Loop-free Alternate (LFA) backup next-hop for forwarding in-transit and CPM generated IP packets when the primary next-hop is not available. IP FRR is supported on IPv4 and IPv6 prefixes forwarded in the base router instance over a network IP interface, or an IES SAP or spoke interface. It is also supported for VPRN VPN-IPv4 prefixes and VPN-IPv6 prefixes forwarded to a VPRN SAP or spoke interface.

FRR requires SPF computation of an LFA next-hop (in addition to the primary next-hop) for all prefixes used by LDP to resolve FECs. The LFA next-hop is populated into the routing table along with the primary next-hop for each prefix.

LFA is configured on IS-IS routing instances, enabling LFA computation by SPF under the IS-IS routing protocol. The LFA next hop can be excluded individually on the IS-IS Level 1 and IS-IS Level 2 objects, as well as on IS-IS interface objects.

LFA is configured on OSPF routing instances, enabling LFA computation by SPF under the OSPF routing protocol. The LFA next hop can be excluded individually on the OSPF area objects, as well as on OSPF interface objects.

Tunnel Templates

Tunnel templates allow users to configure Dynamic LSP, LSP path, and SDP templates to define common characteristics for a tunnel or templatable tunnel object.

To simplify creating tunnel templates, the NFM-P provides examples of common tunnel templates that can be copied and customized. You can also create a tunnel template from an existing templatable object.

After a template is configured, Dynamic LSPs, SR-TE LSPs, LSP paths and SDPs can be configured by choosing a create from template button during configuration. Users can configure multiple LSP paths for a Dynamic or SR-TE LSP. For example, you can configure one primary, one standby, and many secondary LSP paths.

When the NFM-P auto-tunnel creation is used to create LSP paths, the LSP paths must use a hopless path. If the paths belong to the same LSP, they must use different MPLS paths, even when the MPLS paths are hopless. For a RSVP LSP policy, one LSP template can be specified. When an LSP template with multiple LSP paths is specified, many LSP paths are created.

LSP Path Optimization

The NFM-P allows you to resignal LSP Paths to take advantage of new paths that are less congested, fewer hops, have a lower metric and meet least-fill criteria. NEs periodically check the network to determine whether a more efficient path is available and notify the NFM-P when another path is eligible for re-signaling. The NFM-P maintains a list of LSP Paths that are eligible for re-signaling. When an LSP Path is eligible for optimization, the LSP Path can be routed to a different path. When a LSP Path is not eligible for optimization, the LSP Path cannot use newly available network resources. See To configure an LSP Path optimization policy for information about configuring an LSP Path optimization policy.

LDP-over-RSVP tunnels

In networks that contain dozens of NEs spanning multiple routing areas, many RSVP service tunnels may be required. To reduce the number of RSVP tunnels required for service deployment in large networks, you can use the NFM-P to create LSPs using LDP-over-RSVP, sometimes called tunnel-in-tunnel encapsulation. An SDP can ride on multiple LDP-over-RSVP tunnels.

The NFM-P supports automatic, rule-based service-tunnel creation using NEs that are grouped according to their role in the NFM-P-managed network. This functionality greatly reduces the time and effort required to provision a mesh of service tunnels. See Chapter 33, Service tunnels for more information about rule-based automatic service-tunnel creation.

The NFM-P can use tunnel rules and groups to create new RSVP LSP bindings between a PE device that is added to the network and the existing ABRs. It can also create a new LDP-over-RSVP tunnel between a new NE and an existing PE NE. See Chapter 33, Service tunnels for more information about tunnel creation using rules and groups.

Service traffic that is transported by an LDP-over-RSVP tunnel requires a VC label, an LDP label, and an RSVP label. Unlike T-LDP sessions that use IGP SPF algorithms, RSVP LSPs are not advertised to an IGP instance. When the same FEC applies to the destination of an LDP-over-RSVP LSP tunnel and an IGP-based LDP tunnel, the NFM-P uses the LDP tunnel by default to minimize network overhead.

Using tunnel-in-tunnel encapsulation, a pair of LSP tunnels and a T-LDP session between two NEs are equivalent to two adjacent LDP NEs with a non-tunneled LDP session between them. In other words, the LDP tunnel uses the RSVP LSP as one hop between LSRs in the network.

During the configuration of LDP-over-RSVP, you can specify an explicit list of dynamic and static LSPs, or use the NFM-P to find eligible LSPs. After an LSP is explicitly configured for LDP tunneling, the NFM-P associates the LDP targeted peer with the LSP.

You can configure LDP-over-RSVP to enable an OSPF area router to be a stitching point. You can specify which NEs to use as the stitching points in each area. When there are many NEs in an area, this function helps to reduce the number of LSPs required, because a full mesh is not required.

For an LSP to be eligible for LDP-over-RSVP, the following conditions apply:

• The LSP must be an RSVP-owned LSP (strict or loose)

• The LSP must start and terminate either on:

  • The router ID (system IP address)

  • The router ID (loopback address when used in multi-instance OSPF

• The OSPF system/loopback address must be advertised

• A T-LDP session must exist between the originating and terminating routers using the addresses cited above

• LDP-over-RSVP availability must be enabled in the LSP configuration. This indicates that the LSP is eligible for LDP-over-RSVP, and RSVP signals to the IGP that the LSP should be included in the SPF run.

Shared Risk Link Groups

Shared Risk Link Groups (SRLGs) are constructs which allow you to perform two operations that enhance overall system reliability. Firstly, you can establish a FRR LSP path. In addition, you can also use SRLGs to establish a secondary LSP path which is disjointed from the primary LSP path.

Configured SRLGs are associated with MPLS interfaces. The SRLGs are used by the CSPF when computing a FRR detour/bypass path, or a secondary LSP path. Links which are members of the same SRLG represent resources which are assumed to share the same risk. These links are therefore avoided when computing and setting up an alternate LSP path.

• FRR backup

  The SRLG constraint can be enabled system-wide on a PLR NE, in the computation of a FRR detour or bypass to be associated with a primary LSP path. CSPF includes the SRLG constraint in the computation of a FRR detour or bypass. CSPF then prunes all links with interfaces which belong to the same SRLGs as the egress interface being protected (or the immediate downstream NE, depending on the protection level). If a path is found, the bypass or detour is set up. If not, and you included the Enable SRLG for FRR - Strict option, then the bypass or detour is not set up. If the Enable SRLG for FRR - Strict option is not specified, and a path exists that meets other TE constraints (other than the SRLG constraint), then the bypass or detour is still set up.

• Secondary LSP backup

  The SRLG constraint can also be enabled per LSP path on a head-end LER in the computation of an LSP secondary path that includes the standby path. The SRLG constraint is additional to the admin group constraint on the same secondary LSP path. CSPF includes the SRLG constraint in the computation of the secondary LSP path, which requires that the primary LSP path is configured and active. CSPF prunes links with interfaces that belong to the same SRLGs as the interfaces included in the primary path. If a path is found, the secondary LSP path is set up. Otherwise, CSPF keeps trying to set up the secondary LSP path.

You can enable only the SRLG constraint for the FRR backup operation. However, you can enable both the SRLG constraint and the admin-group include/exclude constraint for the secondary LSP backup path operation. In either case, you can still apply the admin-group constraint for the primary path.

The following conditions also apply to SRLGs:

• An SRLG is modeled as a policy object. It therefore follows the normal policy behavior for creation, listing, updating, deletion, distribution and resynchronization

• SRLGs are defined node-wide

• Configured SRLGs are associated with MPLS interfaces. A specific MPLS interface can belong to multiple SRLGs. Up to 64 SRLGs can be associated with a specific MLPLS interface

Bandwidth-based equal cost RSVP LSP path selection

When multiple equal-cost paths satisfy the constraints of a specific RSVP LSP path, CSPF in the 7x50 head-end NE uses a random number generator to choose a path and return it to MPLS. While this method actually balances the number of LSP paths over the links in the network, it does not necessarily balance the bandwidth utilization across those links.

In order to achieve load balancing of the bandwidth amongst the available LSP paths, CSPF must include the link utilization as a criterion in the path selection. One algorithm that considers this is referred to as the “least-fill” path selection. This algorithm identifies the single link in each of the equal-cost paths that has the least available bandwidth in proportion to its maximum reservable bandwidth. CSPF then selects the path containing the link with the largest such available bandwidth to maximum reservable bandwidth percentage. The net effect of using this algorithm is that over time, LSP paths become spread over the network links in such a way that the percentage of link utilization is balanced.

When comparing the percentages of least available link bandwidth across the sorted paths, if two percentages differ by less than a value you configure as a minimum threshold, CSPF considers them equal. It then applies a random number generator to choose amongst these paths. You can also specify a reoptimization threshold, which allows you include a path cost consideration into the decision of when to alter the paths used by the LSP.

LSP on-demand resynchronization

LSP on-demand resynchronization is supported on the 7750 SR and 7950 XRS. On-demand resynchronization does not affect the existing manual full NE resynchronization functionality. However, when LSP on-demand resynchronization is enabled, any scheduled resynchronization is blocked for the following LSP objects:

RSVP session cross-connect in-segment

out-segment actual hop CSPF hop

Therefore, these LSP objects are not resynchronized as a result of a relevant trap. The exception is that for CPAM path monitored LSPs, the actual hop trap (a generic trap) is still processed.

By default, the LSP on-demand resynchronization functionality is disabled. See the procedure to enable LSP on-demand resynchronization in the NSP System Administrator Guide for more information. After you enable LSP on-demand resynchronization, click on the Resync button on the LSP configure form to start the manual LSP on-demand resynchronization. The following objects are resynchronized, depending on the type of LSP:

• for a Dynamic LSP: the LSP, LSP path, CSPF and actual paths, bypass or detour path, cross-connects, in-segments, out-segments, and RSVP sessions

• for a Manual Bypass LSP: the LSP, LSP path, CSPF and actual paths, cross-connects, in-segments, out-segments, and RSVP sessions

• for a Static LSP: the head-end LSP, the static hops, static label maps, cross-connects, in-segments, and out-segments. You must manually resynchronize all of the planned hop sites in a Static LSP before creating a Static LSP.

Administrative tagging

An administrative tag is an identifier you can apply to a dynamic LSP, a segment routing LSP, or an LSP template. You can use an administrative tag policy to include or exclude tags from automatic tunnel binding, giving you explicit control over which LSPs are used by a given BGP site or VPRN service.

Workflow for configuring administrative LSP tagging

The following workflow describes the steps to tag an LSP and enable administrative tagging filtering on a BGP site or VPRN service.

1. Create administrative LSP tags. See To create an administrative LSP tag.

2. Create administrative LSP tag policies. See To create an administrative tag policy.

3. Distribute the created tags and tag policies to NEs where you need to perform administrative tagging filtering. See To release and distribute a policy.

4. Associate administrative LSP tags with dynamic LSPs, segment routing LSPs, or LSP templates using the Admin Tags tab on the configuration form for each object. See To create a Dynamic LSP, To configure a Dynamic or segment routing TE LSP, To create a Dynamic or segment routing LSP from a tunnel template, and To create a segment routing TE LSP for general information about configuring these LSPs.

5. Enable the Enforce Strict Tunnel Tagging parameter on BGP sites and VPRN services where you need to use administrative LSP tagging.

Forwarding policies

An MPLS forwarding policy allows you to direct traffic flows to certain endpoints or endpoint groups. There are two types of MPLS forwarding policy, endpoint policies and label-binding policies:

• An endpoint policy forwards unlabeled packets over a set of direct, indirect, or LSP next-hops. Routes are bound to an endpoint policy when their next-hop matches the endpoint address of the policy.

• A label-binding policy forwards labeled packets matching the ILM of the policy label over the next-hops defined in the policy.

The NFM-P supports configuring endpoint policies on MPLS instances. See To create a reserved label block for information about creating reserved label blocks for use with forwarding policies. See To configure an MPLS instance for information about configuring MPLS, including configuring forwarding policies.