Path Computation Element Protocol(PCEP) Extension for ColorJuniper Networksbalajir@juniper.netJuniper Networksvbeeram@juniper.netZTE Corporationpeng.shaofu@zte.com.cnZTE Corporationxiong.quan@zte.com.cnCisco Systems Inc.mkoldych@cisco.comVerizon Communications Inc.gyan.s.mishra@verizon.com
Routing
PCE Working Groupcolor
Color is a 32-bit numerical attribute that is used to associate
a Traffic Engineering (TE) tunnel or policy with an intent
or objective (e.g. low latency). This document specifies an
extension to Path Computation Element Protocol (PCEP) to carry
the color attribute.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in .
A Traffic Engineering (TE) tunnel or policy can be associated
with an intent or objective (e.g. low latency) by marking it
with a color. This color attribute is used as a guiding criterion
for mapping services onto the TE tunnel or 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 .
Color is part of the tuple that identifies a Segment Routing (SR)
policy () and
is included in the Path Computation Element Protocol (PCEP) extensions
defined for carrying the SR policy identifiers
(). The color
encoding specified in SR policy identifier cannot be reused for other
types of path setup.
This document introduces a generic optional PCEP TLV called the
Color TLV to carry the color attribute and discusses its usage with
RSVP-TE Label Switched Paths (LSPs).
In addition to catering to the use-case discussed in this document, the Color
TLV can also be used to reference SR Composite Candidate Paths as specified
in (). An implementation MAY
also provide a local policy option to use this TLV to reference a set
of path constraints and optimization objectives.
The color attribute can be used as one of the guiding criteria in
selecting the RSVP-TE LSP as a next hop for service prefixes. While
the specific details of how the service prefixes are associated
with the appropriate RSVP-TE LSPs are outside the scope of this
specification, the envisioned high level usage of the color
attribute is as follows.
The service prefixes are marked with some indication of the type of
underlay they need. The underlay LSPs carry corresponding markings,
which we refer to as color in this specification, enabling an ingress
node to associate the service prefixes with the appropriate
underlay LSPs.
As an example, for a BGP-based service, the originating PE could
attach some community, e.g. the Extended Color Community
with the service route. A receiving PE
could use locally configured policies to associate service routes
carrying Extended Color Community 'X' with underlay RSVP-TE LSPs of
color 'Y'.
While the Extended Color Community provides a convenient method to
perform the mapping, the policy on the ingress node is free to
classify on any property of the route to select underlay RSVP-TE LSPs
of a certain color.
The procedure discussed for service mapping in this section can be
applied to any underlay path setup type.
The STATEFUL-PCE-CAPABILITY negotiation message is enhanced to
carry the color capability, which allows PCC (Path Computation
Client) and PCE (Path Computation Element) to
determine how incompatibility should be handled, should only
one of them support color. An older implementation that does
not recognize the new color TLV would ignore it upon
receipt. This can sometimes result in undesirable
behavior. For example, if PCE passes color to a PCC that does
not understand colors, the LSP may not be used as intended. A
PCE that clearly knows the PCC's color capability can handle
such cases better, and vice versa. Following are the rules for
handling mismatch in color capability.
A PCE that has color capability MUST NOT send color TLV to a
PCC that does not have color capability. A PCE that does not
have color capability can ignore color marking reported by
PCC.
When a PCC is interacting with a PCE that does not have color
capability, the PCC
SHOULD NOT report color to the PCE.
MUST NOT override the local color, if it is configured,
based on any messages coming from the PCE.
The actual color value itself is carried in a newly defined
TLV in the LSP Object defined in .
If a PCC is unable to honor a color value passed in an LSP
Update request, the PCC must keep the LSP in DOWN state, and
include an LSP Error Code value of "Unsupported Color" (TBA3)
in LSP State Report message.
When LSPs that belong to the same TE tunnel are with in the
same Path Protection Association Group ,
the color is attached only to the primary LSP. If PCC receives
color TLV for a secondary LSP, it SHOULD respond with an error
code of 4 (Unacceptable Parameters).
Type has the value TBA1. Length carries a value of 4.
The 'color' field is 4-bytes long, and carries the actual color value.
Section 7.1.1 of RFC8231 defines
STATEFUL-PCE-CAPABILITY flags. The following flag is used to
indicate if the speaker supports color capability:
C-bit (TBA2): A PCE/PCC that supports
color capability must turn on this bit.
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.
IANA is requested to allocate a new value in the
"PCEP TLV Type Indicators" sub-registry of the
PCEP Numbers registry as follows:
IANA is requested to allocate a new bit value in the
"STATEFUL-PCE-CAPABILITY TLV Flag Field" sub-registry of the
PCEP Numbers registry as follows:
IANA is requested to allocate a new error code in the
"LSP-ERROR-CODE TLV Error Code Field" sub-registry of the
PCEP Numbers registry as follows:
The authors would like to thank Kaliraj Vairavakkalai, Colby
Barth, Natrajan Venkataraman and Tarek Saad for their review and
suggestions.