Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS
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)
The BANDWIDTH and LOAD-BALANCING objects reuse RSVP-TE SENDER_TSPEC C-Type encodings rather than defining new encodings, because RSVP-TE already provides unambiguous technology-specific bandwidth representations for SDH/SONET, G.709/OTN, Ethernet, and other GMPLS technologies. This avoids duplication and ensures consistency with the data-plane signaling.
The LABEL-REQUEST TLV is separate from the TE-LSP label request (expressed by the SWITCH-LAYER object) because endpoint labels and TE-LSP labels can be different, supporting different LABEL-REQUESTs (e.g., in multi-layer requests where endpoints have distinct switching capabilities from the path itself).
PCEs that set the GMPLS bit in the PCE-CAP-FLAGS Sub-TLV of the IGP PCED TLV MUST follow the procedures in Section 2.1.2 to further qualify their GMPLS support level during PCEP session establishment via the GMPLS-CAPABILITY TLV in the OPEN object.
The RG flag in the RP object is backward compatible with RFC 5440: implementations not supporting it will indicate a reserved value (0), which the receiver treats as unspecified granularity and leaves ERO checking to the PCC.
A LABEL-SET TLV with both O and L bits set MUST trigger a PCErr with Error-Type=10 and Error-value=29. A LABEL-SET TLV with O bit set and Action field not set to 0 (Inclusive List) or containing more than one subchannel MUST trigger Error-value=30.
A PCEP speaker that supports the GMPLS extensions defined in this document MUST include the GMPLS-CAPABILITY TLV in the Open message. If one of the PCEP peers does not include this TLV, the peers MUST NOT make use of the objects and TLVs defined in this document.
For Point-to-Point endpoint type, two endpoint TLVs MUST be present: the first is the source and the second is the destination. For P2MP, the root endpoint MUST be the same for all END-POINTS objects; inconsistent root endpoints require a PCErr with Error-Type=17 and Error-value=4.
If a LABEL-SET TLV is present with the O bit set, the R bit of the RP object MUST be set; otherwise a PCErr MUST be sent with Error-Type=10 and Error-value=28.
If a PCE finds a non-supported TLV in the END-POINTS Generalized Endpoint object, the PCE MUST respond with PCErr Error-Type=4 and Error-value=8 (Unsupported TLV present in END-POINTS Generalized Endpoint object type).
If a PCE honored the requested routing granularity, it MUST indicate the selected routing granularity in the RP object in the response. Otherwise, the PCE MUST use the reserved RG value to leave ERO checking to the PCC.
If a PCEP speaker supports the extensions of this specification but did not advertise GMPLS-CAPABILITY, upon receipt of a message including an extension defined in this document, it MUST generate a PCErr with Error-Type=10 and Error-value=31 (Missing GMPLS-CAPABILITY TLV), and it SHOULD terminate the PCEP session.
If the PROTECTION-ATTRIBUTE TLV is ignored by the PCE, it MUST NOT include the TLV in the LSPA of the response. When used by the PCE, an LSPA object and the TLV MUST be included in the response, with fields not considered set to 0.
The Bandwidth Spec Length in BANDWIDTH object types 3 and 4 MUST be strictly greater than 0. The Reverse Bandwidth Spec Length MAY be equal to 0 (used for symmetric bidirectional paths).
When the PCE is not able to handle different Bw Spec Types in the BANDWIDTH and LOAD-BALANCING objects, it MUST return a NO-PATH with the bit 'LOAD-BALANCING could not be performed with the bandwidth constraints' set in the NO-PATH-VECTOR TLV.
A Label subobject (Type 10) is added to the IRO to support explicit label control. The Label subobject MUST follow a subobject identifying a link (IP address Type 1/2 or interface ID Type 4). If the PCE cannot allocate labels from the set, it sends NO-PATH with 'No label resource in range' bit set.
A new 2-bit Routing Granularity (RG) flag (bits 15-16) is defined in the RP object to indicate the requested ERO route granularity: 0=reserved, 1=node, 2=link, 3=label. This supports the Explicit Label Control feature of RSVP-TE.
BANDWIDTH object type 3 represents Generalized bandwidth for a new TE-LSP; type 4 represents Generalized bandwidth of an existing TE-LSP for which reoptimization is requested. Both reuse RSVP-TE traffic specification encodings supporting SONET/SDH, G.709, Ethernet, OTN-TDM, SSON, and Intserv.
END-POINTS object type 5 (Generalized Endpoint) supports unnumbered interfaces, label restrictions, and P2MP endpoints in GMPLS networks. It contains an 8-bit Endpoint Type field (0=P2P, 1-4=P2MP leaf types, 5-244=Unassigned, 245-255=Experimental) followed by TLVs.
Seven new bits are defined in the NO-PATH-VECTOR TLV flags field: bits 18 (Protection Mismatch), 17 (No Resource), 16 (Granularity not supported), 15 (No endpoint label resource), 14 (No endpoint label resource in range), 13 (No label resource in range), and 12 (LOAD-BALANCING could not be performed with bandwidth constraints).
The GMPLS-CAPABILITY TLV (Type=45) is included in the OPEN object to negotiate GMPLS capability during session establishment. It contains a 32-bit Flags field; all flags are currently unassigned and MUST be set to zero on transmission and ignored on receipt.
The PROTECTION-ATTRIBUTE TLV (Type 44) is optionally carried in the LSPA object and contains LSP Flags, Link Flags, and Segment Flags as defined in RFC 4872 and RFC 4873. It conveys end-to-end protection type and link protection type for GMPLS path computation policy input.
IANA allocated new PCEP object types: BANDWIDTH types 3 (Generalized bandwidth) and 4 (Generalized bandwidth of existing TE-LSP for reoptimization), LOAD-BALANCING type 2 (Generalized Load Balancing), and END-POINTS type 5 (Generalized Endpoint).
IANA allocated seven new PCEP TLV type values: 39 (IPV4-ADDRESS), 40 (IPV6-ADDRESS), 41 (UNNUMBERED-ENDPOINT), 42 (LABEL-REQUEST), 43 (LABEL-SET), 44 (PROTECTION-ATTRIBUTE), and 45 (GMPLS-CAPABILITY) in the 'PCEP TLV Type Indicators' subregistry.
IANA created a new 'Generalized Endpoint Types' registry for the Endpoint Type field of the END-POINTS Generalized Endpoint object. Values 0-4 are defined (P2P and P2MP leaf types 1-4), 5-244 are Unassigned (assigned by Standards Action), and 245-255 are for Experimental Use only.
IANA created a new 'GMPLS-CAPABILITY TLV Flag Field' subregistry within the PCEP Numbers registry. New bit numbers are assigned by Standards Action. The initial contents are empty with bits 0-31 marked Unassigned.
GMPLS LSPs can carry high traffic volumes and form critical infrastructure; the PCE plays a key role in resource usage and physical path determination. PCE and PCC SHOULD use TLS (RFC 8253) for authentication, message integrity, replay protection, and confidentiality. PCC SHOULD have policies to validate that returned paths satisfy the provided constraints.
Three main attack scenarios exist in GMPLS PCE context: PCE identity theft (malicious PCE returns paths ignoring constraints or enabling physical attacks), PCC identity theft (malicious PCC learns physical topology of critical infrastructure), and message inspection (sniffing PCEP messages reveals infrastructure details). TLS per RFC 8253 and PCC-side path validation policies are recommended mitigations.
The BANDWIDTH object types 3 and 4 (Generalized bandwidth) have a variable-length body with a 16-bit Bandwidth Spec Length, a 16-bit Reverse Bandwidth Spec Length, an 8-bit Bw Spec Type (corresponding to RSVP-TE SENDER_TSPEC C-Types), followed by Generalized Bandwidth and optional Reverse Generalized Bandwidth fields, and optional TLVs.
The Generalized Load Balancing object (LOAD-BALANCING type 2) has a variable-length body with 16-bit Bandwidth Spec Length, 16-bit Reverse Bandwidth Spec Length, 8-bit Bw Spec Type, 8-bit Max-LSP, variable Min Bandwidth Spec, optional Min Reverse Bandwidth Spec, and optional TLVs.
The LABEL-SET TLV (Type 43) encodes label or label range restrictions with an 8-bit Action field, reserved bits, L/O/U flag bits, a Label Type field, and variable-length Subchannel fields. The L bit indicates a suggested (loose) label set; U indicates upstream direction; O indicates old label for reoptimization.
The UNNUMBERED-ENDPOINT TLV (Type 41) encodes an unnumbered interface as a 32-bit LSR Router ID followed by a 32-bit Interface ID, following the semantics of RFC 3477.
The XRO Label subobject (Type 10) encodes a 1-bit X field, 7-bit Type=10, 8-bit Length, 1-bit U field, reserved bits, 8-bit C-Type (as per RFC 3473), and a variable-length Label field. The X bit indicates mandatory (0) or desired (1) exclusion.