Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol
Extracted elements (17)
Class-Type 0 is excluded from the CLASSTYPE object (its inclusion is prohibited) to allow backward compatibility with PCEs that do not support the CLASSTYPE object. The absence of the object signals Class 0, avoiding rejection by legacy PCEs.
To ensure coherent DS-TE operation, a PCE and PCC should share a common understanding of DS-TE Class-Types and TE-classes. If a path computation request crosses an Autonomous System boundary, these should have global significance in all domains, though enforcement of this is outside the scope of this document.
A path computation reply message MUST NOT include a CLASSTYPE object.
A PCE that does not recognize the CLASSTYPE object MUST reject the entire PCEP message and MUST send a PCE error with Error-Type 'Unknown Object' or 'Not supported object' as defined in RFC 5440.
A PCE that recognizes the CLASSTYPE object but determines the Class-Type value is not valid (i.e., value 0) MUST send a PCE error with error type 'Diffserv-aware TE error' (Error-Type 12) and error value 'Invalid Class-Type' (Error-value 2).
If a path computation request contains multiple CLASSTYPE objects, only the first is meaningful; subsequent CLASSTYPE objects MUST be ignored and MUST NOT be forwarded.
If a PCE needs to forward a path computation request containing the CLASSTYPE object to another PCE, it MUST store the Class-Type of the TE LSP in order to complete the path computation when the reply arrives.
If included, the CLASSTYPE object must be taken into account by the PCE, so the P flag MUST be set. The I flag is ignored.
If the CLASSTYPE object is absent from the path computation request, the LSR MUST associate Class-Type 0 to the LSP.
If the LSP is associated with Class-Type N (1 <= N <= 7), the PCC originating the PCReq MUST include the CLASSTYPE object with the CT field set to N.
If the TE LSP belongs to Class 0, the path computation request MUST NOT contain the CLASSTYPE object. This preserves backward compatibility with PCEs that do not support the CLASSTYPE object.
TE-Class determination uses the CT value from the CLASSTYPE object combined with the setup priority from the LSPA object. If the LSPA object is absent, setup priority is assumed to be 0. A CT and preemption priority pair maps to one of up to 8 TE-classes.
The CLASSTYPE object is an optional PCEP object used to carry the Class-Type of a TE LSP in a path computation request. It is meaningful only in PCReq messages and is ignored in path reply messages. Object-Class is 22, Object-Type is 1.
The PCReq message format places the CLASSTYPE object after the END-POINTS objects and before LSPA, BANDWIDTH, metric-list, RRO, IRO, and LOAD-BALANCING objects within each request element.
IANA allocated Object-Class 22 with name CLASSTYPE (Object-Type 1: Class-Type) in the PCEP objects sub-registry, and Error-Type 12 'Diffserv-aware TE error' with three error values: 1 (Unsupported Class-Type), 2 (Invalid Class-Type), 3 (Class-Type and setup priority do not form a configured TE-class).
This document does not introduce new security issues. The security considerations pertaining to PCEP (RFC 5440) remain relevant.
The CLASSTYPE object body is a 32-bit word following the PCEP common object header. It contains a 3-bit CT field (Class-Type, values 1–7) in the least-significant bits and a 29-bit Reserved field that MUST be set to zero on transmission and MUST be ignored on receipt.