Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol
obsoletes
- rfc-7150 — Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol
updated by
- rfc-9752 — Conveying Vendor-Specific Information in the Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
Extracted elements (17)
RFC 7470 was created to obsolete RFC 7150 for two reasons: to clarify that the VENDOR-INFORMATION-TLV is available in any PCEP object (existing or future) that supports TLVs, and to allocate a different Object-Class code point (34 instead of 32) due to an inadvertent clash with codepoints used in a deployed Internet-Draft without IANA allocation.
The existing PCEP METRIC Object had no facility for vendor-specific metrics, and no PCEP mechanism existed for carrying complex vendor-specific information. The Vendor Information object and TLV were introduced to fill this gap while encouraging vendors to eventually bring widely-adopted extensions to the IETF for standardization.
A legacy implementation that does not recognize the Vendor Information object will reject the PCReq with PCErr Error-Type 3 ('Unknown Object') if the P flag is set, or safely ignore the object if the P flag is not set, per RFC 5440 procedures.
By definition, inclusion of the Vendor Information object or VENDOR-INFORMATION-TLV implies an inability to interoperate functionally with implementations from other vendors unless a cooperation agreement exists between vendors.
A PCC SHOULD monitor the capabilities of a PCE via discovery mechanisms or negative responses, and SHOULD NOT include vendor information in a PCReq to a PCE believed not to support the information and that will not forward the request to a supporting PCE.
A PCE that receives a PCReq containing a Vendor Information object MUST act according to the P flag in the object header: if P is set, the object is mandatory and the request must be processed using the object's contents or rejected; if P is clear, the object may be used or ignored.
A PCE that supports the Vendor Information object but receives one carrying an unknown Enterprise Number MUST act according to the P flag: if P is set, the PCE MUST reject the PCReq with Error-Type 'Not supported Object' and return the corresponding Vendor Information object.
If the Enterprise Number in a Vendor Information TLV is unknown to the PCE, it MUST treat the TLV as an unknown TLV and handle it as described in RFC 5440, which requires unrecognized TLVs to be ignored.
It is NOT RECOMMENDED that standard MIB modules be extended to include detailed information about the content of the Vendor Information object or TLV; the MIB module MAY be extended to report the use of the object or TLV and the Enterprise Numbers they contain.
Multiple instances of the Vendor Information object MAY be used in a single PCReq message, each MUST be treated according to its P-bit setting, and different instances MAY carry different Enterprise Numbers.
Unrecognized TLVs in PCEP objects MUST be ignored per Section 7.1 of RFC 5440, ensuring backward compatibility for implementations that do not recognize the VENDOR-INFORMATION-TLV.
The VENDOR-INFORMATION object (Object-Class 34, Object-Type 1) carries arbitrary vendor-specific constraints or metrics in PCEP messages. It is identified by an Enterprise Number that uniquely identifies the organization responsible for the content's definition and meaning.
The VENDOR-INFORMATION-TLV (Type 7) can be carried in any PCEP object that supports TLVs, allowing vendor-specific information to be scoped to a specific PCEP object. Its format is identical to the VENDOR-INFORMATION object.
IANA assigned Object-Class value 34 for the VENDOR-INFORMATION object with Object-Type 1 (Vendor-Specific Constraints) in the 'PCEP Objects' subregistry of 'Path Computation Element Protocol (PCEP) Numbers'. The previously assigned value 32 was released and marked 'Unassigned'.
IANA assigned TLV Type value 7 for the VENDOR-INFORMATION-TLV in the 'PCEP TLV Type Indicators' subregistry, updating the reference from RFC 7150 to RFC 7470.
The security considerations of RFC 5440 apply unchanged, as the extensions defined in RFC 7470 do not substantially change the nature of PCEP. The Vendor Information object and TLV may provide a vector for message-bloat attacks; authentication and integrity procedures from RFC 5440 should be used to mitigate this risk.
Both the VENDOR-INFORMATION object and VENDOR-INFORMATION-TLV share the same format: a 32-bit Enterprise Number field followed by a variable-length Enterprise-Specific Information field. The Enterprise Number is assigned by IANA per RFC 2578.