RFC 6805
The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS
RFC 6805 📜✨ (Part 1 of 7)
okay bestie, let's get into it 💖 RFC 6805 is called The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS 🎀. The editors are D. King and A. Farrel, both from Old Dog Consulting, and the doc is dated November 2012. It's marked Informational (so it's not a Standards Track spec 🙈) and its ISSN is 2070-1721. It doesn't obsolete or update any other RFCs, so it's a fresh little standalone. 🦋
Abstract ✨
okay so the big problem is that when you want the best route for an LSP across multiple domains in MPLS-TE and GMPLS networks, it's kinda messy 😭 because no single path computation point knows every link and resource in every domain. the fix people use is the Path Computation Element (PCE) architecture 🧚
when you already know the sequence of domains, there are a few techniques for finding the optimum path 💅. if the domains are simply connected, or if you already know which points of interconnection you prefer, you can use the Per-Domain Path Computation technique 🌸. and if there are multiple connections between domains but no preference for which one to use, the Backward-Recursive PCE-based Computation (BRPC) procedure can get you an optimal path 👑.
this document is about the harder case, where the sequence of domains is not known in advance 🔥. it shows how the PCE architecture can be extended so the optimum sequence of domains gets picked, and then the optimum end-to-end path gets derived using a hierarchical relationship between domains. main character energy for sure ✨
Status of This Memo ✨
okay, so this doc is not an Internet Standards Track specification. it's just published for information 🧚
this is a product of the Internet Engineering Task Force (IETF) 🌈. it represents the consensus of the IETF community, it's had public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🫶. not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the details 🙈.
for the current status, any errata, or how to send feedback, check http://www.rfc-editor.org/info/rfc6805 💜.
Copyright Notice ✨
the copyright is 2012 IETF Trust and the persons identified as the document authors 🎀. all rights are reserved.
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as they were on the publication date 💅. please actually read those, bestie, because they explain your rights and restrictions for this doc 🫶. and if you pull any Code Components out of this document, they need to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions. they also come with no warranty, as described in the Simplified BSD License 🔥.
Table of Contents 📑
1. Introduction ....................................................4
1.1. Problem Statement ..........................................5
1.2. Definition of a Domain .....................................5
1.3. Assumptions and Requirements ...............................6
1.3.1. Metric Objectives ...................................6
1.3.2. Diversity ...........................................7
1.3.2.1. Physical Diversity .........................7
1.3.2.2. Domain Diversity ...........................7
1.3.3. Existing Traffic Engineering Constraints ............7
1.3.4. Commercial Constraints ..............................8
1.3.5. Domain Confidentiality ..............................8
1.3.6. Limiting Information Aggregation ....................8
1.3.7. Domain Interconnection Discovery ....................8
1.4. Terminology ................................................8
2. Examination of Existing PCE Mechanisms ..........................9
2.1. Per-Domain Path Computation ................................9
2.2. Backward-Recursive PCE-Based Computation ..................10
2.2.1. Applicability of BRPC When the Domain Path
is Not Known .......................................11
3. Hierarchical PCE ...............................................12
4. Hierarchical PCE Procedures ....................................13
4.1. Objective Functions and Policy ............................13
4.2. Maintaining Domain Confidentiality ........................14
4.3. PCE Discovery .............................................14
4.4. Traffic Engineering Database for the Parent Domain ........15
4.5. Determination of Destination Domain .......................16
4.6. Hierarchical PCE Examples .................................16
4.6.1. Hierarchical PCE Initial Information Exchange ......18
4.6.2. Hierarchical PCE End-to-End Path
Computation Procedure ..............................19
4.7. Hierarchical PCE Error Handling ...........................20
4.8. Requirements for Hierarchical PCEP Protocol Extensions ....20
4.8.1. PCEP Request Qualifiers ............................21
4.8.2. Indication of Hierarchical PCE Capability ..........21
4.8.3. Intention to Utilize Parent PCE Capabilities .......21
4.8.4. Communication of Domain Connectivity Information ...22
4.8.5. Domain Identifiers .................................22
5. Hierarchical PCE Applicability .................................23
5.1. Autonomous Systems and Areas ..............................23
5.2. ASON Architecture .........................................24
5.2.1. Implicit Consistency between Hierarchical
PCE and G.7715.2 ...................................25
5.2.2. Benefits of Hierarchical PCEs in ASON ..............26
6. A Note on BGP-TE ...............................................26
6.1. Use of BGP for TED Synchronization ........................27
7. Management Considerations ......................................27
7.1. Control of Function and Policy ............................27
7.1.1. Child PCE ..........................................27
7.1.2. Parent PCE .........................................27
7.1.3. Policy Control .....................................28
7.2. Information and Data Models ...............................28
7.3. Liveness Detection and Monitoring .........................28
7.4. Verifying Correct Operation ...............................28
7.5. Impact on Network Operation ...............................29
8. Security Considerations ........................................29
9. Acknowledgements ...............................................30
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................31
11. Contributors ..................................................321. Introduction 🦋
okay so the ability to compute routes for end-to-end inter-domain MPLS-TE and GMPLS LSPs is written up as requirements in [RFC4105] and [RFC4216] 💖. a Path Computation Element (PCE) can make that happen 🧚. the PCE architecture itself is defined in [RFC4655], and the methods for setting up and controlling inter-domain MPLS-TE and GMPLS LSPs are in [RFC4726] 🌸.
so in this context, a domain is a separate administrative, geographic, or switching environment inside the network 🌈. it can also be described as a zone of routing or computational ability. under those definitions, a domain could be an Autonomous System (AS) or an Interior Gateway Protocol (IGP) area [RFC4726] [RFC4655] ✨. domains connect through ingress and egress boundary nodes (BNs) 🫶. there's a more detailed definition in Section 1.2, bestie 💅.
in a multi-domain setup, finding an end-to-end traffic engineered path is a problem, because no single path computation point knows all the links and resources in each domain 😭. PCEs can compute end-to-end paths with the per-domain path computation technique [RFC5152] 🎀. or there's the Backward-Recursive PCE-based Computation (BRPC) mechanism [RFC5441], which lets multiple PCEs team up to pick an optimal end-to-end path that crosses several domains 👑. but both of those assume you already know the sequence of domains from ingress to egress 🔥.
this document looks at how to find the optimum path when that sequence of domains is not known in advance 🧚. it shows how the PCE architecture can be extended to select the optimum sequence of domains and then derive the optimum end-to-end path 💜.
the model in this doc adds a hierarchical relationship between domains 🌈. it's a good fit for environments with small groups of domains where the ingress Label Switching Router (LSR) can't see much 👀. applying the hierarchical PCE model to big groups of domains like the Internet is not considered feasible or desirable, so that's out of scope 🙈.
this doc doesn't specify any protocol extensions or enhancements 💅. that work is left for future protocol specification documents. but it does make some assumptions about which protocols will provide specific functions, and it gives guidance to future protocol developers in the form of requirements statements 🫶.
1.1. Problem Statement ✨
using a PCE to compute a path between nodes in one single domain is pretty straightforward 🌸. but when the source and destination nodes are in different domains, you need multiple PCEs, each in charge of its own domain, to cooperate 🤝.
the inter-domain path computation techniques described so far ([RFC5152] and [RFC5441]) assume the sequence of domains from source to destination is already well known 😤. no explanation is given (for example, in [RFC4655]) of how that sequence is generated or what criteria should pick paths between domains 🙈. in small clusters of domains, like simple cooperation between adjacent ISPs, the selection process isn't complicated 💖. but in more advanced deployments (such as optical networks built from multiple sub-domains, or multi-AS environments), the choice of domains in the end-to-end sequence can be critical to finding an optimum end-to-end path 🔥👑.
1.2. Definition of a Domain
okay bestie, so [RFC4726] says a domain is any collection of network elements sitting under a common sphere of address management or path computational responsibility 🦋. Think IGP areas or Autonomous Systems. Wholly or partially overlapping domains are not within the scope of this document, so we're skipping those 🙈.
In GMPLS, the biggie example is the Automatically Switched Optical Network (ASON) subnetwork [G-8080] 🌈. Here a domain might be an ASON Routing Area [G-7715]. Also, computing an end-to-end path means picking nodes and links inside a routing area, and some of those nodes may actually be subnetworks 🧚. A PCE can perform the path computation function of an ASON Routing Controller, as described in [G-7715-2]. Check out Section 5.2 for more on how this fits the ASON architecture 💜.
This document assumes that choosing a sequence of domains for an end-to-end path is, in some sense, a hierarchical path computation problem 🎀. So one mechanism determines a path across a domain, and a separate mechanism (or at least a separate set of paradigms) determines the sequence of domains. The responsibility for selecting domain interconnection can belong to either or both of those mechanisms 👑.
1.3. Assumptions and Requirements
Networks are often built from multiple domains 🌸, and those domains are often interconnected through multiple interconnect points. It's assumed that the sequence of domains for an end-to-end path is not always well known. Like, an application asking for end-to-end connectivity has no preference for the sequence of domains, or no way to specify one 🙈.
The traffic engineering properties of a domain can't be seen from outside the domain 🔥. TE aggregation or abstraction hides info, and that can lead to failed path setup or the selection of suboptimal end-to-end paths [RFC4726]. Aggregation may also have big scaling issues for networks with lots of possible routes and multiple TE metrics 💀. Flooding TE info breaks confidentiality and doesn't scale in the routing protocol. See Section 6 for the inter-domain TE info exchange idea known as BGP-TE 🫶.
The main goal of this document is defining how to derive optimal end-to-end, multi-domain paths when the sequence of domains isn't known in advance 👑. The solution needs to be scalable and to keep internal domain topology confidential while still providing the optimal end-to-end path. It can't rely on exchanging TE info between domains, and for the confidentiality, scaling, and aggregation reasons just mentioned, it can't use a computation element that has universal knowledge of the TE properties and topology of all domains 😭.
The subsections below set out the primary objectives and requirements that a PCE solution for multi-domain path computation needs to satisfy 💖.
1.3.1. Metric Objectives
Optimality is dependent on policy and is based on a single objective or a group of objectives 💅. An objective is expressed as an objective function [RFC5541] and may be specified on a path computation request. The objective functions identified in this document define how path metrics and TE link qualities get manipulated during inter-domain path computation ✨. The list is not proscriptive and may be expanded in other documents 🌈.
- Minimize the cost of the path [RFC5541].
- Select a path using links with the minimal load [RFC5541].
- Select a path that leaves the maximum residual bandwidth [RFC5541].
- Minimize aggregate bandwidth consumption [RFC5541].
- Minimize the load of the most loaded link [RFC5541].
- Minimize the cumulative cost of a set of paths [RFC5541].
- Minimize or cap the number of domains crossed.
- Disallow domain re-entry.
See Section 4.1 for further discussion of objective functions 🦋.
1.3.2. Diversity
1.3.2.1. Physical Diversity
In a "Carrier's Carrier" environment, MPLS services may share common underlying equipment and resources, including optical fiber and nodes 🍓. An MPLS service request may require a path for traffic that is physically disjointed from another service. So if a physical link or node fails on one of the disjoint paths, not all traffic is lost ✨.
1.3.2.2. Domain Diversity
A pair of paths is domain-diverse if they don't transit any of the same domains. A pair of paths that share a common ingress and egress is domain-diverse if they only share the same domains at the ingress and egress (the ingress and egress domains) 🎀. Domain diversity may be maximized for a pair of paths by selecting paths that have the smallest number of shared domains. (Note that this is not the same as finding paths with the greatest number of distinct domains! 🙃)
Path computation should facilitate selecting paths that share ingress and egress domains but don't share any transit domains 💜. That reduces the risk of shared failure along any path and automatically helps ensure path diversity for most of the route of a pair of LSPs 🔥.
So domain path selection should provide the capability to include or exclude specific domains and specific boundary nodes 🌸.
1.3.3. Existing Traffic Engineering Constraints
Any solution should take advantage of typical traffic engineering constraints (hop count, bandwidth, lambda continuity, path cost, etc.) to meet the service demands expressed in the path computation request [RFC4655] 🧚.
1.3.4. Commercial Constraints
The solution should provide the capability to include commercially relevant constraints such as policy, Service Level Agreements (SLAs), security, peering preferences, and monetary costs 💅.
Additionally, it may be necessary for the service provider to request that specific domains are included or excluded based on commercial relationships, security implications, and reliability 🫶.
1.3.5. Domain Confidentiality
A key requirement is the ability to maintain domain confidentiality when computing inter-domain end-to-end paths 🤫. It should be possible for local policy to require that a PCE not disclose to any other PCE the intra-domain paths it computes or the internal topology of the domain it serves. This requirement should have no impact on the optimality or quality of the end-to-end path that is derived 🔐.
1.3.6. Limiting Information Aggregation
In order to reduce processing overhead and to not sacrifice computational detail, there should be no requirement to aggregate or abstract traffic engineering link information 🌷.
1.3.7. Domain Interconnection Discovery
To support domain mesh topologies, the solution should allow the discovery and selection of domain interconnections. Pre-configuration of preferred domain interconnections should also be supported for network operators that have bilateral agreements and a preference for the choice of points of interconnection 🌈.
1.4. Terminology
This document uses PCE terminology defined in [RFC4655], [RFC4726], and [RFC5440]. Additional terms are defined below 📚.
- Domain Path: The sequence of domains for a path.
- Ingress Domain: The domain that includes the ingress LSR of a path.
- Transit Domain: A domain that has an upstream and downstream neighbor domain for a specific path.
- Egress Domain: The domain that includes the egress LSR of a path.
- Boundary Nodes: Each Domain has entry LSRs and exit LSRs that could be Area Border Routers (ABRs) or Autonomous System Border Routers (ASBRs) depending on the type of domain. They are defined here more generically as Boundary Nodes (BNs).
- Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) on a path.
- Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) on a path.
- Parent Domain: A domain higher up in a domain hierarchy such that it contains other domains (child domains) and potentially other links and nodes.
- Child Domain: A domain lower in a domain hierarchy such that it has a parent domain.
- Parent PCE: A PCE responsible for selecting a path across a parent domain and any number of child domains by coordinating with child PCEs and examining a topology map that shows domain interconnectivity.
- Child PCE: A PCE responsible for computing the path across one or more specific (child) domains. A child PCE maintains a relationship with at least one parent PCE.
- Objective Function (OF): A set of one or more optimization criteria used for the computation of a single path (e.g., path cost minimization), or the synchronized computation of a set of paths (e.g., aggregate bandwidth consumption minimization). See [RFC4655] and [RFC5541].
2. Examination of Existing PCE Mechanisms
This section gives a brief overview of two existing PCE cooperation mechanisms, the Per-Domain Path Computation method and the BRPC method 🌷. It describes how these methods apply to the multi-domain problem 🔍.
2.1. Per-Domain Path Computation
The Per-Domain Path Computation method for establishing inter-domain TE-LSPs [RFC5152] defines a technique where the path gets computed during the signaling process on a per-domain basis 🚂. The entry BN of each domain is responsible for performing the path computation for the section of the LSP that crosses the domain, or for requesting that a PCE for that domain computes that piece of the path.
During per-domain path computation, each computation results in a path that crosses the domain to provide connectivity to the next domain in the sequence. The chosen path across the domain will be selected as best according to the optimization characteristics of the computation 💫. The next domain in the sequence is usually indicated in signaling by an identifier of the next domain or the identity of the next entry BN.
Per-domain path computation may lead to suboptimal end-to-end paths because the most optimal path in one domain may lead to the choice of an entry BN for the next domain that results in a very poor path across that next domain 😬.
In the case that the domain path (in particular, the sequence of boundary nodes) is not known, the path computing entity must select an exit BN based on some determination of how to reach the destination that is outside the domain for which the path computing entity has computational responsibility. [RFC5152] suggest that this might be achieved using the IP shortest path as advertised by BGP. Note, however, that the existence of an IP forwarding path does not guarantee the presence of sufficient bandwidth, let alone an optimal TE path. Furthermore, in many GMPLS systems, inter-domain IP routing will not be present. Thus, per-domain path computation may require a significant number of crankback routing attempts to establish even a suboptimal path 🙃.
Note also that the path computing entities in each domain may have different computation capabilities, may run different path computation algorithms, and may apply different sets of constraints and optimization criteria, etc.
This can result in the end-to-end path being inconsistent and suboptimal 💔.
Per-domain path computation can suit simply connected domains where the preferred points of interconnection are known ✨.
2.2. Backward-Recursive PCE-Based Computation 🦋
okay so the Backward-Recursive PCE-based Computation (BRPC) [RFC5441] procedure is all about PCEs working together to find an optimal end-to-end path across multiple domains 🤝✨ The sequence of domains can be figured out before or during the path computation. When the sequence is already known, the ingress Path Computation Client (PCC) sends a path computation request to the PCE in charge of the ingress domain 💌 That request gets passed along between PCEs, domain-by-domain, until it reaches the PCE for the egress domain 🚶♀️
Here's the iconic part 💅 The egress PCE builds a set of optimal paths from all of the domain entry BNs to the egress LSR. That set is shown as a tree of potential paths called a Virtual Shortest Path Tree (VSPT), and the egress PCE sends it back to the previous PCE on the domain path. As the VSPT travels back toward the ingress domain, each PCE works out the optimal paths from its entry BNs to its exit BNs that hook up to the rest of the tree 🌳 It adds those paths to the VSPT and passes it on. Once the VSPT reaches the PCE for the ingress domain, that PCE computes paths from the ingress LSR to connect to the rest of the tree. Then the ingress PCE picks the optimal end-to-end path out of the tree and sends it back to the PCC that started the whole thing 🎀
BRPC may suit environments where there are multiple connections between domains and no preference for which points of interconnection to use 🌸 It's best suited to scenarios where the domain path is known in advance, but it can also be used when the domain path is not known 🧚
2.2.1. Applicability of BRPC When the Domain Path is Not Known 🔍
okay so we already know BRPC can find an optimal inter-domain path when the domain sequence is known. But even when the sequence of domains is not known, BRPC could be used like this:
- The PCC sends a request to a PCE for the ingress domain (the ingress PCE). 📨
- The ingress PCE sends the path computation request direct to a PCE responsible for the domain containing the destination node (the egress PCE). 🎯
- The egress PCE computes an egress VSPT and passes it to a PCE responsible for each of the adjacent (potentially upstream) domains. 🌊
- Each PCE in turn constructs a VSPT and passes it on to all of its neighboring PCEs. 🫠
- When the ingress PCE has received a VSPT from each of its neighboring domains, it is able to select the optimum path. 👑
Clearly, this mechanism (which could be called path computation flooding) has significant scaling issues 😭 It could be improved by the application of policy and filtering, but such mechanisms are not simple and would still leave scaling concerns 💀
3. Hierarchical PCE 🧚♀️
okay so in the hierarchical PCE architecture, a parent PCE keeps a domain topology map. That map has the child domains (seen as vertices in the topology) and their interconnections (links in the topology) 🗺️ The parent PCE has zero info about what's inside the child domains 🙈 It doesn't know the resource availability within the child domains, and it doesn't know the availability of connectivity across each domain either. Why? Because that would break the confidentiality requirement, and either it would need full info flooded up to the parent (a scaling issue) or it would need some form of aggregation 😤 The parent PCE does know the TE capabilities of the interconnections between child domains, since those interconnections are links in its own topology map ✨
Note that, when the domains are IGP areas, there is no link between the domains (the ABRs have a presence in both neighboring areas) 🦋 The parent domain may choose to represent this in its Traffic Engineering Database (TED) as a virtual link that is unconstrained and has zero cost, but this is entirely an implementation issue 💅
Each child domain has at least one PCE capable of computing paths across the domain. These PCEs are known as child PCEs and they have a relationship with the parent PCE 🫶 Each child PCE also knows the identity of the domains that neighbor its own domain. A child PCE only knows the topology of the domain it serves and does not know the topology of other child domains. Child PCEs are also not aware of the general domain mesh connectivity (i.e., the domain topology map) beyond the connectivity to the immediate neighbor domains of the domain it serves 🔒
The parent PCE builds the domain topology map either from configuration or from information received from each child PCE. This tells it how the domains are interconnected, including the TE properties of the domain interconnections 🌈 But the parent PCE still does not know the contents of the child domains. Discovery of the domain topology and domain interconnections is discussed further in Section 4.3 🔎
When a multi-domain path is needed, the ingress PCE sends a request to the parent PCE (using the Path Computation Element Protocol, PCEP [RFC5440]) 📬 The parent PCE selects a set of candidate domain paths based on the domain topology and the state of the inter-domain links. Then it sends computation requests to the child PCEs responsible for each of the domains on the candidate domain paths. These requests may be sequential or parallel depending on implementation details ⚡
Each child PCE computes a set of candidate path segments across its domain and sends the results to the parent PCE. The parent PCE uses this info to select path segments and concatenate them to derive the optimal end-to-end inter-domain path 🧩 The end-to-end path is then sent to the child PCE that received the initial path request, and that child PCE passes the path on to the PCC that issued the original request 🎀
Specific deployment and implementation scenarios are out of scope of this document. However, the hierarchical PCE architecture described does support the function of parent PCE and child PCE being implemented as a common PCE 💜
4. Hierarchical PCE Procedures 🎀
4.1. Objective Functions and Policy 👑
okay so the definition of "optimal" when you're deriving an optimal end-to-end path depends on the choices made during path selection 🎯 An Objective Function (OF) [RFC5541], or a set of OFs, specifies the intentions of the path computation, and that's what defines the "optimality" for that computation ✨
An OF specifies the desired outcome of a computation. It doesn't describe or demand the algorithm to use, and an implementation may apply any algorithm or set of algorithms to achieve the result the OF indicates 🧠 OFs can be included in PCEP computation requests to satisfy the policies encoded or configured at the PCC. A PCE may be subject to policy when deciding whether it meets the OFs included in the computation request, or whether it applies its own OFs 🫠
In 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 different policy 🌸
When computing end-to-end paths, OFs may include (see Section 1.3.1):
- Minimum cost path
- Minimum load path
- Maximum residual bandwidth path
- Minimize aggregate bandwidth consumption
- Minimize or cap the number of transit domains
- Disallow domain re-entry
The objective function may be requested by the PCC, the ingress domain PCE (according to local policy), or applied by the parent PCE according to inter-domain policy 🧚
More than one OF (or a composite OF) may be chosen to apply to a single computation, provided they are not contradictory. Composite OFs may include weightings and preferences for the fulfillment of pieces of the desired outcome ⚖️
4.2. Maintaining Domain Confidentiality 🔒
Information about the content of child domains is not shared, for scaling and confidentiality reasons 🙊 This means that a parent PCE is aware of the domain topology and the nature of the connections between domains, but it is not aware of the content of the domains. Similarly, a child PCE cannot know the internal topology of another child domain. Child PCEs also don't know the general domain mesh connectivity, since that info is only known by the parent PCE 🫣
As described in the earlier sections of this document, PCEs can exchange path information in order to construct an end-to-end inter-domain path. Each per-domain path fragment reveals info about the topology and resource availability within a domain. Some management domains or ASes will not want to share this info outside of the domain (even with a trusted parent PCE) 😤 To conceal it, a PCE may replace a path segment with a path-key [RFC5520]. This mechanism effectively hides the content of a segment of a path 🦋
4.3. PCE Discovery 🔎
It's a simple matter for each child PCE to be configured with the address of its parent PCE. Typically, there will only be one or two parents of any child 🫶
The parent PCE also needs to be aware of the child PCEs for all child domains that it can see. This info is most likely to be configured (as part of the administrative definition of each domain) 📋
Discovery of the relationships between parent PCEs and child PCEs does not form part of the hierarchical PCE architecture. Mechanisms that rely on advertising or querying PCE locations across domain or provider boundaries are undesirable for security, scaling, commercial, and confidentiality reasons 🚫
The parent PCE also needs to know the inter-domain connectivity. This info could be configured with suitable policy and commercial rules, or it could be learned from the child PCEs as described in Section 4.4 🌈
In order for the parent PCE to learn about domain interconnection, the child PCE will report the identity of its neighbor domains. The IGP in each neighbor domain can advertise its inter-domain TE link capabilities [RFC5316] [RFC5392]. This info can be collected by the child PCEs and forwarded to the parent PCE, or the parent PCE could participate in the IGP in the child domains 💖
4.4. Traffic Engineering Database for the Parent Domain 🗺️
okay so the parent PCE keeps a domain topology map of the child domains and how they connect to each other 💅. If the inter-domain connections are TE links, the parent PCE may also know what those links can do. It builds its own TED for the parent domain the same way any PCE does ✨
The parent domain can be just the child domains plus how they're connected 🧩. It can also include the details of the inter-domain TE links, and it can have its own nodes and links too. It's giving flexible 🎀
Building the parent TED is probably going to lean heavily on admin configuration and business stuff, because the network got split into domains in the first place to deal with exactly those issues 💼
Now here's the tea 🫖 Some info can get passed up from the child domains to the parent PCE so it can build that TED. In theory, the parent PCE could just listen to the routing protocols in the child domains 🙈 but that would break the confidentiality and scaling principles that probably caused the network to be split up in the first place 😭 So it's way more likely that a solution has a child entity (like the child PCE) send over the specific info it needs. Like we said, the "necessary information" is about how the child domains connect to each other 🔗. The topology and available resources inside a child domain don't need to go to the parent PCE, because that would break the PCE architecture 🚫
Reporting mechanisms are shown in the examples in Section 4.6, where a child PCE "reports its neighbor domain connectivity to its parent PCE" (very abstract, on purpose 🙃). The specifics of a solution are out of scope for this doc, but the requirements are listed in Section 4.8. See Section 6 for a quick look at BGP-TE 🦋
In models like ASON (see Section 5.2), you can imagine a separate instance of an IGP running inside the parent domain 🧚. The participating speakers would be the nodes directly in that domain plus the PCEs (Routing Controllers) for each child domain 👑
4.5. Determination of Destination Domain 📍
So the PCC asking for an inter-domain path computation already knows who the destination node is, by definition 💖 If it also knows the egress domain, it can include that in the path computation request. But if it doesn't know the egress domain, then the child PCE has to know it, or the parent PCE has to know or figure it out 🤔
In some specialist topologies, the parent PCE could work out the destination domain from the destination address, for example from configuration 🧠 But that's not a great fit for lots of multi-domain addressing setups 😬 In IP-based multi-domain networks, the parent PCE might be able to find the destination domain by taking part in inter-domain routing 🌐 And finally, the parent PCE could send specific requests to the child PCEs asking if they contain the destination node. Honestly though, that has scaling implications 💀
For this document, the exact way to discover the destination domain is out of scope 🙅♀️ Just know that for every multi-domain path computation, some mechanism will be needed to find where the destination is 📌
4.6. Hierarchical PCE Examples 🌸
The following example describes a generic hierarchical domain topology ✨ Figure 1 shows four interconnected domains sitting inside a fifth, parent domain. Each domain has a single PCE 🎀
- Domain 1 is the ingress domain, and child PCE 1 can compute paths within it 🚀 Its neighbors are Domain 2 and Domain 4. The domain also has the source LSR (S) and three egress boundary nodes (BN11, BN12, and BN13).
- Domain 2 is served by child PCE 2 🧁 Its neighbors are Domain 1 and Domain 3. It also has four boundary nodes (BN21, BN22, BN23, and BN24).
- Domain 3 is the egress domain and is served by child PCE 3 🦩 Its neighbors are Domain 2 and Domain 4. It also has the destination LSR (D) and three ingress boundary nodes (BN31, BN32, and BN33).
- Domain 4 is served by child PCE 4 🍓 Its neighbors are Domain 2 and Domain 3. It also has two boundary nodes (BN41 and BN42).
All of these domains are inside Domain 5, which is served by the parent PCE (PCE 5) 👑
-----------------------------------------------------------------
| Domain 5 |
| ----- |
| |PCE 5| |
| ----- |
| |
| ---------------- ---------------- ---------------- |
| | Domain 1 | | Domain 2 | | Domain 3 | |
| | | | | | | |
| | ----- | | ----- | | ----- | |
| | |PCE 1| | | |PCE 2| | | |PCE 3| | |
| | ----- | | ----- | | ----- | |
| | | | | | | |
| | ----| |---- ----| |---- | |
| | |BN11+---+BN21| |BN23+---+BN31| | |
| | - ----| |---- ----| |---- - | |
| | |S| | | | | |D| | |
| | - ----| |---- ----| |---- - | |
| | |BN12+---+BN22| |BN24+---+BN32| | |
| | ----| |---- ----| |---- | |
| | | | | | | |
| | ---- | | | | ---- | |
| | |BN13| | | | | |BN33| | |
| -----------+---- ---------------- ----+----------- |
| \ / |
| \ ---------------- / |
| \ | | / |
| \ |---- ----| / |
| ----+BN41| |BN42+---- |
| |---- ----| |
| | | |
| | ----- | |
| | |PCE 4| | |
| | ----- | |
| | | |
| | Domain 4 | |
| ---------------- |
| |
-----------------------------------------------------------------Figure 1: Sample Hierarchical Domain Topology
Figure 2 shows the view of the domain topology as the parent PCE (PCE 5) sees it 👀 This is an abstracted topology. PCE 5 knows how the domains connect, but it doesn't know the internal topology inside each domain 🫶
----------------------------
| Domain 5 |
| ---- |
| |PCE5| |
| ---- |
| |
| ---- ---- ---- |
| | |---| |---| | |
| | D1 | | D2 | | D3 | |
| | |---| |---| | |
| ---- ---- ---- |
| \ ---- / |
| \ | | / |
| ----| D4 |---- |
| | | |
| ---- |
| |
----------------------------Figure 2: Abstract Domain Topology as Seen by the Parent PCE
4.6.1. Hierarchical PCE Initial Information Exchange 🤝
Based on the topology in Figure 1, here's how the initial hierarchical PCE information exchange goes 🧃
- Child PCE 1, the PCE responsible for Domain 1, is configured with the location of its parent PCE (PCE 5) 📬
- Child PCE 1 establishes contact with its parent PCE. The parent applies policy to make sure communication with PCE 1 is allowed 🔐
- Child PCE 1 listens to the IGP in its domain and learns its inter-domain connectivity. That is, it learns about the links BN11-BN21, BN12-BN22, and BN13-BN41 👂
- Child PCE 1 reports its neighbor domain connectivity to its parent PCE 📣
- Child PCE 1 reports any change in the resource availability on its inter-domain links to its parent PCE 🔄
Each child PCE does steps 1 through 5, so the parent PCE can build the domain topology view shown in Figure 2 🦋✨
4.6.2. Hierarchical PCE End-to-End Path Computation Procedure ✨
okay bestie, this is an example of a source PCC asking for an end-to-end path across a multi-domain setup 🌸 The topology is in Figure 1. We're assuming that each child PCE has already connected to its parent PCE and swapped the initial info the parent needs to build its domain topology view, like we covered in Section 4.6.1 🫶
- The source PCC (the ingress LSR in our example) sends a request to the PCE responsible for its domain (PCE 1) asking for a path to the destination LSR (D) 💖
- PCE 1 figures out that the destination is not in domain 1 🙈
- PCE 1 sends a computation request up to its parent PCE (PCE 5) 🦋
- The parent PCE determines that the destination is in Domain 3. (See Section 4.5.) 🧚
- PCE 5 works out the likely domain paths based on domain interconnectivity and the TE capabilities between the domains. For example, if the link BN12-BN22 isn't suitable for the requested path, three domain paths come out of it 💅
S-BN11-BN21-D2-BN23-BN31-D
S-BN11-BN21-D2-BN24-BN32-D
S-BN13-BN41-D4-BN42-BN33-D- PCE 5 sends edge-to-edge path computation requests to PCE 2, which handles Domain 2 (that's BN21-to-BN23 and BN21-to-BN24), and to PCE 4 for Domain 4 (that's BN41-to-BN42) ✨
- PCE 5 sends source-to-edge path computation requests to PCE 1, which handles Domain 1 (that's S-to-BN11 and S-to-BN13) 🎀
- PCE 5 sends edge-to-egress path computation requests to PCE 3, which handles Domain 3 (that's BN31-to-D, BN32-to-D, and BN33-to-D) 🍓
- PCE 5 pulls together all the computation responses from each child PCE, adds in the info about the inter-domain links, and applies any requested and locally configured policies 🔥
- PCE 5 then picks the optimal end-to-end multi-domain path that meets the policies and objective functions, and passes the resulting path to PCE 1 👑
- PCE 1 forwards the path to the PCC (the ingress LSR) 🦋
Note that there is no requirement for steps 6, 7, and 8 to be carried out in parallel or in series. Honestly they could even overlap with step 5. That's an implementation issue 💜
4.7. Hierarchical PCE Error Handling 😭
So what happens if a child PCE in a domain can't find a suitable path to the egress? Then that child PCE should send back the relevant error to notify the parent PCE. Depending on the error, the parent PCE picks one of these moves:
- Cancel the request and send the relevant response back to the initial child PCE that asked for the end-to-end path;
- Relax some of the constraints tied to the initial path request; or
- Select another candidate domain and send the path request to the child PCE responsible for that domain.
If the parent PCE doesn't hear back from a child PCE within an allotted time period, the parent PCE can elect to:
- Cancel the request and send the relevant response back to the initial child PCE that asked for the end-to-end path;
- Send the path request to another child PCE in the same domain, if a secondary child PCE exists; or
- Select another candidate domain and send the path request to the child PCE responsible for that domain.
The parent PCE may also want to prune any unresponsive child PCE domain paths from the candidate set 🧹
4.8. Requirements for Hierarchical PCEP Protocol Extensions 📋
This section lists the high-level requirements for extensions to the PCEP that support the hierarchical PCE model. It's here to give guidance to PCEP protocol developers so they can design a solution that works well in a hierarchical PCE framework 🫶
4.8.1. PCEP Request Qualifiers 🎀
PCReq messages are how a PCC or a PCE makes a computation request or enquiry to a PCE. The requests are qualified so the PCE knows what kind of action is needed 💅
Supporting the hierarchical PCE architecture brings in two new qualifications:
- It must be possible for a child PCE to indicate that the response it receives from the parent PCE should consist of a domain sequence only (i.e., not a fully specified end-to-end path). This lets the child PCE kick off Per-Domain or BRPC. iykyk 💜
- A parent PCE may need to be able to ask a child PCE whether a particular node address (the destination of an end-to-end path) is present in the domain that the child PCE serves.
In PCEP, these request qualifications are carried as bit flags in the RP object (Request Parameter object) within the PCReq message 🔥
4.8.2. Indication of Hierarchical PCE Capability 🌈
Parent/child PCE relationships are probably configured, but it'll help network operations a lot if the parent PCE can tell the child that it really is capable of acting as a parent PCE. That way, misconfigurations get caught early 🚨
In PCEP, these capabilities are carried in the Open Object within the Open message ✨
4.8.3. Intention to Utilize Parent PCE Capabilities 🦋
A PCE that's capable of acting as a parent PCE might not be configured or willing to be the parent for a specific child PCE. This can be figured out when the child sends a PCReq that needs parental activity (like querying other child PCEs). The result could be a negative response in a PCEP Error (PCErr) message 😭
BUT the expense of a poorly targeted PCReq can be avoided if the child PCE indicates that it might wish to use the parent-capable PCE as a parent (for example, in the Open message), and the parent-capable PCE decides right then whether it's willing to act as a parent to this child. Smart, right? 🧠
4.8.4. Communication of Domain Connectivity Information 🌸
Section 4.4 explains that the parent PCE needs a parent TED, and that the info could come from the child PCEs in each domain. This needs a way for a child PCE to hand over info about inter-domain links to the parent PCE, for example in a PCEP Notify (PCNtf) message 💖
The info that would be exchanged includes:
- Identifier of advertising child PCE
- Identifier of PCE's domain
- Identifier of the link
- TE properties of the link (metrics, bandwidth)
- Other properties of the link (technology-specific)
- Identifier of link endpoints
- Identifier of adjacent domain
It may be desirable for this info to be updated periodically, for example when available bandwidth changes. In that case, the parent PCE might be given the ability to configure thresholds in the child PCE to prevent flapping of information 🦋
4.8.5. Domain Identifiers 🍓
Domain identifiers are already in PCEP so a PCE can say which domains it serves, and so domains can be represented as abstract nodes in paths. Using domains in more places within PCEP message objects is going to be needed for this hierarchical PCE work, and that should pose no problems ✨
Still, more attention may need to go into how precisely domain identifiers are defined, so it's always possible to unambiguously identify a domain from its identifier. This work is needed for configuration and for protocol specifications too. For example, an OSPF area identifier is enough within an Autonomous System, but it gets ambiguous in a path that crosses multiple Autonomous Systems 🙈
5. Hierarchical PCE Applicability 🌈
As per [RFC4655], PCE can inherently support inter-domain path computation for any definition of a domain set out in Section 1.2 of this document 💅
Hierarchical PCE can be applied to inter-domain environments, including Autonomous Systems and IGP areas. The hierarchical PCE procedures make no distinction between Autonomous Systems and IGP area applications. It's worth noting, though, that the TED maintained by a parent PCE must be able to support the concept of child domains connected by inter-domain links or directly connected at boundary nodes (see Section 3) 🫶
This section sets out the applicability of hierarchical PCE to three environments:
- MPLS traffic engineering across multiple Autonomous Systems
- MPLS traffic engineering across multiple IGP areas
- GMPLS traffic engineering in the ASON architecture
5.1. Autonomous Systems and Areas 🎀
Networks are made up of domains. A domain can be thought of as a collection of network elements within an AS or area that has a common sphere of address management or path computational responsibility 💖
As networks get bigger and more complicated, it may be required to bring in scaling methods that reduce the amount of information flooded within the network and keep it 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 a router's visibility to information about links and other routers within its single area. So if a router needs to compute a route to a destination located in another area, a method is required to compute a path across the area boundary 🧚
When an LSR within an AS or area needs to compute a path across an area or AS boundary, it must also use an inter-AS computation technique. Hierarchical PCE is equally applicable to computing inter-area and inter-AS MPLS and GMPLS paths across domain boundaries 🦋
5.2. ASON Architecture 🦋
okay so the ITU defines the ASON architecture in [G-8080] 💅. Then [G-7715] defines the routing architecture for ASON and introduces a hierarchical architecture, and it's giving layers. In this setup, 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. Note that the RA hierarchy can be recursive 🌀.
In the ASON framework, a path computation request is called a Route Query ✨. This query runs before signaling gets used to set up an LSP called a Switched Connection (SC) or a Soft Permanent Connection (SPC). [G-7715-2] defines the requirements and architecture for the functions that Routing Controllers (RCs) perform during remote route queries. An RC is synonymous with a PCE 🧚. For an end-to-end connection, the route may be computed by a single RC or by multiple RCs working together in a collaborative way (i.e., RC federations). In the case of RC federations, [G-7715-2] describes three styles during remote route query operation:
- step-by-step remote path computation
- hierarchical remote path computation
- a combination of the above.
In a hierarchical ASON routing environment, a child RC may communicate with its parent RC (at the next higher level of the ASON routing hierarchy) to request the computation of an end-to-end path across several RAs. It does this using a route query message (known as the abstract message RI_QUERY). The corresponding parent RC may communicate with other child RCs that belong to other child RAs at the next lower hierarchical level. Thus, a parent RC can act as either a Route Query Requester or Route Query Responder. It's giving flexible 💖.
It can be seen that the hierarchical PCE architecture fits the hierarchical ASON routing architecture really well 🎀. It can be used to provide paths across subnetworks and to determine end-to-end paths in networks constructed from multiple subnetworks or RAs.
When hierarchical PCE is applied to implement hierarchical remote path computation in [G-7715-2], it is very important for operators to understand the different terminology and implicit consistency between hierarchical PCE and [G-7715-2] 🫶.
5.2.1. Implicit Consistency between Hierarchical PCE and G.7715.2
This section highlights the correspondence between features of the hierarchical PCE architecture and the ASON routing architecture. Let's go 🌈.
(1) RC (Routing Controller) and PCE (Path Computation Element)
[G-8080] describes the Routing Controller component as an abstract entity, which is responsible for responding to requests for path (route) information and topology information. It can be implemented as a single entity, or as a distributed set of entities that make up a cooperative federation.
[RFC4655] describes PCE (Path Computation Element) as an entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
Therefore, in the ASON architecture, a PCE can be regarded as a realization of the RC. Same energy, different name 💜.
(2) Route Query Requester/Route Query Responder and PCC/PCE
[G-7715-2] describes the Route Query Requester as a Connection Controller or Routing Controller that sends a route query message to a Routing Controller requesting one or more paths that satisfy a set of routing constraints. The Route Query Responder is a Routing Controller that performs path computation upon receipt of a route query message from a Route Query Requester, sending a response back at the end of the path computation.
In the context of ASON, a Signaling Controller initiates and processes signaling messages and is closely coupled to a Signaling Protocol Speaker. A Routing Controller makes routing decisions and is usually coupled to configuration entities and/or a Routing Protocol Speaker.
It can be seen that a PCC corresponds to a Route Query Requester, and a PCE corresponds to a Route Query Responder. A PCE/RC can also act as a Route Query Requester sending requests to another Route Query Responder 🔥.
The Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages between PCC and PCE correspond to the RI_QUERY and RI_UPDATE messages in [G-7715-2].
(3) Routing Area Hierarchy and Hierarchical Domain
The ASON routing hierarchy model is shown in Figure 6 of [G-7715] through an example that illustrates routing area levels. If the hierarchical remote path computation mechanism of [G-7715-2] is applied in this scenario, each routing area should have at least one RC to perform the route query function, and the child RCs within the area should have a parent RC.
According to [G-8080], the parent RC has visibility of the structure of the lower level, so it knows the interconnectivity of the RAs in the lower level. Each child RC can compute edge-to-edge paths across its own child RA.
Thus, an RA corresponds to a domain in the PCE architecture, and the hierarchical relationship between RAs corresponds to the hierarchical relationship between domains in the hierarchical PCE architecture. Furthermore, a parent PCE in a parent domain can be regarded as a parent RC in a higher routing level, and a child PCE in a child domain can be regarded as a child RC in a lower routing level 👑.
5.2.2. Benefits of Hierarchical PCEs in ASON
RCs in an ASON environment can use the hierarchical PCE model to fully match the ASON hierarchical routing model, so the hierarchical PCE mechanisms can be applied to fully satisfy the architecture and requirements of [G-7715-2] without any changes. If the hierarchical PCE mechanism is applied in ASON, it can be used to determine end-to-end optimized paths across subnetworks and RAs before initiating signaling to create the connection. It can also improve the efficiency of connection setup to avoid crankback 🦋✨.
6. A Note on BGP-TE 🌸
The concept of exchange of TE information between Autonomous Systems (ASes) is discussed in [BGP-TE]. 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.
There are a number of discussion points associated with the use of [BGP-TE] concerning the volume of information, the rate of churn of information, the confidentiality of information, the accuracy of aggregated or potential-connectivity information, and the processing required to generate aggregated information. The PCE architecture and the architecture enabled by [BGP-TE] make different assumptions about the operational objectives of the networks, and this document does not attempt to make one of the approaches "right" and the other "wrong". Instead, this work assumes that a decision has been made to utilize the PCE architecture 🤷♀️💅.
6.1. Use of BGP for TED Synchronization
Indeed, [BGP-TE] may have some uses within the PCE model. For example, [BGP-TE] could be used as a "northbound" TE advertisement such that a PCE does not need to listen to an IGP in its domain, but has its TED populated by messages received (for example) from a Route Reflector. Furthermore, the inter-domain connectivity and capabilities that are required information for a parent PCE could be obtained as a filtered subset of the information available in [BGP-TE]. This scenario is discussed further in [PCE-AREA-AS] 🧚.
7. Management Considerations 🎀
General PCE management considerations are discussed in [RFC4655]. In the case of the hierarchical PCE architecture, there are additional management considerations.
The administrative entity responsible for the management of the parent PCEs must be determined. In the case of multi-domains (e.g., IGP areas or multiple ASes) within a single service provider network, the management responsibility for the parent PCE would most likely be handled by the service provider. In the case of multiple ASes within different service provider networks, it may be necessary for a third party to manage the parent PCEs according to commercial and policy agreements from each of the participating service providers 🍓.
7.1. Control of Function and Policy
7.1.1. Child PCE
Support of the hierarchical procedure will be controlled by the management organization responsible for each child PCE. A child PCE must be configured with the address of its parent PCE in order for it to interact with its parent PCE. The child PCE must also be authorized to peer with the parent PCE 🔐.
7.1.2. Parent PCE
The parent PCE must only accept path computation requests from authorized child PCEs. If a parent PCE receives requests from an unauthorized child PCE, the request should be dropped 🚫.
This means that a parent PCE must be configured with the identities and security credentials of all of its child PCEs, or there must be some form of shared secret that allows an unknown child PCE to be authorized by the parent PCE 🗝️.
7.1.3. Policy Control
It may be necessary to maintain a policy module on the parent PCE [RFC5394]. This would allow the parent PCE to apply commercially relevant constraints such as SLAs, security, peering preferences, and monetary costs.
It may also be necessary for the parent PCE to limit end-to-end path selection by including or excluding specific domains based on commercial relationships, security implications, and reliability 💅.
7.2. Information and Data Models
A PCEP MIB module is defined in [PCEP-MIB] that describes managed objects for modeling of PCEP communication. An additional PCEP MIB 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, and
- notification of parent PCE TED updates and changes.
7.3. Liveness Detection and Monitoring
The hierarchical procedure requires interaction with multiple PCEs. Once a child PCE requests an end-to-end path, a sequence of events occurs that requires interaction between the parent PCE and each child PCE. If a child PCE is not operational, and an alternate transit domain is not available, then a failure must be reported 🚨.
7.4. Verifying Correct Operation
Verifying the correct operation of a parent PCE can be performed by monitoring a set of parameters. The parent PCE implementation should provide the following parameters monitored by the parent PCE:
- number of child PCE requests,
- number of successful hierarchical PCE procedures completions on a per-PCE-peer basis,
- number of hierarchical PCE procedure completion failures on a per-PCE-peer basis, and
- number of hierarchical PCE procedure requests from unauthorized child PCEs.
7.5. Impact on Network Operation
The hierarchical PCE procedure is a multiple-PCE path computation scheme. Subsequent requests to and from the child and parent PCEs do not differ from other path computation requests and should not have any significant impact on network operations 🌈💖.
8. Security Considerations ✨
okay so bestie, this section is SERIOUS but also kinda iconic 💅 The hierarchical PCE procedure leans on PCEP and inherits all the security requirements from [RFC5440]. 🔐 As we saw back in Section 7, child and parent PCEs have a security relationship. Like any PCEP relationship, this one assumes the identities, authority, and keys are pre-configured, or it can work through any key distribution mechanism that lives outside PCEP. And since PCEP runs over TCP, it MAY make use of any TCP security mechanism. 🦋
The hierarchical PCE architecture uses PCE policy [RFC5394] and the security aspects of the PCE Communication Protocol written up in [RFC5440]. 🎀 It is expected that the parent PCE will REQUIRE all child PCEs to use full security when they talk to the parent. Security is maintained by not supporting discovery of child PCEs by a parent. 🙈 The parent is not going to go looking for its children, no thank you!
Okay, now the TED part, which is lowkey where things get spicy 🌶️ PCE operation depends on the information used to build the TED. Attacks on a PCE system can happen by falsifying this info or blocking its flow. 😭 The child PCE TEDs are built as described in [RFC4655] and are UNCHANGED in this document. If the PCE listens to the IGP for this information, normal IGP security measures MAY be applied. Also worth noting: an IGP routing system is generally assumed to be a trusted domain, so router subversion is not considered a risk. 🫶 The parent PCE TED is built as described in this document and may involve:
- multiple parent-child relationships using PCEP (as already described)
- the parent PCE listening to child domain IGPs (with the same security features as a child PCE listening to its IGP)
- an external mechanism (such as [BGP-TE]), which will need to be authorized and secured. 🔒
Any multi-domain operation necessarily involves exchanging information across domain boundaries. 💀 This is bound to be a significant security and confidentiality risk, especially when the child domains are controlled by different commercial companies. PCEP lets individual PCEs keep their domain path information confidential using path-keys [RFC5520], and the hierarchical PCE architecture is specifically designed to isolate domain topology and capabilities information as much as possible. 👑 Isolation is literally the whole vibe!
For further considerations of security issues related to inter-AS path computation, see [RFC5376]. 🌈
9. Acknowledgements 🫶
The authors would like to thank David Amzallag, Oscar Gonzalez de Dios, Franz Rambach, Ramon Casellas, Olivier Dugeon, Filippo Cugini, Dhruv Dhody, and Julien Meuric for their comments and suggestions. 💜 Thank you, queens!
10. References 📚
10.1. Normative References
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC
4655, August 2006.
[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.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394,
December 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.10.2. Informative References
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle,
Ed., "Requirements for Inter-Area MPLS Traffic
Engineering", RFC 4105, June 2005.
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
Autonomous System (AS) Traffic Engineering (TE)
Requirements", RFC 4216, November 2005.
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
Framework for Inter-Domain Multiprotocol Label
Switching Traffic Engineering", RFC 4726, November
2006.
[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.
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
Requirements for the Path Computation Element
Communication Protocol (PCECP)", RFC 5376, November
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.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, June 2009.
[G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for
the automatically switched optical network (ASON).
[G-7715] ITU-T Recommendation G.7715 (2002), Architecture and
Requirements for the Automatically Switched Optical
Network (ASON).
[G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing
architecture and requirements for remote route query.
[BGP-TE] Gredler, H., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", Work in Progress, October 2012.
[PCE-AREA-AS] King, D., Meuric, J., Dugeon, O., Zhao, Q., Gonzalez de
Dios, O., and F. Chico, "Applicability of the Path
Computation Element to Inter-Area and Inter-AS MPLS and
GMPLS Traffic Engineering", Work in Progress, January
2012.
[PCEP-MIB] Koushik, A., Emile, S., Zhao, Q., King, D., and J.
Hardwick, "PCE communication protocol (PCEP) Management
Information Base", Work in Progress, July 2012.11. Contributors 🌸
Quintin Zhao
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
EMail: qzhao@huawei.com
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
EMail: zhangfatai@huawei.comAuthors' Addresses 🧚
Daniel King
Old Dog Consulting
UK
EMail: daniel@olddog.co.uk
Adrian Farrel
Old Dog Consulting
UK
EMail: adrian@olddog.co.ukAnd that's a wrap, bestie! 🌈💖 You made it through the whole spec, and honestly? Iconic behaviour. 👑
📦 where this page comes from
- ietf: rfc6805 2012-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms