5. PCEP

5.1. Introduction to the Path Computation Element Protocol (PCEP)

The Path Computation Element Protocol (PCEP) is one of several protocols used for communication between a Wide-Area Network (WAN) Software-Define Networking (SDN) controller and network elements.

The Nokia WAN SDN Controller is known as the Network Services Platform (NSP). The NSP is a set of applications which are built on a common framework that hosts and integrates them by providing common functions. The applications are developed in a Java environment.

The NSP provides two major functions:

  1. programmable multi-vendor service provisioning
  2. network resource control, including resource management at Layer 0 (optical path), Layer 1 (ODU path), Layer 2 (MPLS tunnel), and at the IP flow level

The network discovery and control implements a common set of standards-based south-bound interfaces to the network elements for both topology discovery and tunnel and flow programming. It is a virtual SR OS (vSROS) image which applies the south-bound interfaces to the network elements and the adaptation layer to the applications. The south-bound interfaces include IGP and BGP-LS for topology discovery, PCEP for handling path computation requests and LSP state updates with the network elements, and forwarding plane programming protocols such as Openflow, BGP FlowSpec, and I2RS.

The above NSP functions are provided in a number of modules which can be used together or separately as illustrated in Figure 59.

Figure 59:  NSP Functional Modules 

The two main features of the NSP are as follows:

  1. Network Services Director (NSD) — The NSD is a programmable and multi-vendor service provisioning tool exposing a single and simple API to the user and OSS. It implements service model abstraction and adapts to each vendor-specific service model. It supports provisioning services such as E-Line, E-LAN, E-Tree, L3 VPN, traffic steering, and service chaining.
  2. Network Resource Controller (NRC) — The NRC implements a separate module for computing and managing optimal paths for optical tunnels (NRC-T) and MPLS tunnels (NRC-P), and for computing optimal routing and placement of IP flows (NRC-P). In addition, a resource controller for inter-layer IP and optical path computation and more complex inter-domain MPLS path computation is provided as part of the NRC-X.

The NRC-P implements the stateful Path Computation Element (PCE) for packet networks. Figure 60 illustrates the NRC-P architecture and its main components.

Figure 60:  Packet Network Resource Controller (NRC-P) Architecture 

The NRC-P has the following architecture:

  1. a single Virtual Machine (VM) handling the Java implementation of an MPLS path computation engine, a TE graph database, and an LSP database
  2. a plug-in adapter with the Nokia CPROTO interface, providing reliable, TCP-based message delivery between vSROS and Java-VM. The plug-in adapter implements a compact encoding/decoding (codec) function for the message content using Google ProtoBuf. Google ProtoBuf also provides for automatic C++ (vSROS side) and Java (Java-VM side) code generation to process the exchanged message content.
  3. a single VM running a vSROS image handles the functions of topology discovery of multiple IGP instances and areas via IGP or BGP-LS and the PCE PCEP functions

The PCE module uses PCEP to communicate with its clients, such as the PCE Client (PCC). It also uses the PCEP to communicate with other PCEs to coordinate inter-domain path computation. Each router acting as a PCC initiates a PCEP session to the PCE in its domain.

When the user enables PCE control for one or more segment routing or RSVP LSPs, the PCE owns the path updating and periodic re-optimization of the LSP. In this case, the PCE acts in an active stateful role. The PCE can also act in a stateful passive role for other LSPs on the router by discovering them and taking into account their resource consumption when computing the path for the LSPs it has control ownership of.

The following is a high-level description of the PCE and PCC capabilities:

  1. base PCEP implementation, per RFC 5440
  2. active and passive stateful PCE LSP update, as per draft-ietf-pce-stateful-pce
  3. delegation of LSP control to PCE
  4. synchronization of the LSP database with network elements for PCE-controlled LSPs and network element-controlled LSPs
  5. support for the SR-TE P2P LSP type, as per draft-ietf-pce-segment-routing
  6. support for PCC-initiated LSPs, as per draft-ietf-pce-stateful-pce
  7. support for LSP path diversity across different LERs using extensions to the PCE path profile, as per draft-alvarez-pce-path-profiles
  8. support for LSP path bidirectionality constraints using extensions to the PCE path profile, as per draft-alvarez-pce-path-profiles

5.1.1. PCC and PCE Configuration

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

  1. local-address
  2. keepalive
  3. 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:

  1. local-address
  2. keepalive
  3. dead-timer
  4. peer (regardless of shutdown state)

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

  1. report-path-constraints
  2. unknown-message-rate

5.1.2. Base Implementation of Path Computation Elements (PCE)

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

The main functions of the PCEP are:

  1. PCEP session establishment, maintenance, and closing
  2. path computation requests using the PCReq message
  3. path computation replies using the PCRep message
  4. notification messages (PCNtf) by which the PCEP speaker can inform its peer about events, such as path request cancellation by PCC or path computation cancellation by PCE
  5. error messages (PCErr) by which the PCEP speaker can inform its peer about errors related to processing requests, message objects, or TLVs

Table 50 lists the base PCEP messages and objects.

Table 50:  Base PCEP Message Objects and TLVs 

TLV, Object, or Message

Contained in Object

Contained in Message

OPEN Object

N/A

OPEN, PCErr

Request Parameter (RP) Object

N/A

PCReq, PCRep, PCErr, PCNtf

NO-PATH Object

N/A

PCRep

END-POINTS Object

N/A

PCReq

BANDWIDTH Object

N/A

PCReq, PCRep, PCRpt, PCInitiate

METRIC Object

N/A

PCReq, PCRep, PCRpt, PCInitiate

Explicit Route Object (ERO)

N/A

PCRep

Reported Route Object (RRO)

N/A

PCReq

LSPA Object

N/A

PCReq, PCRep, PCRpt, PCInitiate

Include Route Object (IRO)

N/A

PCReq, PCRep

SVEC Object

N/A

PCReq

NOTIFICATION Object

N/A

PCNtf

PCEP-ERROR Object

N/A

PCErr

LOAD-BALANCING Object

N/A

PCReq

CLOSE Object

N/A

CLOSE

The behavior and limitations of the implementation of the objects in Table 50 are as follows:

  1. PCE treats all supported objects received in a PCReq message as mandatory, regardless of whether the P-flag in the object’s common header is set (mandatory object) or not (optional object).
  2. The PCC implementation will always set the B-flag (B=1) in the METRIC object containing the hop metric value, which means that a bound value must be included in PCReq. PCE returns the computed value in PCRep with flags set identically to PCReq.
  3. The PCC implementation will always set 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 with flags set identically to PCReq.
  4. The IRO and LOAD-BALANCING objects are not in the NSP PCE feature. If the PCE receives a PCReq message with one or more of these objects, it will ignore them regardless of the setting of the P-flag, and will process the path computations normally.
  5. LSP path setup and hold priorities will be configurable during SR-TE LSP configuration on the router, and PCC will pass the configurations on in an LSPA object. However, PCE does not implement LSP pre-emption.
  6. The LSPA, METRIC, and BANDWIDTH objects are also included in the PCRpt message.

The following features are not supported in the SR OS:

  1. PCE discovery using IS-IS, per RFC 5089, and OSPF, per RFC 5088, along with corresponding extensions for discovering stateful PCE, per draft-sivabalan-pce-disco-stateful
  2. security of the PCEP session using MD5 or TLS between PCEP peers
  3. PCEP synchronization optimization as per draft-ietf-pce-stateful-sync-optimizations
  4. support of end-to-end secondary backup paths for an LSP. PCE standards do not currently support an LSP container with multiple paths, and treats each request as a path with a unique PLSP ID. It is up to the router to tie the two paths together to create 1:1 protection, and to request path or SRLG diversity among them when it makes the request to PCE. This is not specific to PCE controlling an SR-TE LSP, but also to controlling an RSVP LSP.
  5. jitter, latency, and packet loss metrics support as per RFC 7471 and draft-ietf-isis-te-metric-extensions, and their use in the PCE METRIC object as per draft-ietf-pce-pcep-service-aware

