Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification
updated by
- rfc-9756 — Update to the IANA Path Communication Element Protocol (PCEP) Numbers Registration Procedures and the Allowance of Experimental Error Codes
Extracted elements (32)
Flow Specification state is carried as part of LSP-DB information (per RFC 8231), so synchronization between PCEP peers is achieved automatically through normal or enhanced LSP-DB synchronization procedures rather than requiring a separate mechanism.
Flow Specification TLV type values 0–255 are partitioned to mirror the BGP Flow Spec Component Types registry (RFC 8955/8956), using the BGP encoding but without the BGP type octet since PCEP uses 2-octet type fields. This enables direct reuse of BGP flow component definitions without re-specification.
In PCEP, no action is encoded with a Flow Specification because the only applicable action is to forward matching traffic onto the associated LSP or SR path. This differs from BGP Flow Specifications, which carry explicit actions; the PCEP action is implicit from the association with a path.
When both BGP (RFC 8955) and PCEP distribute Flow Specifications to the same implementation, the same RFC 8955 precedence ordering MUST be applied regardless of distribution protocol. Implementations MAY provide a configuration control to give one protocol precedence over the other for identical matches with different actions.
A Flow Filter TLV MUST NOT contain more than one Flow Specification TLV of the same type. A receiver finding duplicate types MUST respond with PCErr Error-Type 30, Error-value 2 (Malformed FlowSpec) and MUST NOT install the Flow Specification.
A PCC MUST enable an operator to view installed Flow Specifications presented in order of precedence, so that when two Flow Specifications overlap, the higher-precedence one is shown first.
An implementation receiving a Flow Specification TLV with an unrecognized or unsupported type MUST respond with PCErr Error-Type 30, Error-value 1 (Unsupported FlowSpec) and MUST NOT install the Flow Specification.
An implementation that cannot resolve a new Flow Specification against already-installed ones (e.g., irresolvable conflicts) MUST respond with PCErr Error-Type 30, Error-value 3 (Unresolvable Conflict) and MUST NOT install the Flow Specification.
During PCEP session establishment, a PCC or PCE that supports Flow Specifications MUST include the PCE-FLOWSPEC-CAPABILITY TLV in the OPEN object. If either peer omits this TLV, the other peer MUST NOT include a FLOWSPEC object in any subsequent PCEP message to that peer.
If the L (LPM) bit is set and the receiver does not support LPM route installation from Flow Specifications in the Flow Filter TLV, the peer MUST respond with PCErr Error-Type 30, Error-value 5 (Unsupported LPM Route).
PCCs MUST apply the same Flow Specification ordering and prioritization rules defined in RFC 8955 Section 5.1. When both BGP and PCEP distribute Flow Specifications, implementations supporting both MUST apply RFC 8955 ordering regardless of which protocol distributed them.
PCE FlowSpec capability MUST be negotiated during PCEP session setup even if it was previously advertised in IGP. A PCEP peer that advertised FlowSpec support in the IGP is not obliged to support it on any given PCEP session.
The Flow Filter TLV MUST be present in the FLOWSPEC object when the R (Remove) bit is clear. If absent with R=0, the peer MUST respond with PCErr Error-Type 30, Error-value 2 (Malformed FlowSpec).
The SPEAKER-ENTITY-ID TLV (per RFC 8232) MUST be included in every FLOWSPEC object to uniquely identify the FlowSpec originator. If missing, the receiver MUST respond with PCErr Error-Type 30, Error-value 2 (Malformed FlowSpec). If multiple instances are present, only the first is processed.
When modifying a Flow Specification, all Flow Specification TLVs for the intended flow MUST be included in the FLOWSPEC object. The FS-ID MUST be retained from the previous description, and the same Speaker Entity Identifier TLV MUST be used.
When the R (Remove) bit is set in a FLOWSPEC object and no matching FS-ID exists, the receiver MUST generate a PCErr with Error-Type 30, Error-value 4 (Unknown FlowSpec). If the AFI is unrecognized, Error-value 2 (Malformed FlowSpec) MUST be returned.
Knowledge of connected endpoints (multicast receivers, VPN sites) and routing topology exposed via PCEP FlowSpec is typically private customer information. Implementations concerned with privacy MUST apply IPsec or TLS to protect the PCEP session.
Flow Specification TLVs are carried within the Flow Filter TLV. Type values 0–255 mirror the BGP Flow Spec registry (RFC 8955/8956) and use BGP encoding without the type octet; values 256–65535 are PCEP-specific allocations from a new IANA registry.
The Flow Filter TLV (Type=52) is carried within the FLOWSPEC object and contains one or more Flow Specification TLVs representing the complete flow definition. Only one Flow Filter TLV is permitted per FLOWSPEC object; additional flows require additional FLOWSPEC objects.
The PCEP FLOWSPEC object (Object-Class 43, Object-Type 1) is OPTIONAL and MAY appear zero, one, or more times in PCReq, PCRep, PCErr, PCInitiate, PCRpt, and PCUpd messages. Each instance specifies a separate traffic flow and MAY carry a Flow Filter TLV.
IANA added Error-Type 30 (FlowSpec error) to the 'PCEP-ERROR Object Error Types and Values' subregistry with Error-values: 1 (Unsupported FlowSpec), 2 (Malformed FlowSpec), 3 (Unresolvable Conflict), 4 (Unknown FlowSpec), 5 (Unsupported LPM Route).
IANA allocated PCEP Object-Class 43 (FLOWSPEC) with Object-Type 0 (Reserved) and Object-Type 1 (Flow Specification) in the 'PCEP Objects' subregistry.
IANA allocated PCEP TLV Type 51 (PCE-FLOWSPEC-CAPABILITY TLV) and Type 52 (FLOW FILTER TLV) in the 'PCEP TLV Type Indicators' subregistry.
IANA created a new 'FLOWSPEC Object Flag Field' subregistry under PCEP Numbers (Standards Action assignment policy). Initial allocations: bit 6 = LPM (L bit), bit 7 = Remove (R bit); bits 0–5 unassigned.
IANA created a new 'PCEP Flow Specification TLV Type Indicators' subregistry. Range 0–255 is reserved mirroring BGP Flow Spec registries; 256–64506 requires Specification Required; 64507–65531 is First Come First Served; 65532–65535 is Experimental. Initial values: 256 (Route Distinguisher), 257 (IPv4 Multicast), 258 (IPv6 Multicast).
IANA registered bit 16 as the 'FlowSpec' capability flag in the OSPF 'Path Computation Element (PCE) Capability Flags' registry, allowing PCEs to advertise FlowSpec support via IGP discovery.
Complex overlapping Flow Specifications installed in different orders can lead to unexpected forwarding behavior that may be engineered by an attacker to create gaps in traffic monitoring or bypass mitigations. Implementers and operators SHOULD pay careful attention to manageability considerations.
Flow Specification distribution via PCEP can be attacked to misroute traffic without tearing down LSPs or SR paths. Implementations MUST secure the PCEP session using IPsec (RFC 5440 Sections 10.4–10.6) or TLS (RFC 8253). TCP-MD5 SHOULD NOT be relied upon as it provides insufficient security guarantees.
IPv4 Multicast Flow (Type=257) and IPv6 Multicast Flow (Type=258) TLVs encode: Reserved field, S and G wildcard bits, Src Mask Length, Group Mask Length, Source Address (32 or 128 bits), and Group multicast Address (32 or 128 bits). If G=1 and S=0, receiver MUST respond with PCErr Error-Type 30/Error-value 2.
The PCE-FLOWSPEC-CAPABILITY TLV has Type=51, Length=2 octets. The Value field MUST be set to 0 and ignored on receipt; two bytes of padding MUST be set to zero and ignored on receipt.
The PCEP FLOWSPEC object body contains: FS-ID (32-bit unique session-scoped identifier, values 0 and 0xFFFFFFFF reserved), AFI (16-bit Address Family Identifier per RFC 4760), Reserved (8 bits, zero), Flags (8 bits including L bit for LPM and R bit for Remove), followed by TLVs.
The ROUTE-DISTINGUISHER TLV (Type=256, Length=8) carries an 8-byte RD value formatted per RFC 4364, used to identify that other flow filter information is associated with a specific VPN.