Path Computation Element (PCE) Communication Protocol (PCEP)
updated by
- rfc-7896 — Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP)
- rfc-8253 — PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)
- rfc-8356 — Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP)
- rfc-9488 — Local Protection Enforcement in the Path Computation Element Communication Protocol (PCEP)
- rfc-9756 — Update to the IANA Path Communication Element Protocol (PCEP) Numbers Registration Procedures and the Allowance of Experimental Error Codes
Extracted elements (31)
PCEP was designed to run over TCP rather than UDP or a new transport because TCP provides reliable messaging and flow control, fulfilling RFC 4657 requirements without additional protocol machinery. This choice also allows intermittent or permanent session models depending on request frequency.
Only one PCEP session and only one TCP connection on the PCEP port may exist between a pair of PCEP peers at any time. Each PCEP message is a single transmission unit and parts of messages MUST NOT be interleaved; a peer must finish sending one message before beginning the next.
A PCEP implementation that receives an unrecognized message MUST send a PCErr with Error-value=2 (capability not supported). If unrecognized messages arrive at a rate ≥ MAX-UNKNOWN-MESSAGES (recommended: 5) per minute, the peer MUST send a Close message and MUST close the TCP session.
A PCReq message MUST contain both an RP object and an END-POINTS object; if either is missing the PCE MUST send a PCErr with Error-Type 'Required Object missing'. Implementations MUST form PCEP messages using the object ordering specified in the document.
After sending an Open message the sender MUST start an OpenWait timer (1 minute fixed); if no Open message is received it sends a PCErr and releases TCP. After receiving an Open message it MUST start a KeepWait timer (1 minute); if neither Keepalive nor PCErr arrives before expiry, it MUST send a PCErr and release the TCP connection.
All PCEP messages MUST be sent using TCP port 4189 for both source and destination TCP port. PCEP relies on TCP to fulfill reliable messaging and flow control requirements without further protocol work.
If a second Open message is received with the same unacceptable session parameters, the receiving peer MUST send a PCErr and MUST immediately close the TCP connection. The PCEP session is considered established only once both peers have received a Keepalive message from their peer.
Once a TCP connection is established, the first message sent by either peer MUST be an Open message. Any message received prior to an Open message MUST trigger a PCErr with Error-Type 'PCEP session establishment failure' and the TCP connection MUST be immediately closed.
The DeadTimer SHOULD be set to 0 and MUST be ignored when Keepalive is set to 0. If Keepalive is nonzero, the recommended default DeadTimer is 4 times the value of the Keepalive used by the remote peer to avoid excessive TCP keepalive traffic.
The Request-ID-number value 0x00000000 is invalid. Request-ID-numbers MUST be changed for each new request. If unknown request references are received at a rate ≥ MAX-UNKNOWN-REQUESTS (recommended: 5) per minute, the peer MUST send a Close message and MUST close the TCP session.
Upon receipt of a valid Close message, the receiving peer MUST cancel all pending requests, MUST close the TCP connection, and MUST NOT send any further PCEP messages. A Close message can only be sent after a PCEP session has been successfully established.
When a PCE cannot find a path satisfying the constraints, it MUST include a NO-PATH object in the PCRep message. When the R bit is set and the TE LSP is non-zero-bandwidth, the absence of an RRO object MUST trigger a PCErr with Error-Type='Required Object Missing' and Error-value='RRO Object missing for reoptimization'.
When the P flag is set in a PCReq object, the PCE MUST take that object into account during path computation. If the PCE does not understand or chooses to ignore a P-flagged object, it MUST reject the entire corresponding request and send a PCErr with Error-Type 'Unknown Object' or 'Not supported Object'.
PCEP messages expose detailed network topology and traffic engineering information including source/destination addresses, bandwidth requirements, constraints, and computed explicit paths. This data should be protected against eavesdropping as it may reveal confidential network structure and traffic patterns.
PCEP defines seven message types: Open (1), Keepalive (2), Path Computation Request/PCReq (3), Path Computation Reply/PCRep (4), Notification/PCNtf (5), Error/PCErr (6), and Close (7).
The PCRep message bundles multiple path computation replies and contains a response-list where each response includes an RP object, optional NO-PATH, optional attribute-list (LSPA, BANDWIDTH, METRIC, IRO), and optional path-list (each path is an ERO followed by an attribute-list). The PCRep MUST contain at least one RP object.
The RP (Request Parameters) object carries request characteristics: Pri (3-bit priority 1–7), R (reoptimization bit), B (bidirectional bit), O (strict/loose path bit), and a 32-bit Request-ID-number. The Request-ID-number combined with PCC and PCE addresses uniquely identifies the path computation request context.
The SVEC (Synchronization VECtor) object allows a PCC to request synchronized computation of a set of TE LSPs, specifying dependency relationships (link-diverse, node-diverse, SRLG-diverse) that the PCE must honor across the bundled requests. A PCReq may include an svec-list preceding the request-list.
RFC 5440 creates IANA registries for: PCEP Messages (types 1–7), PCEP Object classes and types, Message Common Header flags, Open Object flags, RP Object flags, NO-PATH Object flags, NO-PATH-VECTOR TLV flags, METRIC Object T field values (1–3), NOTIFICATION Object type/value, PCEP-ERROR Object type/value, CLOSE Object reasons, and PCEP TLV Type Indicators.
PCEP is vulnerable to impersonation of a PCE or PCC, man-in-the-middle injection of crafted requests or replies, and replay attacks that could cause incorrect paths to be computed and deployed in the network. TCP-level or PCEP-level authentication and integrity protection are required to mitigate these risks.
PCEP SHOULD use TCP authentication (TCP MD5 per RFC 2385, noting its known weaknesses, or TCP-AO per RFC 5925) or IPsec to protect session integrity and authenticity. Key configuration and distribution are deployment concerns; static pre-shared keys or out-of-band key exchange are discussed.
To protect against DoS attacks, PCEP implementations must enforce MAX-UNKNOWN-MESSAGES and MAX-UNKNOWN-REQUESTS rate limits (both recommended at 5 per minute), close the session on breach, and implement request input shaping/policing. PCE overload should be signaled via PCNtf so PCCs can redirect to alternate PCEs.
The PCEP FSM (Appendix A) defines states: Idle, TCPPending, OpenWait (awaiting Open after TCP established), KeepWait (awaiting Keepalive after Open sent), and SessionUp. Transitions are triggered by TCP connection events, reception/validity of Open and Keepalive messages, PCErr, timer expiry (OpenWait or KeepWait, both 1 minute), and Close reception.
PCEP TLVs have a fixed structure: Type (2 bytes), Length (2 bytes, length of value portion only), and Value (variable). TLVs are padded to 4-byte alignment; padding bytes are not counted in the Length field. Unrecognized TLVs MUST be ignored.
The BANDWIDTH object body is 4 bytes: a single 32-bit IEEE 754 floating-point value representing bandwidth in bytes per second. Object-Type=1 is requested bandwidth; Object-Type=2 is bandwidth of the existing TE LSP being reoptimized. If requested bandwidth is nonzero, the PCReq MUST contain a BANDWIDTH object.
The END-POINTS object specifies source and destination IP addresses. IPv4 (Object-Type=1) body is 8 bytes (two 32-bit addresses); IPv6 (Object-Type=2) body is 32 bytes (two 128-bit addresses). The P flag MUST be set; if received cleared, a PCErr with Error-Type=10 Error-value=1 MUST be sent.
The METRIC object body is 8 bytes: Reserved (16 bits), Flags (8 bits, B=bound and C=compute-and-return), T/type (8 bits, 1=IGP metric, 2=TE metric, 3=hop count), and metric-value (32-bit IEEE 754 float). Multiple METRIC objects per request are allowed; at most one instance per metric type per B flag value.
The NO-PATH object body is 32 bits plus optional TLVs: NI/Nature of Issue (8 bits, 0=no satisfying path, 1=PCE chain broken), C flag (1 bit, unsatisfied constraints included in reply), Flags (15 bits reserved), and Reserved (8 bits). An optional NO-PATH-VECTOR TLV (type=1, length=4, 32-bit flags) provides additional failure detail.
The OPEN object body is 32 bits plus optional TLVs: Ver (3 bits), Flags (5 bits, reserved), Keepalive (8 bits, seconds between messages, min=1, recommended=30, 0=disabled), DeadTimer (8 bits, recommended=4×Keepalive), and SID/session ID (8 bits, incremented per session, used for logging).
The PCEP common object header is one 32-bit word: Object-Class (8 bits), OT/Object-Type (4 bits), Res/reserved (2 bits, must be zero), P flag/Processing-Rule (1 bit), I flag/Ignore (1 bit), and Object-Length (16 bits, total object length in bytes, always a multiple of 4, minimum 4).
The PCEP message common header is one 32-bit word: Ver (3 bits, current=1), Flags (5 bits, reserved/zero), Message-Type (8 bits, values 1–7), and Message-Length (16 bits, total message length in bytes including header).