Network Working Group E. Oki Request for Comments: 5521 University of Electro-Communications Category: Standards Track T. Takeda NTT A. Farrel Old Dog Consulting April 2009 Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
AbstractThe Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed "route exclusions". The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. 1. Introduction ................................................. 3 1.1. Conventions Used in This Document .......................3 2. Protocol Procedures and Extensions ........................... 4 2.1. Exclude Route Object (XRO) ............................. 4 2.1.1. Definition ..................................... 4 2.1.2. Processing Rules ............................... 8 2.2. Explicit Route Exclusion ............................... 9 2.2.1. Definition ..................................... 9 2.2.2. Processing Rules .............................. 10 3. Exclude Route with Confidentiality .......................... 11 3.1. Exclude Route Object (XRO) Carrying Path-Key .......... 11 3.1.1. Definition .................................... 11 3.1.2. Processing Rules .............................. 12 4. IANA Considerations ......................................... 13 4.1. PCEP Objects .......................................... 13 4.2. New Subobject for the Include Route Object ............ 13 4.3. Error Object Field Values ............................. 13 4.4. Exclude Route Flags ................................... 14 5. Manageability Considerations ................................ 14 6. Security Considerations ..................................... 14 7. References .................................................. 15 7.1. Normative References .................................. 15 7.2. Informative References ................................ 15 Acknowledgements ................................................ 16
RFC4655] is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed. When a PCC requests a PCE for a route, it may be useful for the PCC to specify abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the route. For example, disjoint paths for inter-domain Label Switched Paths (LSPs) may be computed by cooperation between PCEs, each of which computes segments of the paths across one domain. In order to achieve path computation for a secondary (backup) path, a PCE may act as a PCC to request another PCE for a route that must be node/link/SRLG disjoint from the primary (working) path. Another example is where a network operator wants a path to avoid specified nodes for administrative reasons, perhaps because the specified nodes will be out-of-service in the near future. [RFC4657] specifies generic requirements for a communication protocol between PCCs and PCEs. Generic constraints described in [RFC4657] include route exclusions for links, nodes, and SRLGs. That is, the requirement for support of route exclusions within the PCC-PCE communication protocol is already established. The PCE communication protocol (PCEP) is designed as a communication protocol between PCCs and PCEs and is defined in [RFC5440]. This document presents PCEP extensions to satisfy the requirements for route exclusions as described in Sections 5.1.4 and 5.1.16 of [RFC4657]. Note that MPLS-TE and GMPLS signaling extensions for communicating route exclusions between network nodes for specific Label Switched Paths (LSPs) are described in [RFC4874]. Route exclusions may be specified during provisioning requests for specific LSPs by setting the mplsTunnelHopInclude object of MPLS-TE-STD-MIB defined in [RFC3812] to false (2). RFC2119].
RFC4874]. 1. Exclusion of certain abstract nodes or resources from the whole path. This set of abstract nodes is referred to as the Exclude Route List. 2. Exclusion of certain abstract nodes or resources between a specific pair of abstract nodes present in an explicit path. Such specific exclusions are referred to as an Explicit Route Exclusion. This document defines protocol extensions to allow a PCC to specify both types of route exclusions to a PCE on a path computation request. A new PCEP object, the Exclude Route Object (XRO), is defined to convey the Exclude Route List. The existing Include Route Object (IRO) in PCEP [RFC5440] is modified by introducing a new IRO subobject, the Explicit Exclusion Route subobject (EXRS), to convey Explicit Route Exclusions.
signaled during LSP setup using the extensions to Resource Reservation Protocol (RSVP)-TE [RFC4874]. The XRO Object-Class is 17. The XRO Object-Type is 1. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |F| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Subobjects) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: XRO Body Format Reserved: 16 bits - MUST be set to zero on transmission and SHOULD be ignored on receipt. Flags: 16 bits - The following flags are currently defined: F (Fail - 1 bit): when set, the requesting PCC requires the computation of a new path for an existing TE LSP that has failed. If the F bit is set, the path of the existing TE LSP MUST be provided in the PCReq message by means of a Record Route Object (RRO) defined in [RFC5440]. This allows the path computation to take into account the previous path and reserved resources to avoid double bandwidth booking should the Traffic Engineering Database (TED) have not yet been updated or the corresponding resources not be yet been released. This will usually be used in conjunction with the exclusion from the path computation of the failed resource that caused the LSP to fail. Subobjects: The XRO is made up of one or more subobject(s). An XRO with no subobjects MUST NOT be sent and SHOULD be ignored on receipt. In the following subobject definitions, a set of fields have consistent meaning as follows: X The X-bit indicates whether the exclusion is mandatory or desired. 0 indicates that the resource specified MUST be excluded from the path computed by the PCE. 1 indicates that the resource specified SHOULD be excluded from the path computed by the PCE, but MAY be
included subject to PCE policy and the absence of a viable path that meets the other constraints and excludes the resource. Type The type of the subobject. The following subobject types are defined. Type Subobject -------------+------------------------------- 1 IPv4 prefix 2 IPv6 prefix 4 Unnumbered Interface ID 32 Autonomous system number 34 SRLG Length The length of the subobject including the Type and Length fields. Prefix Length Where present, this field can be used to indicate a set of addresses matching a prefix. If the subobject indicates a single address, the prefix length MUST be set to the full length of the address. Attribute The Attribute field indicates how the exclusion subobject is to be interpreted. 0 Interface The subobject is to be interpreted as an interface or set of interfaces. All interfaces identified by the subobject are to be excluded from the computed path according to the setting of the X-bit. This value is valid only for subobject types 1, 2, and 3. 1 Node The subobject is to be interpreted as a node or set of nodes. All nodes identified by the subobject are to be excluded from the computed path according to the setting of the X-bit. This value is valid only for subobject types 1, 2, 3, and 4. 2 SRLG The subobject identifies an SRLG explicitly or indicates all of the SRLGs associated with the resource or resources identified by the subobject. Resources that share any SRLG with those identified are to be excluded from the computed path according to the setting of the X-bit. This value is valid for all subobjects.
Reserved Reserved fields within subobjects MUST be transmitted as zero and SHOULD be ignored on receipt. The subobjects are encoded as follows: IPv4 prefix Subobject 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type = 1 | Length | IPv4 address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (continued) | Prefix Length | Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 prefix Subobject 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type = 2 | Length | IPv6 address (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | Prefix Length | Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unnumbered Interface ID Subobject 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type = 3 | Length | Reserved | Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TE Router ID and Interface ID fields are as defined in [RFC3477].
Autonomous System Number Subobject 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type = 4 | Length | 2-Octet AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that as in other PCEP objects [RFC5440] and RSVP-TE objects [RFC3209], no support for 4-octet Autonomous System (AS) Numbers is provided. It is anticipated that, as 4-octet AS Numbers become more common, both PCEP and RSVP-TE will be updated in a consistent way to add this support. SRLG Subobject 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| Type = 5 | Length | SRLG Id (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG Id (continued) | Reserved | Attribute | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Attribute SHOULD be set to two (2) and SHOULD be ignored on receipt. RFC5440]. If the PCE is unwilling or unable to process the XRO, it MUST return a PCErr message with the Error-Type "Not supported object" and follow the relevant procedures described in [RFC5440].
If the PCE processes the XRO and attempts to compute a path, it MUST adhere to the requested exclusions as expressed in the XRO. That is, the returned path MUST NOT include any resources encoded with the X-bit clear, and SHOULD NOT include any with the X-bit set unless alternate paths that match the other constraints expressed in the PCReq are unavailable. When a PCE returns a path in a PCRep, it MAY also supply an XRO. An XRO in a PCRep message with the NO-PATH object indicates that the set of elements of the original XRO prevented the PCE from finding a path. On the other hand, if an XRO is present in a PCRep message without a NO-PATH object, the PCC SHOULD apply the contents using the same rules as in [RFC4874] and the PCC or a corresponding LSR SHOULD signal an RSVP-TE XRO to indicate the exclusions that downstream LSRs should apply. This may be particularly useful in per-domain path computation scenarios [RFC5152]. RFC5440]. This information is encoded by defining a new subobject for the IRO. The new IRO subobject, the Explicit Exclusion Route subobject (EXRS), has type 33 (see Section 4). The EXRS contains one or more subobjects in its own right. An EXRS MUST NOT be sent with no subobjects, and if received with no subobjects, MUST be ignored. The format of the EXRS is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // One or more EXRS subobjects // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L MUST be set to zero on transmission and MUST be ignored on receipt.
Reserved MUST be set to zero on transmission and SHOULD be ignored on receipt. The EXRS subobject may carry any of the subobjects defined for inclusion in the XRO by this document or by future documents. The meanings of the fields of the XRO subobjects are unchanged when the subobjects are included in an EXRS, except that scope of the exclusion is limited to the single hop between the previous and subsequent elements in the IRO. RFC5440]. The PCE MAY also include the IRO in the PCErr to indicate in which case the IRO SHOULD be terminated immediately after the unrecognized EXRS. If a PCE that supports the EXRS in an IRO parses an IRO and encounters an EXRS that contains a subobject that it does not support or recognize, it MUST act according to the setting of the X-bit in the subobject. If the X-bit is clear, the PCE MUST respond with a PCErr with Error-Type "Unrecognized EXRS subobject" and set the Error-Value to the EXRS subobject type code (see Section 4). If the X-bit is set, the PCE MAY respond with a PCErr as already stated or MAY ignore the EXRS subobject: this choice is a local policy decision. If a PCE parses an IRO and encounters an EXRS subobject that it recognizes, it MUST act according to the requirements expressed in the subobject. That is, if the X-bit is clear, the PCE MUST NOT produce a path that includes any resource identified by the EXRS subobject in the path between the previous abstract node in the IRO and the next abstract node in the IRO. If the X-bit is set, the PCE SHOULD NOT produce a path that includes any resource identified by the EXRS subobject in the path between the previous abstract node in the IRO and the next abstract node in the IRO unless it is not possible to construct a path that avoids that resource while still complying with the other constraints expressed in the PCReq message.
A successful path computation reported in a PCRep message MUST include an ERO to specify the path that has been computed as specified in [RFC5440]. That ERO MAY contain specific route exclusions using the EXRS as specified in [RFC4874]. If the path computation fails and a PCErr is returned with a NO-PATH object, the PCE MAY include an IRO to report the hops that could not be complied with as described in [RFC5440], and that IRO MAY include EXRSs. RFC5298]. Backward Recursive Path Computation (BRPC) may be used for inter-domain path computation [RFC5441]. In some cases of inter-domain computation (e.g., where domains are administered by different service providers), confidentiality must be kept. For primary path computation, to preserve confidentiality, instead of explicitly expressing the computed route, Path-Key Subobjects (PKSs) [RFC5520] are carried in the Explicit Route Object (ERO) in the PCRep Message. Therefore, during inter-domain diverse path computation, it may be necessary to request diversity from a path that is not fully known and where a segment of the path is represented by a PKS. This means that a PKS may be present as a subobject of the XRO on a PCReq message. The format and definition of PKS when it appears as an XRO subobject are as defined in [RFC5520], except for the definition of the L bit. The L bit of the PKS subobject in the XRO MUST be ignored.
RFC5221] PCEP-MIB]. That MIB module allows examination of individual PCEP messages, in particular requests, responses and errors. The MIB module MUST be extended to include the ability to view the route exclusion extensions defined in this document. Several local policy decisions should be made at the PCE. Firstly, the exact behavior with regard to desired exclusions must be available for examination by an operator and may be configurable. Second, the behavior on receipt of an unrecognized XRO or EXRS subobject with the X-bit set should be configurable and must be available for inspection. The inspection and control of these local policy choices may be part of the PCEP MIB module. RFC5440] are considered more important. Note, however, that the route exclusion mechanisms also provide the operator with the ability to route around vulnerable parts of the network and may be used to increase overall network security.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008. [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009. [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009. [PCEP-MIB] Koushik, A. S. K., and E. Stephan, "PCE Communication Protocol(PCEP) Management Information Base", Work in Progress, November 2008. [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. [RFC5298] Takeda, T., Ed., Farrel, A., Ed., Ikejiri, Y., and JP. Vasseur, "Analysis of Inter-Domain Label Switched Path (LSP) Recovery", RFC 5298, August 2008.