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 Base PCEP message objects and TLVs 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)

• security of the PCEP session using MD5 or TLS between PCEP peers

• PCEP synchronization optimization (as defined in draft-ietf-pce-stateful-sync-optimizations)

• support of end-to-end secondary backup paths for an LSP

• jitter, latency, and packet loss metrics support (as defined in RFC 7471 and draft-ietf-isis-te-metric-extensions) and their use in the PCE METRIC object (as defined in draft-ietf-pce-pcep-service-aware)

• ASSOCIATION object for RSVP LSPs

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 user-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 returns 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 returns 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 timers

  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 try reestablishing the PCEP session. When the PCEP session is reestablished, the LSP database is synchronized with the PCE, and any LSP that went down since the last time the PCEP session was up has its path updated by the PCE. The redelegation timer and state timer are known as the Redelegation Timeout Interval and State Timeout Interval respectively in RFC 8231.

PCEP over TLS (PCEPS) is secured using TLS on port 4189. The PCC is configured with a TLS client profile to initiate the TLS handshake. The PCE is configured with a TLS server profile to allow PCEP over TLS. When a TLS server profile is configured on the PCE, the PCE can establish TLS and non-TLS connections, in PCE secured (PCES) and PCE modes. See PCE behavior for more information about the modes supported by SR OS.

In TLS mode, both the PCC and PCE must provide certificates for authentication. The PCE provides the server certificate to the PCC and requires the client certificate to authenticate the PCC.

An LSP that is configured on the router is referred to as 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 referred to as a PCE-initiated LSP.

The SR OS supports three different modes of operations for PCC-initiated LSPs which 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 referred to as 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 option. In this case, the PCE acts in passive stateful mode for this LSP. The LSP path cannot be updated by the PCE. In other words, the 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 referred to as 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 option. In this case, the PCE acts in passive stateful mode for this LSP.

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

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

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

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

SR OS also supports PCE-initiated LSPs. PCE-initiated LSPs allow 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 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 pce-initiated-lsp sr-te to enable the PCC to accept and process the 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 messages 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.

PCEP path profile extension objects and TLVs 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 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, PCE-initiated, 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 following CLI syntax to configure PCE associations on the PCC under the following contexts:

• classic CLI

  configure router pcep
     pcc
        pce-associations
           [no] diversity association-name
              association-id [1..65535]
              no association-id
              association-source ip-address
              no association-source
              disjointness-reference
              no disjointness-reference
              disjointness-type {loose | strict}
              no disjointness-type
              diverity-type {link | node | srlg-link | srlg-node}
              no diversity-type
           [no] policy association-name
              association-id association-id
              no association-id
              association-source ip-address
              no association-source        
              

• MD-CLI

  configure router pcep
       pcc
         pce-associations
            diversity [assoc-name] string
              association-id number
              association-source ipv4-address
              disjointness-reference {true|false}
              disjointness-type {strict | loose}
              diversity-type {none | link | node | srlg-link | srlg-node}
            policy [assoc-name] string
              association-id number
              association-source ip-address

The user must configure the Association ID and Association Source address. 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-label 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. It is mutually exclusive with the path-computation-method local-cspf and no path-computation-method commands.

The fallback mechanism is only triggered if the PCC informs MPLS that 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 CLI command configures the routing preference to reach the PCE server. Use this command to configure in-band reachability for the PCE when the BOF autoconfiguration is enabled and a wide static route, for example, 0.0.0.0/0, is assigned through DHCP.

configure router pcep pcc peer ip-address route-preference {both | inband | outband}

The command options are:

both

specifies the use of the out-of-band routes in the management routing instance to reach the server before the in-band routes in the base routing instance. The default value is both.

inband

specifies the use of in-band routes only

outband

specifies the use of out-of-band routes only

The cproto channels are established through the management interface IPv4 or IPv6 address and open TCP port 4199 on both the primary and secondary VSR-NRCs.

In addition, the NRC-P always provides the active VSR-NRC acting as a cproto server with the system address of the mate VSR-NRC which to initiate the cproto channel to. The address is provided using the new Global Health and Notification cproto channel.

NRC-P provides a configuration for the primary VSR-NRC. This is the preferred active VSR-NRC. The other VSR-NRC is secondary. Nokia recommends setting the VSR-NRC co-located with the NRC-P as the primary VSR-NRC to take advantage of lowest latency and more reliable cproto channel.

In NSP ecosystem redundancy in dual-site deployment, the primary VSR-NRC in the local site is VSR-NRC-A and the secondary VSR-NRC in the remote site is VSR-NRC-B. The reverse configuration is performed in the remote site. With single-site VSR-NRC redundancy, both VSR-NRCs are local and either can be configured as the primary VSR-NRC.

The following describes NSP cluster redundancy rules:

• 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 secondary 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 active role at the 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 role 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.