Path Computation Element Protocol (PCEP) Extension for Color
RFC 9863
Balaji Rajagopalan
Juniper Networks
balajir@juniper.net
Vishnu Pavan Beeram
Juniper Networks
vbeeram@juniper.net
Shaofu Peng
ZTE Corporation
peng.shaofu@zte.com.cn
Mike Koldychev
Ciena Corporation
mkoldych@proton.me
Gyan Mishra
Verizon Communications Inc.
gyan.s.mishra@verizon.com
September 2025
RTG
pce
color
Color is a 32-bit numerical (unsigned integer) attribute used to associate a Traffic Engineering (TE) tunnel or policy with an intent or objective. For example, a TE Tunnel constructed to deliver low latency services and whose path is optimized for delay can be tagged with a color that represents "low latency." This document specifies extensions to the Path Computation Element Protocol (PCEP) to carry the color attribute.
Introduction
A Traffic Engineering (TE) Tunnel [RFC3209] or Segment Routing (SR) policy [RFC9256] can be associated with an intent or objective (e.g., low latency) by tagging it with a color. This color attribute is used as a guiding criterion for mapping services onto the TE Tunnel [RFC9012] or SR Policy [RFC9256]. The term "color" used in this document must not be interpreted as the "thread color" specified in [RFC3063] or the "resource color" (also referred to as "link color") specified in [RFC3630], [RFC5329], [RFC5305], and [RFC7308].
[RFC8231] specifies extensions to the Path Computation Element Protocol (PCEP) that enable the deployment of a stateful Path Computation Element (PCE) model. These extensions allow a Path Computation Client (PCC) to delegate control of the Label Switched Paths (LSPs) associated with its TE Tunnels to a stateful PCE. [RFC8281] specifies extensions that allow a PCE to instantiate and manage PCE-initiated LSPs on a PCC under the stateful PCE model. [RFC8664] specifies extensions that enable stateful control of SR paths via PCEP.
This document introduces extensions to PCEP to allow a color tag to be assigned to any TE path operated under a stateful PCE model (including those set up using RSVP-TE [RFC8408] or Segment Routing [RFC8664]). The only exception where the extensions defined in this document MUST NOT be used to carry the color attribute is for SR paths established using the extensions defined in [RFC9862]. For these SR paths, the associated color is already included as part of the SR Policy identifier encoding.
The mechanism employed by the PCC for mapping services onto a TE path associated with a color attribute is outside the scope of this document, as is any other use of the color tag.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Protocol Operation
When the PCEP session is created, a PCEP (PCE/PCC) speaker sends an Open message with an OPEN object that contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A STATEFUL-PCE-CAPABILITY TLV Flag (see Section 3.1) is introduced in this document to enable the PCEP speaker to advertise color capability.
In PCRpt, PCUpd, and PCInitiate messages, the LSP object [RFC8231] [RFC8281] is a mandatory inclusion and is used to carry information specific to the target LSP. A TLV called the COLOR TLV (see Section 3.2), which MAY be carried in the LSP object, is introduced in this document to carry the color attribute associated with the LSP. Only one COLOR TLV SHOULD be included in the LSP object. If the COLOR TLV appears in the LSP object more than once, only the first occurrence is processed, and any others MUST be ignored.
A PCEP speaker that has advertised color capability MUST NOT send COLOR TLV encoded in the LSP object to a PCEP Peer [RFC5440] that has not advertised color capability. A PCEP speaker that advertises both color capability and SR Policy Association [RFC9862] capability MUST NOT send COLOR TLV encoded in the LSP object for SR Paths. The COLOR TLV is ignored if it shows up in the LSP object of a message that carries an ASSOCIATION object of type SR Policy Association [RFC9862]. The color encoded in the SR Policy Association takes precedence in such a scenario.
If a PCC is unable to honor a color value passed in a PCUpd or a PCInitiate message, the PCC MUST reject the message and send a PCErr message with Error-Type=19 (Invalid Operation) and Error-value=31 (Invalid color). This is expected behavior in scenarios where a PCC implementation does not support a color value of zero for specific path setup types, and it receives that value in the COLOR TLV of a PCUpd or a PCInitiate message.
When LSPs that belong to the same TE Tunnel are within the same Path Protection Association Group [RFC8745], they are all expected to have the same color attached to them. If a PCEP speaker determines inconsistency in the color associated with the LSPs belonging to the same Path Protection Association Group, it MUST reject the message carrying the inconsistent color and send a PCErr message with Error-Type=19 (Invalid Operation) and Error-value=32 (Inconsistent color).
Protocol Extensions
Color Capability
Section 7.1.1 of [RFC8231] defines STATEFUL-PCE-CAPABILITY TLV flags. The following flag is used to indicate if the speaker supports color capability:
C-bit (Bit 20):
A PCE/PCC indicates that it supports the color capability defined in this document by setting this bit.
COLOR TLV
COLOR TLV

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type                      |          Length=4             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                             Color                             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
67
Length:
4
Color:
4-byte field that carries the actual color value (specified as an unsigned integer). A value of zero is allowed.
Security Considerations
This document defines a TLV for color and a flag for color capability negotiation, which do not add any security concerns beyond those discussed in [RFC5440], [RFC8231], and [RFC8281].
An unauthorized PCE may maliciously associate the LSP with an incorrect color. The procedures described in [RFC8253] and [RFC9325] can be used to protect against this attack.
Manageability Considerations
This section follows the advice and guidance of [RFC6123].
Control of Function through Configuration and Policy
An implementation supporting this document SHOULD allow the operator to turn on and off the PCEP color capability advertisement (Section 3.1). An implementation supporting this document SHOULD allow the configuration of color assignment to a TE Tunnel or an SR Policy. A PCC MAY have a local policy configuration that specifies how the color tag is used. This policy configuration is outside the scope of this document.
Information and Data Models
An implementation supporting this document SHOULD allow the inclusion of color in the data model used to retrieve the operational state of a TE Tunnel or an SR Policy. The YANG model in [I-D.ietf-teas-yang-te] could be used to retrieve the operational state of a TE Tunnel, and the YANG model in [I-D.ietf-spring-sr-policy-yang] could be used to retrieve the operational state of an SR Policy.
Liveness Detection and Monitoring
The extensions defined in this document do not require any additional liveness detection and monitoring support. See [RFC5440] and [RFC5886] for more information.
Verifying Correct Operation
The operator MAY retrieve the operational state of TE Paths to verify if they are tagged with the correct intended color.
Requirements on Other Protocols
This document places no explicit requirements on other protocols.
Impact on Network Operation
The impact on network operations depends on how the color tag is used in the deployment. This is outside the scope of this document.
IANA Considerations
PCEP TLV Type Indicator
IANA has assigned a value in the "PCEP TLV Type Indicators" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group as follows:
Value | Description | Reference
67 | Color | RFC 9863
STATEFUL-PCE-CAPABILITY TLV Flag Field
IANA has assigned a bit value in the "STATEFUL-PCE-CAPABILITY TLV Flag Field" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group as follows:
Value | Description | Reference
20 | COLOR-CAPABILITY | RFC 9863
PCEP-Error Object
IANA has assigned two Error-values for Error-Type=19 (Invalid Operation) within the "PCEP-ERROR Object Error Types and Values" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group as follows:
Error-Type | Meaning | Error-value | Reference
19 | Invalid Operation | 31: Invalid Color | RFC 9863
32: Inconsistent Color | RFC 9863
LSP-ERROR-CODE TLV Error Code Field
A draft version of this document added an error code in the "LSP-ERROR-CODE TLV Error Code Field" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group, which was also early allocated by the IANA.
IANA has marked it as deprecated.
Value | Meaning | Reference
9 | Deprecated (Unsupported Color) | RFC 9863
References
Normative References
[RFC9862]

Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths
Mike Koldychev
Ciena Corporation
Siva Sivabalan
Ciena Corporation
Samuel Sidor
Cisco Systems, Inc.
Colby Barth
Juniper Networks, Inc.
Shuping Peng
Huawei Technologies
Hooman Bidgoli
Nokia
September 2025
RFC 9862
DOI 10.17487/RFC9862
Informative References
[RFC3209]
[RFC9256]
[RFC9012]
[RFC3063]
[RFC3630]
[RFC5329]
[RFC5305]
[RFC7308]
[RFC8231]
[RFC8281]
[RFC8664]
[RFC8408]
[RFC2119]
[RFC8174]
[RFC5440]
[RFC8745]
[RFC8253]
[RFC9325]
[RFC6123]
[I-D.ietf-teas-yang-te]
[I-D.ietf-spring-sr-policy-yang]
[RFC5886]
Acknowledgments
The authors would like to thank Kaliraj Vairavakkalai, Colby Barth, Natrajan Venkataraman, Tarek Saad, Dhruv Dhody, Adrian Farrel, Andrew Stone, Diego Achaval, and Narasimha Kommuri for their review and suggestions.
Contributors
The following people have contributed to this document:
Quan Xiong
ZTE Corporation
xiong.quan@zte.com.cn