Network Working Group JP. Vasseur, Ed. Request for Comments: 5441 Cisco Systems, Inc Category: Standards Track R. Zhang BT Infonet N. Bitar Verizon JL. Le Roux France Telecom April 2009 A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths 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 ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. General Assumptions . . . . . . . . . . . . . . . . . . . . . 5 4. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Domain Path Selection . . . . . . . . . . . . . . . . . . 6 4.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 6 5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 8 6. VSPT Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 10 8. Usage in Conjunction with Per-Domain Path Computation . . . . 10 9. BRPC Procedure Completion Failure . . . . . . . . . . . . . . 10 10. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Diverse End-to-End Path Computation . . . . . . . . . . . 11 10.2. Path Optimality . . . . . . . . . . . . . . . . . . . . . 12 11. Reoptimization of an Inter-Domain TE LSP . . . . . . . . . . . 12 12. Path Computation Failure . . . . . . . . . . . . . . . . . . . 12 13. Metric Normalization . . . . . . . . . . . . . . . . . . . . . 12 14. Manageability Considerations . . . . . . . . . . . . . . . . . 13 14.1. Control of Function and Policy . . . . . . . . . . . . . . 13 14.2. Information and Data Models . . . . . . . . . . . . . . . 13 14.3. Liveness Detection and Monitoring . . . . . . . . . . . . 13 14.4. Verifying Correct Operation . . . . . . . . . . . . . . . 13 14.5. Requirements on Other Protocols and Functional Components . . . . . . . . . . . . . . . . . . . . . . . . 14 14.6. Impact on Network Operation . . . . . . . . . . . . . . . 14 14.7. Path Computation Chain Monitoring . . . . . . . . . . . . 14 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 15.1. New Flag of the RP Object . . . . . . . . . . . . . . . . 14 15.2. New Error-Type and Error-Value . . . . . . . . . . . . . . 14
15.3. New Flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 15 16. Security Considerations . . . . . . . . . . . . . . . . . . . 15 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 18.1. Normative References . . . . . . . . . . . . . . . . . . . 16 18.2. Informative References . . . . . . . . . . . . . . . . . . 16 RFC4105] and [RFC4216], respectively. The framework for inter-domain Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) has been provided in [RFC4726]. [RFC5152] defines a technique for establishing an inter-domain Generalized MPLS (GMPLS) TE Label Switched Path (LSP) whereby the path is computed during the signaling process on a per-domain basis by the entry boundary node of each domain (each node responsible for triggering the computation of a section of an inter-domain TE LSP path is always along the path of such TE LSP). This path computation technique fulfills some of the requirements stated in [RFC4105] and [RFC4216] but not all of them. In particular, it cannot guarantee to find an optimal (shortest) inter-domain constrained path. Furthermore, it cannot be efficiently used to compute a set of inter- domain diversely routed TE LSPs. The Path Computation Element (PCE) architecture is defined in [RFC4655]. The aim of this document is to describe a PCE-based path computation procedure to compute optimal inter-domain constrained (G)MPLS TE LSPs. Qualifying a path as optimal requires some clarification. Indeed, a globally optimal TE LSP placement usually refers to a set of TE LSPs whose placements optimize the network resources with regards to a specified objective function (e.g., a placement that reduces the maximum or average network load while satisfying the TE LSP constraints). In this document, an optimal inter-domain constrained TE LSP is defined as the shortest path satisfying the set of required constraints that would be obtained in the absence of multiple domains (in other words, in a totally flat IGP network between the source and destination of the TE LSP). Note that this requires the use of consistent metric schemes in each domain (see Section 13).
RFC4105] and [RFC4216]), which is critical to preserve IGP/BGP scalability and confidentiality. o While certain constraints like bandwidth can be used across different domains, other TE constraints (such as resource affinity, color, metric, etc. [RFC2702]) could be translated at domain boundaries. If required, it is assumed that, at the domain boundary nodes, there will exist some sort of local mapping based on policy agreement, in order to translate such constraints across domain boundaries during the inter-PCE communication process. o Each AS can be made of several IGP areas. The path computation procedure described in this document applies to the case of a single AS made of multiple IGP areas, multiple ASes made of a single IGP area, or any combination of the above. For the sake of simplicity, each AS will be considered to be made of a single area in this document. The case of an inter-AS TE LSP spanning multiple ASes, where some of those ASes are themselves made of multiple IGP areas, can be easily derived from this case by applying the BRPC procedure described in this document, recursively. o The domain path (the set of domains traversed to reach the destination domain) is either administratively predetermined or discovered by some means that is outside of the scope of this document. RFC4655]. A possible model consists of hosting the PCE function on boundary nodes (e.g., ABR or ASBR), but this is not mandated by the BRPC procedure. The BRPC procedure relies on communication between cooperating PCEs. In particular, the PCC sends a PCReq to a PCE in its domain. The request is forwarded between PCEs, domain-by-domain, until the PCE responsible for the domain containing the LSP destination is reached. The PCE in the destination domain creates a tree of potential paths
to the destination (the Virtual Shortest Path Tree - VSPT) and passes this back to the previous PCE in a PCRep. Each PCE in turn adds to the VSPT and passes it back until the PCE in the source domain uses the VSPT to select an end-to-end path that the PCE sends to the PCC. The BRPC procedure does not make any assumption with regards to the nature of the inter-domain TE LSP that could be contiguous, nested, or stitched. Furthermore, no assumption is made on the actual path computation algorithm in use by a PCE (e.g., it can be any variant of Constrained Shortest Path First (CSPF) or an algorithm based on linear programming to solve multi-constraint optimization problems). RFC5440] so that it is available to all PCEs. Note also that a sequence of PCEs MAY be enforced by policy on the PCC, and this constraint can be carried in the PCEP path computation request (as defined in [PCE-MONITOR]). The BRPC procedure guarantees to compute the optimal path across a specific sequence of traversed domains (which constitutes an additional constraint). In the case of an arbitrary set of meshed domains, the BRPC procedure can be used to compute the optimal path across each domain set in order to get the optimal constrained path between the source and the destination of the TE LSP. The BRPC procedure can also be used across a subset of all domain sequences, and the best path among these sequences can then be selected.
VSPT(i): MP2P (multipoint-to-point) tree returned by PCE(i) to PCE(i-1): Root (TE LSP destination) / | \ BN-en(1,i) BN-en(2,i) ... BN-en(j,i). where [X-en(i)] is the number of entry BNs in domain i and j<= [X-en(i)] Figure 1: MP2P Tree Each link of tree VSPT(i) represents the shortest constrained path between BN-en(j,i) and the TE LSP destination that satisfies the set of required constraints for the TE LSP (bandwidth, affinities, etc.). These are path segments to reach the TE LSP destination from BN-en(j,i). Note that PCE(i) only considers the entry BNs of domain(i), i.e., only the BNs that provide connectivity from domain(i-1). In other words, the set BN-en(k,i) is only made of those BNs that provide connectivity from domain (i-1) to domain(i). Furthermore, some BNs may be excluded according to policy constraints (either due to local policy or policies signaled in the path computation request). Step 1: First, the PCC needs to determine the PCE capable of serving its path computation request (this can be done with local configuration or via IGP discovery (see [RFC5088] and [RFC5089])). The path computation request is then relayed until reaching a PCE(n) such that the TE LSP destination resides in the domain(n). At each step of the process, the next PCE can either be statically configured or dynamically discovered via IGP/BGP extensions. If no next PCE can be found or the next-hop PCE of choice is unavailable, the procedure stops and a path computation error is returned (see Section 9). If PCE(i-1) discovers multiple PCEs for the adjacent domain(i), PCE(i) may select a subset of these PCEs based on some local policies or heuristics. The PCE selection process is outside of the scope of this document. Step 2: PCE(n) computes VSPT(n), the tree made of the list of shortest constrained paths between every BN-en(j,n) and the TE LSP destination using a suitable path computation algorithm (e.g., CSPF) and returns the computed VSPT(n) to PCE(n-1).
Step i: For i=n-1 to 2: PCE(i) computes VSPT(i), the tree made of the shortest constrained paths between each BN-en(j,i) and the TE LSP destination. It does this by considering its own TED and the information in VSPT(i+1). In the case of inter-AS TE LSP computation, this also requires adding the inter-AS TE links that connect the domain(i) to the domain(i+1). Step n: Finally, PCE(1) computes the end-to-end shortest constrained path from the source to the destination and returns the corresponding path to the requesting PCC in the form of a PCRep message as defined in [RFC5440]. Each branch of the VSPT tree (path) may be returned in the form of an explicit path (in which case, all the hops along the path segment are listed) or a loose path (in which case, only the BN is specified) so as to preserve confidentiality along with the respective cost. In the latter case, various techniques can be used in order to retrieve the computed explicit paths on a per-domain basis during the signaling process, thanks to the use of path keys as described in [PATH-KEY]. A PCE that can compute the requested path for more than one consecutive domain on the path SHOULD perform this computation for all such domains before passing the PCRep to the previous PCE in the sequence. BRPC guarantees to find the optimal (shortest) constrained inter- domain TE LSP according to a set of defined domains to be traversed. Note that other variants of the BRPC procedure relying on the same principles are also possible. Note also that in case of Equal Cost Multi-Path (ECMP) paths, more than one path could be returned to the requesting PCC. RFC5440]) to specify that the shortest paths satisfying the constraints from the destination to the set of entry boundary nodes are requested (such a set of paths forms the downstream VSPT as specified in Section 4.2).
The following new flag of the RP object is defined: VSPT Flag Bit Number Name Flag 25 VSPT When set, the VSPT Flag indicates that the PCC requests the computation of an inter-domain TE LSP using the BRPC procedure defined in this document. Because path segments computed by a downstream PCE in the context of the BRPC procedure MUST be provided along with their respective path costs, the C flag of the METRIC object carried within the PCReq message MUST be set. It is the choice of the requester to appropriately set the O bit of the RP object. Example: <---- area 1 ----><---- area 0 -----><------ area 2 ------> ABR1-A-B-+ | | ABR2-----D | | ABR3--C--+ Figure 2: An Example of VSPT Encoding Using a Set of EROs In the simple example shown in Figure 2, if we make the assumption that a constrained path exists between each ABR and the destination D, the VSPT computed by a PCE serving area 2 consists of the following non-ordered set of EROs: o ERO1: ABR1(TE Router ID)-A(Interface IP address)-B(Interface IP address)-D(TE Router ID) o ERO2: ABR2(TE Router ID)-D(TE Router ID) o ERO3: ABR3(TE Router ID)-C(interface IP address)-D(TE Router ID) The PCReq message, PCRep message, PCEP END-POINT object, and ERO object are defined in [RFC5440].
RFC4655]. That said, a straightforward solution consists of allowing the ASBRs to flood the TE information related to the inter-ASBR links although no IGP TE is enabled over those links (there is no IGP adjacency over the inter-ASBR links). This allows the PCE of a domain to get entire TE visibility up to the set of entry ASBRs in the downstream domain (see the IGP extensions defined in [RFC5316] and [RFC5392]). RFC5152]) to compute the end-to-end path. In this case, end-to-end path optimality can no longer be guaranteed. RFC5440], the PCE sends a PCErr message to the upstream PCE with an Error-Type=4 (Not supported object), Error-value=4 (Unsupported parameter). The PCE may include the parent object (RP object) up to and including (but no further than) the unknown or unsupported parameter. In this case where the unknown or unsupported parameter is a bit flag (VSPT flag), the included RP object should contain the whole bit flag field with all bits after the parameter at issue set to zero. The corresponding path computation request is then cancelled by the PCE without further notification. If the BRPC procedure cannot be completed because a PCE along the domain path recognizes but does not support the procedure, it MUST return a PCErr message to the upstream PCE with an Error-Type "BRPC procedure completion failure". The PCErr message MUST be relayed to the requesting PCC. PCEP-ERROR objects are used to report a PCEP protocol error and are characterized by an Error-Type that specifies the type of error and an Error-value that provides additional information about the error type. Both the Error-Type and the Error-value are managed by IANA.
A new Error-Type is defined that relates to the BRPC procedure. Error-Type Meaning 13 BRPC procedure completion failure Error-value 1: BRPC procedure not supported by one or more PCEs along the domain path Section 3, the requirements for inter-area and inter-AS MPLS Traffic Engineering have been developed by the Traffic Engineering Working Group (TE WG) and have been stated in [RFC4105] and [RFC4216], respectively. Among the set of requirements, both documents indicate the need for some solution that provides the ability to compute an optimal (shortest) constrained inter-domain TE LSP and to compute a set of diverse inter-domain TE LSPs. RFC5440]) allows a PCC to request the computation of a set of diverse TE LSPs by setting the SVEC object's flags L, N, or S to request link, node, or SRLG (Shared Risk Link Group) diversity, respectively. Such requests MUST be taken into account by each PCE along the path computation chain during the VSPT computation. In the context of the BRPC procedure, a set of diversely routed TE LSPs between two LSRs can be computed since the path segments of the VSPT are simultaneously computed by a given PCE. The BRPC procedure allows for the computation of diverse paths under various objective functions (such as minimizing the sum of the costs of the N diverse paths, etc.). By contrast, with a 2-step approach consisting of computing the first path followed by computing the second path after having removed the set of network elements traversed by the first path (if that does not violate confidentiality preservation), one cannot guarantee that a solution will be found even if such solution exists. Furthermore, even if a solution is found, it may not be the most optimal one with respect to an objective function such as minimizing the sum of the paths' costs, bounding the path delays of both paths, and so on. Finally, it must be noted that such a 2-step path computation approach is usually less efficient in terms of signaling delays since it requires that two serialized TE LSPs be set up.
RFC4105] and [RFC4216]. In the case of a TE LSP reoptimization request, the reoptimization procedure defined in [RFC5440] applies when the path in use (if available on the head-end) is provided as part of the path computation request so that the PCEs involved in the reoptimization request can avoid double bandwidth accounting. RFC5440] that contains a NO-PATH object. In such case, the NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in [RFC5440]) with the newly defined bit named "BRPC path computation chain unavailable" set. Bit number Name Flag 28 BRPC path computation chain unavailable
metric for TE LSP path computation (in that case, the use of the TE metric must be requested in the PCEP path computation request) using the METRIC object (defined in [RFC5440]). PCE-MANAGE]. Section 9. 9 and 12, respectively. Furthermore, a built-in diagnostic tool to check the availability and performances of a PCE chain is defined in [PCE-MONITOR].
RFC4655] and does not differ from any other path computation request. PCE-MONITOR] specifies a set of mechanisms that can be used to gather PCE state metrics. Because BRPC is a multiple-PCE path computation technique, such mechanisms could be advantageously used in the context of the BRPC procedure to check the liveness of the path computation chain, locate a faulty component, monitor the overall performance, and so on. RFC5440]) is defined in this document. IANA maintains a registry of RP object flags in the "RP Object Flag Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA has allocated the following value: Bit Description Reference 25 VSPT This document
A new Error-value is defined for the Error-Type "Not supported object" (type 4). Error-Type Meaning and error values Reference 4 Not supported object Error-value=4: Unsupported parameter This document A new Error-Type is defined in this document as follows: Error-Type Meaning Reference 13 BRPC procedure completion failure This document Error-value=1: BRPC procedure not This document supported by one or more PCEs along the domain path RFC5440]) is specified in this document. IANA maintains a registry of flags for the NO-PATH-VECTOR TLV in the "NO-PATH-VECTOR TLV Flag Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA has allocated the following allocation value: Bit number Meaning Reference 4 BRPC path computation This document chain unavailable Section 10 of [RFC5440]. In addition to the security mechanisms described in [RFC5440] with regards to spoofing, snooping, falsification, and denial of service, an implementation MAY support a policy module governing the conditions under which a PCE should participate in the BRPC procedure. The BRPC procedure does not increase the information exchanged between ASes and preserves topology confidentiality, in compliance with [RFC4105] and [RFC4216].
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5440] Vasseur, J., Ed. and J. Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, April 2009. [PATH-KEY] Bradford, R., Vasseur, J., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism", Work in Progress, November 2008. [PCE-MANAGE] Farrel, A., "Inclusion of Manageability Sections in PCE Working Group Drafts", Work in Progress, January 2009. [PCE-MONITOR] Vasseur, J., Roux, J., and Y. Ikejiri, "A set of monitoring tools for Path Computation Element based Architecture", Work in Progress, November 2008. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006. [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008. [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per- Domain Path Computation Method for Establishing Inter- Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008. [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008. [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, January 2009.