The base implementation of PCE uses the PCEP extensions defined in RFC 5440.
The main functions of the PCEP are:
PCEP session establishment, maintenance, and closing
path computation requests using the PCReq message
path computation replies using the PCRep message
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
error messages (PCErr) by which the PCEP speaker can inform its peer about errors related to processing requests, message objects, or TLVs
Table 1 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 |
|
Include Route Object (IRO) |
— |
PCReq, PCRep |
|
SVEC Object |
— |
PCReq |
|
NOTIFICATION Object |
— |
PCNtf |
|
PCEP-ERROR Object |
— |
PCErr |
|
LOAD-BALANCING Object |
— |
PCReq |
|
CLOSE Object |
— |
CLOSE |
The behavior and limitations of the implementation of the objects in Table 1 are as follows:
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).
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.
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.
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.
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.
The LSPA, METRIC, and BANDWIDTH objects are also included in the PCRpt message.
The following features are not supported in the SR OS:
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
security of the PCEP session using MD5 or TLS between PCEP peers
PCEP synchronization optimization as per draft-ietf-pce-stateful-sync-optimizations
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.
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