Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol
obsoleted by
- rfc-7470 — Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol
Extracted elements (18)
The existing PCEP METRIC Object supports new standardized metrics but has no facility for vendor-specific metrics, and there is no general mechanism in PCEP for complex vendor-specific information; the Vendor Information object and TLV fill this gap without modifying existing objects.
The mechanism uses an IANA-assigned Enterprise Number to identify the organization responsible for interpreting the vendor-specific content, rather than a PCEP-specific registry, allowing arbitrary vendor differentiation without exhausting a shared codepoint space. Vendors are encouraged to document and eventually standardize widely useful extensions.
A legacy implementation that does not recognize the VENDOR-INFORMATION-TLV will ignore it per RFC 5440 Section 7.1, which requires that unrecognized TLVs be ignored, ensuring backward compatibility.
By definition, inclusion of a Vendor Information object or VENDOR-INFORMATION-TLV implies an inability to interoperate at a functional level with implementations from other vendors unless a cooperation agreement between vendors exists.
A PCC SHOULD monitor the capabilities of a PCE (via discovery or negative responses) and SHOULD NOT include vendor information in a PCReq to a PCE that it believes does not support the information and will not forward the request to a PCE that does.
A PCE that receives a PCReq containing a Vendor Information object MUST act according to the P flag: if the P flag is set, the object is mandatory and the request must either be processed using the object's contents or rejected per RFC 5440; if the P flag is clear, the object MAY be used or ignored.
A PCE that supports the Vendor Information object but receives one with an unsupported Enterprise Number MUST act according to the P flag. If the P flag is set, the PCE MUST reject the PCReq by sending an Error message with Error-Type='Not supported Object' along with the corresponding Vendor Information object.
If a PCE receives a Vendor Information TLV with an unknown Enterprise Number, it MUST treat it as an unknown TLV and handle it per RFC 5440, which requires that unrecognized TLVs MUST 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; however, MIB modules MAY be extended to report the use of these constructs 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. Different instances MAY carry different Enterprise Numbers.
The Vendor Information object can also be included in PCRep messages in exactly the same way as any other object, appearing within the <response> and <end-point-path-pair-list> grammar constructs.
The Vendor Information object can be placed in a PCReq message to apply to a single path computation request or to a set of synchronized requests, mirroring the usage of the Objective Function object. Its position in the PCReq grammar is defined within <svec-list> and <request> as a <vendor-info-list>.
The Vendor Information object (Object-Class 32, Object-Type 1) is a new PCEP object used to carry arbitrary, proprietary information such as vendor-specific constraints or metrics from a PCC to a PCE or vice versa.
The VENDOR-INFORMATION-TLV (Type 7) is a new PCEP TLV that can carry vendor-specific information within any existing PCEP object that supports TLVs.
IANA allocated Object-Class value 32 with name VENDOR-INFORMATION in the 'PCEP Objects' subregistry, with Object-Type 1 for Vendor-Specific Constraints (types 0 and 2-255 unassigned).
IANA allocated TLV Type value 7 with description VENDOR-INFORMATION-TLV in the 'PCEP TLV Type Indicators' subregistry.
The protocol extensions do not substantially change the nature of PCEP, so the security considerations of RFC 5440 apply unchanged; further considerations for PCEP over TCP are in RFC 6952. Operators should be aware that the Vendor Information object and TLV may be used as a vector for message-size amplification attacks consuming bandwidth and processing power, mitigated by authentication and integrity procedures from RFC 5440.
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 and identifies the organization defining the content.