Path Computation Element Protocol (PCEP)

The following PCE parameters cannot be modified while the PCEP session is operational:

• local-address
• local-address-ipv6
• keepalive
• dead-timer

The unknown-message-rate PCE parameter can be modified while the PCEP session is operational.

The following PCC parameters cannot be modified while the PCEP session is operational:

• local-address
• local-address-ipv6
• keepalive
• dead-timer
• peer (regardless of the shutdown state in classic CLI or the administrative state in the MD-CLI)

The following PCC parameters can be modified while the PCEP session is operational:

• report-path-constraints
• unknown-message-rate

The base implementation of PCE uses the PCEP extensions defined in RFC 5440.

The main functions of the PCEP are:

• establishing, maintaining, and closing PCEP sessions

• generating path computation requests using the PCReq message

• generating path computation replies using the PCRep message

• generating notification messages (PCNtf) by which the PCEP speaker can inform its peer about events, such as path request cancellation by the PCC or path computation cancellation by the PCE

• generating error messages (PCErr) by which the PCEP speaker can inform its peer about errors related to processing requests, message objects, or TLVs

The following table lists the base PCEP messages and objects.

The behavior and limitations of the implementation of the objects in the preceding table are as follows:

• The PCE treats all supported objects received in a PCReq message as mandatory, regardless of whether the P-flag in the common header of the object is set (mandatory object) or not (optional object).

• The PCC implementation always sets the B-flag (B=1) in the METRIC object containing the hop metric value, which means that a bound value must be included in the PCReq message. The PCE returns the computed value in the PCRep message with flags set identically to the PCReq message.

• The PCC implementation always sets flags B=0 and C=1 in the METRIC object for the IGP or TE metric values in the PCReq message. This means that the request is to optimize (minimize) the metric without providing a bound. PCE returns the computed value in PCRep message with flags set identically to the PCReq message.

• The IRO and LOAD-BALANCING objects are not supported in the NSP PCE feature. If the PCE receives a PCReq message with one or more of these objects, it ignores them regardless of the setting of the P-flag and processes the path computations normally.

• LSP path setup and hold priorities are configurable during SR-TE LSP configuration on the router, and the PCC passes the configurations on in an LSPA object. However, the PCE does not implement LSP preemption.

• The LSPA, METRIC, and BANDWIDTH objects are also included in the PCRpt message.

The following features are not supported in SR OS:

• PCE discovery using IS-IS (as defined in RFC 5089) and OSPF (as defined in RFC 5088) along with corresponding extensions for discovering stateful PCE (as defined in draft-sivabalan-pce-disco-stateful)

• PCEP synchronization optimization (as defined in RFC 8232)

• jitter, latency, or packet loss link metric signaling in the PCE METRIC object (as defined in RFC 8233)

The PCEP protocol operates over TCP using destination TCP port 4189. The PCE client (PCC) always initiates the connection. After the user configures the PCEP local IPv4 or IPv6 address and the peer IPv4 or IPv6 address on the PCC, the PCC initiates a TCP connection to the PCE. If both a local IPv4 and a local IPv6 address are configured, the connection uses the local address of the same family as the peer address. When the connection is established, the PCC and PCE exchange OPEN messages, and this process initializes the PCEP session and exchanges the session parameters to be negotiated.

By default, the PCC attempts to reach the remote PCE address out of band using the management port. If it cannot, it attempts to reach the remote PCE address in band. The user can modify the configuration of the peer to attempt connecting in band only or out of band only. When the session comes up out of band, the management IP address is used as the local address. The local IPv4 or IPv6 address configured by the user is only used for in-band sessions and is otherwise ignored.

A keepalive mechanism is used as an acknowledgment of the acceptance of the session within the negotiated parameters. It is also used as a maintenance function to detect whether the PCEP peer is still alive.

The negotiated parameters include the keepalive timer and the dead timer, and one or more PCEP capabilities such as support of stateful PCE and the SR-TE LSP path type.

The following figure shows PCEP session initialization steps.