5.1.3. PCEP Session Establishment and Maintenance

The PCEP protocol operates over TCP using destination TCP port 4189. The PCC always initiates the connection. Once the user configures the PCEP local address and the peer address on the PCC, the PCC initiates a TCP connection to the PCE. Once a connection is established, the PCC and PCE exchange OPEN messages, which initializes the PCEP session and exchanges the session parameters to be negotiated.

The PCC always checks first if the remote PCE address is reachable out-of-band via the management port. If not, it will try to reach the remote PCE address in-band. When the session comes up out-of-band, the management IP address is always used; the local address configured by the user is ignored and is only used for an in-band session.

A keep-alive 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 or not the PCEP peer is still alive.

The negotiated parameters include the Keepalive timer and the DeadTimer, and one or more PCEP capabilities such as support of Stateful PCE and the SR-TE LSP Path type.

The PCEP session initialization steps are illustrated in Figure 61.

Figure 61:  PCEP Session Initialization 

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 re-established. Any subsequent change to the state of an LSP is synchronized at the time the session is re-established.

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.

5.1.4. PCEP Parameters

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.

  1. Keep-alive timer — A PCEP speaker (PCC or PCE) must send a keep-alive 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 keep-alive message is sent.
    The keep-alive mechanism is asymmetric, meaning that each peer can use a different keep-alive 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.
  2. 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.
  3. 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.
  4. Session re-delegation and state timeout — 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 will continue to try re-establishing the PCEP session. When the PCEP session is re-established, the LSP database is synchronized with the PCE, and any LSP which went down since the last time the PCEP session was up will have its path updated by the PCE.

5.1.4.1. Stateful PCE

The main function introduced by stateful PCE over the base PCE implementation is the ability to synchronize the LSP state between the PCC and the PCE. This allows the PCE to have all the required LSP information to perform re-optimization and updating of the LSP paths.

Table 51 describes the messages and objects supported by stateful PCE in the SR OS.

Table 51:  PCEP Stateful PCE Extension Objects and TLVs 

TLV, Object, or Message

Contained in Object

Contained in Message

Path Computation State Report (PCRpt)

N/A

New message

Path Computation Update Request (PCUpd)

N/A

New message

Stateful PCE Capability TLV

OPEN

OPEN

Stateful Request Parameter (SRP) Object

N/A

PCRpt, PCErr, PCInitiate

LSP Object

ERO

PCRpt, PCReq, PCRep, PCInitiate

LSP Identifiers TLV

LSP

PCRpt

Symbolic Path Name TLV

LSP, SRP

PCRpt, PCInitiate

LSP Error Code TLV

LSP

PCRpt

RSVP Error Spec TLV

LSP

PCRpt

The behavior and limitations of the implementation of the objects in Table 51 are as follows:

  1. PCC and PCE support all PCEP capability TLVs defined in this document and will 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 will not use them during that specific PCEP session.
  2. The PCC always includes the LSP object in the PCReq message to make sure that the PCE can correlate the PLSP-ID for this LSP when a subsequent PCRpt message arrives with delegation bit set. The PCE will, however, still honor a PCReq message without the LSP Object.
  3. PCE path computation will only consider the bandwidth used by LSPs in its LSP-DB. As a result, there are two situations where PCE path computation will not accurately take into account the bandwidth used in the network:
    1. When there are LSPs which are signaled by the routers but are not synchronized up with the PCE. The user can enable the reporting of the LSP to the PCE LSP database for each LSP.
    2. When the stateful PCE is peering with a third party stateless PCC, implementing only the original RFC 5440. While PCE will be able to bring the PCEP session up, the LSP database will not be updated, since stateless PCC does not support the PCRpt message. As such, PCE path computation will not accurately take into account the bandwidth used by these LSPs in the network.
  4. PCE ignores the R-flag (re-optimize flag) in the PCReq message when acting in stateful-passive mode for a given LSP, and will always return the new computed path, regardless if it is link-by-link identical or has the same metric as the current path. The decision whether or not to initiate the new path in the network belongs to the PCC.
  5. The SVEC object is not supported in the SR OS and the NSP. If the PCE receives a PCReq message with the SVEC object, it will ignore the SVEC object and treat each path computation request in the PCReq message as independent, regardless of the setting of the P-flag in the SVEC object common header.
  6. 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 due to the PCE not having received a PCReq message for the same PLSP-ID. In order for the PCE to become aware of the original constraints of the LSP, the following additional procedures are performed.
    1. 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.
    2. 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. SR OS PCC does not support putting a bound on the IGP or TE metric in the path computation.
    3. The path computation on the PCE uses the first set of objects when updating a path if the PCRpt contains a single set. If the PCRpt contains a duplicate set, PCE path computation must use the constraints in the duplicate set.
    4. For interoperability, implementations compliant to PCEP standards should be able to accept the first metric object and ignore the second object without additional error handling. Since there are also BANDWIDTH and LSPA objects, the [no] 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.

Stateful PCE uses the additional messages, TLVs, and objects described in Table 52 for PCE initiation of LSPs.

Table 52:  PCEP Stateful PCE Extension Objects and TLVs Locations 

TLV, Object, or Message

Contained in Object

Contained in Message

PCE LSP Initiate Message (PCInitiate)

N/A

New message

PCC LSP Create Flag (C-Flag)

LSP

PCRpt

PATH_PROFILE_ID TLV

Path Profile

N/A

5.1.4.2. PCEP Extensions in Support of SR-TE LSPs

In order for the PCE and PCC to manage the path of an SR-TE LSP, they both implement the following extensions to PCEP in support of segment routing.

  1. A new Segment Routing capability TLV in the OPEN object to indicate support of segment routing tunnels by the PCE and the PCC during PCEP session initialization. This TLV is referred to as the SR-PCE-CAPABILITY TLV.
  2. The PCC and PCE support all PCEP capability TLVs defined in this chapter, and will always advertise them. If the OPEN object received from a PCEP speaker does not contain one or more of the capabilities, the PCE or the PCC will not use them during that specific PCEP session.
  3. A new Path Setup Type TLV for SR-TE LSPs to be included in the Stateful PCE Request Parameters (SRP) Object during path report (PCRpt) messages by the PCC.
    A Path Setup Type TLV with a value of 1 identifies an SR-TE LSP.
  4. A new Segment Routing ERO and RRO with sub-objects, referred to as SR-ERO and SR-RRO sub-objects, which encode the SID information in PCRpt messages.
  5. 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 will compute and provide the full explicit path with 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 will be 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.
  6. If the Path Setup Type (PST) TLV is not included in the PCReq message, the PCE or PCC must assume it is for an RSVP-TE LSP.

Table 53 describes the segment routing extension objects and TLVs supported in the SR OS.

Table 53:  PCEP Segment Routing Extension Objects and TLVs 

TLV, Object, or Message

Contained in Object

Contained in Message

SR PCE CAPABILITY TLV

OPEN

OPEN

Path Setup Type (PST) TLV

SRP

PCReq, PCRep, PCRpt

SR-ERO Sub-object

ERO

PCRep, PCRpt

SR-RRO Sub-object

RRO

PCReq, PCRpt

Segment-ID (SID) Depth Value in METRIC Object

METRIC

PCReq, PCRpt

