PCEP Configuration

Understanding MPLS RSVP-TE

Traffic engineering (TE) deals with performance optimization of operational networks, mainly mapping traffic flows onto an existing physical topology. Traffic engineering provides the ability to move traffic flow away from the shortest path selected by the interior gateway protocol (IGP) and onto a potentially less congested physical path across a network.

For traffic engineering in large, dense networks, MPLS capabilities can be implemented because they potentially provide most of the functionality available from an overlay model, in an integrated manner, and at a lower cost than the currently competing alternatives. The primary reason for implementing MPLS traffic engineering is to control paths along which traffic flows through a network. The main advantage of implementing MPLS traffic engineering is that it provides a combination of the traffic engineering capabilities of ATM, along with the class-of-service (CoS) differentiation of IP.

In an MPLS network, data plane information is forwarded using label switching. A packet arriving on a provider edge (PE) router from the customer edge (CE) router has labels applied to it, and it is then forwarded to the egress PE router. The labels are removed at the egress router and it is then forwarded out to the appropriate destination as an IP packet. The label-switching routers (LSRs) in the MPLS domain use label distribution protocols to communicate the meaning of labels used to forward traffic between and through the LSRs. RSVP-TE is one such label distribution protocol that enables an LSR peer to learn about the label mappings of other peers.

When both MPLS and RSVP are enabled on a router, MPLS becomes a client of RSVP. The primary purpose of the Junos OS RSVP software is to support dynamic signaling within label-switched paths (LSPs). RSVP reserves resources, such as for IP unicast and multicast flows, and requests quality-of-service (QoS) parameters for applications. The protocol is extended in MPLS traffic engineering to enable RSVP to set up LSPs that can be used for traffic engineering in MPLS networks.

When MPLS and RSVP are combined, labels are associated with RSVP flows. Once an LSP is established, the traffic through the path is defined by the label applied at the ingress node of the LSP. The mapping of label to traffic is accomplished using different criteria. The set of packets that are assigned the same label value by a specific node belong to the same forwarding equivalence class (FEC), and effectively define the RSVP flow. When traffic is mapped onto an LSP in this way, the LSP is called an LSP tunnel.

LSP tunnels are a way to establish unidirectional label-switched paths. RSVP-TE builds on the RSVP core protocol by defining new objects and modifying existing objects used in the PATH and RESV objects for LSP establishment. The new objects—LABEL-REQUEST object (LRO), RECORD-ROUTE object (RRO), LABEL object, and EXPLICIT-ROUTE object (ERO)—are optional with respect to the RSVP protocol, except for the LRO and LABEL objects, which are both mandatory for establishing LSP tunnels.

In general, RSVP-TE establishes a label-switched path that ensures frame delivery from ingress to egress router. However, with the new traffic engineering capabilities, the following functions are supported in an MPLS domain:

• Possibility to establish a label-switched path using either a full or partial explicit route (RFC 3209).

• Constraint-based LSP establishment over links that fulfill requirements, such as bandwidth and link properties.

• Endpoint control, which is associated with establishing and managing LSP tunnels at the ingress and egress routers.

• Link management, which manages link resources to do resource-aware routing of traffic engineering LSPs and to program MPLS labels.

• MPLS fast reroute (FRR), which manages the LSPs that need protection and assigns backup tunnel information to these LSPs.

Current MPLS RSVP-TE Limitations

Although the RSVP extensions for traffic engineering enable better network utilization and meet requirements of classes of traffic, today’s MPLS RSVP-TE protocol suite has several issues inherent to its distributed nature. This causes a number of issues during contention for bisection capacity, especially within an LSP priority class where a subset of LSPs share common setup and hold priority values. The limitations of RSVP-TE include:

• Lack of visibility of individual per-LSP, per-device bandwidth demands—The ingress routers in an MPLS RSVP-TE network establish LSPs without having a global view of the bandwidth demand on the network. Information about network resource utilization is only available as total reserved capacity by traffic class on a per interface basis. Individual LSP state is available locally on each label edge router (LER) for its own LSPs only. As a result, a number of issues related to demand pattern arise, particularly within a common setup and hold priority.

• Asynchronous and independent nature of RSVP signaling—In RSVP-TE, the constraints for path establishment are controlled by an administrator. As such, bandwidth reserved for an LSP tunnel is set by the administrator and does not automatically imply any limit on the traffic sent over the tunnel. Therefore, bandwidth available on a traffic engineering link is the bandwidth configured for the link, excluding the sum of all reservations made on the link. Thus, the unsignaled demands on an LSP tunnel lead to service degradation of the LSP requiring excess bandwidth, as well as the other LSPs that comply with the bandwidth requirements of the traffic engineering link.

• LSPs established based on dynamic or explicit path options in the order of preference—The ingress routers in an MPLS RSVP-TE network establish LSPs for demands based on the order of arrival. Because the ingress routers do not have a global view of the bandwidth demand on the network, using the order of preference to establish LSPs can cause traffic to be dropped or LSPs not being established at all when there is an excess of bandwidth demand.

As an example, Figure 2 is configured with MPLS RSVP-TE, in which A and G are the label edge routers (LERs). These ingress routers establish LSPs independently based on the order of demands and have no knowledge or control over each other’s LSPs. Routers B, C, and D are intermediate or transit routers that connect to the egress routers E and F.

Figure 2: Example MPLS Traffic Engineering

The ingress routers establish LSPs based on the order in which the demands arrive. If Router G receives two demands of capacity 5 each for G-F, then G signals two LSPs – LSP1 and LSP2 – through G-B-D-F. In the same way, when Router A receives the third demand of capacity 10 for A-E, then it signals an LSP, LSP3, through A-B-C-E. However, if the demand on the A-E LSP increases from 10 to 15, Router A cannot signal LSP3 using the same (A-B-C-E) path, because the B-C link has a lower capacity.

Router A should have signaled the increased demand on LSP3 using the A-B-D-C-E path. Since LSP1 and LSP2 have utilized the B-D link based on the order of demands received, LSP3 is not signaled.

Thus, although adequate max-flow bandwidth is available for all the LSPs, LSP3 is subject to potentially prolonged service degradation. This is due to Router A’s lack of global demand visibility and the lack of systemic coordination in demand placement by the ingress routers A and G.

Use of an External Path Computing Entity

As a solution to the current limitations found in the MPLS RSVP-TE path computation, an external path computing entity with a global view of per-LSP, per-device demand in the network independent of available capacity is required.