If the session to the PCE times out, the router acting as a PCC keeps the last successfully-programmed path provided by the PCE until the session to the PCE is reestablished. Any subsequent change to the state of an LSP is synchronized at the time the session is reestablished.

When a PCEP session to a peer times out or closes, the rate at which the PCEP speaker attempts the establishment of the session is subject to an exponential back-off mechanism.

The following PCEP parameters are configurable on both the PCC and PCE. On the PCE, the configured parameter values are used on sessions to all PCCs.

• keepalive timer

  A PCEP speaker (PCC or PCE) must send a keepalive message if no other PCEP message is sent to the peer at the expiry of this timer. This timer is restarted every time a PCEP message is sent or the keepalive message is sent.

  The keepalive mechanism is asymmetric, meaning that each peer can use a different keepalive timer value.

  The range of this parameter is 1 to 255 seconds, and the default value is 30 seconds. The no version reverts to the default value.

• dead timer

  This timer tracks the amount of time a PCEP speaker (PCC or PCE) waits after the receipt of the last PCEP message before declaring its peer down.

  The dead timer mechanism is asymmetric, meaning that each PCEP speaker can propose a different dead timer value to its peer to use to detect session timeouts.

  The range of this parameter is 1 to 255 seconds, and the default value is 120 seconds. The no version reverts to the default value.

• maximum rate of unknown messages

  When the rate of received unrecognized or unknown messages reaches this limit, the PCEP speaker closes the session to the peer.

• session redelegation and state timer

  If the PCEP session to the PCE goes down, all delegated PCC-initiated LSPs have their state maintained in the PCC and are not timed out. The PCC continues to attempt to reestablish the PCEP session. When the PCEP session is reestablished, the LSP database is synchronized with the PCE, and any LSP that went down after the last time the PCEP session was up has its path updated by the PCE.

The main function of stateful PCE, as opposed to the base PCE implementation, is the ability to synchronize the LSP state between the PCC and the PCE. This function allows the PCE to have all the required LSP information to perform reoptimization and updating of the LSP paths.

The following table describes the messages and objects supported by stateful PCE in the SR OS.

The following behavior and limitations apply to the implementation of the objects listed in the preceding table:

• PCC and PCE support all PCEP capability TLVs defined in this document and always advertise them. If the OPEN object received from a PCEP speaker does not contain one or more of the capabilities, neither the PCE nor the PCC use them during the specific PCEP session.

• The PCC always includes the LSP object in the PCReq message to ensure that the PCE can correlate the PLSP ID for this LSP when a subsequent PCRpt message arrives with the delegation bit set. The PCE, however, still honors a PCReq message without the LSP object.

• PCE path computation only considers the bandwidth used by LSPs in its LSP-DB. As a result, in the following situations, the PCE path computation does not accurately account for the bandwidth used in the network:

  • When there are LSPs that are signaled by the routers but are not synchronized with the PCE. The user can enable the reporting of the LSP to the PCE LSP database for each LSP.

  • When the stateful PCE is peering with a third-party stateless PCC, implementing only the original RFC 5440. While the PCE is able to bring the PCEP session up, the LSP database is not updated, because stateless PCC does not support the PCRpt message. As such, PCE path computation does not accurately account for the bandwidth used by these LSPs in the network.

• The PCE ignores the reoptimize flag (R-flag) in the PCReq message when acting in stateful-passive mode for a specific LSP and always returns the new computed path, regardless of whether it is link-by-link identical or has the same metric as the current path. The PCC decides whether to initiate the new path in the network.

• The SVEC object is not supported in SR OS nor in the NSP. If the PCE receives a PCReq message with the SVEC object, it ignores the SVEC object and treats each path computation request in the PCReq message as independent, regardless of the setting of the P-flag in the SVEC object common header.

