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.

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

The behavior and limitations of the implementation of the objects in Table: PCEP stateful PCE extension objects and TLVs are as follows:

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

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

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

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

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

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

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

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

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

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

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

  • For interoperability, implementations compliant to PCEP standards should be able to accept the first METRIC object and ignore the second object without additional error handling. Because 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 the following table for PCE initiation of LSPs.