Currently, only online and real-time constraint-based routing path computation is provided in an MPLS RSVP-TE network. Each router performs constraint-based routing calculations independent of the other routers in the network. These calculations are based on currently available topology information—information that is usually recent, but not completely accurate. LSP placements are locally optimized, based on current network status. The MPLS RSVP-TE tunnels are set up using the CLI. An operator configures the TE LSP, which is then signaled by the ingress router.

In addition to the existing traffic engineering capabilities, the MPLS RSVP-TE functionality is extended to include an external path computing entity, called the Path Computation Element (PCE). The PCE computes the path for the TE LSPs of ingress routers that have been configured for external control. The ingress router that connects to a PCE is called a Path Computation Client (PCC). The PCC is configured with the Path Computation Client Protocol (PCEP) to facilitate external path computing by a PCE.

For more information, see Components of External Path Computing.

To enable external path computing for a PCC’s TE LSPs, include the lsp-external-controller pccd statement at the [edit mpls] and [edit mpls lsp lsp-name] hierarchy levels.

Components of External Path Computing

The components that make up an external path computing system are:

• Path Computation Element
• Path Computation Client
• Path Computation Element Protocol

Interaction Between a PCE and a PCC Using PCEP

Figure 3 illustrates the relationship between a PCE, PCC, and the role of PCEP in the context of MPLS RSVP-TE.

Figure 3: PCC and RSVP-TE

The PCE to PCC communication is enabled by the TCP-based PCEP. The PCC initiates the PCEP session and stays connected to a PCE for the duration of the PCEP session.

Once the PCEP session is established, the PCC performs the following tasks:

1. LSP state synchronization—The PCC sends information about all the LSPs (local and external) to all connected PCEs. For external LSPs, the PCC sends information about any configuration change, RRO change, state change, and so on, to the PCE.

   For PCE-initiated LSPs, there is no LSP configuration present on the PCC. The PCE initiating the LSP sends the LSP parameters to the PCC that has indicated its capability of supporting PCE-initiated LSPs.

   Note:

   Support for PCE-initiated LSPs is provided in Junos OS Release 13.3 and later releases.

2. LSP delegation—After the LSP state information is synchronized, the PCC then delegates the external LSPs to one PCE, which is the main active stateful PCE. Only the main PCE can set parameters for the external LSP. The parameters that the main PCE modifies include bandwidth, path (ERO), and priority (setup and hold). The parameters specified in the local configuration are overridden by the parameters that are set by the main PCE.

   Note:

   When the PCEP session with the main PCE is terminated, the PCC elects a new main PCE, and all delegated LSPs to the previously main PCE are delegated to the newly available main PCE.

   In the case of PCE-initiated LSPs, the PCC creates the LSP using the parameters received from the PCE. The PCC assigns the PCE-initiated LSP a unique LSP-ID, and automatically delegates the LSP to the PCE. A PCC cannot revoke the delegation for the PCE-initiated LSPs for an active PCEP session.

   When a PCEP session terminates, the PCC starts two timers without immediately deleting the PCE-initiated LSPs – delegation cleanup timeout and lsp cleanup timer – to avoid disruption of services. During this time, an active stateful PCE can acquire control of the LSPs provisioned by the failed PCE, by sending a create request for the LSP.

   Control over PCE-initiated LSPs reverts to the PCC at the expiration of the delegation cleanup timeout. When the delegation cleanup timeout expires, and no other PCE has acquired control over the LSP from the failed PCE, the PCC takes local control of the non-delegated PCE-initiated LSP. Later, when the original or a new active stateful PCE wishes to acquire control of the locally controlled PCE-initiated LSPs, the PCC delegates these LSPs to the PCE and the lsp cleanup timer timer is stopped.

   A PCE may return the delegation of the PCE-initiated LSP to the PCC to allow LSP transfer between PCEs. This triggers the lsp cleanup timer for the PCE-initiated LSP. The PCC waits for the LSP cleanup timer to expire before removing the non-delegated PCE-initiated LSPs from the failed PCE.

   When the lsp cleanup timer expires, and no other PCE has acquired control over the LSPs from the failed PCE, the PCC deletes all the LSPs provisioned by the failed PCE.

   Note:

   In compliance with draft-ietf-pce-stateful-pce-09, revoking of PCE-initiated LSP delegations by a PCC happens in a make-before-break fashion before the LSPs are redelegated to an alternate PCE. Starting in Junos OS Release 18.1R1, the lsp-cleanup-timer must be greater than or equal to the delegation-cleanup-timeout for the PCC to revoke the LSP delegations. If not, the redelegation timeout interval for the PCC can be set to infinity, where the LSP delegations to that PCE remain intact until specific action is taken by the PCC to change the parameters set by the PCE.

3. LSP signaling—On receiving one or more LSP parameters from the main active stateful PCE, the PCC re-signals the TE LSP based on the PCE provided path. If the PCC fails to set up the LSP, it notifies the PCE of the setup failure and waits for the main PCE to provide new parameters for that LSP, and then re-signals it.

   When the PCE specifies a path that is incomplete or has loose hops where only the path endpoints are specified, the PCC does not perform local constraint-based routing to find out the complete set of hops. Instead, the PCC provides RSVP with the PCE provided path, as it is, for signaling, and the path gets set up using IGP hop-by-hop routing.

Considering the topology used in Figure 2, Figure 4 illustrates the partial client-side PCE implementation in the MPLS RSVP-TE enabled network. The ingress routers A and G are the PCCs that are configured to connect to the external stateful PCE through a TCP connection.

The PCE has a global view of the bandwidth demand in the network and performs external path computations after looking up the traffic engineering database. The active stateful PCE then modifies one or more LSP attributes and sends an update to the PCC. The PCC uses the parameters it receives from the PCE to re-signal the LSP.

Figure 4: Example PCE for MPLS RSVP-TE

This way, the stateful PCE provides a cooperative operation of distributed functionality used to address specific challenges of a shortest interdomain constrained path computation. It eliminates congestion scenarios in which traffic streams are inefficiently mapped onto available resources, causing overutilization of some subsets of network resources, while other resources remain underutilized.

LSP Behavior with External Computing

• LSP Types
• LSP Control Mode

Configuration Statements Supported for External Computing

Table 1 lists the MPLS and existing LSP configuration statements that apply to a PCE-controlled LSP.

The rest of the LSP configuration statements are applicable in the same way as for existing LSPs. On configuring any of the above configuration statements for a PCE-controlled LSP, an MPLS log message is generated to indicate when the configured parameters take effect.

PCE-Controlled LSP Protection

The protection paths, including fast reroute and bypass LSPs, are locally computed by the PCC using constraint-based routing. A stateful PCE specifies the primary path (ERO) only. A PCE can also trigger a non-standby secondary path, even if the local configuration does not have a non-standby secondary path for LSP protection.

