Path Computation Element Protocol(PCEP) Extension for Color

A Traffic Engineering (TE) tunnel or Segment Routing (SR) policy 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 () or SR policy (). The term color used in this document is not to be interpreted as the 'thread color' specified in or the 'resource color' (or 'link color') specified in , , and . 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. specifies extensions that allow a PCE to instantiate and manage PCE-initiated LSPs on a PCC under the stateful PCE model. specifies extensions that enable stateful control of SR paths via PCEP. This document introduces extensions to PCEP to carry the color attribute tagged with TE paths that are setup using RSVP-TE () or Segment Routing (SR) () or any other path setup type supported under the stateful PCE model. The only exception where the extensions defined in this document are not used for carrying the color attribute is when an SR path is setup using the extensions defined in . For these SR paths, the associated color is already included as part of the SR policy identifier encoding. The mechanism used at the PCC for appropriately mapping services onto a TE path that is tagged with a color attribute is outside the scope of this document.

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 when, and only when, they appear in all capitals, as shown here.

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 . A new STATEFUL-PCE-CAPABILITY TLV Flag (See ) is introduced in this document to enable the PCEP speaker to advertise color capability. In PCRpt, PCUpd, and PCInitiate messages, the LSP object (, ) is a mandatory inclusion and is used to carry information specific to the target LSP. A new TLV called the Color TLV (see ), which MAY be carried in the LSP object, is introduced in this document to carry the color attribute associated with the LSP. A PCEP speaker that has advertised color capability MUST NOT send Color TLV encoded in the LSP object to a PCEP Peer that has not advertised color capability. A PCEP speaker that advertises both color capability and SR Policy Association capability () SHOULD 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 which carries an ASSOCIATION object of type SR Policy Association (). 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=TBD1 (Invalid color). When LSPs that belong to the same TE tunnel are within the same Path Protection Association Group , they are all expected to be attached with the same color. 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=TB2 (Inconsistent color).

Section 7.1.1 of defines STATEFUL-PCE-CAPABILITY TLV flags. The following flag is used to indicate if the speaker supports color capability: C-bit (Bit 20 - Early allocation by IANA): A PCE/PCC that supports color capability must turn on this bit.

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 has the value 67 (Early allocation by IANA). Length carries a value of 4. The 'color' field is 4-bytes long, and carries the actual color value.

This document defines a new TLV for color, and a new flag in capability negotiation, which do not add any new security concerns beyond those discussed in , and . An unauthorized PCE may maliciously associate the LSP with an incorrect color. The procedures described in and can be used to protect against this attack.

This document introduces a new value in the "PCEP TLV Type Indicators" sub-registry of the PCEP Numbers registry as follows:

Note: The code point specified for the new TLV Type Indicator is an early allocation by IANA.

This document introduces a new bit value in the "STATEFUL-PCE-CAPABILITY TLV Flag Field" sub-registry of the PCEP Numbers registry as follows:

Note: The code point specified for the new STATEFUL-PCE-CAPABILITY TLV Flag is an early allocation by IANA.

This document introduces two new 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:

An earlier version of this document added a new error code in the "LSP-ERROR-CODE TLV Error Code Field" registry of the PCEP Numbers registry group, which was also early allocated by the IANA. IANA is requested to cancel the early allocation made which is not needed anymore. As per the instructions from the chairs, please mark it as deprecated.

[Note to the RFC-Editor: Please remove this section before publication.]

[Note to the RFC Editor - remove this section before publication, as well as remove the reference to RFC 7942.] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". At the time of publication of this version, there are no known implementations. Juniper Networks has plans to implement the extensions defined in this document.

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.

The following people have contributed to this document ZTE Corporation

xiong.quan@zte.com.cn