5.1.4.3. LSP Initiation

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 support three different modes of operations for PCC-initiated LSPs which are configurable on a per-LSP basis.

  1. 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 PCC-initiated and PCC-controlled.
    A PCC-initiated and PCC-controlled LSP has the following characteristics:
    1. The LSP can contain strict or loose hops, or a combination of both.
    2. CSPF is supported for RSVP-TE LSPs. Local path computation takes the form of hop-to-label translation for SR-TE LSPs.
    3. 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 can not be updated by the PCE. In other words, the control of the LSP is maintained by the PCC.
  2. When the path of the LSP is computed by the PCE at the request of the PCC, it is referred to as PCC-initiated and PCE-computed.
    A PCC-initiated and PCE-computed LSP has the following characteristics:
    1. The user must enable the pce-computation option for the LSP so that the PCE can perform path computation at the request of the PCC only. PCC retains control.
    2. 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.
  3. When the path of the LSP is updated by the PCE following a delegation from the PCC, it is referred to as PCC-initiated and PCE-controlled.
    A PCC-initiated and PCE-controlled LSP has the following characteristics:
    1. 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. PCC delegates full control.
    2. 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.

The SR OS also supports PCE-initiated LSPs. PCE-initiated LSP is a feature that allows a WAN SDN Controller, for example, the Nokia 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 is therefore 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 as per RFC 8281. Missing LSP parameters are added using a default or specified LSP template on the PCC.

PCE-initiated LSPs have the following characteristics.

  1. The user must enable pce-initiated-lsp sr-te to enable the PCC to accept and process PCInitiate messages from the PCE.
  2. 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, they are installed in the TTM and are therefore available to advanced policy-based services using auto-bind such as VPRN and E-VPN. However, they cannot be used with provisioned SDPs.

5.1.4.3.1. PCC-Initiated and PCE-Computed/Controlled LSPs

The following is the procedure for configuring and programming a PCC-initiated SR-TE LSP when control is delegated to the PCE.

  1. The LSP configuration is created on the PE router via CLI or via the OSS/NSP NFM-P.
    The configuration dictates which PCE control mode is desired: active (pce-control and pce-report options enabled) or passive (pce-computation enabled and pce-control disabled).
  2. PCC assigns a unique PLSP-ID to the LSP. The PLSP-ID uniquely identifies the LSP on a PCEP session and must remain constant during its lifetime. PCC on the router must keep track of the association of the PLSP-ID to the Tunnel-ID and Path-ID, and use the latter to communicate with MPLS about a specific path of the LSP. PCC also uses the SRP-ID to correlate PCRpt messages for each new path of the LSP.
  3. The PE router does not validate the entered path. Note however that in the SR OS, the PCE supports the computation of a path for an LSP with empty-hops in its path definition. While PCC will include the IRO objects in the PCReq message to PCE, the PCE will ignore them and compute the path with the other constraints except the IRO.
  4. The PE router sends a PCReq message to the PCE to request a path for the LSP, and includes the LSP parameters in the METRIC object, the LSPA object, and the BANDWIDTH object. The PE router also includes the LSP object with the assigned PLSP-ID. At this point, the PCC does not delegate the control of the LSP to the PCE.
  5. The PCE computes a new path, reserves the bandwidth, and returns the path in a PCRep message with the computed ERO in the ERO object. It also includes the LSP object with the unique PLSP-ID, the METRIC object with any computed metric value, and the BANDWIDTH object.
    Note:

    For the PCE to be able to use the SRLG path diversity and admin-group constraints in the path computation, the user must configure the SRLG and admin-group membership against the MPLS interface and make sure that the traffic-engineering option is enabled in IGP. This causes IGP to flood the link SRLG and admin-group membership in its participating area, and for PCE to learn it in its TE database.

  6. The PE router updates the CPM and the data path with the new path.
    Up to this point, the PCC and PCE are using passive stateful PCE procedures. The next steps will synchronize the LSP database of the PCC and PCE for both PCE-computed and PCE-controlled LSPs. They will also initiate the active PCE stateful procedures for the PCE-controlled LSP only.
  7. The PE router sends a PCRpt message to update the PCE with an UP state, and also sends the RRO as confirmation. It now includes the LSP object with the unique PLSP-ID. For a PCE-controlled LSP, the PE router also sets the delegation control flag to delegate control to the PCE. The state of the LSP is now synchronized between the router and the PCE.
  8. Following a network event or a re-optimization, the PCE computes a new path for a PCE-controlled LSP and returns it in a PCUpd message with the new ERO. It will include the LSP object with the same unique PLSP-ID assigned by the PCC, as well as the Stateful Request Parameter (SRP) object with a unique SRP-ID-number to track error and state messages specific to this new path.
  9. The PE router updates the CPM and the data path with the new path.
  10. The PE router sends a PCRpt message to inform the PCE that the older path is deleted. It includes the unique PLSP-ID value in the LSP object and the R (Remove) bit set.
  11. The PE router sends a new PCRpt message to update PCE with an UP state, and also sends the RRO to confirm the new path. The state of the LSP is now synchronized between the router and the PCE.
  12. If PCE owns the delegation of the LSP and is making a path update, MPLS will initiate the LSP and update the operational value of the changed parameters while the configured administrative values will not change. Both the administrative and operational values are shown in the details of the LSP path in MPLS.
  13. If the user makes any configuration change to the PCE-computed or PCE-controlled LSP, MPLS requests that the PCC first revoke delegation in a PCRpt message (PCE-controlled only), and then MPLS and PCC follow the above steps to convey the changed constraint to PCE which will result in the programming of a new path into the data path, the synchronization of the PCC and PCE LSP databases, and the return of delegation to PCE.

The above procedure is followed when the user performs a no shutdown command on a PCE-controlled or PCE-computed LSP. The starting point is an LSP which is administratively down with no active path. For an LSP with an active path, the following items can apply:

  1. If the user enabled the pce-computation option on a PCC-controlled LSP with an active path, no action is performed until the next time the router needs a path for the LSP following a network event of a LSP parameter change. At that point, the prior procedure is followed.
  2. If the user enabled the pce-control option on a PCC-controlled or PCE-computed LSP with an active path, the PCC will issue a PCRpt message to the PCE with an UP state, as well as the RRO of the active path. It will set the delegation control flag to delegate control to the PCE. The PCE will keep the active path of the LSP and make no updates to it until the next network event or re-optimization. At that point, the prior procedure is followed.

5.1.4.3.2. PCE-Initiated LSPs