PCE-Controlled LSP ERO

For PCE-controlled LSPs (PCC-delegated LSPs and PCE-initated LSPs), only a full-blown Explicit Route Object (ERO) object has to be sent from the PCE to the PCC; otherwise the PCC rejects the PCUpdate or PCCreate message for that PCEP session.

Starting in Junos OS Release 17.2, in addition to external cspf, two new path computation types are introduced for the PCE-controlled LSPs: local cspf and no cspf.

• local cspf—A PCC uses the local cspf computation type only when the PCE sends in a Juniper Vendor TLV (enterprise number: 0x0a4c) of type 5.

• no cspf—Neither the PCE nor the PCC performs a constrained path calculation. The endpoints and constraints are given to the RSVP module for setting up the LSP with the IGP path.

  A PCC uses no cspf computation type in the following cases:

  • When the PCE sends local cspf TLV, and when the Junos OS configuration or matching template for this LSP included no-cspf in the PCC-delegated LSP.

  • When the PCE sends local cspf TLV, and when the Junos OS configuration template for this LSP included no-cspf in the PCE-initiated LSP.

  • When the PCE does not send local cspf TLV with an empty ERO or loose ERO (with loose bit set in the ERO object).

With these new computation types, a PCC can accept an ERO object either as a loose ERO, or as an empty ERO. An external path computing entity that is not capable of computing a path can modify parameters such as bandwidth and color, based on the analytics. In such cases, an empty ERO object or loose ERO is used and the path to be taken is decided by the PCC.

PCE-Controlled Point-to-Multipoint RSVP-TE LSPs

After a PCEP session is established between a PCE and a PCC, the PCC reports all the LSPs in the system to the PCE for LSP state synchronization. This includes PCC-controlled, PCE-delegated, and PCE-initiated point-to-point LSPs. Starting with Junos OS Release 15.1F6 and 16.1R1, this capability is extended to report point-to-multipoint LSPs as well. For a PCE, the point-to-multipoint LSP is similar to that of RSVP point-to-multipoint LSP, where the point-to-multipoint LSP is treated as collection of point-to-point LSPs grouped under a point-to-multipoint identifier.

By default, PCE control of point-to-multipoint LSPs is not supported on a PCC. To add this capability, include the p2mp-lsp-report-capability statement at the [edit protocols pcep pce pce-name] or [edit protocols pcep pce-group group-id] hierarchy levels. After the point-to-multipoint report capability is configured on a PCC, the PCC advertises this capability to the PCE. If the PCE advertises the same point-to-multipoint report capability in return, then the PCC reports the complete point-to-multipoint LSP tree to the PCE for LSP state synchronization.

A PCC with the point-to-multipoint TE LSP capability supports reporting of point-to-multipoint TE LSPs for stateful PCEs, point-to-multipoint update, and LSP database supporting point-to-multipoint LSP name as key. However, the following features and functions are not supported for Junos OS Release 15.1F6 and 16.1:

• Static point-to-multipoint LSPs

• PCE-delegated and PCE-initiated point-to-multipoint LSPs

• Auto-bandwidth

• TE++

• PCE request and reply message

• Creation of point-to-multipoint LSPs using templates

• Configuring forward entry on the PCE-initiated point-to-multipoint LSPs

• Configuring forward entry on the router pointing to a provisioned LSP.

PCE-Initiated Point-to-Point LSPs

Starting with Junos OS Release 16.1, the PCEP functionality is extended to allow a stateful PCE to initiate and provision traffic engineering LSPs through a PCC. Earlier, the LSPs were configured on the PCC and the PCC delegated control over the external LSPs to a PCE. The ownership of the LSP state was maintained by the PCC. With the introduction of the PCE-initiated LSPs, a PCE can initiate and provision a traffic engineering point-to-point LSP dynamically without the need for a locally configured LSP on the PCC. On receiving a PCCreate message from a PCE, the PCC creates the PCE-initiated LSP and automatically delegates the LSP to the PCE.

By default, a PCC rejects the request for provisioning PCE-initiated point-to-point LSPs from a PCE. To enable support of PCE-initated LSPs on the PCC, include the lsp-provisioning statement at the [edit protocols pcep pce pce-id] or [edit protocols pcep pce-group group-id] hierarchy levels.

A PCC indicates its capability of supporting PCE-initiated point-to-point LSPs while establishing the Path Computation Element Protocol (PCEP) session with the PCE. A PCE selects a PCC with this capability to initiate an LSP. The PCE provides the PCC with the PCE-initiated LSP parameters. On receiving the PCE-initiated point-to-point LSP parameters, the PCC sets up the LSP, assigns an LSP ID, and automatically delegates the LSP to the PCE.

When the PCE initiating the LSP does not provide the PCE-initiated point-to-point LSP parameters, the PCC uses the default parameters. An optional LSP template may also be configured to specify values for the PCE-initiated point-to-point LSP when the LSP parameters are not provided by the PCE. To configure an LSP template for PCE-initiated point-to-point LSPs on the PCC, include the label-switched-path-template statement at the [edit protocols mpls lsp-external-controller lsp-external-controller] hierarchy level.

When a PCEP session terminates, the PCC starts two timers without immediately deleting the PCE-initiatedLSPs—delegation cleanup timeout and lsp cleanup timer—to avoid disruption of services. During this time, an active stateful PCE can acquire control of the LSPs provisioned by the failed PCE.

A PCE may return the delegation of the PCE-initiated point-to-point LSP to the PCC to allow LSP transfer between PCEs. Control over PCE-initiated LSPs reverts to the PCC at the expiration of the delegation cleanup timeout. When the delegation cleanup timeout expires, and no other PCE has acquired control over the LSP from the failed PCE, the PCC takes local control of the non-delegated PCE-initiated LSP. Later, when the original or a new active stateful PCE wishes to acquire control of the locally controlled PCE-initiated point-to-point LSPs, the PCC delegates these LSPs to the PCE and the LSP cleanup timer is stopped.

The PCC waits for the LSP cleanup timer to expire before deleting the non-delegated PCE-initiated point-to-point LSPs from the failed PCE. When the LSP cleanup timer expires, and no other PCE has acquired control over the LSPs from the failed PCE, the PCC deletes all the LSPs provisioned by the failed PCE.

