The base implementation of the PCE uses the PCEP extensions defined in RFC 5440.
The main functions of 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 the PCC or path computation cancellation by the PCE
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 TLVs, objects, and messages.
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, PCRpt1 |
METRIC Object |
N/A |
PCReq, PCRep, PCRpt1 |
Explicit Route Object (ERO) |
N/A |
PCRep |
Reported Route Object (RRO) |
N/A |
PCRpt1 |
LSPA Object |
N/A |
PCReq, PCRep, PCRpt1 |
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 the preceding table are as follows:
The 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 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 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 value. The PCE returns the computed value in the PCRep message with flags set identically to the PCReq message.
The IRO and LOAD-BALANCING objects are not part of 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.
The LSPA, metric, and bandwidth objects are also included in the PCRpt message. The inclusion of these objects in the PCRpt message is proprietary to Nokia.
The following features are not supported on the 7210 SAS:
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. PCE standards do not currently support an LSP container with multiple paths, and the PCE 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 the PCE.
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