The following is the procedure for configuring and programming a PCE-initiated SR-TE LSP.

  1. The user must enable pce-initiated-lsp sr-te using the CLI or using the OSS. The user can also optionally configure a limit to the number of PCE-Initiated LSPs that the PCE can instantiate on a node using the max-srte-pce-init-lsps command in the CLI or using the OSS.
  2. The user must configure at least one LSP template of type pce-init-p2p-srte to select the value of the LSP parameters that remain under the control of the PCC. At a minimum, a default template should be configured (type pce-init-p2p-srte default). In addition, LSP templates with a defined template ID can be configured. The template ID can be included in the path profile of the PCEInitiate message to indicate which non-default template to use for a particular LSP. If the PCInitiate message does not include the PCE path profile, MPLS uses the default PCE-initiated LSP template. Table 54 lists the applicable LSP template parameters. These are grouped into:
    1. parameters that are controlled by the PCE and that the PCC cannot change (invalid, implicit, and signaled in PCEP)
    2. parameters that are controlled by the PCC and are used for signaling the LSP in the control plane
    3. parameters that are controlled by the PCC and are related to the usability of the LSP by MPLS and other applications such as routing protocols, services, and OAM
    The user can configure these parameters in the template.
    Table 54:  LSP Template Parameters 

    Controlled by PCE

    Controlled by PCC

    Invalid

    Implicit

    Signaled in PCEP

    LSP Signaling Options

    LSP Usability Options

    auto-bandwidth

    pce-report

    bandwidth

    retry-limit

    cspf

    exclude

    bgp-shortcut

    retry-timer

    pce-control

    from

    bgp-transport-tunnel

    shutdown

    pce-report

    hop-limit

    default-path (mandatory, must be empty)

    least-fill

    pce-computation

    include

    cspf use-te-metric

    entropy-label

    setup-priority

    igp-shortcut

    hold-priority

    load-balancing-weight

    max-sr-labels

    additional-frr-labels

    metric

    vprn-auto-bind

    admin-tag

    All PCE-initiated LSPs using a particular LSP template are deleted if the user deletes the template. The default template can be created or deleted if the pce-initiated-lsp>sr-te context does not exist. However, the pce-init-p2p-sr-te default lsp-template cannot be deleted if the pce-initiated-lsp>sr-te context exists and is not shutdown. This context must be shutdown to delete the pce-init-p2p-sr-te default LSP template, which brings down all PCE Initiated LSPs. The pce-initiated-lsp>sr-te context cannot be administratively enabled if the pce-init-p2p-sr-te default lsp-template is not configured.
    A shutdown of an LSP template does not bring down any already established LSPs. Parameters can only be changed once in the shutdown state and the changes do not take effect until a no shutdown is performed. This means that PCE updates use older parameters if the template is still shut down.
    MPLS copies the lsp-template parameters into the lsp-entry when a PCE initiated LSP is created. MPLS handles lsp-updates based on the last copied parameters.
    After the lsp-template parameter changes, when the lsp-template is no shutdown.
    1. MPLS copies the related TTM parameters (listed below) into the LSP entry, and updates TTM
    2. If there is a change in max-sr-labels, MPLS re-evaluates the related LSPs, and brings paths down if applicable (for example, if current hopCount is greater than the applicable max-sr-labels value).
      The TTM LSP-related parameters include:
      1. Metric
      2. VprnAutoBind
      3. LoadBalWeight
      4. MaxSrLabels
      5. AdditionalFrrLabels
      6. MetricOffset
      7. IgpShortCut
      8. IgpShortcutLfaOnly
      9. IgpShortcutLfaProtect
      10. LspBgpShortCut
      11. LspBgpTransTunnel
    A PCE-initiated LSP “update” request will be accepted regardless of the LSP template administrative state, as follows:
    1. If the LSP template is adminUp, the system copies the LSP template parameters to the LSP/path.
    2. If the LSP template is adminDown, the system uses the previously copied LSP template parameters and responds to the update with an LSP operUp report.
  3. The user can set the redelegation and state timers on the PCC. Redelegation timeout and state timeout timers are started when the PCEP session goes down or the PCE signals overload. The redelegation timer applies to both PCC-initiated and PCE-initiated LSPs, while the state timer applies only to PCE-initiated LSPs. The redelegation and state timers are configured in the CLI or through management, as follows:
    config>router>pcep>pcc>
    [no] redelegation-timer seconds
    [no] state-timer seconds [action {remove | none}]
    If the delegated PCE-initiated LSPs cannot be redelegated by the time these timers expire, a configurable action is performed by the PCC. The supported actions are remove or none, with a default of remove.
  4. The PCE can then initiate and remove LSPs on the PCC. These procedures are described in LSP Instantiation Using PCEP, LSP Deletion Using PCEP, and Dynamic State Handling for PCE Initiated LSPs.

5.1.4.3.3. LSP Instantiation Using PCEP

The following procedures are followed in the instantiation of a PCE-initiated LSP by both the NSP and SR OS router. Further protocol details can be found in RFC 8281.

5.1.4.3.3.1. NSP Generation of PCInitiate

  1. When the PCEP session is established from the PCC to PCE, the PCC and PCE exchange the Open object and both set the new “I flag, LSP-INSTANTIATION CAPABILITY” flag, in the STATEFUL-PCE-CAPABILITY TLV flag field.
  2. The operator, using the north-bound REST interface, the NSD or another interface, makes a request to the NSP to initiate an LSP, specifying the following parameters:
    1. source address
    2. destination address
    3. LSP type (SR-TE)
    4. bandwidth value
    5. include/exclude admin-group constraints
    6. optional PCE path profile ID for the path computation at the PCE
    7. optional PCE-initiated LSP template ID for use by the PCC to complete the instantiation of the LSP
  3. The NSP crafts the PCInitiate message and sends it to the PCC using PCEP. The message contains the LSP object with PLSP-ID=0, the SRP object, the ENDPOINTS object, the computed SR-ERO (SR-TE) object, and the list of LSP attributes (bandwidth object, one or more metric objects, and the LSPA object). The LSP path name is inserted into the Symbolic Path Name TLV in the LSP object.
  4. The PCE-initiated LSP template ID to be used at the PCC, if any, is included in the PATH-PROFILE-ID TLV of the Path Profile object. The Profile ID matches the PCE-initiated LSP template ID at the PCC and is not the same asThe Path Profile ID is used on the PCE to compute the path of this PCE-initiated LSP.

5.1.4.3.3.2. SR OS Router Procedures on Receiving a PCInitiate Message

  1. If a PCInitiate message includes a name that is a duplicate of an existing LSP on the router, the system generates an error.
  2. The router assigns a PLSP-ID and looks up the specified PCE-initiated LSP template ID, if any, or the default PCE-initiated LSP template, to retrieve the local parameters, and instantiates the SR-TE LSP.
  3. The instantiated LSP is added to the TTM and is used by all applications that look up a tunnel in the TTM.
  4. The router crafts a PCRpt message with the Tunnel-ID, LSP-ID, and the RRO and passes it along with the PLSP-ID set to the assigned value and the delegation bit set in the LSP object to the PCE.

5.1.4.3.3.3. NSP Procedures on Receiving a PCRpt Message for a PCE

  1. The NSP confirms the bandwidth reservation and updates its LSP database. The PCC and PCE are synchronized at this point.
  2. The NSP reports the PLSP-ID/Tunnel-ID to the application, for example NSD, or to the operator that uses it in the specific application that originated the request.
  3. The PCE can perform updates to the path during the lifetime of the LSP by using the PCUpd message in the same way as with a delegated PCC-initiated LSP.

5.1.4.3.4. LSP Deletion Using PCEP

The following procedures apply in the deletion of a PCE-initiated LSP. More protocol level details are provided in RFC 8281. These procedures are applicable when the user manually deletes the PCE-initiated LSP or the NSP application, or when NSD requests the deletion of the PCE-initiated LSP. The procedures that apply when a network event occurs are described in SR OS Router Procedures.

  1. The NSP crafts a PCInitiate message for the corresponding PLSP-ID and sets the R-bit in the SRP object flags to indicate to the PCC that it must delete the LSP. The NSP sends the message to the PCC using PCEP.

5.1.4.3.4.1. SR OS Router Procedures on Receipt of a PCInitiate with the R-bit Set

  1. The router deletes the state of the LSP.
  2. The router crafts a PCRpt message with the R-bit set in the LSP object flags.

5.1.4.3.4.2. NSP Procedures Upon Issuance of pce-init delete Command

  1. The NSP deletes the LSP from its LSP database.

5.1.4.3.5. Dynamic State Handling for PCE Initiated LSPs