Starting in Junos OS Release 21.1R1, we support nonstop active routing (NSR) for PCE-initiated RSVP-based point-to-point and point-to-multipoint LSPs. Only the primary Routing Engine maintains the PCEP session with the controller. It synchronizes all RSVP LSPs initiated by PCEs, including multicast flow specifications for any PCE-initiated P2MP LSPs, with the backup Routing Engine. During a switchover, the PCEP session goes down and re-establishes when the backup Routing Engine becomes the primary Routing Engine. This reduces traffic loss for the traffic carried over PCE-initiated RSVP LSPs during Routing Engine switchovers. This feature is enabled when NSR is configured.

PCE-Initiated Bypass LSP

• Understanding PCE-Initiated Bypass LSPs
• Benefits of PCE-Initiated Bypass LSP
• Behavior of PCE-Initiated Bypass LSPs During PCEP Session Failure

PCE-Initiated Point-to-Multipoint LSPs

With the introduction of point-to-multipoint PCE-initiated LSPs, a PCE can initiate and provision a point-to-multipoint LSP dynamically without the need for local LSP configuration on the PCC. This enables the PCE to control the timing and sequence of the point-to-multipoint path computations within and across Path Computation Element Protocol (PCEP) sessions, thereby creating a dynamic network that is centrally controlled and deployed.

For more information, see Understanding Path Computation Element Protocol for MPLS RSVP-TE with Support for PCE-Initiated Point-to-Multipoint LSPs.

SRv6 LSP in PCEP

Segment routing can be applied to both MPLS and IPv6 forwarding plane. The Path Computation Element (PCE) computes SR paths for both MPLS and IPv6 forwarding plane. Segment routing for PCEP supports SR LSPs such as PCE-initiated, locally created, and delegated SR LSPs in IPv6 forwarding plane.

Benefits of SRv6 LSPs in PCEP

• Allows you to create PCE initiated SRv6 LSPs.
• Delegate the SRv6 LSPs created on the router to the controller.
• Report the LSPs which are locally created on the router to the controller.
• SRv6 network programming provides the flexibility to leverage segment routing without deploying MPLS.

PCEP supports creation, updation, and deletion of PCE initiated colored and uncolored SRv6 LSPs. When PCE initiated SRv6 LSP co-exists along with a static SRv6 LSP for the same IP or color-based IP, then the static SRv6 TE LSP contributing route is preferred over PCE initiated SRv6 TE LSP contributing route.

To configure a PCEP session to be SRv6 capable, you need to enable the srv6-capability configuration statement at the [edit protocols pcep pce pce-id] or at the [edit protocols pcep pce-group pce-id] hierarchy levels. If the srv6-capability configuration statement is enabled, then you must also enable srv6 configuration statement at the [edit protocols source-packet-routing] hierarchy level otherwise during commit and error will be displayed.

To configure SRv6 for SR-TE, you need to add the srv6 configuration statement at the [edit protocols source-packet-routing] hierarchy level.