• When an LSP is delegated to the PCE, there can be no prior state in the NRC-P LSP database for the LSP. This could be because the PCE did not receive a PCReq message for the same PLSP-ID. For the PCE to become aware of the original constraints of the LSP, the following additional procedures are performed:

  • The PCC appends a duplicate of each of the LSPA, METRIC, and BANDWIDTH objects in the PCRpt message. The only difference between the two objects of the same type is that the P-flag is set in the common header of the duplicate object to indicate a mandatory object for processing by the PCE.

  • The value of the metric or bandwidth in the duplicate object contains the original constraint value, while the first object contains the operational value. This is applicable to hop metrics in the METRIC object and BANDWIDTH object only. The SR OS PCC does not support putting a bound on the IGP or TE metric in the path computation.

  • The path computation on the PCE uses the first set of objects when updating a path, if the PCRpt message contains a single set. If the PCRpt message contains a duplicate set, the PCE path computation must use the constraints in the duplicate set.

  • For interoperability, implementations compliant to PCEP standards accept the first metric object and ignore the second object without additional error handling. Because there are also BANDWIDTH and LSPA objects, the report-path-constraints command is provided in the PCC on a per-PCEP session basis to disable the inclusion of the duplicate objects. Duplicate objects are included by default.

The following table lists the additional messages, TLVs, and objects used by stateful PCE for PCE initiation of LSPs.

To manage the path of an SR-TE LSP, the PCE and PCC both implement the following extensions to PCEP in support of segment routing:

• An SR-PCE-CAPABILITY in the OPEN object to indicate support of segment routing tunnels by the PCE and the PCC during PCEP session initialization.

  The PCEP speaker on the transmit side encodes the SR-PCE-CAPABILITY as both a top-level TLV in the OPEN object and as a sub-TLV of the PATH SETUP TYPE CAPABILITY TLV in the OPEN object. The PCEP speaker on the receive side processes the SR-PCE-CAPABILITY, which it implements at the TLV level and ignores the sub-TLV. The PCEP speaker performs the following actions:

  • A PCEP speaker that implements RFC 8664 and which receives both the top-level SR-PCE-CAPABILITY TLV and the top-level PATH SETUP TYPE CAPABILITY TLV processes the SR-PCE-CAPABILITY sub-TLV in the top-level PATH SETUP TYPE CAPABILITY TLV.
  • A PCEP speaker that implements RFC 8664 and which receives only the top-level SR-PCE-CAPABILITY TLV treats it as if it received the top-level PATH SETUP TYPE CAPABILITY TLV with PST={0,1}, meaning both RSVP-TE and SE-TE LSP types are supported, along with the SR-PCE-CAPABILITY sub-TLV.
  • A PCEP speaker that implements up to version RFC 8664 and which receives both the top-level SR-PCE-CAPABILITY TLV and the top-level PATH SETUP TYPE CAPABILITY TLV processes the top-level SR-PCE-CAPABILITY and ignores the top-level PATH SETUP TYPE CAPABILITY TLV.

  This implementation is in accordance with the backward compatibility procedure defined in RFC 8664 to process the SR-PCE-CAPABILITY.

  If the OPEN object is received from a PCEP speaker without the SR-PCE-CAPABILITY in either or both of the preceding encodings, the PCE or the PCC does not send or accept PCEP messages for LSP paths of type SR-TE on that specific PCEP session.

• A Path Setup Type TLV for SR-TE LSPs to be included in the Stateful PCE Request Parameters (SRP) object during the path report (PCRpt) messages by the PCC.

  A Path Setup Type TLV with a value of 1 identifies an SR-TE LSP.

• A Segment Routing ERO and an RRO with subobjects, referred to as SR-ERO and SR-RRO subobjects, which encode the SID information in the PCRpt messages.

• The PCE implementation supports the Segment-ID (SID) Depth value in the METRIC object. This is always signaled by the PCC in the PCEP OPEN object as part of the as SR-PCE-CAPABILITY TLV. It is referred to as the Maximum Stack Depth (MSD). In addition, the per-LSP value for the max-sr-labels option, if configured, is signaled by the PCC to the PCE in the Segment-ID (SID) Depth value in a METRIC object for both a PCE-computed LSP and a PCE-controlled LSP. PCE computes and provides the full explicit path with the TE-links specified. If there is no path with the number of hops lower than the MSD value, or the Segment-ID (SID) Depth value if signaled, a reply with no path is returned to the PCC. For a PCC-controlled LSP, if the label stack returned by the TE-DB’s hop-to-label translation exceeds the per-LSP maximum SR label stack size, the LSP is brought down.