5.1.4.3.5.1. NSP Procedures

  1. The NRC-P controls the creation and the deletion of the PCE-initiated LSP.
  2. All LSP creation retries are performed by the NSP. If the PCC rejects an instantiation, the NSP can issue a new request for instantiation or give up and delete the LSP state locally after a configurable maximum number of retries.
  3. The NSP can reject an instantiation request if it does not receive a PCRpt from the PCC message within a configured timeframe.
  4. When the PCEP session comes up and the LSP DB synchronization from the PCC to PCE is complete, the NSP reinitiates the PCE-initiated LSPs that are missing from the PCC reports.
  5. If a PCEP session goes down, the NSP stops sending any new or updated PCE-initiated LSP paths to that PCC; therefore, the LSP DB on the NSP and PCC can go out of synchronization during that time.
  6. If the PCEP session to a PCC goes down, the NSP marks all PCE-initiated and PCC-initiated LSPs for that PCC as stale but keeps their reservation for an amount of time equal to the state-timeout timer. The state-timeout timer applies to both PCE-initiated and PCC-initiated LSPs on the PCE and is set to a fixed value of 10 minutes.
    Note:

    The state-timeout timer must be considerably larger than the maximum state timer on the PCC to give the PCC time to clean up PCE-initiated LSPs and prevent PCInit requests for duplicate LSPs.

    1. If the PCEP session was re-established within that time, the NRC-P reinitiates all PCE-initiated LSPs toward the PCC from which a PCRpt remove with the special error code LSP_ERR_SYNC_DELETE was received during the LSP DB synchronization with the PCC.
    2. If the state-timeout timer expires, the NRC-P releases the resources but does not delete the LSPs from the LSP DB. If the PCEP session comes up subsequently, the NSP recomputes the path of each LSP from which a PCRpt remove with the special error code LSP_ERR_SYNC_DELETE was received during the LSP DB synchronization with the PCC and sends the PCC a PCInitiate message for each LSP.
  7. If the NSP is informed by the VSR-NRC of a PCRpt with the remove flag in the LSP object and SRP object set for each of them, it follows the same procedures for these LSPs as when the PCEP session goes down.

5.1.4.3.5.2. SR OS Router Procedures

Table 55 summarizes the impact of various PCC operational events on the status of PCE-initiated LSPs.

Table 55:  Impact of PCC Operational Events 

Event

Impact on PCE-initiated LSPs

Oper-down

Deleted

MPLS shutdown

X  1

no mpls

X 2

no pce-initiated-lsp

X (all)  2

no sr-te

X (sr-te) 2

sr-te shutdown

X (sr-te)  1

pcc shutdown

X (all)  3

pcc peer shutdown

X 3

Delete LSP template ID

X (LSPs using template) 2

Delete default LSP template

X (all)  2

    Notes:

  1. Also results in a PCRpt to the PCE with LSP error admin down.
  2. Also results in a PCRpt to the PCE with LSP deleted.
  3. A PCRpt with delete and a special error code, for example, LSP_ERR_SYNC_DELETE, is sent during the PCC rejoin synchronization that occurs when the PCC or PCC peer comes back up.

The following list describes in more detail the actions that the PCC takes on PCE-initiated LSPs as a result of PCC operational events:

  1. If any event causes PCE-initiated LSPs to be deleted by the PCC, the PCC sends a PCRpt with remove the flag in both the SRP object and the LSP object set for each impacted LSP. If the event is a failure of the PCEP session to the PCE, or a shutdown of the PCC or PCC peer, the PCRpt is sent, with the special error code LSP_ERR_SYNC_DELETE, only after the PCEP session comes back up during the PCC resynchronization with the PCE.
  2. If any event causes PCE-initiated LSPs to go operationally down, the PCC router sends a PCRpt with the operational bits in the LSP object set to DOWN for each impacted LSP.
  3. If the user shuts down the PCC process on the router, all PCE-initiated LSPs are deleted. When the user performs a no shutdown of the PCC process, the PCC reports to the PCE so that the NSP is aware.
  4. If a PCEP peer is shut down, the PCEP session goes down but the PCC keeps the state of all PCE-initiated LSPs, subject to the following rules regarding redelegation and the cleanup of state. See section 5.7.5 of RFC 8231 and section 6 of RFC 8281. These rules apply to all LSPs delegated to the PCE.
    Redelegation timeout and state timeout timers are started when the PCEP session goes down or the PCE signals overload. Configuration of these timers is described in PCE-Initiated LSPs. The system enforces that the state-timer be greater than the redelegation-timer, as specified in RFC 8231.
    The objectives of redelegation are described in Section 5.7.5 of RFC 8231. The redelegation process is as follows for both PCE-initiated and PCC-initiated LSPs.
    The existing LSP delegation state is maintained while the LSP redelegation timer is running. This gives the PCE time to recover. At the expiry of the redelegation timer, the PCC attempts to redelegate the LSPs to the PCE, as follows:
    1. if the PCEP session to the existing PCE is still down or the PCE is still in overload, return delegation state to the PCC for all the delegated LSPs
    2. wait until the PCEP session comes up and then attempt to redelegate the remaining LSPs back to the PCE. For each LSP, set a redelegation attempted flag once redelegation is attempted. If redelegation is accepted for all PCE-initiated LSPs delegated to the PCC before the state timeout timer expires, the system is behaving as expected.
    3. if the state timeout timer expires, wait until all LSPs have been processed. The LSPs that are not redelegated but have the redelegation attempted flag set have the configured action applied to them. If this is delete, LSPs are deleted; otherwise, wait until the PCEP session comes up and then attempt to redelegate the remaining LSPs back to the PCE.

5.1.4.3.6. PCEP Support for RSVP-TE LSP

This section describes the support of PCE Client-initiated (PCC-initiated) RSVP-TE LSP. The PCEP support of an RSVP-TE LSP provides the same modes of operation as an SR-TE LSP and on per-LSP:

  1. PCC-initiated and PCC-controlled
  2. PCC-initiated and PCE-computed
  3. PCC-initiated and PCE-controlled

The PCEP support of an RSVP-TE LSP differs from that of an SR-TE LSP in the following areas.

  1. Each primary and secondary path is assigned its own unique Path LSP-ID (PLSP-ID).
  2. PCC indicates to PCE the state of each path (both UP and DOWN) and which path is currently active and carrying traffic (ACTIVE state).

5.1.4.3.6.1. Feature Configuration

The following MPLS-level and LSP-level CLI commands, used to configure RSVP-TE LSP in a router acting as a PCEP Client (PCC).

  1. config>router>mpls>pce-report rsvp-te {enable | disable}
  2. config>router>mpls>lsp>path-profile profile-id range [path-group group-id range]
  3. config>router>mpls>lsp>pce-report {enable | disable | inherit}
  4. config>router>mpls>lsp>pce-computation
  5. config>router>mpls>lsp>pce-control

The cspf option must first be enabled before enabling the pce-computation or pce-control options. An attempt to disable the cspf option on an RSVP-TE LSP that has the pce-computation or pce-control options enabled will be rejected.

If the LSP has disabled PCE reporting, either due to inheritance or due to LSP-level configuration, enabling the pce-control option for the LSP has no effect. To help troubleshoot this situation, the output of the show commands for the LSP displays operational values of both the pce-report and pce-control.

Note:

The PCE function implemented in the Nokia Network Services Platform (NSP) and referred to as the Network Resource Controller for Packet (NRC-P), supports only Shared Explicit (SE) style bandwidth management for TE LSPs. The PCEP protocol does not have means for the PCC to convey this value to the PCE, so, regardless of whether the LSP configuration option rsvp-resv-style is set to se or ff, the PCE will always use the SE style in the CSPF computation of the path for a PCE-computed or PCE-controlled RSVP-TE LSP.

A one-hop-p2p or a mesh-p2p RSVP-TE auto-lsp only supports the pce-report command in the LSP template:

config>router>mpls>lsp-template>pce-report {enable | disable | inherit}

The user must first shut down the LSP template before changing the value of the pce-report option.

A manual bypass LSP does not support any of the PCE-related commands. Reporting a bypass LSP to PCE is not required because it does not book bandwidth.

All other MPLS, LSP, and path-level commands are supported, with the exception of backup-class-type, class-type, least-fill, main-ct-retry-limit, mbb-prefer-current-hops, and srlg (on secondary standby path), which, if enabled, will result in a no operation.

