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.
| TLV, object, or message | Contained in object | Contained in message |
|---|---|---|
|
OPEN object |
— |
OPEN, PCErr |
|
Request Parameter (RP) object |
— |
PCReq, PCRep, PCErr, PCNtf |
|
NO-PATH object |
— |
PCRep |
|
END-POINTS object |
— |
PCReq |
|
BANDWIDTH object |
— |
PCReq, PCRep, PCRpt, PCInitiate |
|
METRIC object |
— |
PCReq, PCRep, PCRpt, PCInitiate |
|
Explicit Route Object (ERO) |
— |
PCRep |
|
Reported Route Object (RRO) |
— |
PCReq |
|
LSPA object |
— |
PCReq, PCRep, PCRpt, PCInitiate |
|
NOTIFICATION object |
— |
PCNtf |
|
PCEP-ERROR object |
— |
PCErr |
|
CLOSE object |
— |
CLOSE |
| ASSOCIATION object | – | PCReq, PCRpt, PCRep, PCUpd, PCInitiate |
The behavior and limitations of the implementation of the objects in Table: 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)