• If the Path Setup Type (PST) TLV is not included in the PCReq message, the PCE or PCC must assume the message is for an RSVP-TE LSP.

The following table describes the segment routing extension objects and TLVs supported in the SR OS.

SR OS supports the following methods for PCEP security, as described in RFC 8253, PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP):

• TCP-AO

  With TCP-AO, the channel is only authenticated, and not encrypted. PCEP speaking parties are also authenticated.

• TLS

  With TLS, the channel is encrypted and authenticated, and the PCEP speaking parties are also authenticated.

In SR OS, both TCP-AO and TLS can be used individually or simultaneously for securing the PCEP channel.

An LSP that is configured on the router is called a PCC-initiated LSP. An LSP that is not configured on the router, but is instead created by the PCE at the request of an application or a service instantiation, is called a PCE-initiated LSP.

The SR OS supports the following modes of operations for PCC-initiated LSPs that are configurable on a per-LSP basis:

• When the path of the LSP is computed and updated by the router acting as a PCE Client (PCC), the LSP is called a PCC-initiated and PCC-controlled LSP.

  A PCC-initiated and PCC-controlled LSP has the following characteristics.

  • The LSP can contain strict or loose hops, or a combination of both.

  • CSPF is supported for RSVP-TE LSPs. Local path computation takes the form of hop-to-label translation for SR-TE LSPs.

  • LSPs can be reported to synchronize the LSP database of a stateful PCE server using the pce-report command. In this case, the PCE acts in passive stateful mode for the LSP. The LSP path cannot be updated by the PCE, which means that control of the LSP is maintained by the PCC.

• When the path of the LSP is computed by the PCE at the request of the PCC, it is called a PCC-initiated and PCE-computed LSP.

  A PCC-initiated and PCE-computed LSP has the following characteristics.

  • The user must enable the path-computation-method pce option for the LSP so that the PCE can perform path computations at the request of the PCC only. The PCC retains control.

  • LSPs can be reported to synchronize the LSP database of a stateful PCE server using the pce-report command. In this case, the PCE acts in passive stateful mode for the LSP.

• When the path of the LSP is updated by the PCE following a delegation from the PCC, it is called PCC-initiated and PCE-controlled.

  A PCC-initiated and PCE-controlled LSP has the following characteristics.

  • The user must enable the pce-control command for the LSP so that the PCE can perform path updates after a network event without an explicit request from the PCC. The PCC delegates full control.

  • The user must enable the pce-report command for LSPs that cannot be delegated to the PCE. The PCE acts in active stateful mode for the LSP.

SR OS also supports PCE-initiated LSPs. PCE-initiated LSPs allows a WAN SDN Controller(such as the NSP) to automatically instantiate an LSP based on a service or application request. Only SR-TE PCE-initiated LSPs are supported.

The instantiated LSP does not have a configuration on the network routers and, consequently, is treated in the same way as an auto-LSP. The parameters of the LSP are provided using policy lookup in the NSP and are passed to the PCC using PCEP, in accordance with RFC 8281. Missing LSP parameters are added using a default or specified LSP template on the PCC.

PCE-initiated LSPs have the following characteristics.

• The user must enable the pce-initiated-lsp sr-te command to enable the PCC to accept and process PCInitiate messages from the PCE.

• The user must configure one or more LSP templates of type pce-init-p2p-srte for SR-TE LSPs. A default template is supported that is used for LSPs for which no ID or an ID of 0 is included in the PCInitiate message. The user must configure at least one default PCE-initiated LSP template.

PCE-initiated LSPs are a form of SR-TE auto-LSP and are available to the same forwarding contexts. See Forwarding contexts supported with SR-TE auto-LSP. Similar to other auto-LSPs, PCE-initiated LSPs are installed in the TTM and are therefore available to advanced policy-based services using auto-bind, such as VPRN and E-VPN. However, PCE-initiated LSPs cannot be used with provisioned SDPs.

