RFC 4655
A Path Computation Element (PCE)-Based Architecture
Bestie, this RFC is literally about how we find the best route through a messy network 🦋✨
A Path Computation Element (PCE)-Based Architecture 💖
- Stream: Network Working Group
- RFC number: 4655
- Category: Informational
- Date: August 2006
- Authors: A. Farrel (Old Dog Consulting), J.-P. Vasseur (Cisco Systems, Inc.), and J. Ash (AT&T)
- Obsoletes / Updates: the title block doesn't list any, so this one isn't replacing or changing another RFC 🌸
Status of This Memo 📜
Okay so this doc is just informational, bestie. It's giving "here's some info for the Internet community" and absolutely NOT "here's a standard you have to follow." 🙈 Distribution is totally unlimited too, so share it with everyone 🌈
Copyright Notice ©️
Copyright (C) The Internet Society (2006).
Abstract 🧚
Okay this part is so iconic. Constraint-based path computation is a core building block for traffic engineering in systems like Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Finding a path gets messy fast in big networks that span multiple domains, multiple regions, or multiple layers 😭 It can need special computing pieces and the different network domains have to actually work together.
This document lays out the architecture for a Path Computation Element (PCE)-based model to handle that mess 💅 It doesn't try to describe every single architectural component in detail. Instead, it gives you a set of building blocks you can mix and match to build solutions 🧩
Table of Contents 🗂️
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Definitions .....................................................4
4. Motivation for a PCE-Based Architecture .........................6
4.1. CPU-Intensive Path Computation .............................6
4.2. Partial Visibility .........................................7
4.3. Absence of the TED or Use of Non-TE-Enabled IGP ............7
4.4. Node Outside the Routing Domain ............................8
4.5. Network Element Lacks Control Plane or Routing Capability ..8
4.6. Backup Path Computation for Bandwidth Protection ...........8
4.7. Multi-layer Networks .......................................9
4.8. Path Selection Policy ......................................9
4.9. Non-Motivations ...........................................10
4.9.1. The Whole Internet .................................10
4.9.2. Guaranteed TE LSP Establishment ....................10
5. Overview of the PCE-Based Architecture .........................11
5.1. Composite PCE Node ........................................11
5.2. External PCE ..............................................12
5.3. Multiple PCE Path Computation .............................13
5.4. Multiple PCE Path Computation with Inter-PCE
Communication .............................................14
5.5. Management-Based PCE Usage ................................15
5.6. Areas for Standardization .................................16
6. PCE Architectural Considerations ...............................16
6.1. Centralized Computation Model .............................16
6.2. Distributed Computation Model .............................17
6.3. Synchronization ...........................................17
6.4. PCE Discovery and Load Balancing ..........................18
6.5. Detecting PCE Liveness ....................................20
6.6. PCC-PCE and PCE-PCE Communication .........................20
6.7. PCE TED Synchronization ...................................22
6.8. Stateful versus Stateless PCEs ............................23
6.9. Monitoring ................................................25
6.10. Confidentiality ..........................................25
6.11. Policy ...................................................26
6.11.1. PCE Policy Architecture ...........................26
6.11.2. Policy Realization ................................28
6.11.3. Type of Policies ..................................28
6.11.4. Relationship to Signaling .........................29
6.12. Unsolicited Interactions .................................30
6.13. Relationship with Crankback ..............................30
7. The View from the Path Computation Client ......................31
8. Evaluation Metrics .............................................32
9. Manageability Considerations ...................................33
9.1. Control of Function and Policy ............................33
9.2. Information and Data Models ...............................34
9.3. Liveness Detection and Monitoring .........................34
9.4. Verifying Correct Operation ...............................35
9.5. Requirements on Other Protocols and Functional
Components ................................................35
9.6. Impact on Network Operation ...............................36
9.7. Other Considerations ......................................36
10. Security Considerations .......................................37
11. Acknowledgements ..............................................37
12. Informative References ........................................381. Introduction ✨
Okay so, constraint-based path computation is a core building block for traffic engineering in MPLS [RFC3209] and GMPLS [RFC3473] networks 🔥 [RFC2702] describes the requirements for traffic engineering in MPLS networks, and [RFC4105] and [RFC4216] cover traffic engineering requirements for inter-area and inter-AS environments, respectively 🌈
Path computation in big multi-domain networks is complicated, and it can need special computational components plus some serious teamwork between the elements in different domains 🫶 This document lays out the architecture for a Path Computation Element (PCE)-based model that tackles exactly that problem space 💜
This document describes a set of building blocks for the PCE architecture, and you can build solutions out of them 🧸 For example, it talks about PCE-based implementations like composite, external, and multiple PCE path computation. It also covers architectural considerations: centralized computation, distributed computation, synchronization, PCE discovery and load balancing, detection of PCE liveness, communication between Path Computation Clients (PCCs) and the PCE (PCC-PCE communication), PCE-PCE communication, Traffic Engineering Database (TED) synchronization, stateful and stateless PCEs, monitoring, policy and confidentiality, and evaluation metrics 📚
The model of the Internet is to spread network functionality (for example, routing) throughout the network 🌐 PCE functionality isn't meant to clash with that model. It can match the model exactly, like when PCE functionality lives alongside each Label Switching Router (LSR) in the network. PCE can also step in and boost the network where the Internet model can't supply good enough solutions, like when traffic engineering information isn't exchanged between network domains 🦋
2. Terminology 📖
Here's the vocab you need, bestie 🎀
- CSPF: Constraint-based Shortest Path First.
- LER: Label Edge Router.
- LSDB: Link State Database.
- LSP: Label Switched Path.
- LSR: Label Switching Router.
- PCC: Path Computation Client. Any client application that asks for a path computation to be done by the Path Computation Element. 💅
- PCE: Path Computation Element. An entity (a component, an application, or a network node) that can compute a network path or route based on a network graph and apply computational constraints (see further description in Section 3). It's giving main character energy 👑
- TED: Traffic Engineering Database, which holds the topology and resource information of the domain. The TED may be fed by Interior Gateway Protocol (IGP) extensions or, potentially, by other means. 🍓
- TE LSP: Traffic Engineering MPLS Label Switched Path. 🧚
3. Definitions ✨
okay so first things first, a PCE is an entity that is capable of computing a network path or route based on a network graph, and of applying computational constraints during the computation 💅. The PCE entity is an application that can be located within a network node or component, on an out-of-network server, etc. For example, a PCE would be able to compute the path of a TE LSP by operating on the TED and considering bandwidth and other constraints applicable to the TE LSP service request 🧚.
A domain is any collection of network elements within a common sphere of address management or path computation responsibility 🌸. Examples of domains include IGP areas, Autonomous Systems (ASes), and multiple ASes within a Service Provider network. Domains of path computation responsibility may also exist as sub-domains of areas or ASes.
Bestie, to fully characterize a PCE and clarify these definitions, the following important considerations must also be examined 🫶:
- Path computation is applicable in intra-domain, inter-domain, and inter-layer contexts.
- a. Inter-domain path computation may involve the association of topology, routing, and policy information from multiple domains, from which relationships may be deduced in order to help in performing path computation.
- b. Inter-layer path computation refers to the use of PCE where multiple layers are involved and when the objective is to perform path computation at one or multiple layers while taking into account topology and resource information at these layers.
Overlapping domains are not within the scope of this document. In the inter-domain case, the domains may belong to a single or to multiple Service Providers.
- Single vs. multiple PCE vibes 💖
- a. In "single PCE path computation", a single PCE is used to compute a given path in a domain. There may be multiple PCEs in a domain, but only one PCE per domain is involved in any single path computation.
- b. In "multiple PCE path computation", multiple PCEs are used to compute a given path in a domain.
- Centralized vs. distributed, the iconic showdown 👑
- a. "Centralized computation model" refers to a model whereby all paths in a domain are computed by a single, centralized PCE.
- b. Conversely, "distributed computation model" refers to the computation of paths in a domain being shared among multiple PCEs.
Paths that span multiple domains may be computed using the distributed model with one or more PCEs responsible for each domain, or the centralized model by defining a domain that encompasses all the other domains.
From these definitions, a centralized computation model inherently uses single PCE path computation. However, a distributed computation model could use either single PCE path computation or multiple PCE path computations. There would be no such thing as a centralized model that uses multiple PCEs. 💀
- The PCE may or may not be located at the head-end of the path. For example, a conventional intra-domain solution is to have path computation performed by the head-end LSR of an MPLS TE LSP; in this case, the head-end LSR contains a PCE. But solutions also exist where other nodes on the path must contribute to the path computation (for example, loose hops), making them PCEs in their own right. At the same time, the path computation may be made by some other PCE physically distinct from the computed path. 🦋
- The path computed by the PCE may be an "explicit path" (that is, the full explicit path from start to destination, made of a list of strict hops) or a "strict/loose path" (that is, a mix of strict and loose hops comprising at least one loose hop representing the destination), where a hop may be an abstract node such as an AS. 🌈
- A PCE-based path computation model does not mean to be exclusive and can be used in conjunction with other path computation models. For instance, the path of an inter-AS TE LSP may be computed using a PCE-based path computation model in some ASes, whereas the set of traversed ASes may be specified by other means (not determined by a PCE). Furthermore, different path computation models may be used for different TE LSPs. 🍓
- This document does not make any assumptions about the nature or implementation of a PCE. A PCE could be implemented on a router, an LSR, a dedicated network server, etc. Moreover, the PCE function is orthogonal to the forwarding capability of the node on which it is implemented. 🧠✨
4. Motivation for a PCE-Based Architecture 💅
Several motivations for a PCE-based architecture (described in Section 5) are listed below. This list is not meant to be exhaustive and is provided for the sake of illustration.
It should be highlighted that the aim of this section is to provide some application examples for which a PCE-based path may be suitable. This also clearly states that such a model does not aim to replace existing path computation models, but would apply to specific existing or future situations 🎀.
As can be seen from these examples, PCE does not replace the existing Internet model where intelligence is distributed within the network. Instead, it builds on this model and makes use of distributed centers of information or computational ability. PCE should not, therefore, necessarily be seen as a centralized, "all-seeing oracle in the sky", but as the cooperative operation of distributed functionality used to address specific challenges such as the computation of a shortest inter-domain constrained path. 🫶
4.1. CPU-Intensive Path Computation
There are many situations where the computation of a path may be highly CPU-intensive. Examples of CPU-intensive path computations include the resolution of problems such as:
- Placing a set of TE LSPs within a domain so as to optimize an objective function (for example, minimization of the maximum link utilization)
- Multi-criteria path computation (for example, delay and link utilization, inclusion of switching capabilities, adaptation features, encoding types and optical constraints within a GMPLS optical network)
- Computation of minimal cost Point to Multipoint trees (Steiner trees)
In these situations, it may not be possible or desirable for some routers to perform path computation because of the constraints on their CPUs, in which case the path computations may be off-loaded to some other PCE(s) that may, themselves, be routers or may be dedicated PCE servers. 🔥
4.2. Partial Visibility
There are several scenarios where the node responsible for path computation has limited visibility of the network topology to the destination. This limitation may occur, for instance, when an ingress router attempts to establish a TE LSP to a destination that lies in a separate domain, since TE information is not exchanged across the domain boundaries. In such cases, it is possible to use loose routes to establish the TE LSP, relying on routers at the domain borders to establish the next piece of the path. However, it is not possible to guarantee that the optimal (shortest) path will be used, or even that a viable path will be discovered except, possibly, through repeated trial and error using crankback or other signaling extensions. 😭
This problem of inter-domain path computation may most probably be addressed through distributed computation with cooperation among PCEs within each of the domains, and potentially using crankback between the domains to dynamically resolve provisioning issues. Alternatively, a central "all-seeing" PCE that has access to the complete set of topology information may be used, but in this case there are challenges of scalability (both the size of the TED and the responsiveness of a single PCE handling requests for many domains) and of preservation of confidentiality when the domains belong to different Service Providers. 🌸
Note that the issues described here can be further highlighted in the context of TE LSP reoptimization, or the establishment of multiple diverse TE LSPs for protection or load sharing. 🦋
4.3. Absence of the TED or Use of Non-TE-Enabled IGP
The traffic engineering database (TED) may be a large drain on the resources of a network node (such as an edge router or LER). Maintaining the TED may require a lot of memory and may require non-negligible CPU activity. The use of a distinct PCE may be appropriate in such circumstances, and a separate node can be used to establish and maintain the TED, and to make it available for path computation. 🧚
The IGPs run within some networks are not sufficient to build a full TED. For example, a network may run OSPF/IS-IS without the OSPF-TE/ISIS-TE extensions, or some routers in the network may not support the TE extensions. In these cases, in order to successfully compute paths through the network, the TED must be constructed or supplemented through configuration action and updated as network resources are reserved or released. Such a TED could be distributed to the routers that need to perform path computation or held centrally (on a distinct node that supports PCE) for centralized computation. 🍓
4.4. Node Outside the Routing Domain
An LER might not be part of the routing domain for administrative reasons (for example, a customer-edge (CE) router connected to the provider-edge (PE) router in the context of MPLS VPN [RFC4364] and for which it is desired to provide a CE to CE TE LSP path). 💜
This scenario suggests a solution that does not involve doing computation on the ingress (TE LSP head-end, CE) router, and that does not rely on the configuration of static loose hops. In this case, optimal shortest paths cannot be guaranteed. A solution that a distinct PCE can help here. Note that the PCE in this case may, itself, provide a path that includes loose hops. 🙈
4.5. Network Element Lacks Control Plane or Routing Capability
It is common in legacy optical networks for the network elements not to have a control plane or routing capability. Such network elements only have a data plane and a management plane, and all cross-connections are made from the management plane. It is desirable in this case to run the path computation on the PCE, and to send the cross-connection commands to each node on the computed path. That is, the PCC would be an element of the management plane, perhaps residing in the Network Management System (NMS) or Operations Support System (OSS). ⭐
This scenario is important for Automatically Switched Optical Network (ASON)-capable networks and may also be used for interworking between GMPLS-capable and GMPLS-incapable networks. 🌈
4.6. Backup Path Computation for Bandwidth Protection
A PCE can be used to compute backup paths in the context of fast reroute protection of TE LSPs. In this model, all backup TE LSPs protecting a given facility are computed in a coordinated manner by a PCE. This allows complete bandwidth sharing between backup tunnels protecting independent elements, while avoiding any extensions to TE LSP signaling. Both centralized and distributed computation models are applicable. In the distributed case each LSR can be a PCE to compute the paths of backup tunnels to protect against the failure of adjacent network links or nodes. 👑💖
4.7. Multi-layer Networks ✨
Okay so this one is giving layers within layers, bestie 🧚💖. A server-layer network of one switching capability may support multiple networks of another (more granular) switching capability. For example, a Time-Division Multiplexing (TDM) network may provide connectivity for client-layer networks such as IP, MPLS, or Layer 2 [MLN]. Iconic behavior, honestly 😭.
The server-layer network is unlikely to provide the same connectivity paradigm as the client networks, so bandwidth granularity in the server-layer network may be much coarser than in the client-layer network. Similarly, there is likely to be a management separation between the two networks providing independent address spaces. Furthermore, where multiple client-layer networks make use of the same server-layer network, those client-layer networks may have independent policies, control parameters, address spaces, and routing preferences. Each one gets its own main character energy 💅🌸.
The different client- and server-layer networks may be considered distinct path computation regions within a PCE domain, so the PCE architecture is useful to allow path computation from one client-layer network region, across the server-layer network, to another client-layer network region. Ngl this is the whole point 🦋.
In this case, the PCEs are responsible for resolving address space issues, handling differences in policy and control parameters, and coordinating resources between the networks. Note that, because of the differences in bandwidth granularity, connectivity across the server-layer network may be provided through virtual TE links or Forwarding Adjacencies: the PCE may offer a point of control responsible for the decision to provision new TE links or Forwarding Adjacencies across the server-layer network. The PCE is the one making the call here, periodt 👑🎀.
4.8. Path Selection Policy 💜
A PCE may have a local policy that impacts path computation and selection in response to a path computation request. Such policy may act on information provided by the requesting PCC. The result of applying such policy includes, for example, rejection of the path computation request, or provision of a path that does not meet all of the requested constraints. Further, the policy may support administratively configured paths, or selection among transit providers. Inclusion of policy within PCE may simplify the application of policy within the path computation/selection process. Policy is literally the bouncer of the path world 🙈.
Similarly, a PCC may apply local policy to the selection of a PCE to compute a specific path, and to the constraints that are requested. Same energy, different angle ✨.
In a PCE context, the policy may be sensitive to the type of path that is being computed. For example, a different set of policies may be applied for an intra-area or single-layer path than would be provided for an inter-area or multi-layer path. Different paths, different rules, no cap 🌈.
Note that synchronization of policy between PCEs or between PCCs and PCEs may be necessary. Such issues are outside the scope of the PCE architecture, but within scope for the PCE policy framework and application which is described in a separate document. That's a whole other episode, so go read that doc when you're ready 📚🫶.
4.9. Non-Motivations 🥀
4.9.1. The Whole Internet
PCE is not considered to be a solution that is applicable to the entire Internet. That is, the applicability of PCE is limited to a set of domains with known relationships. The scale of this limitation is similar to the peering relationships between Service Providers. Not everyone gets invited to the party, and that's the vibe 💅.
4.9.2. Guaranteed TE LSP Establishment
When two or more paths for TE LSPs are computed on the same set of TE link state information, it is possible that the resultant paths will compete for limited resources within the network. This may result in success for only the first TE LSP to be signaled, or it might even mean that no TE LSP can be established. Resource drama is real 😭.
Batch processing of computation requests, back-off times, computation of alternate paths, and crankback can help to mitigate this sort of problem, and PCE may also improve the chances of successful TE LSP setup. However, a single, centralized PCE is not viewed as a solution that can guarantee TE LSP establishment since the potential for network failures or contention for resources still exists where the centralized TED cannot fully reflect current (i.e., real-time) network state. Even the best PCE can't see the future, bestie 🔮💀.
- Overview of the PCE-Based Architecture 🎀
This section gives an overview of the architecture of the PCE model. It needs to be read in conjunction with the details provided in the next section to provide a full view of the flexibility of the model. Think of it as the trailer before the full season 🎬✨.
5.1. Composite PCE Node 🧚
Figure 1 below shows the components of a typical composite PCE node (that is, a router that also implements the PCE functionality) that utilizes path computation. The routing protocol is used to exchange TE information from which the TED is constructed. Service requests to provision TE LSPs are received by the node and converted into signaling requests, but this conversion may require path computation that is requested from a PCE. The PCE operates on the TED subject to local policy in order to respond with the requested path. Okay, look at this glow-up diagram 🦋:
---------------
| --------- | Routing ----------
| | | | Protocol | |
| | TED |<-+----------+-> |
| | | | | |
| --------- | | |
| | | | |
| | Input | | |
| v | | |
| --------- | | |
| | | | | Adjacent |
| | PCE | | | Node |
| | | | | |
| --------- | | |
| ^ | | |
| |Request | | |
| |Response| | |
| v | | |
| --------- | | |
Service | | | | Signaling| |
Request | |Signaling| | Protocol | |
------+->| Engine |<-+----------+-> |
| | | | | |
| --------- | ----------
---------------Figure 1. Composite PCE Node
Note that the routing adjacency between the composite PCE node and any other router may be performed by means of direct connectivity or any tunneling mechanism. Tunnels are not the tea, but they are allowed 🫖.
5.2. External PCE 🌸
Figure 2 shows a PCE that is external to the requesting network element. A service request is received by the head-end node, and before it can initiate signaling to establish the service, it makes a path computation request to the external PCE. The PCE uses the TED subject to local policy as input to the computation and returns a response. Outsourcing the math, iykyk 🧮.
----------
| ----- |
| | TED |<-+----------->
| ----- | TED synchronization
| | | mechanism (for example, routing protocol)
| | |
| v |
| ----- |
| | PCE | |
| ----- |
----------
^
| Request/
| Response
v
Service ---------- Signaling ----------
Request | Head-End | Protocol | Adjacent |
---->| Node |<---------->| Node |
---------- ----------Figure 2. External PCE Node
Note that in this case, the node that supports the PCE function may also be an LSR or router performing forwarding in its own right (i.e., it may be a composite PCE node), but those functions are purely orthogonal to the operation of the function in the instance being considered here. Two jobs, zero drama, separate lanes 💅.
5.3. Multiple PCE Path Computation 💖
Figure 3 illustrates how multiple PCE path computations may be performed along the path of a signaled service. As in the previous example, the head-end PCC makes a request to an external PCE, but the path that is returned is such that the next network element finds it necessary to perform further computation. This may be the case when the path returned is a partial path that does not reach the intended destination or when the computed path is loose. The downstream network element consults another PCE to establish the next hop(s) in the path. In this case, all policy decisions are made independently at each PCE based on information passed from the PCC. Relay race energy, everyone passes the baton 🏃♀️🎀.
Note that either or both PCEs in this case could be composite PCE nodes, as in Section 5.1. Yes, the composite ones can do both, slay 🔥.
---------- ----------
| | | |
| PCE | | PCE |
| | | |
| ----- | | ----- |
| | TED | | | | TED | |
| ----- | | ----- |
---------- ----------
^ ^
| Request/ | Request/
| Response | Response
v v
Service -------- Signaling ------------ Signaling ------------
Request |Head-End| Protocol |Intermediate| Protocol |Intermediate|
---->| Node |<--------->| Node |<--------->| Node |
-------- ------------ ------------Figure 3. Multiple PCE Path Computation
5.4. Multiple PCE Path Computation with Inter-PCE Communication ✨
okay so, the PCE in Section 5.3 couldn't give back a full path for the service, which means the adjacent node has to make its own computation request 😭. Figure 4 shows the fix: the PCEs talk to each other (inter-PCE communication), so the PCE that the head-end node asks can make a request to another PCE to help out 🫶
---------- ----------
| | Inter-PCE Request/Response | |
| PCE |<--------------------------------->| PCE |
| | | |
| ----- | | ----- |
| | TED | | | | TED | |
| ----- | | ----- |
---------- ----------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request | Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
Figure 4. Multiple PCE Path Computation with Inter-PCE CommunicationMultiple PCE path computation with inter-PCE communication is all about coordination between distinct PCEs, where the result one PCE comes up with depends on path fragment info that the other PCEs gave it 🧚 This model does not give you a distributed computation algorithm, but it lets different PCEs be responsible for computing different parts (segments) of the path 💅
PCE-PCE communication gets more detail in Section 6.6.
Ngl, a PCC might not even notice the difference between centralized computation and multiple PCE path computation with inter-PCE communication 👀 The PCC network node or component that asks for the computation sends one request and gets back a full or partial path, but behind the scenes that answer comes from the coordinated, cooperative work of more than one PCE.
In this model, every policy decision may be made independently at each PCE, based on the computation info passed along from the previous PCE. Or, alternatively, there may be explicit communication of policy information between PCEs 💜
5.5. Management-Based PCE Usage
It must be observed that the PCC is not necessarily an LSR 🙈 For example, in Figure 5 the NMS hands the head-end LSR a fully computed explicit path for the TE LSP it's supposed to set up through signaling. The NMS sends this request using a management plane mechanism, and it encodes the data with something like the TE MIB module [RFC3812] 🦋
The NMS builds the explicit path it gives the head-end LSR using info the operator provided. It consults the PCE, and the PCE sends back a path for the NMS to use 💖
Figure 5 draws the PCE as remote from the NMS, but it could, of course, be collocated with the NMS too 🌸
-----------
| ----- |
Service | | TED |<-+----------->
Request | ----- | TED synchronization
| | | | mechanism (for example,
v | | | routing protocol)
------------- Request/ | v |
| | Response| ----- |
| NMS |<--------+> | PCE | |
| | | ----- |
------------- -----------
Service |
Request |
v
---------- Signaling ----------
| Head-End | Protocol | Adjacent |
| Node |<---------->| Node |
---------- ----------
Figure 5. Management-Based PCE Usage5.6. Areas for Standardization
Here's what still needs standardizing in the PCE architecture 📋
- communication between PCCs and PCEs, and between cooperating PCEs, including the communication of policy-related information
- requirements for extending existing routing and signaling protocols in support of PCE discovery and signaling of inter-domain paths
- definition of metrics to evaluate path quality, scalability, responsiveness, robustness, and policy support of path computation models.
- MIB modules related to communication protocols, routing and signaling extensions, metrics, and PCE monitoring information
6. PCE Architectural Considerations 🎀
This section lists the PCE architectural components 🧩 Specific realizations and implementation details (state machines or algorithms, etc.) of PCE-based solutions are out of scope for this document, so we're not going there yet 🙅♀️
Also, PCE-based path computation doesn't affect the use of the computed paths at all 💅 For example, using a PCE doesn't change how TE LSPs get signaled, maintained, and torn down. It only relates to the path computation side of those TE LSPs.
This section gives an architectural view of PCE, meaning it describes which components exist and how they interact 🦋 The architectural model, and especially the functional model, might look different depending on which component of the PCE system you're looking at. For example, the PCC won't know whether a PCE consults other PCEs. The PCC's view of the PCE architecture gets covered in Section 7 ✨
6.1. Centralized Computation Model
A "centralized computation model" assumes that all path computations for a given domain get done by a single, centralized PCE 👑 That PCE might be a dedicated server (for example, an external PCE node), or a designated router (for example, a composite PCE node) in the network. In this model, every PCC in the domain sends its path computation requests to the central PCE. A domain here might be an IGP area or AS, but it could also be a sub-group of network nodes defined by how much they depend on the PCE.
Okay, big warning 😭 this model has a single point of failure: the PCE itself. To avoid that, the centralized computation model may designate a backup PCE that can take over the computation responsibility in a controlled manner if the primary PCE fails. Any policies present on the primary PCE should also be present on the backup, although the primary policies may themselves be subject to policy governing how they're implemented on the backup. And remember, at any moment in time there is only one active PCE in any domain 💀
6.2. Distributed Computation Model
A "distributed computation model" refers to a domain or network that may include multiple PCEs, where computing paths is shared among those PCEs 🌈 A given path may be computed by a single PCE ("single PCE path computation") or by multiple PCEs ("multiple PCE path computation"). A PCC might be linked to one particular PCE, or it might be able to choose freely among several PCEs. How that choice is made is out of scope for this document, but see Section 6.4 for a discussion of PCE discovery, which affects this choice 🔍 Policy implementation should be consistent across the set of available PCEs.
Often, the computation of an individual path is done entirely by a single PCE. For example, this is usually the case in MPLS TE within a single IGP area, where the ingress LSR/composite PCE node is responsible for computing the path or for contacting an external PCE 💅 Multiple PCE path computation, on the other hand, means more than one PCE is involved in computing a single path. One example is where loose hop expansion is performed by transit LSRs/composite PCE nodes on an MPLS TE LSP. Another example is using multiple cooperating PCEs to compute the path of a single TE LSP across multiple domains 🫶
6.3. Synchronization
Often, multiple paths need to be computed to support a single service (for example, for protection or load sharing) 🔥 A PCC that figures out it needs more than one path computed may send a series of individual requests to the PCE. In this case of non-synchronized path computation requests, the PCE may make multiple individual path computations to generate the paths, and the PCC may send its individual requests to different PCEs.
Or, the PCC may send a single request to a PCE asking for a set of paths to be computed, while saying that non-synchronized path computation is acceptable. The PCE may compute each path in turn, exactly as it would have if the PCC had made multiple requests, and the PCE may pass some computations off to other PCEs if it wants to. On the other hand, the PCE isn't prohibited from doing all the computations together in a synchronized manner, as described below 🌸
The PCC may also send a single request asking for all the paths to be computed in a synchronized manner. The PCE then does simultaneous computation of the set of requested paths. This kind of synchronized computation can often give better results ⭐
Involving more than one PCE in computing a series of paths is non-synchronized by nature 🙈 However, a set of cooperating PCEs may be synchronized under the control of a single PCE. For example, a PCC might send a request to a PCE that invokes domain-specific computations by other PCEs before handing a result back to the PCC 🧚
It's desirable to add a parameter to the PCC-PCE protocol that asks the PCE to supply a set of alternate paths for the PCC to use, in case setting up the TE LSP on the principal path fails to complete 🦋 Alternate paths might not always work if the first path fails, but including them in a PCE response could have less overhead than having the PCC send separate requests for subsequent path computations whenever it needs them. This technique is already used in some existing CSPF implementations 💖
6.4. PCE Discovery and Load Balancing ✨
Okay bestie, so for a PCC to talk to a PCE efficiently, it must know where that PCE is 📍. The architecture makes a deliberate call here: PCC requests get aimed at one specific PCE, not broadcast to the whole network for any PCE to answer 🎯. It's giving efficiency. Only the chosen PCE works on that request, which saves network resources during propagation and processing power at the PCEs that never needed to respond 💅.
The PCC can learn where a PCE is through local configuration, or it can rely on a protocol-based discovery mechanism that may be governed by policy 🗺️.
Where more than one PCE is known to a PCC, the PCC must have sufficient information to select an appropriate PCE for its purposes, under the control of policy 👑. This selection lets load get shared between PCEs, and it supports PCEs with different computation capabilities, including different visibility scopes 🌈. So the information the PCC has must include details of PCE capabilities, which may be fixed or may vary dynamically in time ⭐.
The PCC may learn PCE capabilities through static configuration, or it may discover the information dynamically 🧚. Even when the location of the PCE is configured at the PCC, the PCC may still discover the PCE capabilities dynamically. Dynamic PCE capabilities cannot be configured and can only be discovered 🙈.
Proxy PCE advertisement is a viable alternative 🦋. In this setup, the existence of a PCE is advertised via a proxy PCE, which helps when the PCE is incapable of advertising itself. It is a requirement that the proxy adequately advertise the PCE status and capability in a timely and synchronized fashion ⏰.
If multiple PCEs are available to serve a particular path computation request, the PCC must select a PCE to satisfy the request 🫶. How that selection works (for instance, efficiently sharing the computation load across multiple PCEs, or requesting secondary computations after partial or failed computations) is local to the PCC, may be based on policy, and is out of the scope of this document 🔒.
PCE capabilities that may be advertised or configured could include (and are not be limited to):
- a set of constraints that it can account for (diversity, shared risk link groups (SRLGs), optical impairments, wavelength continuity, etc.)
- computational capacity (for example, the number of computations it can perform per second)
- the number of switching capability layers (and which ones)
- the number of path selection criteria (and which ones)
- whether it is a stateless PCE or it can send updates about better paths that might be available in the future
- whether it can compute P2MP trees (and which types)
- whether it can ensure resource sharing between backup tunnels
This information would help a PCC decide which PCE to use 🎀.
Requirements for PCE advertisement will be documented separately 📝. There is no restriction within the architecture about how location and capabilities are advertised, and the two elements should be considered functionally distinct. Think of them as two separate lanes, not one big mess 🛣️.
A PCC might also ask a PCE to perform a particular type of service without knowing the PCE's capabilities 🤷♀️. The PCE could respond that it is unable to perform the service. That response could specify the PCE's capabilities, and it might also suggest another PCE that has the requested capabilities 💜.
6.5. Detecting PCE Liveness 💓
The ability to detect a PCE's liveness is a mandatory piece of the overall architecture 🚨, and there are several ways to get it done. If some form of regular advertisement (such as through IGP extensions) is used for PCE discovery, it is expected that PCE liveness will be determined by means of status advertisement (for example, IGP LSA/LSPs) 📡.
Here's the tea 🍵. The inability of a PCE to service a request (perhaps because of excessive load) may be reported to the PCC through a failure message. But the failure of a PCE, or of the communications mechanism while processing a request, cannot be reported that way 💀. Also, when the load is excessive, the PCE may not have enough resources to send a failure message at all. So the PCC should employ other mechanisms, such as protocol timers, to determine the liveness of the PCE ⏱️. This is especially important for inter-domain path computation, where PCE liveness may not be detected by means of the IGP that runs in the PCC's domain 🌐.
6.6. PCC-PCE and PCE-PCE Communication 🦋
Once the PCC has selected a PCE, and provided that the PCE is not local to the PCC, a request/response protocol is required 🤝. It's how the PCC sends path computation requests to the PCE, and how the PCE sends back the path computation response. Discussion of the security requirements and implications for this protocol is provided in Section 10 of this document 🔐, so go check that out too.
A path computation request may include a significant set of requirements, including the following:
- the source and destination of the path
- the bandwidth and other Quality of Service (QoS) parameters desired
- resources, resource affinities, and shared risk link groups (SRLGs) to use/avoid
- the number of disjoint paths required and whether near-disjoint paths are acceptable
- the levels of resiliency, reliability, and robustness of the path resources
- policy-related information
The level of robustness of the path resources is a qualitative assessment of how vulnerable the resources that may be used are 🏗️. For example, one might grade resources based on empirical evidence (mean time between failures), on known risks (there is major building work going on near this conduit), or on prejudice (vendor X's software is always crashing 💀). A PCC could request that only robust resources be used, or it could allow any resource.
If the PCE responds positively, one or more paths get returned to the requesting node ✅. If it fails to compute the desired path(s), an error is returned together with as much information as possible about the reasons for the failure(s). It may even include advice about which constraints might be relaxed so that a positive result is more likely in a future request 🧠.
Note that the resultant path(s) may be made up of a set of strict or loose hops, or any combination of strict and loose hops. Moreover, a hop may have the form of a non-explicit abstract node 🧩.
A request/response protocol is also required for a PCE to communicate path computation requests to another PCE, and for that PCE to return the path computation response 🔁. The path computation request may include a significant set of requirements, including those defined above. If the PCE responds positively, one or more paths get returned to the requesting PCE. If it fails to compute the desired path(s), an error is returned together with as much information as possible about the reasons for the failure, and potentially advice about which constraints might be relaxed so that a positive result is more likely. Again, the resultant path(s) may be made up of a set of strict or loose hops, or any combination of strict and loose hops, and a hop may have the form of a non-explicit abstract node 🌸.
An important feature of PCEs that are cooperating to compute a path is that they apply compatible or identical computation algorithms and coordinated policies 👯. This may require coordination through communication between the PCEs.
Note that when multiple PCEs cooperate to compute a path, it is important that they have a coordinated view of the meaning of constraints such as costs, resource affinities, and class of service 🎯. This is especially significant where the PCEs are responsible for different domains. It is assumed that this is a matter of policy between domains and between PCEs 🤝.
No assumption is made in this architecture about whether the PCC-PCE and PCE-PCE communication protocols are identical 🙃. They can be, or they can be totally different, and the architecture doesn't care either way 💅.
6.7. PCE TED Synchronization
Okay so, like we said before, the PCE runs on a TED 🗂️✨ and the info it needs to build that TED can reach it through a few different routes, bestie 💅
- Joining the IGP's TE info party. The standard way to spread TE information around an IGP area is through extensions to the IGP [RFC3630, RFC3748] 🌸 This lets participating nodes build a TED, and it's the standard move for things like a single-area MPLS or GMPLS network. A node hosting the PCE function can collect TE info this way by keeping at least one routing adjacency with a router in the domain. The PCE node can be adjacent to that router or non-adjacent (via some tunneling techniques) 🦋 This keeps the TED efficiently synced with the network state, and it's the normal case when the PCE lives right alongside the LSRs in an MPLS or GMPLS network 💜
- Out-of-band TED sync. Sometimes it's not convenient or even possible for a PCE to join the IGPs of one or more domains 😩 (like when there are sooo many domains, when IGP participation isn't wanted, or when some domains aren't running TE-aware IGPs). In that case, some mechanism may need to be defined so the PCE node can retrieve the TED from each domain 🧚 That mechanism could be incremental (like the IGP in the previous case), or it could be a bulk transfer of the complete TED. The bulk version might seriously limit the ability to keep the TED synchronized, which could bump up the failure rate of computed paths or lead to sub-optimal paths 💀 Consideration should also be given to the impact of TED distribution on the network, and on the network node in the domain that's asked to distribute the database. This matters a lot when network state changes frequently 🙈
- Other sources of info in the TED. The TED can hold info from sources other than the IGP. For example, the operator can configure info about link usage policies 🎀 Path computation can also act on a much wider set of info, including data about the TE LSPs provisioned in the network. This can cover TE LSP routes, reserved bandwidth, and measured traffic volume passing through the TE LSP 📈
Info like this can level up TE LSP (re)optimization so it covers "full network" (re)optimization, and it lets traffic fluctuations get taken into account 👑 Detailed TE LSP info may also make it easier to reconfigure the Virtual Network Topology (VNT) [MLN], where lower-layer TE LSPs (like optical paths) provide TE links for the higher layer to use. That reconfiguration is also a "full network" problem, so the detail helps 🌈
Note that synchronization techniques may apply to both intra- and inter-domain TEDs ✨ And the techniques can be mixed across different domains too 🫶 How tightly the PCE and the network are synced is up to implementation and/or policy. Still, better synchronization generally leads to paths that are more likely to succeed 🔥
Also note that the PCE may only have access to a partial TED 👀 For instance, in inter-domain path computation, each domain may be managed by a different entity. In those cases, each PCE may see only a partial TED, and cooperative techniques between PCEs can be used to get end-to-end path computation. There's no requirement that any single PCE handle the complete TED for the set of domains the TE LSP traverses 🦋
6.8. Stateful versus Stateless PCEs
A PCE can be either stateful or stateless 🎀 In the stateful case, there's a strict synchronization between the PCE and not just the network state (topology and resource info), but also the set of computed paths and the reserved resources in use in the network 💖 In other words, the PCE uses info from the TED as well as info about existing paths (like TE LSPs) in the network when it processes new requests. Stateful PCEs can get optimal path computation and a higher path computation success rate, but they need reliable state synchronization mechanisms 😭 That comes with potentially significant control plane overhead and the job of maintaining a large amount of data/state (like a full mesh of TE LSPs) 💅
For example, if there's only one PCE in the domain, all TE LSP computation is done by that PCE, which can track all the existing TE LSPs and stay synchronized. Every TE LSP state change must be tracked by the PCE 🧚 But this model could require substantial control plane resources. If there are multiple PCEs in the network, TE LSP computation and info are distributed among them, so the resources needed for the computations are distributed too ✨ However, the synchronization issues discussed in Section 6.7 also come into play 🙃
Maintaining a stateful database can be non-trivial 😤 Still, in a single centralized PCE environment, being stateful is almost simple: you just remember all the TE LSPs the PCE has computed, whether they were actually set up (if that can be known), and when they were torn down 🌸 Out-of-band TED synchronization can also get complex when there are multiple PCEs in a distributed computation model, and it could be prone to race conditions, scalability concerns, and so on 💀 Even if the PCE has detailed info on all paths, priorities, and layers, taking all of that into account for path computation could be highly complex 🤯 PCEs might synchronize state by communicating with each other, but when TE LSPs are set up using distributed computation among several PCEs, the problems of synchronization and race condition avoidance get bigger and more complicated 😵💫
There's real benefit in knowing which TE LSPs exist and how they're routed 💜 That helps with applications like placing a high-priority TE LSP in a crowded network so it preempts as few other TE LSPs as possible (also known as the "minimal perturbation" problem). Note that preempting based on the minimum number of links might not result in the smallest number of TE LSPs being disrupted 🙈 Another application is the construction and maintenance of a Virtual Network Topology [MLN]. It's also helpful to know which other TE LSPs exist in the network so you can decide how to manage the forward adjacencies that exist or need to be set up 🦋 The cost-benefit of stateful PCE computation would help determine whether the path computation benefit is enough to offset the extra drain on network and computational resources 🍓
Conversely, stateless PCEs don't have to remember any computed path, and each set of request(s) is processed independently of the others 🫧 For example, stateless PCEs may compute paths based on current TED info, which could be out of sync with the actual network state given other recent PCE-computed path changes. Note that a PCC may include a set of previously computed paths in its request, so those paths get taken into account. For instance, that helps avoid double bandwidth accounting or tries to minimize changes (the minimum perturbation problem) 🌈
Note that a stateless PCE still operates on info about network state 💡 The TED contains link state and bandwidth availability info, as distributed by the IGPs or collected through some other means. This info could be enhanced for more granularity and detail, covering things like the current bandwidth usage on certain links according to resource affinities or forwarding equivalence classes 🎀 That info, though, isn't PCE state, so a model that uses it is still described as stateless in the PCE context ✨
A limited form of statefulness might be applied within an otherwise stateless PCE 🌷 The PCE may keep some context from paths it recently computed, so it avoids suggesting the use of the same resources for other TE LSPs 💖
6.9. Monitoring
PCE monitoring is undoubtedly of the utmost importance in any PCE architecture 🔥 This must include collecting variables related to PCE status and operation. For example, it'll be necessary to understand how the TED is being kept synchronized, the rate of arrival of new requests and the computation times, the range of PCCs that are using the PCE, and how the PCC-PCE protocol is operating 👑
6.10. Confidentiality
As stated in [RFC4216], inter-provider TE LSP computation requires the ability to compute a path while preserving confidentiality across multiple Service Provider cores 🔐 Basically, one Service Provider must not be required to spill any info about its resources or topology in order to support inter-provider TE LSP path computation. So any PCE architecture solution must support returning partial paths by means of loose hops (for example, where each loose hop might identify a boundary LSR) 🧩
This requirement isn't a security issue. It relates to Service Provider policy 💅
Confidentiality, integrity, and authentication of PCC-PCE and PCE-PCE messages must also be ensured, and they're described in Section 10 🫶
The ability to compute a path at the request of the head-end PCC, but to supply the path in segments to the domain boundary PCCs, may also be desirable 🦋
6.11. Policy
Policy affects multiple aspects of the PCE architecture 🎀 There are two applications of policy to consider:
- application of policy within an architectural entity (PCC or PCE)
- application of policy to PCE-related communications
As it applies directly to TE LSPs, policy forms part of the signaling mechanism for establishing the TE LSPs, and that isn't described here 🌸
It's envisioned that policy will be largely applied as a local matter within each PCC and PCE 💜 However, this document needs to define policy models that can be supported within the PCE architecture and by PCE-related communication ✨
Some example policies include:
- selection of a PCE by a PCC
- rejection of a request by the PCE based on the identity of the requesting PCC
- selection by the PCE of a path or application of additional constraints to a computation based on the PCC, the computation target, the time of day, etc.
6.11.1. PCE Policy Architecture ✨
okay so policy gets a whole architecture moment 💅 Figures 6 and 7 show two examples of how policy components plug into the PCE setup. These could honestly be applied to the other PCE configurations in Section 5 too 🫶 In every configuration, policy can get checked before a PCE sends back a response, and the PCC/PCE that receives the response can check it as well 👀
a PCE can have a local policy that changes which paths it picks for a given PCE request 🎀 A policy can be applied based on any information the PCC provides.
in Figure 6, the policy component feeds input into the PCE component 🧚 This policy component might consult an external policy database, but that's outside the scope of this document 🙈
------------------------------
| --------- | Routing ----------
| | | | Protocol | |
| | TED |<-+----------+-> |
| | | | | |
| --------- | | |
| | | | |
| | Input | | |
| v | | |
| --------- --------- | | |
| | Policy | | | | | Adjacent |
| |Component|--->| PCE | | | Node |
| | | | | | | |
| --------- --------- | | |
| ^ | | |
| |Request | | |
| |Response| | |
| v | | |
| --------- | | |
Service | | | | Signaling| |
Request | |Signaling| | Protocol | |
------+---------------->| Engine |<-+----------+-> |
| | | | | |
| --------- | ----------
------------------------------
Figure 6. Policy Component in the Composite PCE Nodenote that policy info can be carried on the internal interfaces AND on the external protocol interfaces 🔥
Figure 7 shows the case where PCE is a distinct function, using the multiple PCE with inter-PCE communication example (compare with Figure 4) 🦋 Each PCE takes input from its local policy as part of the router computation/determination process 🌸 The local policy components can consult external policy components or databases, but that's out of scope for this document too.
again, policy info can be conveyed on the external protocol interfaces, including the inter-PCE interface 💜
------------------ ------------------
| | Inter-PCE Request/Response| |
| PCE |<------------------------->| PCE |
| | | |
| ------ ----- | | ------ ----- |
| |Policy| | TED | | | |Policy| | TED | |
| ------ ----- | | ------ ----- |
------------------ ------------------
^
| Request/
| Response
v
Service ---------- Signaling ---------- Signaling ----------
Request| Head-End | Protocol | Adjacent | Protocol | Adjacent |
---->| Node |<---------->| Node |<---------->| Node |
---------- ---------- ----------
Figure 7. Policy Components in Multiple PCEs6.11.2. Policy Realization 🍓
there are multiple options for how policy info gets coordinated, and it's giving options 👑
- policy decisions can be made by PCCs before they consult PCEs 💖 this kind of decision covers selecting the PCE, applying constraints, and interpreting service requests.
- policy decisions can be made independently at a PCE, or at each cooperating PCE 🌈 so the PCE(s) can make their policy decisions separately from the policy decisions made at PCCs or other PCEs.
- there can also be explicit communication of policy info between a PCC and a PCE, or between PCEs, to get some level of policy coordination going ✨ the kind of info that gets conveyed to support policy really matters, because it affects which policies can be applied at each PCE. The requirements for exchanging policy info also shape how you choose or implement the communication protocols: PCC-PCE, PCE-PCE, and discovery protocols 🫶
6.11.3. Type of Policies 🎀
within the context of PCE, we can identify several types of policies, and they're all a vibe 💅
- User-specific policies operate on info that's specific to the user of a service, or to the service itself (the service the path is being computed for, not the computation service) 🌸 Examples include the contents of objects in a signaling or provisioning message, the port ID the message came in on, a VPN ID, a reference point type, or the identity of the user starting the request. These can be applied by a PCC while it builds a path computation request, or by a PCE while it processes the request, as long as the PCC gives the PCE enough info 🧚
- Request-specific policies operate on info that's specific to a path computation request and carried in the request 🔥 Examples include constraints, diversities, constraint and diversity relaxation strategies, and optimization functions. These directly affect path selection, because they say which links, nodes, path segments, and/or paths are unacceptable or, on the flip side, desirable in the resulting paths 💜
- Domain-specific policies operate on the identity of the domain where the requesting PCC lives, and on the identities of the domains the resulting paths go through 🦋 They have the same effect as user-specific policies, except they can apply to a group of users instead of one individual user. One example is a restriction on what info a PCE publishes within a given domain. In that case, PCEs in some domains might only advertise that they're present, while others might advertise details about their capabilities, client authentication process, and computation resource availability 👀
6.11.4. Relationship to Signaling 💀
when a path for an inter-domain TE LSP is being computed, it is not required to consider signaling plane policy 🙈 BUT, not doing so might mean the TE LSP fails to get established, or gets assigned fewer resources than intended, which leads to a substandard service 😭 So where a PCE invoked by a head-end LSR can see into other domains, it should be able to apply policy considerations to the computation, and it should be aware of the inter-domain policy agreements 🫶 When path computation comes from PCEs cooperating (each one responsible for a particular domain), the policy issues should, where possible, get sorted out at computation time, so the TE LSP is more likely to signal successfully ✨ In this context, a policy violation during inter-domain TE LSP computation may interrupt path computation, and the requester should be notified along with the cause 💖
6.12. Unsolicited Interactions 🌈
it may be that PCC-PCE communications (see Section 6.6) can be usefully extended beyond a simple request/response interaction 🧚 For example, the PCE and PCC could exchange capabilities using this protocol. The protocol could also be used to collect and report info in support of a stateful PCE 💅
it may also be the case that a PCE can update a path it computed earlier (maybe because the network changed or the policy did) 👀 In that case, the PCE-PCC communication could support an "unsolicited" path computation message to hand this new path to the PCC 🔥 BUT, this function would require that the PCE kept a record of previous computations and had a clear trigger for doing recomputations 😭 The PCC would also need to be able to match the new path to the old path, and figure out whether it should act on the new path 🎀 Further, the PCC should be able to report the outcome of such path changes back to the requesting PCE 🫶 Note that the PCE-PCC interaction is not a management interaction, and the PCC is not obliged to use any additional path the PCE supplies 💖
these functions fit easily within the architecture described here, but they're left for further discussion in separate requirements documents 🦋
6.13. Relationship with Crankback 🍓
crankback routing is a mechanism where a failure to establish a path, or a failure of an existing path, can be fixed by a new path computation and fresh signaling 💜 Crankback routing relies on distributing crankback info along with the failure notification, so the new computation can be done while avoiding the failure or blockage point 🌸
in the context of PCE, crankback info can be passed back to the head-end, where computation and signaling can be repeated, using the failed resource as an exclusion in the computation process 🧚 But crankback can also be used to try fixing the problem at intermediate points along the path ✨ Those crankback recomputation nodes are most likely to be domain boundaries where the PCC had already invoked a PCE 👑 So a failure within a domain gets reported to the ingress domain boundary, which will try to compute an alternate path across the domain 😭 If that fails, the problem can be reported to the previous domain and communicated to the ingress boundary for that domain, which might try to pick a more successful path, either by choosing a different entry point into the next domain or by selecting a route through a different set of domains 🙌
7. The View from the Path Computation Client ✨
okay so the PCE architecture looks a little different from the PCC's side 👀 the PCC doesn't really know how the PCEs work together to answer its requests, but the bigger thing is that it's asking totally different questions 💅
the PCC is mostly thinking about:
- picking a PCE that can quickly hand back a computed path that meets the constraints it gave 🎯
- how many computation requests it'll have to send 📨 like, will the first PCE it asks (maybe working with other PCEs) give it the whole path, or does it have to go ask other PCEs to fill in the gaps? 🧩
- how many other path computations have to happen inside the network to set up the TE LSP 🛤️
ngl that last one might be out of scope for the head-end LSR 🙈 but there's one constraint the PCC may really want: the path should be computed in its entirety and handed over with no loose hops and no non-simple abstract nodes 💖
so with its limited view, the PCC is going to care a LOT about Multiple PCE Path Computation (Section 5.3) 🔥 and it'll split that into two subcases. in the first, which is shown in Figure 3, the subsequent computation requests are made by other PCCs along the path of the TE LSP 🦋. in the second, the head-end LSR issues several computation requests itself 🙌
the PCC won't know about Multiple PCE Path Computation with Inter-PCE Communication (Section 5.4) though 🤷♀️ to it, that just looks exactly like the simple External PCE Node case (Section 5.2) 🌸
so the PCC is going to be super aware that a Centralized PCE Model (Section 6.1) might still need Multiple PCE Path Computations, with the head-end or subsequent PCCs having to send more requests to the central PCE 😭 but on the flip side, the PCC might be protected from the Distributed PCE Model (Section 6.2) 💜 because the first PCE it asks uses inter-PCE communication to get a complete result, so no more requests are needed 🫶
honestly all of these distinctions can be sorted out by asking two questions: does the computation response include all the necessary paths, and are those paths fully explicit (meaning they only have strict hops between simple abstract nodes)? 🧁 iykyk ✨
8. Evaluation Metrics 🎀
okay this part is the scorecard 📋 these metrics are for judging how efficient and useful any PCE-based solution is. they are NOT used to pick paths, just to evaluate the PCE architecture itself 💅
- Optimality 👑: how well it maximizes network utilization and minimizes cost, while thinking about QoS objectives, multiple regions, and network layers. heads up: models where several PCEs have to get involved one after another (like the multiple PCE model in Section 5.3) might create path loops unless careful policy is applied 🔁
- Scalability 📈: what routing, TE LSP signaling, and PCE communication overhead look like, like how many messages there are and how big they are (LSAs, crankback information, queries, distribution mechanisms, and so on) 🌈
- Load sharing 🤝: letting multiple PCEs share the path computation load, with each one taking care of a subset of the total requests 💖
- Multi-path computation 🦋: being able to compute multiple, potentially diverse paths for load-sharing and protection/restoration, including end-to-end diversity and protection within individual domains ✨
- Reoptimization 🔄: being able to reoptimize TE LSP paths. this also covers inter-layer correlation when reoptimizing at any specific layer 🧠
- Path computation time ⏱️: how long it takes to compute individual paths, multiple diverse paths, and to handle bulk path computation requests. (quick note: this metric only works for problems that are not NP-complete 🙈)
- Network stability 🧘♀️: how well it keeps perturbation to existing TE state low while computing and setting up new TE paths 🫧
- TED synchronization accuracy 🎯: being able to keep the TED accurately synced with the network topology and resource states
- TED synchronization speed 🏃♀️: how fast TED synchronization gets done ⚡
- TED synchronization impact 🌊: how much the synchronization process affects the data flows in the network
- Handling unsatisfiable constraints 🥲: being able to deal with cases where the PCE can't find a path that satisfies the required set of constraints
- Policy 📜: applying policy to PCC-PCE and PCE-PCE communications, and to computing paths that respect inter-domain TE LSP establishment policies 💜
other metrics might matter too 👀 and when you're evaluating a particular PCE-based architecture, you should use them as well. you should also look at the tradeoffs of optimizing these metrics. for example, pushing path optimality up is likely to have consequences for computation time ⏳ so it's all about balance, bestie ⚖️
9. Manageability Considerations 🛠️
the PCE architecture brings in a bunch of elements that need managing 🧚 the PCE itself has to be managed, and so do its communications with PCCs and other PCEs. the mechanism PCEs and PCCs use to discover each other is also subject to manageability 🔍
a lot of the manageability stuff is already covered in other sections of this doc, so you're not going in totally blind 💖
9.1. Control of Function and Policy 🎛️
it has to be possible to enable and disable the PCE function at a PCE 🔌 which means the PCE will either accept requests, reject them, or just not receive them from PCCs 🙅♀️
graceful shutdown of the PCE function should also be considered 🫶 the vibe here is that during controlled situations (like a software upgrade) a PCE should NOT just vanish 👻 it should warn its PCCs and gracefully handle any queued computation requests. that could mean completing them, forwarding them to another PCE, or rejecting them 🍓
same deal with policy: it has to be possible to control how policy gets applied at the PCE through configuration 💅 that can include restricting certain functions or algorithms, setting access rights and priorities for PCCs, and managing relationships with other PCEs both inside and outside the domain 🌸
the policy configuration interface isn't decided yet ✨ it could be purely a local thing, or it could be supported through a standardized interface (like a MIB module) 🧩
9.2. Information and Data Models 📊
the plan is for PCE and PCC operations to be modeled and controlled through appropriate MIB modules 🧁 the tables in the new MIB modules will need to show the relationships between entities, and let people control and report on configurable options 🎀
statistics are a BIG deal for PCEs 📈 an operator needs to be able to see the historical interactions of a PCC with its PCEs, the performance it's experienced, and how often its requests succeed 💯 operators also need to inspect a PCE to check its load and whether one individual PCC is hogging a disproportionate amount of it 🙈
it's also important to be able to record and inspect stats about PCC-PCE communications, including malformed messages, unauthorized messages, and messages thrown away because of congestion 💀 and yes, there's clearly some overlap between manageability and security here 🔐
statistics for the PCE architecture can be made available through appropriate tables in the new MIB modules 🌈
the new MIB modules should also send notifications when key thresholds get crossed or important events happen 🔔 but be careful, bestie 🚨 the network must NOT get flooded with Simple Network Management Protocol (SNMP) notifications 😭 so it might be a bad move to send a notification every single time a PCE gets a request to compute a path 🙅♀️ and either way, full control has to be provided so notifications can be turned off, using things like the mechanisms defined in the SNMP-NOTIFICATION-MIB module in [RFC3413] 🦋
9.3. Liveness Detection and Monitoring 💓
Section 6.5 talks about how important it is for a PCC to be able to detect whether a PCE is alive 🫀 the PCE-PCC communication techniques have to let a PCC figure out the PCE's liveness BOTH before it sends a request AND in the stretch between sending a request and getting a response 🙌
it's less important for a PCE to know whether PCCs are alive 🤷♀️ within the simple request/response model, that's only useful for two things:
- getting a predictive view of how loaded the PCE is likely to be in the future 📉, or
- letting the PCE abandon processing a request it has already received 🛑
9.4. Verifying Correct Operation ✅
correct operation for the PCE architecture comes down to two things: making sure the point-to-point connectivity between PCCs and PCEs is right, and checking whether the computed paths are valid 🧐 the first one is a security issue that authentication can help with, and it can be monitored through event logging and records as described in Section 9.1 🔐 it can also be a routing issue, to make sure PCC-PCE connectivity is actually possible 🛣️
verifying computed paths is trickier 😵💫 but the info needed for it can still be made available to the operator through MIB tables 📚 as long as full records are kept of the constraints passed on the request, the path computed and handed back in the response, and any extra info the PCE supplies (like the constraint relaxation policies it applied) 💜
9.5. Requirements on Other Protocols and Functional Components 🧚
okay so bestie, we literally can't say for sure what happens to other protocols and components yet, because the solution work isn't finished 🥺. but we can spot a few things 👀
- Dependence on underlying transport protocols 🚚
PCE-PCC communications may choose to use underlying protocols for their transport mechanisms. If they do, some of the manageability considerations from the earlier sections may get handed down to those protocols.
- Re-use of existing protocols for discovery 🔍
Without messing with the requirements and solutions work for PCE discovery (see Section 6.4), existing protocols might get used to help with this job. If they do, some of the manageability considerations from the previous sections may get passed on to those protocols.
- Impact on LSRs and TE LSP signaling 🛰️
The main example of a PCC in this architecture is an MPLS or GMPLS LSR, so we have to think about how manageable LSRs are, plus the extra manageability constraints on the TE LSP signaling protocols. 😤
Beyond the PCC management from the previous sections, an LSR needs to be configurable so it can decide whether it uses a remote PCE at all. The two options are hop-by-hop routing, or supplying the PCE function itself. It's probably important for an LSR to tell whether the route for a TE LSP came in a signaling message from another LSR, from an operator, or from a PCE. And if it came in a signaling message, it also needs to tell whether a PCE enhanced or expanded it. 🧩
- Reuse of existing policy models and mechanisms 📜
Policy support can get pretty extensive, so it's worth checking how much of that prior work can be leveraged and applied to PCE. 💅 That said, wanting to reuse prior work doesn't mean you're required to use any particular solution or protocol.
9.6. Impact on Network Operation 🚦
This architecture can have two impacts on how a network runs. First, TE LSP setup times go up, because requests get sent to and processed by a remote PCE. Second, it can cause congestion in the network if a big pile of computation requests shows up in a short window 😬. These problems are worst in busy networks and right after failures. The effect can get softened if protection paths are precomputed, or if the path computation load is spread across a set of PCEs 🌈.
Congestion during recovery from failures can be eased with pre-established protection schemes, like fast reroute ⚡.
Congestion needs to be handled proactively, because once a network is already congested, it may be impossible to fix it reactively 🙈. An operator should be able to rate limit the requests a PCC sends to a PCE. And a PCE should be able to report impending congestion, based on a configured threshold, both to the operator and to its PCCs 📣.
9.7. Other Considerations 💅
No other management considerations have been identified, so that's the whole list, bestie ✨.
10. Security Considerations 🔐
The impact of a PCE-based architecture has to be looked at alongside its impact on the security of the existing routing and signaling protocols and techniques in use in the network 😰. It's less likely to be a problem for intra-domain use of PCE. But more inter-domain information flows, plus making inter-domain path establishment easier, can make the network more vulnerable to security attacks 🚨.
The confidentiality implications of a PCE-based architecture for multi-domain networks are a really big deal 👀. A multi-domain PCE solution doesn't automatically wreck security, but solutions MUST examine their effects in this area. No cap, this is not optional 💀.
Applicability statements for particular combinations of signaling, routing and path computation techniques are expected to include detailed security sections 📝.
Heads up: using a non-local PCE (one that's not co-resident with the PCC) adds extra security issues 🙀. The biggest ones are:
- interception of PCE requests or responses;
- impersonation of PCE or PCC;
- falsification of TE information, policy information, or PCE capabilities; and
- denial-of-service attacks on PCE or PCE communication mechanisms.
PCE solutions are expected to deal with these issues in detail, using authentication and security techniques 🔒.
11. Acknowledgements 🫶
The authors want to give the warmest thanks to these lovely people (in alphabetical order) for their review and suggestions: Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella, Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou, Richard Rabbat, Payam Torab, Takao Shimizu, and Raymond Zhang 💖. Lou Berger gave really valuable and detailed input on the policy discussion in this document 👑.
Thanks also to Pekka Savola, Russ Housley and Dave Kessens for their review and constructive discussions during the final stages of publication 🌸.
12. Informative References 📚
- [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
- [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
- [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
- [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
- [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
- [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
- [RFC3748] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
- [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
- [RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
- [RFC4216] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
- [MLN] Shiomoto, K., Papdimitriou, D., Le Roux, J.-L., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-based multi-region and multi-layer networks (MRN/MLN)", Work in Progress, June 2006.
Authors' Addresses 📮
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
Jean-Philippe Vasseur
1414 Massachussetts Avenue
Boxborough, MA 01719
USA
EMail: jpv@cisco.com
Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748,
USA
Phone: (732)-420-4578
Fax: (732)-368-8659
EMail: gash@att.comFull Copyright Statement ©️
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth in that, the authors keep all their rights 🌈.
This document and the information in it are provided on an "AS IS" basis. Here's the legal bit, verbatim:
THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧾
The IETF doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope. It also doesn't say whether a license under those rights is or isn't available, and it doesn't claim to have looked into any such rights on its own 🕵️. You can find out how rights work for RFC documents in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses to be made available, or the results of an attempt to get a general license or permission to use those proprietary rights for implementers or users of this spec, can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
The IETF invites anyone who's interested to bring any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard to its attention. Send that info to ietf-ipr@ietf.org 📬.
Acknowledgement 🌟
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 💜.
📦 where this page comes from
- ietf: rfc4655 2006-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms