diff options
Diffstat (limited to 'doc/rfc/rfc8694.txt')
| -rw-r--r-- | doc/rfc/rfc8694.txt | 1225 |
1 files changed, 1225 insertions, 0 deletions
diff --git a/doc/rfc/rfc8694.txt b/doc/rfc/rfc8694.txt new file mode 100644 index 0000000..0119176 --- /dev/null +++ b/doc/rfc/rfc8694.txt @@ -0,0 +1,1225 @@ + + + + +Internet Engineering Task Force (IETF) D. King +Request for Comments: 8694 Old Dog Consulting +Category: Informational 郑好棉 (H. Zheng) +ISSN: 2070-1721 华为技术有限公司 (Huawei Technologies) + December 2019 + + +Applicability of the Path Computation Element to Inter-area and Inter-AS + MPLS and GMPLS Traffic Engineering + +Abstract + + The Path Computation Element (PCE) may be used for computing services + that traverse multi-area and multi-Autonomous System (multi-AS) + Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) + Traffic-Engineered (TE) networks. + + This document examines the applicability of the PCE architecture, + protocols, and protocol extensions for computing multi-area and + multi-AS paths in MPLS and GMPLS networks. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8694. + +Copyright Notice + + Copyright (c) 2019 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 + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 1.1. Domains + 1.2. Path Computation + 1.2.1. PCE-Based Path Computation Procedure + 1.3. Traffic Engineering Aggregation and Abstraction + 1.4. Traffic-Engineered Label Switched Paths + 1.5. Inter-area and Inter-AS-capable PCE Discovery + 1.6. Objective Functions + 2. Terminology + 3. Issues and Considerations + 3.1. Multihoming + 3.2. Destination Location + 3.3. Domain Confidentiality + 4. Domain Topologies + 4.1. Selecting Domain Paths + 4.2. Domain Sizes + 4.3. Domain Diversity + 4.4. Synchronized Path Computations + 4.5. Domain Inclusion or Exclusion + 5. Applicability of the PCE to Inter-area Traffic Engineering + 5.1. Inter-area Routing + 5.1.1. Area Inclusion and Exclusion + 5.1.2. Strict Explicit Path and Loose Path + 5.1.3. Inter-Area Diverse Path Computation + 6. Applicability of the PCE to Inter-AS Traffic Engineering + 6.1. Inter-AS Routing + 6.1.1. AS Inclusion and Exclusion + 6.2. Inter-AS Bandwidth Guarantees + 6.3. Inter-AS Recovery + 6.4. Inter-AS PCE Peering Policies + 7. Multi-domain PCE Deployment Options + 7.1. Traffic Engineering Database and Synchronization + 7.1.1. Applicability of BGP-LS to PCE + 7.2. Pre-planning and Management-Based Solutions + 8. Domain Confidentiality + 8.1. Loose Hops + 8.2. Confidential Path Segments and Path-Keys + 9. Point to Multipoint + 10. Optical Domains + 10.1. Abstraction and Control of TE Networks (ACTN) + 11. Policy + 12. Manageability Considerations + 12.1. Control of Function and Policy + 12.2. Information and Data Models + 12.3. Liveness Detection and Monitoring + 12.4. Verifying Correct Operation + 12.5. Impact on Network Operation + 13. Security Considerations + 13.1. Multi-domain Security + 14. IANA Considerations + 15. References + 15.1. Normative References + 15.2. Informative References + Acknowledgements + Contributors + Authors' Addresses + +1. Introduction + + Computing paths across large multi-domain environments may require + special computational components and cooperation between entities in + different domains capable of complex path computation. + + Issues that may exist when routing in multi-domain networks include + the following: + + * There is often a lack of full topology and TE information across + domains. + + * No single node has the full visibility to determine an optimal or + even feasible end-to-end path across domains. + + * Knowing how to evaluate and select the exit point and next domain + boundary from a domain. + + * Understanding how the ingress node determines which domains should + be used for the end-to-end path. + + An information exchange across multiple domains is often limited due + to the lack of trust relationship, security issues, or scalability + issues, even if there is a trust relationship between domains. + + The Path Computation Element (PCE) [RFC4655] provides an architecture + and a set of functional components to address the problem space and + the issues highlighted above. + + A PCE may be used to compute end-to-end paths across multi-domain + environments using a per-domain path computation technique [RFC5152]. + The so-called backward recursive PCE-based computation (BRPC) + mechanism [RFC5441] defines a path computation procedure to compute + inter-domain constrained Multiprotocol Label Switching (MPLS) and + Generalized MPLS (GMPLS) Traffic-Engineered (TE) networks. However, + both per-domain and BRPC techniques assume that the sequence of + domains to be crossed from source to destination is known, either + fixed by the network operator or obtained by other means. + + In more advanced deployments (including multi-area and multi- + Autonomous System (multi-AS) environments), the sequence of domains + may not be known in advance, and the choice of domains in the end-to- + end domain sequence might be critical to the determination of an + optimal end-to-end path. In this case, the use of the hierarchical + PCE [RFC6805] architecture and mechanisms may be used to discover the + intra-area path and select the optimal end-to-end domain sequence. + + This document describes the processes and procedures available when + using the PCE architecture and protocols for computing inter-area and + inter-AS MPLS and GMPLS Traffic-Engineered paths. + + The scope of this document does not include discussions of deployment + scenarios for stateful PCE, active PCE, remotely initiated PCE, or + PCE as a central controller (PCECC). + +1.1. Domains + + Generally, a domain can be defined as a separate administrative, + geographic, or switching environment within the network. A domain + may be further defined as a zone of routing or computational ability. + Under these definitions, a domain might be categorized as an + Autonomous System (AS) or an Interior Gateway Protocol (IGP) area (as + per [RFC4726] and [RFC4655]). + + For the purposes of this document, a domain is considered to be a + collection of network elements within an area or AS that has a common + sphere of address management or path computational responsibility. + Wholly or partially overlapping domains are not within the scope of + this document. + + In the context of GMPLS, a particularly important example of a domain + is the Automatically Switched Optical Network (ASON) subnetwork + [G-8080]. In this case, computation of an end-to-end path requires + the selection of nodes and links within a parent domain where some + nodes may, in fact, be subnetworks. Furthermore, a domain might be + an ASON routing area [G-7715]. A PCE may perform the path + computation function of an ASON Routing Controller as described in + [G-7715-2]. + + It is assumed that the PCE architecture is not applied to a large + group of domains, such as the Internet. + +1.2. Path Computation + + For the purpose of this document, it is assumed that path computation + is the sole responsibility of the PCE as per the architecture defined + in [RFC4655]. When a path is required, the Path Computation Client + (PCC) will send a request to the PCE. The PCE will apply the + required constraints, compute a path, and return a response to the + PCC. In the context of this document, it may be necessary for the + PCE to cooperate with other PCEs in adjacent domains (as per BRPC + [RFC5441]) or with a parent PCE (as per [RFC6805]). + + It is entirely feasible that an operator could compute a path across + multiple domains without the use of a PCE if the relevant domain + information is available to the network planner or network management + platform. The definition of what relevant information is required to + perform this network planning operation and how that information is + discovered and applied is outside the scope of this document. + +1.2.1. PCE-Based Path Computation Procedure + + As highlighted, the PCE is an entity capable of computing an inter- + domain TE path upon receiving a request from a PCC. There could be a + single PCE per domain or a single PCE responsible for all domains. A + PCE may or may not reside on the same node as the requesting PCC. A + path may be computed by either a single PCE node or a set of + distributed PCE nodes that collaborate during path computation. + + According to [RFC4655], a PCC should send a path computation request + to a particular PCE using [RFC5440] (PCC-to-PCE communication). This + negates the need to broadcast a request to all the PCEs. Each PCC + can maintain information about the computation capabilities of the + PCEs it is aware of. The PCC-PCE capability awareness can be + configured using static configurations or by automatic and dynamic + PCE discovery procedures. + + If a network path is required, the PCC will send a path computation + request to the PCE. A PCE may then compute the end-to-end path if it + is aware of the topology and TE information required to compute the + entire path. If the PCE is unable to compute the entire path, the + PCE architecture provides cooperative PCE mechanisms for the + resolution of path computation requests when an individual PCE does + not have sufficient TE visibility. + + End-to-end path segments may be kept confidential through the + application of Path-Keys to protect partial or full path information. + A Path-Key is a token that replaces a path segment in an explicit + route. The Path-Key mechanism is described in [RFC5520]. + +1.3. Traffic Engineering Aggregation and Abstraction + + Networks are often constructed from multiple areas or ASes that are + interconnected via multiple interconnect points. To maintain network + confidentiality and scalability, the TE properties of each area and + AS are not generally advertised outside each specific area or AS. + + TE aggregation or abstraction provide a mechanism to hide information + but may cause failed path setups or the selection of suboptimal end- + to-end paths [RFC4726]. The aggregation process may also have + significant scaling issues for networks with many possible routes and + multiple TE metrics. Flooding TE information breaks confidentiality + and does not scale in the routing protocol. + + The PCE architecture and associated mechanisms provide a solution to + avoid the use of TE aggregation and abstraction. + +1.4. Traffic-Engineered Label Switched Paths + + This document highlights the PCE techniques and mechanisms that exist + for establishing TE packet and optical Label Switched Paths (LSPs) + across multiple areas (inter-area TE LSP) and ASes (inter-AS TE LSP). + In this context and within the remainder of this document, we + consider all LSPs to be constraint based and traffic engineered. + + Three signaling options are defined for setting up an inter-area or + inter-AS LSP [RFC4726]: + + * Contiguous LSP + + * Stitched LSP + + * Nested LSP + + All three signaling methods are applicable to the architectures and + procedures discussed in this document. + +1.5. Inter-area and Inter-AS-capable PCE Discovery + + When using a PCE-based approach for inter-area and inter-AS path + computation, a PCE in one area or AS may need to learn information + related to inter-AS-capable PCEs located in other ASes. The PCE + discovery mechanism defined in [RFC5088] and [RFC5089] facilitates + the discovery of PCEs and disclosure of information related to inter- + area and inter-AS-capable PCEs. + +1.6. Objective Functions + + An Objective Function (OF) [RFC5541] or a set of OFs specifies the + intentions of the path computation and so defines the "optimality" in + the context of the computation request. + + An OF specifies the desired outcome of a computation. It does not + describe or specify the algorithm to use. Also, an implementation + may apply any algorithm or set of algorithms to achieve the result + indicated by the OF. A number of general OFs are specified in + [RFC5541]. + + Various OFs may be included in the PCE computation request to satisfy + the policies encoded or configured at the PCC, and a PCE may be + subject to policy in determining whether it meets the OFs included in + the computation request or whether it applies its own OFs. + + During inter-domain path computation, the selection of a domain + sequence, the computation of each (per-domain) path fragment, and the + determination of the end-to-end path may each be subject to different + OFs and policies. + +2. Terminology + + This document also uses the terminology defined in [RFC4655] and + [RFC5440]. Additional terminology is defined below: + + ABR: IGP Area Border Router -- a router that is attached to more + than one IGP area. + + ASBR: Autonomous System Border Router -- a router used to connect + together ASes of a different or the same Service Provider via + one or more inter-AS links. + + Inter-area TE LSP: A TE LSP whose path transits through two or more + IGP areas. + + Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or + more ASes or sub-ASes (BGP confederations) + + SRLG: Shared Risk Link Group. + + TED: Traffic Engineering Database, which contains the topology and + resource information of the domain. The TED may be fed by + Interior Gateway Protocol (IGP) extensions or potentially by + other means. + +3. Issues and Considerations + +3.1. Multihoming + + Networks constructed from multi-areas or multi-AS environments may + have multiple interconnect points (multihoming). End-to-end path + computations may need to use different interconnect points to avoid a + single-point failure disrupting both the primary and backup services. + +3.2. Destination Location + + A PCC asking for an inter-domain path computation is typically aware + of the identity of the destination node. If the PCC is aware of the + destination domain, it may supply the destination domain information + as part of the path computation request. However, if the PCC does + not know the destination domain, this information must be determined + by another method. + +3.3. Domain Confidentiality + + When the end-to-end path crosses multiple domains, it may be possible + that each domain (AS or area) is administered by separate Service + Providers. Thus, if a PCE supplies a path segment to a PCE in + another domain, it may break confidentiality rules and could disclose + AS-internal topology information. + + If confidentiality is required between domains (ASes and areas) + belonging to different Service Providers, then cooperating PCEs + cannot exchange path segments; otherwise, the receiving PCE or PCC + will be able to see the individual hops through another domain. + + This topic is discussed further in Section 8 of this document. + +4. Domain Topologies + + Constraint-based inter-domain path computation is a fundamental + requirement for operating traffic-engineered MPLS [RFC3209] and GMPLS + [RFC3473] networks in inter-area and inter-AS (multi-domain) + environments. Path computation across multi-domain networks is + complex and requires computational cooperational entities like the + PCE. + +4.1. Selecting Domain Paths + + Where the sequence of domains is known a priori, various techniques + can be employed to derive an optimal multi-domain path. If the + domains are connected to a simple path with no branches and single + links between all domains or if the preferred points of + interconnection are also known, the per-domain path computation + [RFC5152] technique may be used. Where there are multiple + connections between domains and there is no preference for the choice + of points of interconnection, BRPC [RFC5441] can be used to derive an + optimal path. + + When the sequence of domains is not known in advance or the end-to- + end path will have to navigate a mesh of small domains (especially + typical in optical networks), the optimum path may be derived through + the application of a hierarchical PCE [RFC6805]. + +4.2. Domain Sizes + + Very frequently, network domains are composed of dozens or hundreds + of network elements. These network elements are usually + interconnected in a partial-mesh fashion to provide survivability + against dual failures and to benefit from the traffic-engineering + capabilities of MPLS and GMPLS protocols. Network operator feedback + in the development of the document highlighted that the node degree + (the number of neighbors per node) typically ranges from 3 to 10 (4-5 + is quite common). + +4.3. Domain Diversity + + Domain and path diversity may also be required when computing end-to- + end paths. Domain diversity should facilitate the selection of paths + that share ingress and egress domains but do not share transit + domains. Therefore, there must be a method allowing the inclusion or + exclusion of specific domains when computing end-to-end paths. + +4.4. Synchronized Path Computations + + In some scenarios, it would be beneficial for the operator to rely on + the capability of the PCE to perform synchronized path computation. + + Synchronized path computations, known as Synchronization VECtors + (SVECs), are used for dependent path computations. SVECs are defined + in [RFC5440], and [RFC6007] provides an overview of the use of the + PCE SVEC list for synchronized path computations when computing + dependent requests. + + In hierarchical PCE (H-PCE) deployments, a child PCE will be able to + request both dependent and synchronized domain-diverse end-to-end + paths from its parent PCE. + +4.5. Domain Inclusion or Exclusion + + A domain sequence is an ordered sequence of domains traversed to + reach the destination domain. A domain sequence may be supplied + during path computation to guide the PCEs or are derived via the use + of hierarchical PCE (H-PCE). + + During multi-domain path computation, a PCC may request specific + domains to be included or excluded in the domain sequence using the + Include Route Object (IRO) [RFC5440] and Exclude Route Object (XRO) + [RFC5521]. The use of Autonomous Number (AS) as an abstract node + representing a domain is defined in [RFC3209]. [RFC7897] specifies + new subobjects to include or exclude domains such as an IGP area or a + 4-byte AS number. + + An operator may also need to avoid a path that uses specified nodes + for administrative reasons. If a specific connectivity service is + required to have a 1+1 protection capability, two separate disjoint + paths must be established. A mechanism known as Shared Risk Link + Group (SRLG) information may be used to ensure path diversity. + +5. Applicability of the PCE to Inter-area Traffic Engineering + + As networks increase in size and complexity, it may be required to + introduce scaling methods to reduce the amount of information flooded + within the network and make the network more manageable. An IGP + hierarchy is designed to improve IGP scalability by dividing the IGP + domain into areas and limiting the flooding scope of topology + information to within area boundaries. This restricts visibility of + the area to routers in a single area. If a router needs to compute + the route to a destination located in another area, a method would be + required to compute a path across area boundaries. + + In order to support multiple vendors in a network in cases where data + or control-plane technologies cannot interoperate, it is useful to + divide the network into vendor domains. Each vendor domain is an IGP + area, and the flooding scope of the topology (as well as any other + relevant information) is limited to the area boundaries. + + Per-domain path computation [RFC5152] exists to provide a method of + inter-area path computation. The per-domain solution is based on + loose hop routing with an Explicit Route Object (ERO) expansion on + each Area Border Router (ABR). This allows an LSP to be established + using a constrained path. However, at least two issues exist: + + * This method does not guarantee an optimal constrained path. + + * The method may require several crankback signaling messages, as + per [RFC4920], increasing signaling traffic and delaying the LSP + setup. + + PCE-based architecture [RFC4655] is designed to solve inter-area path + computation problems. The issue of limited topology visibility is + resolved by introducing path computation entities that are able to + cooperate in order to establish LSPs with the source and destinations + located in different areas. + +5.1. Inter-area Routing + + An inter-area TE-LSP is an LSP that transits through at least two IGP + areas. In a multi-area network, topology visibility remains local to + a given area for scaling and privacy purposes. A node in one area + will not be able to compute an end-to-end path across multiple areas + without the use of a PCE. + +5.1.1. Area Inclusion and Exclusion + + The BRPC method [RFC5441] of path computation provides a more optimal + method to specify inclusion or exclusion of an ABR. Using the BRPC + procedure, an end-to-end path is recursively computed in reverse from + the destination domain towards the source domain. Using this method, + an operator might decide if an area must be included or excluded from + the inter-area path computation. + +5.1.2. Strict Explicit Path and Loose Path + + A strict explicit path is defined as a set of strict hops, while a + loose path is defined as a set of at least one loose hop and zero or + more strict hops. It may be useful to indicate whether a strict + explicit path is required during the path computation request. An + inter-area path may be strictly explicit or loose (e.g., a list of + ABRs as loose hops). + + A PCC request to a PCE does allow indication of whether a strict + explicit path across specific areas ([RFC7897]) is required or + desired or whether the path request is loose. + +5.1.3. Inter-Area Diverse Path Computation + + It may be necessary to compute a path that is partially or entirely + diverse from a previously computed path to avoid fate sharing of a + primary service with a corresponding backup service. There are + various levels of diversity in the context of an inter-area network: + + * Per-area diversity (the intra-area path segments are a link, node, + or SRLG disjoint). + + * Inter-area diversity (the end-to-end inter-area paths are a link, + node, or SRLG disjoint). + + Note that two paths may be disjointed in the backbone area but non- + disjointed in peripheral areas. Also, two paths may be node + disjointed within areas but may share ABRs, in which case path + segments within an area are node disjointed but end-to-end paths are + not node disjointed. Per-domain [RFC5152], BRPC [RFC5441], and H-PCE + [RFC6805] mechanisms all support the capability to compute diverse + paths across multi-area topologies. + +6. Applicability of the PCE to Inter-AS Traffic Engineering + + As discussed in Section 5 (Applicability of the PCE to Inter-area + Traffic Engineering), it is necessary to divide the network into + smaller administrative domains, or ASes. If an LSR within an AS + needs to compute a path across an AS boundary, it must also use an + inter-AS computation technique. [RFC5152] defines mechanisms for the + computation of inter-domain TE LSPs using network elements along the + signaling paths to compute per-domain constrained path segments. + + The PCE was designed to be capable of computing MPLS and GMPLS paths + across AS boundaries. This section outlines the features of a PCE- + enabled solution for computing inter-AS paths. + +6.1. Inter-AS Routing + +6.1.1. AS Inclusion and Exclusion + + [RFC5441] allows the specification of AS or ASBR inclusion or + exclusion. Using this method, an operator might decide whether an AS + must be included or excluded from the inter-AS path computation. + Exclusion and/or inclusion could also be specified at any step in the + LSP path computation process by a PCE (within the BRPC algorithm), + but the best practice would be to specify them at the edge. In + opposition to the strict and loose path, AS inclusion or exclusion + doesn't impose topology disclosure as ASes and their interconnection + are public entities. + +6.2. Inter-AS Bandwidth Guarantees + + Many operators with multi-AS domains will have deployed the MPLS-TE + Diffserv either across their entire network or at the domain edges on + CE-PE links. In situations where strict QoS bounds are required, + admission control inside the network may also be required. + + When the propagation delay can be bounded, the performance targets, + such as maximum one-way transit delay, may be guaranteed by providing + bandwidth guarantees along the Diffserv-enabled path. These + requirements are described in [RFC4216]. + + One typical example of the requirements in [RFC4216] is to provide + bandwidth guarantees over an end-to-end path for VoIP traffic + classified as an EF (Expedited Forwarding) class in a Diffserv- + enabled network. In cases where the EF path is extended across + multiple ASes, an inter-AS bandwidth guarantee would be required. + + Another case for an inter-AS bandwidth guarantee is the requirement + to guarantee a certain amount of transit bandwidth across one or + multiple ASes. + +6.3. Inter-AS Recovery + + During a path computation process, a PCC request may contain the + requirement to compute a backup LSP for protecting the primary LSP, + such as 1+1 protection. A single LSP or multiple backup LSPs may + also be used for a group of primary LSPs; this is typically known as + m:n protection. + + Other inter-AS recovery mechanisms include [RFC4090], which adds Fast + Reroute (FRR) protection to an LSP. So, the PCE could be used to + trigger computation of backup tunnels in order to protect inter-AS + connectivity. + + Inter-AS recovery clearly requires backup LSPs for service + protection, but it would also be advisable to have multiple PCEs + deployed for path computation redundancy, especially for service + restoration in the event of catastrophic network failure. + +6.4. Inter-AS PCE Peering Policies + + Like BGP peering policies, inter-AS PCE peering policies are required + for an operator. In an inter-AS BRPC process, the PCE must cooperate + in order to compute the end-to-end LSP. Therefore, the AS path must + not only follow technical constraints, e.g., bandwidth availability, + but also the policies defined by the operator. + + Typically, PCE interconnections at an AS level must follow the agreed + contract obligations, also known as peering agreements. The PCE + peering policies are the result of the contract negotiation and + govern the relation between the different PCEs. + +7. Multi-domain PCE Deployment Options + +7.1. Traffic Engineering Database and Synchronization + + An optimal path computation requires knowledge of the available + network resources, including nodes and links, constraints, link + connectivity, available bandwidth, and link costs. The PCE operates + on a view of the network topology as presented by a TED. As + discussed in [RFC4655], the TED used by a PCE may be learned by the + relevant IGP extensions. + + Thus, the PCE may operate its TED by participating in the IGP running + in the network. In an MPLS-TE network, this would require OSPF-TE + [RFC3630] or ISIS-TE [RFC5305]. In a GMPLS network, it would utilize + the GMPLS extensions to OSPF and IS-IS defined in [RFC4203] and + [RFC5307]. Inter-AS connectivity information may be populated via + [RFC5316] and [RFC5392]. + + An alternative method to providing network topology and resource + information is offered by [RFC7752], which is described in the + following section. + +7.1.1. Applicability of BGP-LS to PCE + + The concept of the exchange of TE information between Autonomous + Systems (ASes) is discussed in [RFC7752]. The information exchanged + in this way could be the full TE information from the AS, an + aggregation of that information, or a representation of the potential + connectivity across the AS. Furthermore, that information could be + updated frequently (for example, for every new LSP that is set up + across the AS) or only at threshold-crossing events. + + In an H-PCE deployment, the parent PCE will require the inter-domain + topology and link status between child domains. This information may + be learned by a BGP-LS speaker and provided to the parent PCE. + Furthermore, link-state performance, including delay, available + bandwidth, and utilized bandwidth, may also be provided to the parent + PCE for optimal path link selection. + +7.2. Pre-planning and Management-Based Solutions + + Offline path computation is performed ahead of time before the LSP + setup is requested. That means that it is requested by or performed + as part of an Operation Support System (OSS) management application. + This model can be seen in Section 5.5 of [RFC4655]. + + The offline model is particularly appropriate for long-lived LSPs + (such as those present in a transport network) or for planned + responses to network failures. In these scenarios, more planning is + normally a feature of LSP provisioning. + + The management system may also use a PCE and BRPC to pre-plan an AS + sequence, and the source domain PCE and per-domain path computation + to be used when the actual end-to-end path is required. This model + may also be used where the operator wishes to retain full manual + control of the placement of LSPs, using the PCE only as a computation + tool to assist the operator and not as part of an automated network. + + In environments where operators peer with each other to provide end- + to-end paths, the operator responsible for each domain must agree on + the extent to which paths must be pre-planned or manually controlled. + +8. Domain Confidentiality + + This section discusses the techniques that cooperating PCEs can use + to compute inter-domain paths without each domain disclosing + sensitive internal topology information (such as explicit nodes or + links within the domain) to the other domains. + + Confidentiality typically applies to inter-provider (inter-AS) PCE + communication. Where the TE LSP crosses multiple domains (ASes or + areas), the path may be computed by multiple PCEs that cooperate + together, with each local PCE responsible for computing a segment of + the path. With each local PCE responsible for computing a segment of + the path. + + In situations where ASes are administered by separate Service + Providers, it would break confidentiality rules for a PCE to supply + path segment details to a PCE responsible for another domain, thus + disclosing AS-internal or area topology information. + +8.1. Loose Hops + + A method for preserving the confidentiality of the path segment is + for the PCE to return a path containing a loose hop in place of the + segment that must be kept confidential. The concept of loose and + strict hops for the route of a TE LSP is described in [RFC3209]. + + [RFC5440] supports the use of paths with loose hops; whether it + returns a full explicit path with strict hops or uses loose hops is a + local policy decision at a PCE. A path computation request may + require an explicit path with strict hops or may allow loose hops, as + detailed in [RFC5440]. + +8.2. Confidential Path Segments and Path-Keys + + [RFC5520] defines the concept and mechanism of a Path-Key. A Path-Key + is a token that replaces the path segment information in an explicit + route. The Path-Key allows the explicit route information to be + encoded and is contained in the Path Computation Element + Communication Protocol (PCEP) ([RFC5440]) messages exchanged between + the PCE and PCC. + + This Path-Key technique allows explicit route information to be used + for end-to-end path computation without disclosing internal topology + information between domains. + +9. Point to Multipoint + + For inter-domain point-to-multipoint application scenarios using + MPLS-TE LSPs, the complexity of domain sequences, domain policies, + and the choice and number of domain interconnects is magnified + compared to point-to-point path computations. As the size of the + network grows, the number of leaves and branches increases, further + increasing the complexity of the overall path computation problem. A + solution for managing point-to-multipoint path computations may be + achieved using the PCE inter-domain point-to-multipoint path + computation [RFC7334] procedure. + +10. Optical Domains + + The International Telecommunication Union (ITU) defines the ASON + architecture in [G-8080]. [G-7715] defines the routing architecture + for ASON and introduces a hierarchical architecture. In this + architecture, the Routing Areas (RAs) have a hierarchical + relationship between different routing levels, which means a parent + (or higher level) RA can contain multiple child RAs. The + interconnectivity of the lower RAs is visible to the higher-level RA. + + In the ASON framework, a path computation request is termed a route + query. This query is executed before signaling is used to establish + an LSP, which is termed a Switched Connection (SC) or a Soft + Permanent Connection (SPC). [G-7715-2] defines the requirements and + architecture for the functions performed by Routing Controllers (RC) + during the operation of remote route queries. An RC is synonymous + with a PCE. + + In the ASON routing environment, an RC responsible for an RA may + communicate with its neighbor RC to request the computation of an + end-to-end path across several RAs. The path computation components + and sequences are defined as follows: + + * Remote route query. An operation where a Routing Controller + communicates with another Routing Controller, which does not have + the same set of layer resources, in order to compute a routing + path in a collaborative manner. + + * Route query requester. The connection controller or RC that sends + a route query message to a Routing Controller that requests one or + more routing paths satisfying a set of routing constraints. + + * Route query responder. An RC that performs the path computation + upon reception of a route query message from a Routing Controller + or connection controller, and sends a response back at the end of + the computation. + + When computing an end-to-end connection, the route may be computed by + a single RC or multiple RCs in a collaborative manner, and the two + scenarios can be considered a centralized remote route query model + and a distributed remote route query model. RCs in an ASON + environment can also use the hierarchical PCE [RFC6805] model to + fully match the ASON hierarchical routing model. + +10.1. Abstraction and Control of TE Networks (ACTN) + + Where a single operator operates multiple TE domains (including + optical environments), an Abstraction and Control of TE Networks + (ACTN) framework [RFC8453] may be used to create an abstracted + (virtualized network) view of underlay-interconnected domains. This + underlay connectivity is then exposed to higher-layer control + entities and applications. + + ACTN describes the method and procedure for coordinating the underlay + per-domain Provisioning Network Controllers (PNCs), which may be + PCEs, via a hierarchical model to facilitate setup of end-to-end + connections across interconnected TE domains. + +11. Policy + + Policy is important in the deployment of new services and the + operation of the network. [RFC5394] provides a framework for PCE- + based policy-enabled path computation. This framework is based on + the Policy Core Information Model (PCIM) as defined in [RFC3060] and + further extended by [RFC3460]. + + When using a PCE to compute inter-domain paths, policy may be invoked + by specifying the following: + + * Each PCC must select which computations it will request from a + PCE. + + * Each PCC must select which PCEs it will use. + + * Each PCE must determine which PCCs are allowed to use its services + and for what computations. + + * The PCE must determine how to collect the information in its TED, + whom to trust for that information, and how to refresh/update the + information. + + * Each PCE must determine which objective functions and algorithms + to apply. + +12. Manageability Considerations + + General PCE management considerations are discussed in [RFC4655]. In + the case of multi-domains within a single service provider network, + the management responsibility for each PCE would most likely be + handled by the same service provider. In the case of multiple ASes + within different service provider networks, it will likely be + necessary for each PCE to be configured and managed separately by + each participating service provider, with policy being implemented + based on a previously agreed set of principles. + +12.1. Control of Function and Policy + + As per [RFC5440], PCEP implementation allows the user to configure a + number of PCEP session parameters. These are detailed in Section 8.1 + of [RFC5440]. + + In H-PCE deployments, the administrative entity responsible for the + management of the parent PCEs for multi-areas would typically be a + single service provider. In multiple ASes (managed by different + service providers), it may be necessary for a third party to manage + the parent PCE. + +12.2. Information and Data Models + + A PCEP MIB module is defined in [RFC7420], which describes managed + objects for modeling PCEP communication, including: + + * PCEP client configuration and status. + + * PCEP peer configuration and information. + + * PCEP session configuration and information. + + * Notifications to indicate PCEP session changes. + + A YANG module for PCEP has also been proposed [PCEP-YANG]. + + An H-PCE MIB module or YANG data model will be required to report + parent PCE and child PCE information, including: + + * Parent PCE configuration and status. + + * Child PCE configuration and information. + + * Notifications to indicate session changes between parent PCEs and + child PCEs. + + * Notification of parent PCE TED updates and changes. + +12.3. Liveness Detection and Monitoring + + PCEP includes a keepalive mechanism to check the liveliness of a PCEP + peer and a notification procedure allowing a PCE to advertise its + overloaded state to a PCC. In a multi-domain environment, [RFC5886] + provides the procedures necessary to monitor the liveliness and + performance of a given PCE chain. + +12.4. Verifying Correct Operation + + It is important to verify the correct operation of PCEP. [RFC5440] + specifies the monitoring of key parameters. These parameters are + detailed in [RFC5520]. + +12.5. Impact on Network Operation + + [RFC5440] states that in order to avoid any unacceptable impact on + network operations, a PCEP implementation should allow a limit to be + placed on the number of sessions that can be set up on a PCEP speaker + and that it may also be practical to place a limit on the rate of + messages sent by a PCC and received by the PCE. + +13. Security Considerations + + PCEP security considerations are discussed in [RFC5440] and + [RFC6952]. Potential vulnerabilities include spoofing, snooping, + falsification, and using PCEP as a mechanism for denial of service + attacks. + + As PCEP operates over TCP, it may make use of TCP security encryption + mechanisms, such as Transport Layer Security (TLS) and TCP + Authentication Option (TCP-AO). Usage of these security mechanisms + for PCEP is described in [RFC8253], and recommendations and best + current practices are described in [RFC7525]. + +13.1. Multi-domain Security + + Any multi-domain operation necessarily involves the exchange of + information across domain boundaries. This represents a significant + security and confidentiality risk. + + It is expected that PCEP is used between PCCs and PCEs that belong to + the same administrative authority while also using one of the + aforementioned encryption mechanisms. Furthermore, PCEP allows + individual PCEs to maintain the confidentiality of their domain path + information using path-keys. + +14. IANA Considerations + + This document has no IANA actions. + +15. References + +15.1. Normative References + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, + <https://www.rfc-editor.org/info/rfc3209>. + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation Protocol- + Traffic Engineering (RSVP-TE) Extensions", RFC 3473, + DOI 10.17487/RFC3473, January 2003, + <https://www.rfc-editor.org/info/rfc3473>. + + [RFC4216] Zhang, R., Ed. and J.-P. Vasseur, Ed., "MPLS Inter- + Autonomous System (AS) Traffic Engineering (TE) + Requirements", RFC 4216, DOI 10.17487/RFC4216, November + 2005, <https://www.rfc-editor.org/info/rfc4216>. + + [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path + Computation Element (PCE)-Based Architecture", RFC 4655, + DOI 10.17487/RFC4655, August 2006, + <https://www.rfc-editor.org/info/rfc4655>. + + [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework + for Inter-Domain Multiprotocol Label Switching Traffic + Engineering", RFC 4726, DOI 10.17487/RFC4726, November + 2006, <https://www.rfc-editor.org/info/rfc4726>. + + [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, DOI 10.17487/RFC5152, February 2008, + <https://www.rfc-editor.org/info/rfc5152>. + + [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol (PCEP)", RFC 5440, + DOI 10.17487/RFC5440, March 2009, + <https://www.rfc-editor.org/info/rfc5440>. + + [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, + DOI 10.17487/RFC5441, April 2009, + <https://www.rfc-editor.org/info/rfc5441>. + + [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, + DOI 10.17487/RFC5520, April 2009, + <https://www.rfc-editor.org/info/rfc5520>. + + [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of + Objective Functions in the Path Computation Element + Communication Protocol (PCEP)", RFC 5541, + DOI 10.17487/RFC5541, June 2009, + <https://www.rfc-editor.org/info/rfc5541>. + + [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the + Path Computation Element Architecture to the Determination + of a Sequence of Domains in MPLS and GMPLS", RFC 6805, + DOI 10.17487/RFC6805, November 2012, + <https://www.rfc-editor.org/info/rfc6805>. + +15.2. Informative References + + [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, + "Policy Core Information Model -- Version 1 + Specification", RFC 3060, DOI 10.17487/RFC3060, February + 2001, <https://www.rfc-editor.org/info/rfc3060>. + + [RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) + Extensions", RFC 3460, DOI 10.17487/RFC3460, January 2003, + <https://www.rfc-editor.org/info/rfc3460>. + + [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering + (TE) Extensions to OSPF Version 2", RFC 3630, + DOI 10.17487/RFC3630, September 2003, + <https://www.rfc-editor.org/info/rfc3630>. + + [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast + Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, + DOI 10.17487/RFC4090, May 2005, + <https://www.rfc-editor.org/info/rfc4090>. + + [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in + Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, + <https://www.rfc-editor.org/info/rfc4203>. + + [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., + and G. Ash, "Crankback Signaling Extensions for MPLS and + GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007, + <https://www.rfc-editor.org/info/rfc4920>. + + [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. + Zhang, "OSPF Protocol Extensions for Path Computation + Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, + January 2008, <https://www.rfc-editor.org/info/rfc5088>. + + [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. + Zhang, "IS-IS Protocol Extensions for Path Computation + Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, + January 2008, <https://www.rfc-editor.org/info/rfc5089>. + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, DOI 10.17487/RFC5305, October + 2008, <https://www.rfc-editor.org/info/rfc5305>. + + [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions + in Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, + <https://www.rfc-editor.org/info/rfc5307>. + + [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in + Support of Inter-Autonomous System (AS) MPLS and GMPLS + Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, + December 2008, <https://www.rfc-editor.org/info/rfc5316>. + + [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in + Support of Inter-Autonomous System (AS) MPLS and GMPLS + Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, + January 2009, <https://www.rfc-editor.org/info/rfc5392>. + + [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, + "Policy-Enabled Path Computation Framework", RFC 5394, + DOI 10.17487/RFC5394, December 2008, + <https://www.rfc-editor.org/info/rfc5394>. + + [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the + Path Computation Element Communication Protocol (PCEP) for + Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April + 2009, <https://www.rfc-editor.org/info/rfc5521>. + + [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of + Monitoring Tools for Path Computation Element (PCE)-Based + Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, + <https://www.rfc-editor.org/info/rfc5886>. + + [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization + VECtor (SVEC) List for Synchronized Dependent Path + Computations", RFC 6007, DOI 10.17487/RFC6007, September + 2010, <https://www.rfc-editor.org/info/rfc6007>. + + [G-8080] ITU-T, "Architecture for the automatically switched + optical network", ITU-T Recommendation G.8080/Y.1304, + February 2012. + + [G-7715] ITU-T, "Architecture and requirements for routing in the + automatically switched optical networks", ITU-T + Recommendation G.7715/Y.1706, June 2002. + + [G-7715-2] ITU-T, "ASON routing architecture and requirements for + remote route query", ITU-T + Recommendation G.7715.2/Y.1706.2, February 2007. + + [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of + BGP, LDP, PCEP, and MSDP Issues According to the Keying + and Authentication for Routing Protocols (KARP) Design + Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, + <https://www.rfc-editor.org/info/rfc6952>. + + [RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas, + "PCE-Based Computation Procedure to Compute Shortest + Constrained Point-to-Multipoint (P2MP) Inter-Domain + Traffic Engineering Label Switched Paths", RFC 7334, + DOI 10.17487/RFC7334, August 2014, + <https://www.rfc-editor.org/info/rfc7334>. + + [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. + Hardwick, "Path Computation Element Communication Protocol + (PCEP) Management Information Base (MIB) Module", + RFC 7420, DOI 10.17487/RFC7420, December 2014, + <https://www.rfc-editor.org/info/rfc7420>. + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May + 2015, <https://www.rfc-editor.org/info/rfc7525>. + + [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and + S. Ray, "North-Bound Distribution of Link-State and + Traffic Engineering (TE) Information Using BGP", RFC 7752, + DOI 10.17487/RFC7752, March 2016, + <https://www.rfc-editor.org/info/rfc7752>. + + [RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects + for the Path Computation Element Communication Protocol + (PCEP)", RFC 7897, DOI 10.17487/RFC7897, June 2016, + <https://www.rfc-editor.org/info/rfc7897>. + + [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, + "PCEPS: Usage of TLS to Provide a Secure Transport for the + Path Computation Element Communication Protocol (PCEP)", + RFC 8253, DOI 10.17487/RFC8253, October 2017, + <https://www.rfc-editor.org/info/rfc8253>. + + [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for + Abstraction and Control of TE Networks (ACTN)", RFC 8453, + DOI 10.17487/RFC8453, August 2018, + <https://www.rfc-editor.org/info/rfc8453>. + + [PCEP-YANG] + Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A + YANG Data Model for Path Computation Element + Communications Protocol (PCEP)", Work in Progress, + Internet-Draft, draft-ietf-pce-pcep-yang-13, 31 October + 2019, + <https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>. + +Acknowledgements + + The author would like to thank Adrian Farrel for his review and Meral + Shirazipour and Francisco Javier Jiménez Chico for their comments. + +Contributors + + Dhruv Dhody + Huawei Technologies + Divyashree Techno Park, Whitefield + Bangalore 560066 + Karnataka + India + + Email: dhruv.ietf@gmail.com + + + Quintin Zhao + Huawei Technologies + 125 Nagog Technology Park + Acton, MA 01719 + United States of America + + Email: qzhao@huawei.com + + + Julien Meuric + France Telecom + 2, avenue Pierre-Marzin + 22307 Lannion Cedex + France + + Email: julien.meuric@orange.com + + + Olivier Dugeon + France Telecom + 2, avenue Pierre-Marzin + 22307 Lannion Cedex + France + + Email: olivier.dugeon@orange.com + + + Jon Hardwick + Metaswitch Networks + 100 Church Street + Enfield + EN2 6BQ + United Kingdom + + Email: jonathan.hardwick@metaswitch.com + + + Óscar González de Dios + Telefonica I+D + Emilio Vargas 6 + Madrid + Spain + + Email: oscar.gonzalezdedios@telefonica.com + + +Authors' Addresses + + Daniel King + Old Dog Consulting + + Email: daniel@olddog.co.uk + + + Haomian Zheng + Huawei Technologies + H1, Huawei Xiliu Beipo Village, Songshan Lake + Dongguan + Guangdong, 523808 + China + + Email: zhenghaomian@huawei.com + + Additional contact information: + + 郑好棉 + 中国 + 523808 + 广东 东莞 + 松山湖华为溪流背坡村H1 + 华为技术有限公司 |