The PCE path profile defined in draft-alvarez-pce-path-profiles is used to request path diversity or a disjoint for two or more LSPs originating on the same or different PE routers. The PCE path profile is also used to request that paths of two unidirectional LSPs between the same two routers use the same TE links. This is referred to as the bidirectionality constraint. As an alternative, SR OS supports the use of association groups to signal path diversity constraints. See Policy Association Group for more information about association group support.

Path profile and association group are not interoperable. That is, LSPs with path profile and those with association group cannot be considered in the same group and cannot be compared against each other.

The CSPF algorithm optimizes this objective. If a constraint is provided for the same metric, the CSPF algorithm ensures the selected path achieves a lower or equal value to the bound specified in the constraint.

For hop-count metrics, if a constraint is sent in a METRIC object, and is also specified in a PCE profile referenced by the LSP, the constraint in the METRIC object is used.

For IGP and TE metrics, if an objective is sent in a METRIC object, and is also specified in a PCE profile referenced by the LSP, the objective in the path profile is used.

The constraints in the BANDWIDTH object and the LSPA object that include or exclude admin-group constraints and setup and hold priorities are not supported in the PCE profile.

To indicate the path diversity and bidirectionality constraints to the PCE, the user must configure the profile ID and path group ID of the PCE path that the LSP belongs to. The CLI for this is described in the Configuring and operating SR-TE section. The path group ID does not need to be defined in the PCE as part of the path profile configuration; it implicitly identifies the set of paths that must have the path diversity constraint applied.

The user can only associate a single path group ID with a specific PCE path profile ID for an LSP; however, the same path group ID can be associated with multiple PCE profile IDs for the same LSP.

The PCC infers the path profiles using the path ID in the path request. When the PE router acting as a PCC wants to request path diversity from a set of other LSPs belonging to a path group ID value, it adds a new path profile object into the PCReq message. The object contains the path profile ID and the path group ID as an extended ID field. That is, the diversity metric is carried in an opaque way from PCC to PCE.

The bidirectionality constraint operates the same way as the diversity constraint. The user can configure a PCE profile with both the path diversity and bidirectionality constraints. The PCE checks if there is an LSP in the reverse direction that belongs to the same path group ID as an originating LSP it is computing the path for, and enforces the constraint.

For the PCE to be aware of the path diversity and bidirectionality constraints for an LSP that is delegated but for which there is no prior state in the NRC-P LSP database, the PATH-PROFILE object is included in the PCRpt message with the P-flag set in the common header to indicate that the object must be processed.

The following table lists the new objects introduced in the PCE path profile.

A PATH-PROFILE object can contain multiple TLVs containing each profile ID and extend ID, and should be processed properly. If multiple path profile objects are received, the first object is interpreted and the others are ignored. The PCC and the PCE support all PCEP capability TLVs defined in this chapter and always advertise them. If the OPEN object received from a PCEP speaker does not contain one or more of the capabilities, the PCE or PCC does not use them during that PCEP session.

SR OS supports the use of PCEP Association Groups to reference SR-TE and RSVP-TE LSP path constraints. PCEP Association Groups allow LSPs to share common information, such as common policies or common configuration parameters. Users can use association groups for PCC-initiated SR-TE and RSVP-TE LSPs, PCE-initiated SR-TE LSPs, and on-demand SR-TE auto-LSPs. Association groups are supported on both the PCC and NSP PCE.

The PCEP ASSOCIATION object defines an Association ID and an Association Type to signal any type of association between LSPs (as defined in RFC 8697). Association groups are identified by a tuple consisting of an Association ID, Association Type, and Association Source. Association groups offer a disaggregated approach to specifying association, where the Association ID is equivalent to the path group ID, and the tuple (Association ID, Association Type, Association Source) is equivalent to the path profile ID. The tuple is the key to the association group. Both IPv4 and IPv6 PCEP control planes support signaling of the Association IDs. The NSP uses the Association ID to reference a path profile.

