PCEP color: Path Computation Element Protocol (PCEP) Extension for Color

Internet Engineering Task Force (IETF)                    B. Rajagopalan
Request for Comments: 9863                                     V. Beeram
Category: Standards Track                               Juniper Networks
ISSN: 2070-1721                                                  S. Peng
                                                         ZTE Corporation
                                                            M. Koldychev
                                                       Ciena Corporation
                                                               G. Mishra
                                             Verizon Communications Inc.
                                                            October 2025


      Path Computation Element Protocol (PCEP) Extension for Color

Abstract

   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.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9863.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Revised BSD License.

Table of Contents

   1.  Introduction
     1.1.  Requirements Language
   2.  Protocol Operation
   3.  Protocol Extensions
     3.1.  Color Capability
     3.2.  COLOR TLV
   4.  Security Considerations
   5.  Manageability Considerations
     5.1.  Control of Function through Configuration and Policy
     5.2.  Information and Data Models
     5.3.  Liveness Detection and Monitoring
     5.4.  Verifying Correct Operation
     5.5.  Requirements on Other Protocols
     5.6.  Impact on Network Operation
   6.  IANA Considerations
     6.1.  PCEP TLV Type Indicator
     6.2.  STATEFUL-PCE-CAPABILITY TLV Flag Field
     6.3.  PCEP-Error Object
     6.4.  LSP-ERROR-CODE TLV Error Code Field
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgments
   Contributors
   Authors' Addresses

1.  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.

1.1.  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.

2.  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).

3.  Protocol Extensions

3.1.  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.

3.2.  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                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 1: COLOR TLV

   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.

4.  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.

5.  Manageability Considerations

   This section follows the advice and guidance of [RFC6123].

5.1.  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.

5.2.  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 [YANG-TE] could be
   used to retrieve the operational state of a TE Tunnel, and the YANG
   model in [SR-POLICY-YANG] could be used to retrieve the operational
   state of an SR Policy.

5.3.  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.

5.4.  Verifying Correct Operation

   The operator MAY retrieve the operational state of TE Paths to verify
   if they are tagged with the correct intended color.

5.5.  Requirements on Other Protocols

   This document places no explicit requirements on other protocols.

5.6.  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.

6.  IANA Considerations

6.1.  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  |
                    +-------+-------------+-----------+

                                  Table 1

6.2.  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  |
                 +-------+------------------+-----------+

                                 Table 2

6.3.  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  | RFC 9863  |
    |            |                   | Color             |           |
    +------------+-------------------+-------------------+-----------+

                                 Table 3

6.4.  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  |
          +-------+--------------------------------+-----------+

                                 Table 4

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.

   [RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
              "PCEPS: Usage of TLS to Provide a Secure Transport for the
              Path Computation Element Communication Protocol (PCEP)",
              RFC 8253, DOI 10.17487/RFC8253, October 2017,
              <https://www.rfc-editor.org/info/rfc8253>.

   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
              <https://www.rfc-editor.org/info/rfc8281>.

   [RFC8408]  Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
              Hardwick, "Conveying Path Setup Type in PCE Communication
              Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
              July 2018, <https://www.rfc-editor.org/info/rfc8408>.

   [RFC8664]  Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
              and J. Hardwick, "Path Computation Element Communication
              Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
              DOI 10.17487/RFC8664, December 2019,
              <https://www.rfc-editor.org/info/rfc8664>.

   [RFC8745]  Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I.,
              and M. Negi, "Path Computation Element Communication
              Protocol (PCEP) Extensions for Associating Working and
              Protection Label Switched Paths (LSPs) with Stateful PCE",
              RFC 8745, DOI 10.17487/RFC8745, March 2020,
              <https://www.rfc-editor.org/info/rfc8745>.

   [RFC9012]  Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
              "The BGP Tunnel Encapsulation Attribute", RFC 9012,
              DOI 10.17487/RFC9012, April 2021,
              <https://www.rfc-editor.org/info/rfc9012>.

   [RFC9325]  Sheffer, Y., Saint-Andre, P., and T. Fossati,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
              2022, <https://www.rfc-editor.org/info/rfc9325>.

   [RFC9862]  Koldychev, M., Sivabalan, S., Sidor, S., Barth, C., Peng,
              S., and H. Bidgoli, "Path Computation Element
              Communication Protocol (PCEP) Extensions for Segment
              Routing (SR) Policy Candidate Paths", RFC 9862,
              DOI 10.17487/RFC9862, October 2025,
              <https://www.rfc-editor.org/info/rfc9862>.

7.2.  Informative References

   [RFC3063]  Ohba, Y., Katsube, Y., Rosen, E., and P. Doolan, "MPLS
              Loop Prevention Mechanism", RFC 3063,
              DOI 10.17487/RFC3063, February 2001,
              <https://www.rfc-editor.org/info/rfc3063>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              DOI 10.17487/RFC3630, September 2003,
              <https://www.rfc-editor.org/info/rfc3630>.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <https://www.rfc-editor.org/info/rfc5305>.

   [RFC5329]  Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed.,
              "Traffic Engineering Extensions to OSPF Version 3",
              RFC 5329, DOI 10.17487/RFC5329, September 2008,
              <https://www.rfc-editor.org/info/rfc5329>.

   [RFC5886]  Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of
              Monitoring Tools for Path Computation Element (PCE)-Based
              Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010,
              <https://www.rfc-editor.org/info/rfc5886>.

   [RFC6123]  Farrel, A., "Inclusion of Manageability Sections in Path
              Computation Element (PCE) Working Group Drafts", RFC 6123,
              DOI 10.17487/RFC6123, February 2011,
              <https://www.rfc-editor.org/info/rfc6123>.

   [RFC7308]  Osborne, E., "Extended Administrative Groups in MPLS
              Traffic Engineering (MPLS-TE)", RFC 7308,
              DOI 10.17487/RFC7308, July 2014,
              <https://www.rfc-editor.org/info/rfc7308>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

   [SR-POLICY-YANG]
              Saleh, T., Raza, S. K., Zhuang, S., Matsushima, S., and V.
              P. Beeram, "YANG Data Model for Segment Routing Policy",
              Work in Progress, Internet-Draft, draft-ietf-spring-sr-
              policy-yang-06, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              sr-policy-yang-06>.

   [YANG-TE]  Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
              Bryskin, "A YANG Data Model for Traffic Engineering
              Tunnels, Label Switched Paths, and Interfaces", Work in
              Progress, Internet-Draft, draft-ietf-teas-yang-te-39, 17
              October 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-teas-yang-te-39>.

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
   Email: xiong.quan@zte.com.cn


Authors' Addresses

   Balaji Rajagopalan
   Juniper Networks
   Email: balajir@juniper.net


   Vishnu Pavan Beeram
   Juniper Networks
   Email: vbeeram@juniper.net


   Shaofu Peng
   ZTE Corporation
   Email: peng.shaofu@zte.com.cn


   Mike Koldychev
   Ciena Corporation
   Email: mkoldych@proton.me


   Gyan Mishra
   Verizon Communications Inc.
   Email: gyan.s.mishra@verizon.com