The RSVP-TE PCC supports the same instantiation modes as the SR-TE LSP. See LSP Initiation for more information.

5.1.4.3.6.2. Behavior of the LSP Path Update

When the pce-control option is enabled, the PCC delegates the control of the RSVP-TE LSP to the PCE.

The NRC-P sends a path update using the PCUpd message in the following cases:

  1. a failure event that impacts a link or a node in the path of a PCE-controlled LSP
    The operation is performed by the PCC as an MBB if the LSP remained in the UP state due to protection provided by FRR or a secondary path. If the LSP went down, then the update brings it into the UP state. A PCRpt message is sent by the PCC for each change to the state of the LSP during this process.
  2. a topology change that impacts a link in the path of a PCE-controlled LSP
    This topology change can be a change to the IGP metric, the TE metric, admin-group, or SRLG membership of an interface. This update is performed as an MBB by the PCC.
  3. the user performed a manual resignal of PCE-controlled RSVP-TE LSP path from the NRC-P
    This update is performed as an MBB by the PCC.
  4. the user performed a Global Concurrent Optimization (GCO) on a set of PCE-controlled RSVP-TE LSPs from the NRC-P
    This update is performed as an MBB by the PCC.

The procedures for the path update are the same as those for an SR-TE LSP. See LSP Initiation for more information. However, the PCUpd message from the PCE does not contain the label for each hop in the computed ERO. PCC then signals the path using the ERO returned by the PCE and, if successful, programs the data path, then sends the PCRpt message with the resulting RRO and hop labels provided by RSVP-TE signaling.

If the signaling of the ERO fails, then the ingress LER returns a PCErr message to PCE with the LSP Error code field of the LSP-ERROR-CODE TLV set to a value of 8 (RSVP signaling error).

If an RSVP-TE LSP has the no adaptive option set, the ingress LER cannot perform an MBB for such an LSP. A PCUpd message received from the PCE is then failed by the ingress LER, which returns a PCErr message to PCE with the LSP Error code field of the LSP-ERROR-CODE TLV set to a value of 8 (RSVP signaling error).

When the NRC-P reoptimizes the path of a PCE-controlled RSVP-TE LSP, it is possible that a path that satisfies the constraints of the LSP no longer exists. In this case, the NRC-P sends a PCUpd message with an empty ERO, which forces the PCC to bring down the path of the RSVP-TE LSP.

NRC-P sends a PCUpd message with an empty ERO if the following cases are true.

  1. The requested bandwidth is the same as current bandwidth, which avoids bringing down the path on a resignal during a MBB transition.
  2. Local protection is not currently in use, which avoids bringing down a path that activated an FRR backup path. The LSP can remain on the FRR backup path until a new primary path can be found by NRC-P.
  3. The links of the current path are all operationally up, which allows NRC-P to make sure that the RSVP control plane will report the path down when a link is down and not prematurely bring the path down with an empty ERO.

5.1.4.3.6.3. Behavior of LSP MBB

In addition to the Make-Before-Break (MBB) support when the PCC receives a path update, as described in Behavior of the LSP Path Update, an RSVP-TE LSP supports the MBB procedure for any parameter configuration change, including the PCEP-related commands when they result in a change to the path of the LSP.

If the user adds or modifies the path-profile command for an RSVP-TE LSP, a Config Change MBB is only performed if the pce-computation, pce-report, or pce-control options are enabled on the LSP. Otherwise, no action occurs. When pce-computation, pce-report, or pce-control are enabled on the LSP, the Path Update MBB (tools perform router mpls update-path) will be failed, resulting in a no operation.

MBB is also supported for the Manual Resignal and Auto-Bandwidth MBB types.

When the LSP goes into a MBB state at the ingress LER, the behavior is dependent on the LSP’s operating mode.

5.1.4.3.6.3.1. PCE-Controlled LSP

The LSP MBB procedures for a PCE-controlled LSP (pce-control enabled) are as follows.

Items 1 through 5 of the following procedures apply to the Config Change, Manual Resignal, and Auto-Bandwidth MBB types. The Delayed Retry MBB type used with the SRLG on secondary standby LSP feature is not supported with a PCE controlled LSP. See Behavior of Secondary LSP Paths for information about the SRLG on secondary standby LSP feature.

  1. PCC temporarily removes delegation by sending a PCRpt message for the corresponding PLSP-ID with the delegation D-bit clear.
  2. For an LSP with pce-computation disabled, MPLS submits a path request to the local CSPF including the updated path constraints.
  3. For an LSP with pce-computation enabled, PCC issues a PCReq for the same PLSP-ID and includes the updated constraints in the metric, LSPA, or bandwidth objects. The bandwidth object contains the current operational bandwidth of the LSP in the case of the auto-bandwidth MBB.
    1. If the PCE successfully finds a path, it replies with a PCRep message with the ERO.
    2. If the PCE does not find a path, it replies with a PCRep message containing the No-Path object.
  4. If the local CSPF or the PCE return a path, the PCC performs the following actions.
    1. PCC signals the LSP with RSVP control plane and moves traffic to the new MBB path. It then sends a PCRpt message with the delegation D-bit set to return delegation and containing the RRO and LSP object, with the LSP identifiers TLV containing the LSP-ID of the new MBB path. The message includes the metric, LSPA, and bandwidth objects where the P-flag is clear, which indicates the operational values of these parameters. Unless the user disabled the report-path-constraints option under the pcc context, the PCC also includes a second set of metric, LSPA, or bandwidth objects with the P-flag set to convey to PCE the constraints of the path.
    2. PCC sends a PathTear message to delete the state of the older path in the network. PCC then sends a PCRpt message to PCE with the older path PLSP-ID and the remove R-bit set to also have PCE remove the state of that LSP from its database.
  5. If the local CSPF or the PCE returns no path or the RSVP-TE signaling of the returned path fails, the router makes no further requests. That is, there is no retry for the MBB.
    1. The PCC sends a PCErr message to PCE with the LSP Error code field of the LSP-ERROR-CODE TLV set to a value of 8 (RSVP signaling error) if the MBB failed due to a RSVP-TE signaling error.
    2. The PCC sends a PCRpt message with the delegation D-bit set to return delegation and containing the RRO and LSP objects with the LSP identifiers TLV containing the LSP-ID of the currently active path. The message includes the metric, LSPA, and bandwidth objects with the P-flag is clear to indicate the operational values of these parameters. Unless the user disabled the report-path-constraints option under the pcc context, the PCC also includes a second set of metric, LSPA, and bandwidth objects with the P-flag set to convey to PCE the constraints of the path.
  6. The ingress LER takes no action in the case of a network event triggered MBB, such as FRR Global Revertive, TE Graceful Shutdown, or Soft Pre-Emption.
    1. The ingress PE keeps the information as required and sets the state of MBB to one of the FRR global Revertive, TE Graceful Shutdown, or Soft Pre-emption MBB values but does not perform the MBB action.
    2. The NRC-P computes a new path in the case of Global Revertive MBB due to a failure event. This computation uses the PCUpd message to update the path using the MBB procedure described in Behavior of the LSP Path Update. The activation of a bypass LSP by a PLR in the network causes the PCC to issue an updated PCRpt message with the new RRO reflecting the PLR and RRO hops. PCE should release the bandwidth on the links that are no longer used by the LSP path.
    3. The NRC-P computes a new path in the case of the TE graceful MBB if the RSVP-TE is using the TE metric, because the TE metric of the link in TE graceful shutdown is set to infinity. This computation uses the PCUpd message to update the path using the MBB procedure described in Behavior of the LSP Path Update.
    4. The NRC-P does not act on the TE graceful MBB if the RSVP-TE is using the IGP metric or is on the soft pre-emption MBB; however, the user can perform a manual resignal of the LSP path from the NRC-P to force a new path computation, which accounts for the newly available bandwidth on the link that caused the MBB event. This computation uses the PCUpd message to update the path using the MBB procedure described in Behavior of the LSP Path Update.
    5. The user can perform a manual resignal of the LSP path from the ingress LER, which forces an MBB for the path as per the remove-delegation/MBB/return-delegation procedures described in this section.
    6. If the user performs no pce-control while the LSP still has the state for any of the network event triggered MBBs, the MBB is performed immediately by the PCC as described in the procedures in PCE-Computed LSP for a PCE-computed LSP and as described in the procedures in PCC-Controlled LSP for a PCC-controlled LSP.
  7. The timer-based resignal MBB behaves like the TE graceful or soft pre-emption MBB. The user can perform a manual resignal of the LSP path from the ingress LER or from PCE.
  8. The Path Update MBB (tools perform router mpls update-path) is failed and will result in a no operation. This is true in all cases when the RSVP-TE LSP enables the pce-report option.