Path diversity constraints are signaled using the Disjoint Association Type defined in RFC 8800, while policy constraints are signaled using the Policy Association Type defined in draft-ietf-pce-association-policy-16. The Association ID for a policy association is also used by the PCE to signal which LSP template to bind to a PCE-initiated SR-TE LSP.

Use the commands in the following contexts to configure PCE associations on the PCC.

configure router pcep pcc pce-associations diversity
configure router pcep pcc pce-associations policy

You must configure the Association ID and Association Source address in these contexts. In most cases, the Association Source address (which may be IPv4 or IPv6) is the PCC source address. Configuring the Association Source address allows interoperability with third-party controllers that assume a specific allocation scheme, which supports cases such as the diversity between LSPs that originate on different PCC nodes but are configured with the same Association Source address for a specific Association ID and Association Type.

For PCC-initiated RSVP-TE and SR-TE LSPs, the router supports fallback to a local path computation method in the case where the configured PCEP sessions are down or the PCE is unreachable, or when all configured PCEs are signaling overload and the redelegation timer expires while all configured LSPs are signaling overload so that the LSP cannot be redelegated. The fallback method can be configured to be the local-cspf or none. In the latter case, MPLS uses the hop-to-label translation (SR-TE LSPs) or the explicit IGP path (RSVP-TE LSPs).

This capability is supported by both active and passive stateful LSPs. Active stateful LSPs are fully delegated to the PCE by being both PCE-computed (path-computation-method pce) and PCE-controlled. Passive stateful LSPs are PCE-computed.

A fallback path computation method is configured as follows:

configure>router>
   mpls
      lsp lsp-name
         pce-control
         path-computation-method {pce | local-cspf} 
         fallback-path-computation-method {none | local-cspf}

If none is configured, MPLS uses the default method based on the configured path, which is hop-to-labeled path computation for SR-TE LSPs and IGP-based path computation for RSVP-TE LSPs.

The fallback-path-computation-method command is only valid for path-computation-method pce, irrespective of whether pce-control is configured. The fallback-path-computation-method command cannot be configured if the path-computation-method local-cspf or no path-computation-method commands are configured.

The fallback mechanism is only triggered if PCC informs MPLS that the PCEP is down. It is not triggered while the PCC is administratively down or is not yet configured.

PCE reports are sent, where applicable, with the delegation bit cleared.

The NSP ecosystem resilience consists of local, or single site, and remote, or dual site, redundancy mechanisms.

The following CLI command enables the configuration on the PCC of a second PCEP session to the secondary backup PCE peer. A preference parameter value is used to indicate the primary or the secondary backup PCE peer role:

configure router pcep pcc peer ip-address [preference preference]

A maximum of two PCE peers are supported. The PCE peer that is not in overload is always selected by the PCC as the active PCE; however, if neither of the PCEs are signaling the overload state, the PCE with the higher numerical preference value is selected. In case of a tie, the PCE with the lower IP address is selected.

To change the value of the preference parameter, the peer must be deleted and recreated.

The following rules apply to the NSP cluster:

• At each site, a master is elected among the cluster of three VMs. In a DR deployment, the cluster in one site is designated as the primary, meaning it is the preferred active cluster. The site is referred to as the primary site. The second cluster and site are referred to as secondary and therefore act as the standby backup cluster or site.

• The application processes at the standby site are shut down, but the Neo4j and other databases are synchronized with the primary/active site.

• Switching to the standby site can be initiated manually or by using an automated approach stemming from the loss of heartbeat between the primary and standby sites.

• When the NSP cluster at the primary/active site is down (two out of three servers must be inactive, shut down, or failed), the heartbeat mechanism between the primary and standby NSP clusters fails after three timeouts. This initiates the activity at the inactive secondary/standby site.

• When the NSP cluster at the primary site is back up, the heartbeat mechanism between the primary/standby and secondary/active NSP clusters is restored. The primary site can be restored to the active site manually. Automatic reversion to the primary NSP cluster is not supported.

This feature implements support for the single site or local 1+1 redundancy of the VSR-NRC.