Path Computation Element Protocol(PCEP) Extension for RSVP ColorJuniper Networksbalajir@juniper.netJuniper Networksvbeeram@juniper.netVerizon Communications Inc.gyan.s.mishra@verizon.com
Routing
PCE Working GroupRSVPcolor
This document specifies extensions to Path Computation Element
Protocol (PCEP) to carry a newly defined attribute of RSVP LSP
called 'color' that can be used as a guiding criterion for
selecting the LSP as a next hop for a service route.
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 .
This document defines a new RSVP LSP property, called “color”,
that can be exchanged over PCEP. The ‘color’ field can be used
as one of the guiding criteria in selecting the LSP as a next
hop for service prefixes.
While the specific details of how the service prefixes are
associated with the appropriate RSVP LSP’s are outside the
scope of this specification, the envisioned high level usage
of the 'color' field is as follows.
The service prefixes are marked with some indication of the
type of underlay they need. The underlay LSP's 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 LSP's.
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 LSP's 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 LSP's of a certain color.
The 'color' specified in this draft is mainly used for
facilitating underlay selection, and does not have any effect
on the constraints used for path computation.
The STATEFUL-PCE-CAPABILITY negotiation message is enhanced to
carry the color capability, which allows PCC & PCE 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" [Value
to be assigned by IANA] in LSP State Report message.
If an RSVP tunnel has multiple LSP's associated with it, the
PCE should designate one of the LSP's as primary, and attach
the color with that LSP. If PCC receives color TLV for an LSP
that it treats as secondary, it SHOULD respond with an error
code of 4 (Unacceptable Parameters).
Type has the value [TO-BE-ASSIGNED-BY-IANA]. 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 (TO-BE-ASSIGNED-BY-IANA): A PCE/PCC that supports
color capability must turn on this bit.
RSVP LSP's marked with color can also be used for inter-domain
service mapping as defined in BGP-CT . In
BGP-CT, the mapping community of the service route is used to
select a “resolution scheme”, which in turn selects LSP’s of
various “transport classes” in the defined order of
preference. The ‘color’ field defined in this specification
could be used to associate the RSVP LSP with a particular
transport class.
A colored RSVP LSP can also be exported into BGP-CT for
inter-domain classful transport.
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 assign code points for the following:
Code point for "Color" TLV from the sub-registry "PCEP TLV Type Indicators".
C-bit value from the sub-registry "STATEFUL-PCE-CAPABILITY TLV Flag Field".
An error code for "Unsupported color" from the sub-registry
"LSP-ERROR-CODE TLV Error Code Field".
The authors would like to thank Kaliraj Vairavakkalai, Colby
Barth & Natrajan Venkataraman for their review &
suggestions, which helped improve this specification.