5.1.4.3.6.3.2. PCE-Computed LSP

All MBB types are supported for PCE-computed LSP. The LSP MBB procedures for a PCE-computed LSP (pce-computation enabled and pce-control disabled) are as follows.

  1. PCC issues a PCReq for the same PLSP-ID and includes the updated constraints in the metric, LSPA, and bandwidth objects.
    1. If PCE successfully finds a path, it replies with a PCRep message with the ERO.
    2. If PCE does not find a path, it replies with a PCRep message containing the No-Path object.
  2. If the PCE returns a path, the PCC signals the LSP with RSVP control plane and moves traffic to the new MBB path. If pce-report is enabled for this LSP, the PCC sends a PCRpt message with the delegation D-bit clear to retain control and containing the RRO and LSP object with the LSP identifiers TLVs containing the LSP-ID of the new MBB path. The message includes the metric, LSPA, and bandwidth objects where the P-flag is clear, which indicates the operational values of these parameters. Unless the user disables the report-path-constraints option under the pcc context, PCC also includes a second set of metric, LSPA, and bandwidth objects with the P-flag set to convey to PCE the constraints of the path.
  3. If the PCE returns no path or the RSVP-TE signaling of the returned path failed, MPLS puts the LSP into retry mode and sends a request to PCE every retry-timer seconds and up to the value of retry-count.
  4. When the pce-report is enabled for the LSP and the FRR Global Revertive MBB is triggered following a bypass LSP activation by a PLR in the network, PCC issues an updated PCRpt message with the new RRO reflecting the PLR and RRO hops. PCE releases the bandwidth on the links that are no longer used by the LSP path.
  5. If the user changes the RSVP-TE LSP configuration from pce-computation to no pce-computation, then MBB procedures are not supported. In this case, the LSP path is torn down and is put into retry mode to compute a new path from the local CSPF on the router to signal it.
5.1.4.3.6.3.3. PCC-Controlled LSP

All MBB types are supported for PCC-controlled LSP. The LSP MBB procedures for a PCC-controlled LSP (pce-computation and pce-control disabled) are as follows.

  1. MPLS submits a path request, including the updated path constraints, to the local CSPF.
  2. If the local CSPF returns a path, PCC signals the LSP with RSVP control plane and moves traffic to the new MBB path. If pce-report is enabled for this LSP, the PCC sends a PCRpt message with the delegation bit clear to retain control and containing the RRO and LSP object with the LSP identifiers TLV containing the LSP-ID of the new MBB path. It includes the metric, LSPA, and bandwidth objects where the P-flag is clear, which indicates the operational values of these parameters. Unless the user disables the report-path-constraints option under the pcc context, PCC also includes a second set of metric, LSPA, and bandwidth objects with the P-flag set to convey to PCE the constraints of the path.
  3. If the CSPF returns no path or the RSVP-TE signaling of the returned path fails, MPLS puts the LSP into retry mode and sends a request to the local CSPF every retry-timer seconds and up to the value of retry-count.
  4. When pce-report is enabled for the LSP and the FRR Global Revertive MBB is triggered following a bypass LSP activation by a PLR in the network, PCC issues an updated PCRpt message with the new RRO reflecting the PLR and RRO hops. PCE releases the bandwidth on the links that are no longer used by the LSP path.

5.1.4.3.6.4. Behavior of Secondary LSP Paths

Each of the primary, secondary standby, and secondary non-standby paths of the same LSP must use a separate PLSP-ID. The PCE function of the NSP, the NRC-P, checks the LSP-IDENTIFIERS TLVs in the LSP object and can identify which PLSP-IDs are associated with the same LSP or the same RSVP session. The parameters are the IPv4 Tunnel Sender Address, the Tunnel ID, the Extended Tunnel ID, and the IPv4 Tunnel Endpoint Address. This approach allows the use of all the PCEP procedures for all three types of LSP paths.

PCC indicates to PCE the following states for the path in the LSP object: down, up (signaled but is not carrying traffic), or active (signaled and carrying traffic).

PCE tracks active paths and displays them in the NSP GUI. It also provides only the tunnel ID of an active PLSP-ID to a given destination prefix when a request is made by a service or a steering application.

PCE recomputes the paths of all PLSP-IDs that are affected by a network event. The user can select each path separately on the NSP GUI and trigger a manual resignal of one or more paths of the RSVP-TE LSP.

Note:

Enabling the srlg option on a secondary standby path results in a no operation. The NRC-P supports link and SRLG disjointness using the PCE path profile, and the user can apply to the primary and secondary paths of the same LSP. See PCE Path Profile Support for more information.

5.1.4.3.6.5. PCE Path Profile Support

The PCE path profile ID and path group ID are configured at the LSP level.

The NRC-P can enforce path disjointness and bidirectionality among a pair of forward and a pair of reverse LSP paths. Both pairs of LSP paths must use a unique path group ID along with the same Path Profile ID, which is configured on the NRC-P to enforce path disjointness or path bidirectionality constraints.

When the user wants to apply path disjointness and path bidirectionality constraints to RSVP-TE LSP paths, it is important to follow the following guidelines. The user can configure the following sets of LSP paths:

  1. A set consisting of a pair of forward RSVP-TE LSPs and a pair of reverse RSVP-TE LSPs each with a single path, primary or secondary. The pair of forward LSPs can originate and terminate on different routers. The pair of reverse LSPs must mirror the forward pair. In this case, the path profile ID and the path group ID configured for each LSP must match. Because each LSP has a single path, the bidirectionality constraint applies automatically to the forward and reverse LSPs, which share the same originating node and the same terminating routers.
  2. A pair consisting of a forward RSVP-TE LSP and a reverse RSVP-TE LSP, each with a primary path and a single secondary path, or each with a couple of secondary paths. Because the two paths of each LSP inherit the same LSP level path profile ID and path group ID configuration, the NRC-P path computation algorithm cannot guarantee that the primary paths in both directions meet the bidirectionality constraint. That is, it is possible that the primary path for the forward LSP shares the same links as the secondary path of the reverse LSP and vice-versa.

5.1.4.3.7. LSP Path Diversity and Bidirectionality Constraints

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. It 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.

Path profiles are defined by the user directly on the NRC-P Policy Manager with a number of LSP path constraints, which are metrics with upper bounds specified, and with an objective, which are metrics optimized with no bound specified. The NRC-P Policy Manager allows the following PCE constraints to be configured within each PCE Path Profile:

  1. path diversity, node-disjoint, link-disjoint
  2. path bidirectionality, symmetric reverse route preferred, symmetric reverse route required
  3. maximum path IGP metric (cost)
  4. maximum path TE metric
  5. maximum hop count

The user can also specify which PCE objective to use to optimize the path of the LSP in the PCE Path Profile:

  1. IGP metric (cost)
  2. TE metric
  3. hops (span)

