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 1 describes the messages and objects supported by stateful PCE in the SR OS.
TLV, Object, or Message |
Contained in Object |
Contained in Message |
---|---|---|
Path Computation State Report (PCRpt) |
— |
New message |
Path Computation Update Request (PCUpd) |
— |
New message |
Stateful PCE Capability TLV |
OPEN |
OPEN |
Stateful Request Parameter (SRP) Object |
— |
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 1 are as follows:
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.
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.
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:
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.
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.
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.
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.
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.
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 contains a single set. If the PCRpt contains a duplicate set, 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. 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 2 for PCE initiation of LSPs.
TLV, Object, or Message |
Contained in Object |
Contained in Message |
---|---|---|
PCE LSP Initiate Message (PCInitiate) |
— |
New message |
PCC LSP Create Flag (C-Flag) |
LSP |
PCRpt |
PATH_PROFILE_ID TLV |
Path Profile |
N/A |