[See Understanding SR-TE Policy for SRv6 Tunnel for more information.

To configure the maximum segment list depth for SRv6 LSP, you need to enable the maximum-srv6-segment-list-depth configuration statement at the [edit protocols pcep] hierarchy level.

Auto-Bandwidth and PCE-Controlled LSP

Starting in Junos OS Release 14.2R4, support of auto-bandwidth is provided for PCE-controlled LSPs. In earlier releases, the auto-bandwidth option did not apply to PCE-controlled LSPs, although LSPs under the control of auto-bandwdith and constraint-based routing could coexist with PCE-controlled LSPs. The statistics collection for auto-bandwidth was taking effect only when the control mode of a PCE-controlled LSP changes from external to local. This was happening in cases such as no connectivity to a PCE or when a PCE returns delegation of LSPs back to the PCC.

TCP-MD5 Authentication for PCEP Sessions

A stateful PCE server automates the creation of traffic engineering paths across the network, increasing network utilization and enabling a customized programmable networking experience with the use of PCEP communication with a PCC. A PCC sends LSP reports to a PCE server, and the PCE updates or provisions LSPs back to the PCC. The data sent over a PCEP session is crucial for a PCE server to perform external path computing. As a result, an attack on the PCEP communication can disrupt network services. If altered PCEP messages are sent to a PCC, inappropriate LSPs can be set up. Similarly, if altered PCEP messages are sent to a PCE, an incorrect view of the network is learned by the PCE.

Considering the significance of the PCEP communication between a PCE and PCC in executing the PCE functionalities effectively, Junos OS Release 16.1 introduces the feature of securing a PCEP session using TCP-MD5 authentication as per RFC 5440. This feature protects the communication between a PCE and PCC over a PCEP session, which might be subject to an attack, and can disrupt network services.

To enable the MD5 security mechanism for a PCEP session, it is recommended that you define and bind the MD5 authentication key at the [edit protocols pcep pce pce-id] hierarchy level for a PCEP session. You can, however, also use a predefined keychain from the [edit security authentication-key-chains key-chain] hierarchy level to secure a PCEP session. In this case, you should bind the predefined keychain into the PCEP session at the [edit protocols pcep pce pce-id] hierarchy level.

The following configuration is executed on the PCC to establish a secure PCEP session with a PCE:

• Using MD5 authentication key:

• Using predefined authentication keychain:

For secure PCEP sessions to be established successfully, the MD5 authentication should be configured with the pre-shared authentication key on both the PCE server and the PCC. The PCE and PCC use the same key to verify the authenticity of each segment sent on the TCP connection of the PCEP session.

Impact of Client-Side PCE Implementation on Network Performance

The maintenance of a stateful database can be non-trivial. In a single centralized PCE environment, a stateful PCE simply needs to remember all the TE LSPs that the PCE has computed, the TE LSPs that were actually set up (if this can be known), and when the TE LSPs were torn down. However, these requirements cause substantial control protocol overhead in terms of state, network usage and processing, and optimizing links globally across the network. Thus, the concerns of a stateful PCE implementation include:

• Any reliable synchronization mechanism results in significant control plane overhead. PCEs might synchronize state by communicating with each other, but when TE LSPs are set up using distributed computation performed among several PCEs, the problems of synchronization and race condition avoidance become larger and more complex.

• Out-of-band traffic engineering database synchronization can be complex with multiple PCEs set up in a distributed PCE computation model, and can be prone to race conditions, scalability concerns, and so on.

• Path calculations incorporating total network state is highly complex, even if the PCE has detailed information on all paths, priorities, and layers.

In spite of the above concerns, the partial client-side implementation of the stateful PCE is extremely effective in large traffic engineering systems. It provides rapid convergence and significant benefits in terms of optimal resource usage, by providing the requirement for global visibility of a TE LSP state and for ordered control of path reservations across devices within the system being controlled.

Benefits of PCE-Initiated Point-to-Multipoint LSPs

Meets the requirements of point-to-multipoint traffic engineering LSP placement in response to application demands through dynamic creation and tear down of point-to-multipoint LSPs, thereby creating a dynamic network that is centrally controlled and deployed.

Signaling of PCE-Initiated Point-to-Multipoint LSPs

The signaling of PCE-initiated point-to-multipoint LSPs is as follows:

• When a new branch is added (Grafting)—Only the new branch sub-LSP is signaled and does not result in re-signaling of the entire point-to-multipoint tree.

  If any topology changes occurred before provisioning of the new sub-LSP, then the Path Computation Server (PCS) re-computes the entire point-to-multipoint tree and updates the point-to-multipoint LSP using a PC update message.

• When a branch is deleted (Pruning)—The deleted branch sub-LSP is torn down and does not result in re-signaling of the entire point-to-multipoint tree.

• When a branch sub-LSP parameter is changed—Change in sub-LSP parameters, such as Explicit Route Object (ERO), bandwidth, or priority, can happen either because of optimization, or on user request. If there is a re-signaling request for a sub-LSP, the entire point-to-multipoint tree is re-signaled, and then the switchover to the new instance happens once the new instances of all the branches are up.

• When a branch sub-LSP path fails—An error is reported to the PCS for the failed branch sub-LSP. On receiving the new ERO from the PCS, the entire point-to-multipoint tree is re-signaled along with the failed branch sub-LSP, and the switchover to the new instance happens in a make-before-break (MBB) fashion.

Behavior of PCE-Initiated Point-to-Multipoint LSPs After PCEP Session Failure

When a PCEP session fails, the PCE-initiated point-to-multipoint LSPs are orphaned until the expiration of the state timeout timer. After the state timeout timer expires, the PCE-initiated LSPs are cleaned up.

To obtain control of a PCE-initiated point-to-multipoint LSP after a PCEP session failure, the primary or secondary PCE sends a PCInitiate message before the state timeout timer expires.

Configuring PCE-Initiated Point-to-Multipoint LSP Capability

By default, the creation and provisioning of point-to-multipoint LSPs by a PCE is not supported on a PCC. To enable this capability, include the p2mp-lsp-init-capability and p2mp-lsp-update-capability statements at the [edit protocols pcep pce pce-name] or [edit protocols pcep pce-group group-id] hierarchy levels.

The p2mp-lsp-init-capability statement provides the capability to provision point-to-multipoint RSVP-TE LSPs by a PCE. The p2mp-lsp-update-capability statement provides the capability to update point-to-multipoint RSVP-TE LSP parameters by a PCE.

Supported and Unsupported Features for PCE-Initiated Point-to-Multipoint LSPs

The following features are supported with PCE-initiated point-to-multipoint LSPs:

• Partial compliance with the Internet draft draft-ietf-pce-stateful-pce-p2mp (expires October 2018), Path Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths.

• Starting in Junos OS Release 21.1R1, we support nonstop active routing (NSR) for PCE-initiated RSVP-based point-to-multipoint LSPs. Only the primary Routing Engine maintains the PCEP session with the controller. It synchronizes all RSVP LSPs initiated by PCEs, including multicast flow specifications for any PCE-initiated P2MP LSPs, with the backup Routing Engine. During a switchover, the PCEP session goes down and re-establishes when the backup Routing Engine becomes the primary Routing Engine. This reduces traffic loss for the traffic carried over PCE-initiated RSVP LSPs during Routing Engine switchovers. This feature is enabled when NSR is configured.

The following features are not supported with PCE-initiated point-to-multipoint LSPs:

• Delegation of point-to-multipoint locally controlled LSP.

• LSP control delegation.

• Interior gateway protocol (IGP) extension for PCE discovery within an IGP routing domain.

• Request/response messaging.

• Direct movement of branch sub-LSP from one point-to-multipoint tree to another.

  The same can be achieved by deleting a branch sub-LSP from the first point-to-multipoint tree and re-adding it to another after the PCReport message indicates LSP removal from the device.

• IPv6 is not supported.

• SERO based signalling is not supported.

• Empty-ERO feature is not supported.

• Link protection is not supported.

Mapping PCE-initiated Point-To-Multipoint LSPs to MVPN

You can associate a single or range of MVPN multicast flows (S,G) to a dynamically created PCE-initiated point-to-multipoint label-switched path (LSP). You can specify only selective types of flows for this feature to work. This includes:

• Route distinguisher (RD) which is mapped to the MVPN routing-instance.

• (S,G) which is the source of a multicast packet and destination multicast group address. This is used to filter incoming traffic for mapping it to the tunnel.

• Point-to-multipoint LSP that is used to send traffic that matches the above-mentioned flow specification.

For more details, see Internet draft draft-ietf-pce-pcep-flowspec-05 (expires February 16, 2020) PCEP Extension for Flow Specification.

The current implementation of this feature does not implement the following sections of the draft:

• Section 3.1.2—Advertising PCE capabilties in IGP

• Section 3.2—PCReq and PCRep message

• Section 7—Most of the flow specifications, except route distinguThe current implementation of this feature does not supporisher and IPv4 multicast flow specifications, are not supported.

To enable the mapping of PCE-initiated point-to-multipoint LSPs to MVPN:

• Include the pce_traffic_steering statement at the [edit protocols pcep pce pce-id] hierarchy level to indicate the support for flow specification capability (also called traffic steering) by the PCC.

• Include the external-controller statement at the [edit routing-instances routing-instance-name provider-tunnel] hierarchy level.

  The presence of external-controller in the provider-tunnel configuration for MVPN indicates that the point-to-multipoint LSP and (S,G) for this MVPN instance can be provided by the external controller. This enables the external controller to dynamically configure (S,G) and point-to-multipoint LSP for MVPN.

Take the following into consideration for mapping of PCE-initiated point-to-multipoint LSPs to MVPN:

• If you do not enable the external-controller pccd statement for a particular MVPN instance, then the PCCD process does not configure (S,G) dynamically.

• If you disable the external-controller pccd configuration from the CLI, then the dynamically learned multicast flows (S,G) for that particular MVPN instance is deleted and reported to the external controller.

• When (S,G) is already configured from the CLI, the PCC cannot configure (S,G) dynamically as local configuration has a higher priority.

• If any particular (S,G) is learned from the external controller dynamically and then you configure the same (S,G) for the same MVPN instance, then the dynamically learned (S,G) is deleted and reported to the external controller through the PCC.

• If the routing protocol process reboots, then the PCCD process reconfigures all the (S,G) again.

• If the PCCD process reboots, then MVPN reports all PCCD configured (S,G) to the external controller.

• If user enables external-controller pccd for a particular MVPN instance, then MVPN requests the PCCD process to configure (S,G), if any present.

• If there are major configuration changes to a particular MPVN instance, then MVPN requests the PCCD process to reconfigure all (S,G) for that particular MVPN instance.

• All flow specifications associated with any PCE-initiated point-to-multipoint LSP must have the same RD. During PC initiation if all flow specifications do not have the same RD, then the PC initiate message is dropped with an error.

• You can associate a point-to-multipoint LSP only with selective type of flow specifications, otherwise the PC initiate message is dropped with an error.

• During PC update if all flow specifications do not have same the RD either due to a new flow specification addition, or due to existing flow specification update, then the PCC drops the update message.

• During PC update if all flow specifications do not meet the selective condition either due to new flow specification addition, or due to existing flow specifications update, then the PCC drops the update message.

• Behavior for mapping of PCE-initiated point-to-multipoint LSP with MVPN routing-instance and mapping of static (locally configured) point-to-multipoint LSP with MVPN instance is the same at user level.

• A flow specification ID can be associated with only one point-to-multipoint LSP. To associate the same RD and (S,G) to multiple point-to-multipoint LSPs, you can add multiple flow specifications with different IDs and same RD & (S,G).

• For PCEP-mapped dynamic (S,G), the threshold value is always the default value of 0.

• There is no limit on the number of flow specifications mapped to a single PCE-initiated point-to-multipoint LSP.

• The current implementation of this feature does not support:

  • Reporting of forwarding states that are associated with the point-to-multipoint LSP.

  • Inclusive provider tunnel dynamic configuration

  • Mapping for MVPN ingress replication tunnel

  • Programmable routing protocol process (prpd)

  • Reporting of CLI configured point-to-multipoint LSP which is mapped to MVPN multicast flows (S,G).

Distributed CSPF Computation Constraints

Segment routing LSP paths are computed when all the configured constraints are met.

The distributed CSPF computation feature supports the following subset of constraints specified in the Internet draft, draft-ietf-spring-segment-routing-policy-03.txt, Segment Routing Policy for Traffic Engineering:

• Inclusion and exclusion of administrative groups.

• Inclusion of loose or strict hop IP addresses.

  Note:

  You can specify only router IDs in the loose or strict hop constraints. Labels and other IP addresses cannot be specified as loose or strict hop constraints in Junos OS Release 19.2R1-S1.

• Maximum number of segment IDs (SIDs) in the segment list.

• Maximum number of segment lists per candidate segment routing path.

The distributed CSPF computation feature for segment routing LSPs does not support the following types of constraints and deployment scenarios:

• IPV6 addresses.

• Inter domain segment routing traffic engineering (SR-TE) LSPs.

• Unnumbered interfaces.

• Multiple protocols routing protocols such as, OSPF, ISIS, and BGP-LS, enabled at the same time.

• Computation with prefixes or anycast addresses as destinations.

• Including and excluding interface IP addresses as constraints.

Distributed CSPF Computation Algorithm

The distributed CSPF computation feature for segment routing LSPs uses the label stack compression algorithm with CSPF.

• Label Stack Compression Enabled
• Label Stack Compression Disabled

Distributed CSPF Computation Database

The database used for SR-TE computation has all links, nodes, prefixes and their characteristics irrespective of whether traffic-engineering is enabled in those advertising nodes. In other words, it is the union of the traffic-engineering database (TED) and the IGP link state database of all domains that the computing node has learnt from. As a result, for CSPF to work, you must include the igp-topology statement at the [edit protocols isis traffic-engineering] hierarchy level.

Configuring Distributed CSPF Computation Constraints

You can use a compute profile to logically group the computation constraints. These compute profiles are referenced by the segment routing paths for computing the primary and secondary segment routing LSPs.

To configure a compute profile, include the compute-profile statement at the [edit protocols source-packet-routing] hierarchy level.

The configuration for the supported computation constraints include:

• Administrative groups

  You can configure admin-groups under the [edit protocols mpls] hierarchy level. Junos OS applies the administrative group configuration to the segment routing traffic-engineering (SR-TE) interfaces.

  To configure the computation constraints you can specify three categories for a set of administrative groups. The computation constraint configuration can be common to all candidate segment routing paths, or it can be under individual candidate paths.

  • include-any—Specifies that any link with at least one of the configured administrative groups in the list is acceptable for the path to traverse.

  • include-all—Specifies that any link with all of the configured administrative groups in the list is acceptable for the path to traverse.

  • exclude—Specifies that any link which does not have any of the configured administrative groups in the list is acceptable for the path to traverse.

• Explicit path

  You can specify a series of router IDs in the compute profile as a constraint for computing the SR-TE candidate paths. Each hop has to be an IPv4 address and can be of type strict or loose. If the type of a hop is not configured, strict is used. You must include the compute option under the segment-list statement when specifying the explicit path constraint.

• Maximum number of segment lists (ECMP paths)

  You can associate a candidate path with a number of dynamic segment-lists. The paths are ECMP paths, where each segment-list translates into a next hop gateway with active weight. These paths are a result of path computation with or without compression.

  You can configure this attribute using the maximum-computed-segment-lists maximum-computed-segment-lists option under the compute-profile configuration statement. This configuration determines the maximum number of such segment lists computed for a given primary and secondary LSP.

• Maximum segment list depth

  The maximum segment list depth computation parameter ensures that amongst the ECMP paths that satisfy all other constraints such as administrative group, only the paths that have segment lists less than or equal to the maximum segment list depth are used. When you configure this parameter as a constraint under the compute-profile, it overrides the maximum-segment-list-depth configuration under the [edit protocols source-packet-routing] hierarchy level, if present.

  You can configure this attribute using the maximum-segment-list-depth maximum-segment-list-depth option under the compute-profile configuration statement.

• Protected or unprotected adjacency SIDs

  You can configure protected or unprotected adjacency SID as a constraint under the compute-profile to avoid links with the specified SID type.

• Metric type

  You can specify the type of metric on the link to be used for computation. By default, SR-TE LSPs use traffic-engineering metrics of the links for computation. The traffic-engineering metric for links is advertised by traffic-engineering extensions of IGP protocols. However, you may also choose to use the IGP-metric for computation by using the metric-type configuration in the compute profile.

  You can configure this attribute using the metric-type (igp | te) option under the compute-profile configuration statement.

Distributed CSPF Computation

The SR-TE candidate paths are computed locally such that they satisfy the configured constraints. When label stack compression is disabled, the multi-path CSPF computation result is a set of adjacency SID stacks. When label stack compression is enabled, the result is a set of compressed label stacks (composed of adjacent SIDs and node SIDs).

When secondary paths are computed, the links, nodes and SRLGs taken by the primary paths are not avoided for computation. For more information on primary and secondary paths, see Configuring Primary and Secondary LSPs.

For any LSPs with unsuccessful computation result, the computation is retried as traffic-engineering database (TED) changes.

Interaction Between Distributed CSPF Computation and SR-TE Features

• Weights Associated With Paths of an SR-TE Policy
• BFD Liveliness Detection
• inherit-label-nexthops
• Auto-Translate Feature

Distributed CSPF Computation Sample Configurations

• Example 1
• Example 2
• Example 3

Benefits of multiple paths for PCEP SR-TE LSPs

• LSPs can have multiple sets of EROs to a destination

• Provides load balancing capabilities by configuring weights for individual EROs

• Aligns with SR-TE architecture draft for defining candidate paths

The following PCEP multiple path capabilities are supported:

• When PCEP for multiple paths is enabled (default), you can configure multiple primary (or one secondary) paths in a PCC configured and controlled candidate path.

• When PCEP for multiple paths is disabled, you can configure only one primary path in a candidate path. Secondary path configuration is not allowed.

If you enable PCEP multipaths, compute-profile can now be configured with maximum number of segment-lists (maximum-computed-segment-lists) greater than 1.

When PCEP multipath capability is enabled, secondary path configuration is allowed for a non-delegated PCC candidate path, the EXPLICIT-ROUTE object (EROs) specific to the secondary path is sent to the PCE with backup flag set for the ERO. Primary paths do not include the MULTIPATH-BACKUP-TLV in the PCRpt message. Secondary path include MULTIPATH-BACKUP-TLV with backup flag set.

The following PCEP multipath functionalities are supported:

• Multipath weight TLV (MULTIPATH-WEIGHT-TLV) in path attribute (PATH-ATTRIB) object

• MULTIPATH-BACKUP TLV in path attribute (PATH-ATTRIB) object only for PCC controlled SR-TE LSPs

• MULTIPATH-CAP TLV in PCEP LSP object

• Restricts multiple primary and secondary paths in SR candidate path when PCEP multipath is disabled

• Multiple primary paths and secondary paths in SR candidate path when PCEP multipath is enabled for PCC controlled LSPs

• Maximum computed segment lists (max-computed-segment-lists) more than 1 in SR-TE compute profile for delegated and PCE-initiated LSPs

• Multiple EROs for PCE-initiated candidate path in SR-TE and in PCCD

• SRv6 LSPs

• SR MPLS (IPv4)

• SR MPLS (IPv4) dynamic tunnels

• Multi-controller support

• Multiple ERO paths for PCE-initiated, PCC-configured and controlled, and delegated colored and uncolored candidate paths

• Backward compatible with earlier versions of Paragon Pathfinder. For backward compatibility, you need to configure disable-multipath-capability configuration statement at the [edit protocols pcep] hierarchy level.

• Error code support for failure in validation of PCE-initiated candidate paths

  • Total sub-candidate paths per candidate path is limited to 127. For PCE initiated LSPs, if the number of ERO paths crosses 127, SR-TE throws ERROR to PCCD (and PCCD sends PCEP error message to PCE) and the corresponding ERO paths are rejected.

The following PCEP error messages are supported:

Limitations

The following PCEP limitations apply:

• The following TLVs mentioned in the draft-ietf-pce-multipath-06 are not supported:

  • Multipath backup TLV

  • Multipath opposite direction path TLV

  • Composite candidate path

• When multipath capability is disabled in PCEP, configuring multiple sub-candidate paths is not allowed. However, on Junos devices without multipath capability (Junos OS versions earlier than 22.4R1), multiple sub-candidate path configuration is allowed. When PCEP multi-segment is enabled (by default), multiple primary paths are allowed for PCC controlled LSPs for the purpose of reporting. However, only one primary path is supported for delegated candidate path when PCEP multi-segment is enabled.

• Admin groups and any other constraints will not be notified to PCE for PCC configured and controlled SR-MPLS and SRv6 candidate paths (with single or multiple primary configurations). There is no impact for delegated and PCE-initiated candidate paths.

• When PCEP multipath capability is enabled, secondary path configuration is allowed for non-delegated candidate paths. When the PCEP multipath capability is disabled, secondary path configuration is not allowed.

• Candidate paths cannot have a mix of PCE-initiated and delegated LSPs.

• Multiple sub-candidate paths for a PCE-initiated colored candidate path is not supported.

• Delegate features with multiple sub-candidate paths in a candidate path is not supported.

Configuration

To enable PCCD to send multipath capability TLV in LSP object to notify the maximum computed segment list for a specific candidate path, include the propagate-max-segmentlist configuration statement at the [edit protocols pcep] hierarchy level. By default, the TLV is not sent in LSP object.

To disable PCEP multiple capability session for all PCEs, include the disable-multipath-capability configuration statement at the [edit protocols pcep] hierarchy level.

You can enable the following protocol traceoptions for diagnostics:

• user@host# set protocols pcep traceoptions …

• user@host# set protocols pcep pce pce1 traceoptions …

• user@host# set protocols source-packet-routing traceoptions

You can use the following show commands to display the state of LSPs in PCC:

• user@host> show path-computation-client lsp—Display the state of label-switched paths (LSPs) known to the Path Computation Client (PCC).

• user@host> show path-computation-client lsp extensive—Display extensive level of output about each known LSP - point-to-point and point-to-multipoint LSPs.

• user@host> show path-computation active-pce—Display the status of multipath in the sessions.

• user@host> show spring-traffic-engineering lsp detail—Display ingress details of SPRING traffic engineering.

Benefits of Enabling TLS for PCEP Sessions

• Protects PCEP sessions from attacks such as spoofing (PCC or PCE impersonation), snooping (message interception), falsification, and denial of service.

• Leverages TLS security benefits.

Enabling TLS in Path Computation Client (PCC)

To enable TLS in PCC and to establish PCEPS session, set the tls-strict CLI statement at the [edit protocols pcep] hierarchy level.

After enabling tls-strict configuration statement, the following events happen:

1. PCEP session flaps. Any existing TCP connection is terminated and a reconnection is done using TLS.

2. PCC establishes TCP connection with the PCE.

3. TLS procedures are initiated by the StartTLS message from PCE to PCC and from PCC to PCE. The StartTLS message is sent by PCC and the StartTLSWait timer is started. You can configure the StartTLSWait timer by configuring the start-tls-wait-timer seconds CLI statement at the [edit protocols pcep pce pce-id] hierarchy level.

   Note:

   The recommended value for the StartTLSWait timer is 60 seconds and must not be less than the OpenWait timer. The default OpenWait timer value is set as 60 seconds.

   • If Open message is received by PCC instead of StartTLS message, PCErr message with Error-Type set to 1 (PCEP session establishment failure) and Error-value set to 1 (reception of an invalid Open message or a non-Open message), and the TCP session is closed.

   • If StartTLS message is not received from PCE, then after the StartTLSWait timer expires, PCC sends a PCErr message with Error-Type set to 25 (PCEP StartTLS failure) and Error-value set to 5 (no StartTLS message (nor PCErr/Open) before StartTLSWait timer expiry), and the TCP session is closed.

4. Negotiation and establishment of TLS connection happens.

5. Exchange of PCEP messages is started as per RFC5440.

Updating Certificates Using the Public Key Infrastructure (PKI)

The PKI doesn’t notify PCC about certificate expiry. You must manually update the certificate using the following CLI command. In this method, you must keep track of the certificate expiry date.

Establishing TLS Connection

The following steps describes how a TLS connection (using TLS v1.2) is established:

1. Generate certificates for the nodes (Junos OS devices/pce-server). You can generate the certificates using one of the following methods:

   • Method 1—Generate key-pair and CSR on the device and send this CSR to CA to get the certificate. Once the certificate is issued, it is copied to the box and installed.

   • Method 2—Generate key-pair and the certificate out of the box. Both the certificate and the private key are copied on the device and installed together.

2. Load the certification authority (CA) on the PCC so that the PCE server certificate can be validated against the loaded CA.

   Note:

   CAs can be loaded in flat hierarchy as an independent CA. If a CA is a sub-CA of another CA, the chain is constructed internally by PKI.

   Note:

   The server certificate should be signed by a CA. Self-signed certificates are not allowed.

3. Enable TLS on PCC.

4. PCEP session is established over TLS with TLS handshake mechanism.

5. PCE server listens to port 4189 for incoming PCC connection requests through TLS.

6. PCC initiates the connection request to destination port 4189.

7. Upon completion of a three-way handshake, the TLS handshake begins by using the certificates and the one-way authentication is done (PCC authenticates server certificate). Both the server and client waits for StartTLSWait time to receive the StartTLS message. You can configure the StartTLSWait timer by configuring the start-tls-wait-timer seconds CLI statement at the [edit protocols pcep pce pce-id] hierarchy level.

   Note:

   The recommended value for the StartTLSWait timer is 60 seconds and must not be less than the OpenWait timer. The default OpenWait timer value is set as 60 seconds.

8. After the successful TLS handshake session, PCC and PCE initiates PCEP session establishment over TLS during which the session parameters are negotiated.

   • If the certificate validation fails, then PCC terminates the TCP connection.

9. PCEP message is sent over TLS connection as application data.

10. Encryption and decryption happen on both PCC and PCE after a successful TLS handshake.

11. When the PCEP session is closed, the TLS session is removed.

Understanding the Basic TLS Handshake Mechanism

The handshake is a series of the messages exchanged between a server and a client. The exact steps in handshake varies depending on key exchange algorithm, cipher suite, etc. The following are the basic TLS handshake mechanism steps:

1. Client Hello—The client initiates the handshake by sending this message. This message contains TLS version, list of supported cryptographic algorithms or cipher suite and other client details.

2. Server Hello—The server replies to Client Hello by sending Sever Hello message. This message contains server certificate, selected cryptographic algorithm, session id and server’s public key.

3. Authentication—The client in background verifies the server’s certificate with configured Certificate Authority which had issued the certificate. On successful verification the client confirms that the server is genuine and continues with interacting.

4. Optional Client Certificate—If the server has requested a certificate from the client in Server Hello message, then the client sends the client certificate (only in case of mutual TLS).

5. Client Key Exchange—The client sends secret Key encrypted with the Server’s Public key (acquired in Server Hello message).

6. Decrypt secret key—The server decrypts the secret key using the Private key.

7. Client Finished—The client sends a finish message which is encrypted with the shared secret key and signals handshake complete.

8. Server Finished—The server responds with finish message which is encrypted with the shared secret key and signals handshake complete.

9. Exchange Messages—The messages after handshake completion are symmetrically encrypted.

Diagnosing and Validating TLS for PCEP Sessions

For diagnostics, use the following traceoptions CLI statements:

Enable PKI logs using the following configuration and capture the same file from /var/log/<filename>

Verify the loaded CA certificate using the following command:

Sample Output

The following is a sample output of show path-computation-client statistics command:

This sample output provides the following information:

• TLS is enabled at PCC.

• PCE is TLS capable.

• TLS session is established. This also indicates that the PCE server certificate is valid.

• PCEPS session status is up and running.

Benefits of Reporting Path Optimization and Computed Metrics in PCEP

• Reporting of path optimization metrics configured in PCC helps PCE to be aware of the constraints that is used for path computation.

• Reporting of computed metrics to the PCE. This helps PCE to analyze if the LSP requires further optimization.

Understanding Optimization Metrics

The following section describes the intended and actual optimization metrics for RSVP and and SR-TE (SR MPLS) LSPs in PCEP.

• Locally Created RSVP LSP
• Delegated RSVP LSP
• PCE-initiated RSVP LSP
• Delegated SR-TE LSP
• PCE-initiated SR-TE LSP
• Sending Optimization Metric in PCRpt Message
• Sending Computed Metric in PCRpt Message
• Backward Incompatibility for Route Metric

Configuring Optimization Metrics for LSPs

You can configure optimization metrics (IGP, TE, and path delay) for RSVP LSPs and SR-TE LSP.

To configure the IGP, TE, and path delay optimization metrics for RSVP LSPs, include the metric-type <igp|te|delay|delay minimum> CLI statement at the [edit protocols mpls label-switched-path <lsp-name>] hierarchy level.

To configure the IGP, TE, and path delay optimization metrics for SR-TE LSPs, include the metric-type <igp|te|delay|delay minimum> CLI statement at the [edit protocols source-packet-routing compute-profile <compute-profile-name>] hierarchy level.

Sample Output

You can use the show path-computation-client lsp and show path-computation-client lsp extensive CLI commands to display the state of label-switched paths (LSPs) known to the Path Computation Client (PCC).

The following is a sample output of show path-computation-client lsp extensive:

The output shows that the LSP is optimized with the metric type IGP. The computed value of IGP metric is 50. The Route metric installed in the route table is 50.