The CSPF algorithm will optimize this objective. If a constraint is provided for the same metric, then the CSPF algorithm makes sure that 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, specifically the include/exclude admin-group constraints and setup and hold priorities, are not supported in the PCE profile.

In order 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, and identifies implicitly the set of paths which 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 a given LSP. However, the same path group ID can be associated with multiple PCE profile IDs for the same LSP.

The path profiles are inferred using the path ID in the path request by the PCC. 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. In other words, 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. PCE will check if there is an LSP in the reverse direction which belongs to the same path group ID as an originating LSP it is computing the path for, and will enforce the constraint.

In order 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.

Table 56 describes the new objects introduced in the PCE path profile.

Table 56:  PCEP Path Profile Extension Objects and TLVs 

TLV, Object, or Message

Contained in Object

Contained in Message

PATH-PROFILE-CAPABILITY TLV

OPEN

OPEN

PATH-PROFILE Object

N/A

PCReq, PCRpt, PCInitiate

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 will 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 will not use them during that PCEP session.

5.2. NSP and VSR-NRC PCE Redundancy

This feature introduces resilience support to the PCE and PCC capabilities.

5.2.1. Feature Configuration

In Release 16.0.R4, a CLI command parameter is introduced in the PCC for configuring the PCEP session to the standby backup PCE peer. A preference parameter value is used to decide the primary and the standby backup PCE peer:

# 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.

In order to change the value of the preference parameter, the peer must be deleted and recreated.

5.2.2. Feature Behavior

Figure 62 illustrates the NSP ecosystem and the provision of resilience across two separate sites. This is referred to as Disaster Recovery (DR) and is also sometimes referred to as geo-redundancy.

Figure 62:  NSP Ecosystem Resilience 

NSP ecosystem resilience consists of two mechanisms that can be deployed separately or together:

  1. High-Availability (HA) at a single site
    1. NSP, where the applications reside, is protected by a cluster of three Virtual Machines (VMs)
    2. the VSR-NRC module, which implements PCEP, OpenFlow, and BGP-LS/IGP, does not support HA and is deployed with a single VM which contains the combined CPM and IOM codes
  2. DR, which consists of a primary site and a secondary standby backup site. Each site consists of an NSP cluster and an VSR-NRC VM complex. A heartbeat protocol runs between the NSP clusters at the primary site and the standby backup sites.
    The VSR-NRC can be deployed as a standalone configuration; however, the NSP must be deployed in a cluster at each site. This configuration is also referred to as a 3+3 deployment.

Each parent NSP cluster establishes a reliable TCP session with a virtual IP to the local VSR-NRC. The TCP session runs an internal protocol, also known as cproto. This configuration is done prior to system startup and cannot be changed with an active NSP; the NSP must be shut down for any changes.

5.2.2.1. NSP Cluster Behavior

The following describes NSP cluster rules:

  1. At a single site, a master is elected among the cluster of three VMs. Between sites, a single cluster at one site, is the primary/active site and the other DR site is the secondary/standby site.
  2. The application processes at the standby site are shut down, but the neo4j and other databases are synchronized with the primary/active site.
  3. 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.
  4. 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.
  5. 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.

5.2.2.2. VSR-NRC Behavior

The following describes VSR-NRC rules:

  1. steady state behavior
    1. The VSR-NRC at the secondary/standby site, in the same way as the VSR-NRC at the primary/active site, establishes PCEP sessions to the PCCs. However, the VSR-NRC at the standby site has its PCEP sessions to the PCCs in the overload state. The VSR-NRC enters this PCEP overload state when its upstream cproto session to the NSP cluster is down, resulting from either the NSP cluster going into the standby state or the cproto session failing.
    2. The VSR-NRC acting as a PCE signals the overload state to the PCCs in a PCEP notification message. In the overload state, the VSR-NRC PCE accepts reports (PCRpt) without delegation but rejects requests (PCReq) and reject reports (PCRpt) with delegation. The VSR-NRC PCE also does not originate initiate messages (PCInitiate) and update messages (PCUpd).
    3. The VSR-NRC at the secondary/standby site maintains its BGP and IGP peerings with the network and updates its TE database as a result of any network topology changes.
  2. primary/active NSP cluster failure
    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/active and secondary/standby NSP clusters fails. This initiates the NSP cluster activity at the secondary/standby site.
    The following are the activities on the VSR-NRC:
    1. The VSR-NRC at the primary site detects cproto session failure and puts all its PCEP sessions to the PCCs into the overload state.
    2. The NSP cluster at the secondary site establishes the cproto session to the local VSR-NRC which then brings its PCEP sessions out of the overload state.
    3. The VSR-NRC at the secondary site begins synchronizing the TE and LSP databases with the parent NSP cluster at the secondary site that is now the active site.
    4. The VSR-NRC at the primary site must also return the delegation of all LSPs back to the PCCs by sending an empty LSP Update Request that has the Delegate flag set to 0 as per RFC 8231. This allows the PCCs to delegate all eligible LSPs, including PCE-initiated LSPs, to the PCE function in the VSR-NRC at the secondary site.
    Note:

    If the entire primary site fails, the above actions of the VSR-NRC at the primary site do not apply; however, the remaining actions do apply.

  3. VSR-NRC complex failure at the primary site (NSP server is still up)
    A VSR-NRC complex failure at the primary/active NSP site does not initiate an NSP switchover to the secondary/standby NSP site. If the VSR-NRC at the primary site does not recover, a manual switchover to the secondary NSP site is required. The VSR-NRC failure causes alarms to be raised on the NSP (cproto session failure alarm indicating that the NSP cannot communicate with the VSR-NRC). An operator can manually perform a switchover of the NSP activity to the secondary site.

5.2.2.3. PCC Behavior

The following describes PCC rules:

  1. PCCs can establish upstream PCEP sessions with at most two VSR-NRC PCEs.
  2. Each upstream session has a preference that takes effect when both upstream PCEP sessions are successfully established. 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, and in case of a tie, the PCE with the lower IP address is selected.
  3. In the steady state, because one upstream VSR-NRC PCE is in overload, only one PCEP session is active. The PCCs delegate an LSP using a report message (PCRpt) with the Delegate flag set to the active VSR-NRC PCE only. Request messages (PCReq) are not sent to the secondary/standby VSR-NRC PCE in overload. PCRpt messages are sent with the Delegate flag clear to the secondary/standby VSR-NRC PCE in overload.
  4. If the current active PCEP session signals overload state, the PCC will select the other PCE as the active PCE as long as the corresponding PCEP session is not in overload. Any new path request message (PCReq) or path report message (PCRpt) with the Delegate flag set, is sent to the new PCE.
    The PCE in overload should return the delegation of all existing LSPs back to this PCC by sending an empty LSP Update Request that has the Delegate flag set as per RFC 8231. This PCC will then delegate these LSPs to the new active PCE by sending a path report (PCRpt) with the Delegate flag set.
  5. If the current active PCEP session goes operationally down, the PCC starts the redelegation timer (default 90 seconds) and state timeout timer (default 180 seconds).
    1. If the PCEP session is restored before the redelegation timer expires, no delegation change is performed and the LSP state is maintained.
    2. Upon expiration of the redelegation timer, the PCC looks for the other PCEP session and, if not in overload, it immediately delegates the LSPs to the newly active PCE. If the new PCE accepts the delegation, the LSP state is maintained.
    3. If the PCEP session does not recover before the redelegation timer expires and the PCC fails to find another active PCEP session, then by default the PCC clears the LSP state of PCE-initiated LSPs after state timeout expiry; the PCC deletes the PCE-initiated LSPs and releases all their resources. A configuration option of the redelegation timer CLI command allows the user to keep the state of the pce-initiated LSPs instead. The PCC does not clear the state of PCC-initiated LSPs; however, the user can do this by deleting the configuration.