RFC 8694

Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering

📅 published December 2019, from ietf

RFC 8694 glow-up time 🎀✨

Okay bestie, let's start with the basics. This is RFC 8694, published in December 2019 as an Informational document (so it's published for information, not as a standards-track spec) 📚. Its ISSN is 2070-1721. The authors are D. King from Old Dog Consulting, and 郑好棉 (H. Zheng) from 华为技术有限公司 (Huawei Technologies) 🤝. The title is Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering. Nothing is listed as obsoleted or updated in the title block, so this one stands on its own 💅.

Abstract ✨

The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-Autonomous System (multi-AS) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic-Engineered (TE) networks.

This document looks at how well the PCE architecture, protocols, and protocol extensions fit when you need to compute multi-area and multi-AS paths in MPLS and GMPLS networks 🦋.

Status of This Memo 🧾

This document is not an Internet Standards Track specification. It's published for informational purposes 💜.

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves can be a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for the details 🙈.

For the latest status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8694 🔗.

Copyright Notice ⚖️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🫶.

Table of Contents 🗂️

1.  Introduction
  1.1.  Domains
  1.2.  Path Computation
    1.2.1.  PCE-Based Path Computation Procedure
  1.3.  Traffic Engineering Aggregation and Abstraction
  1.4.  Traffic-Engineered Label Switched Paths
  1.5.  Inter-area and Inter-AS-capable PCE Discovery
  1.6.  Objective Functions
2.  Terminology
3.  Issues and Considerations
  3.1.  Multihoming
  3.2.  Destination Location
  3.3.  Domain Confidentiality
4.  Domain Topologies
  4.1.  Selecting Domain Paths
  4.2.  Domain Sizes
  4.3.  Domain Diversity
  4.4.  Synchronized Path Computations
  4.5.  Domain Inclusion or Exclusion
5.  Applicability of the PCE to Inter-area Traffic Engineering
  5.1.  Inter-area Routing
    5.1.1.  Area Inclusion and Exclusion
    5.1.2.  Strict Explicit Path and Loose Path
    5.1.3.  Inter-Area Diverse Path Computation
6.  Applicability of the PCE to Inter-AS Traffic Engineering
  6.1.  Inter-AS Routing
    6.1.1.  AS Inclusion and Exclusion
  6.2.  Inter-AS Bandwidth Guarantees
  6.3.  Inter-AS Recovery
  6.4.  Inter-AS PCE Peering Policies
7.  Multi-domain PCE Deployment Options
  7.1.  Traffic Engineering Database and Synchronization
    7.1.1.  Applicability of BGP-LS to PCE
  7.2.  Pre-planning and Management-Based Solutions
8.  Domain Confidentiality
  8.1.  Loose Hops
  8.2.  Confidential Path Segments and Path-Keys
9.  Point to Multipoint
10. Optical Domains
  10.1.  Abstraction and Control of TE Networks (ACTN)
11. Policy
12. Manageability Considerations
  12.1.  Control of Function and Policy
  12.2.  Information and Data Models
  12.3.  Liveness Detection and Monitoring
  12.4.  Verifying Correct Operation
  12.5.  Impact on Network Operation
13. Security Considerations
  13.1.  Multi-domain Security
14. IANA Considerations
15. References
  15.1.  Normative References
  15.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 🌸

Computing paths across big multi-domain environments can need special computational components, plus cooperation between entities in different domains that are able to do complex path computation 🧠.

Routing in multi-domain networks can run into a few issues:

There's often no full topology or TE information across domains 😭.
No single node can see enough to work out an optimal, or even feasible, end-to-end path across domains 💀.
It's hard to know how to evaluate and pick the exit point and the next domain boundary out of a domain 🤔.
It's also unclear how the ingress node decides which domains should be used for the end-to-end path 🧭.

Sharing information across multiple domains is often limited. The reasons are a lack of trust relationship, security issues, or scalability issues, and that can happen even when the domains do trust each other 🔒.

The Path Computation Element (PCE) [RFC4655] gives us an architecture and a set of functional components to tackle the problem space and the issues above 💅.

A PCE may be used to compute end-to-end paths across multi-domain environments using a per-domain path computation technique [RFC5152]. The backward recursive PCE-based computation (BRPC) mechanism [RFC5441] defines a path computation procedure for computing inter-domain constrained Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic-Engineered (TE) networks. But both the per-domain and BRPC techniques assume that the sequence of domains to be crossed from source to destination is already known, either fixed by the network operator or obtained some other way 🗺️.

In more advanced deployments, including multi-area and multi-Autonomous System (multi-AS) environments, the sequence of domains may not be known in advance. And choosing domains in the end-to-end domain sequence can be critical to finding an optimal end-to-end path 👑. In that case, the hierarchical PCE [RFC6805] architecture and mechanisms may be used to discover the intra-area path and select the optimal end-to-end domain sequence ✨.

This document describes the processes and procedures available when using the PCE architecture and protocols to compute inter-area and inter-AS MPLS and GMPLS Traffic-Engineered paths 🎀.

The scope of this document does not include discussions of deployment scenarios for stateful PCE, active PCE, remotely initiated PCE, or PCE as a central controller (PCECC) 🙅‍♀️.

1.1. Domains 🏰

Generally, a domain is a separate administrative, geographic, or switching environment within the network. A domain can also be described as a zone of routing or computational ability. Under those definitions, a domain might be categorized as an Autonomous System (AS) or an Interior Gateway Protocol (IGP) area (as per [RFC4726] and [RFC4655]) 🧩.

For the purposes of this document, a domain is a collection of network elements within an area or AS that has a common sphere of address management or path computational responsibility. Wholly or partially overlapping domains are not in scope for this document 🚫.

In the context of GMPLS, a really important example of a domain is the Automatically Switched Optical Network (ASON) subnetwork [G-8080]. Here, computing an end-to-end path means selecting nodes and links within a parent domain, where some of those nodes may actually be subnetworks 🌈. A domain might also be an ASON routing area [G-7715]. A PCE may perform the path computation function of an ASON Routing Controller, as described in [G-7715-2] 🦄.

It's assumed that the PCE architecture is not applied to a large group of domains, such as the Internet 🌐.

1.2. Path Computation 🧮

For this document, path computation is assumed to be the sole responsibility of the PCE, as per the architecture defined in [RFC4655] 💖. When a path is needed, the Path Computation Client (PCC) sends a request to the PCE. The PCE applies the required constraints, computes a path, and returns a response to the PCC 📬. In this context, the PCE may need to cooperate with other PCEs in adjacent domains (as per BRPC [RFC5441]) or with a parent PCE (as per [RFC6805]) 🤝.

It's entirely feasible for an operator to compute a path across multiple domains without using a PCE, as long as the relevant domain information is available to the network planner or network management platform 📋. What counts as relevant information for this network planning operation, and how that information is discovered and applied, is outside the scope of this document 🙃.

1.2.1. PCE-Based Path Computation Procedure ✨

As we've seen, the PCE is an entity that can compute an inter-domain TE path when it receives a request from a PCC 🧚. There could be a single PCE per domain, or a single PCE responsible for all domains. A PCE may or may not live on the same node as the requesting PCC. A path may be computed by a single PCE node or by a set of distributed PCE nodes that collaborate during the computation 🫧.

According to [RFC4655], a PCC should send a path computation request to a particular PCE using [RFC5440] (PCC-to-PCE communication). That means there's no need to broadcast a request to all the PCEs 📣. Each PCC can keep information about the computation capabilities of the PCEs it knows about. PCC-PCE capability awareness can come from static configuration or from automatic and dynamic PCE discovery procedures 🔍.

If a network path is needed, the PCC sends a path computation request to the PCE. A PCE may then compute the end-to-end path if it knows the topology and TE information required to compute the entire path 💫. If the PCE can't compute the entire path, the PCE architecture provides cooperative PCE mechanisms to resolve path computation requests when an individual PCE doesn't have enough TE visibility 🤝💅.

End-to-end path segments can be kept confidential by applying Path-Keys to protect partial or full path information. A Path-Key is a token that replaces a path segment in an explicit route. The Path-Key mechanism is described in [RFC5520] 🔐.

1.3. Traffic Engineering Aggregation and Abstraction 🪞

Networks are often built from multiple areas or ASes that are interconnected through multiple interconnect points. To keep the network confidential and scalable, the TE properties of each area and AS are generally not advertised outside that specific area or AS 🫣.

TE aggregation or abstraction gives us a way to hide information, but it can cause failed path setups or the selection of suboptimal end-to-end paths [RFC4726]. The aggregation process can also have significant scaling issues for networks with many possible routes and multiple TE metrics 😵‍💫. Flooding TE information breaks confidentiality and does not scale in the routing protocol 🚨.

The PCE architecture and its associated mechanisms provide a solution that avoids using TE aggregation and abstraction altogether 🦋👑.

1.4. Traffic-Engineered Label Switched Paths ✨

okay so this section is about the PCE tricks for setting up TE LSPs (packet and optical) that cross multiple areas (inter-area TE LSP) and multiple ASes (inter-AS TE LSP) 🛤️. Quick note: in this doc, every LSP we talk about is constraint based and traffic engineered. No exceptions, bestie 💅

There are three signaling options for setting up an inter-area or inter-AS LSP [RFC4726] 🦋:

Contiguous LSP
Stitched LSP
Nested LSP

All three work with the architectures and procedures in this document. Iconic ✨

1.5. Inter-area and Inter-AS-capable PCE Discovery 🔍

when a PCE-based approach is doing inter-area or inter-AS path computation, a PCE in one area or AS might need to learn about inter-AS-capable PCEs sitting in other ASes 👀. That's where PCE discovery comes in. The mechanisms in [RFC5088] and [RFC5089] help PCEs find each other and share info about inter-area and inter-AS-capable PCEs 🫶.

1.6. Objective Functions 🎯

An Objective Function (OF) [RFC5541] (or a whole set of OFs) spells out what the path computation is trying to achieve, and that's what "optimal" means for a given computation request 💜.

An OF tells you the outcome you want. It does NOT say how to get there, so it doesn't pick an algorithm. An implementation can use any algorithm or combo of algorithms to hit the result the OF asks for 🧚. A bunch of general OFs are defined in [RFC5541] ✨.

Different OFs can go into the PCE computation request so it matches the policies configured at the PCC 📋. A PCE can also be subject to its own policy when deciding whether it can meet the OFs in the request, or whether it should apply its own OFs instead 🙈.

During inter-domain path computation, three things can each have their own OFs and policies: picking the domain sequence, computing each per-domain path fragment, and deciding the end-to-end path 🌈.

2. Terminology 📖

this doc also uses the terms from [RFC4655] and [RFC5440], plus a few extra ones 💅:

ABR: IGP Area Border Router. A router attached to more than one IGP area 🌸.
ASBR: Autonomous System Border Router. A router that connects ASes of the same or different Service Provider through one or more inter-AS links 🔗.
Inter-area TE LSP: A TE LSP whose path goes through two or more IGP areas 🛤️.
Inter-AS MPLS TE LSP: A TE LSP whose path goes through two or more ASes or sub-ASes (BGP confederations) 👑.
SRLG: Shared Risk Link Group 💀.
TED: Traffic Engineering Database. It holds the topology and resource info for the domain. The TED can be fed by Interior Gateway Protocol (IGP) extensions, or possibly by other means 🧠.

3. Issues and Considerations 🤔

3.1. Multihoming 🏠

Networks built from multiple areas or multiple ASes often have several interconnect points (multihoming) 🪢. End-to-end path computations may need to use different interconnect points so that one single-point failure doesn't take out both the primary and backup services 🛡️.

3.2. Destination Location 📍

A PCC asking for an inter-domain path computation usually knows who the destination node is 👀. If the PCC knows the destination domain, it can include that domain info in the path computation request 💖. But if the PCC doesn't know the destination domain, that info has to be figured out some other way 🤷‍♀️.

3.3. Domain Confidentiality 🔐

When the end-to-end path crosses multiple domains, each domain (AS or area) could be run by a different Service Provider 🏢. So if a PCE hands a path segment over to a PCE in another domain, it could break confidentiality rules and leak AS-internal topology info 😭.

If confidentiality is required between domains (ASes and areas) that belong to different Service Providers, then cooperating PCEs cannot exchange path segments. Otherwise, the receiving PCE or PCC can see every individual hop through the other domain 👁️.

We dig deeper into this topic in Section 8 of this document 📚.

4. Domain Topologies 🗺️

Constraint-based inter-domain path computation is a must-have for running traffic-engineered MPLS [RFC3209] and GMPLS [RFC3473] networks across inter-area and inter-AS (multi-domain) setups 🌐. Path computation across multi-domain networks is seriously complex, so it needs computational cooperational entities like the PCE 🧚‍♀️.

4.1. Selecting Domain Paths 🧭

When you already know the sequence of domains in advance, there are several ways to get an optimal multi-domain path ✨. If the domains connect in a simple path with no branches and single links between every pair, or if the preferred interconnection points are already known, the per-domain path computation [RFC5152] technique can be used 🪄. If there are multiple connections between domains and no preference for which interconnection points to use, BRPC [RFC5441] can be used to derive an optimal path 🎀.

When the sequence of domains isn't known ahead of time, or the end-to-end path has to navigate a mesh of small domains (which is super common in optical networks), the optimum path can be derived by applying a hierarchical PCE [RFC6805] 🦋.

4.2. Domain Sizes 📏

Network domains are very often made up of dozens or hundreds of network elements 🍓. These elements are usually connected in a partial-mesh fashion so they survive dual failures and can use the traffic-engineering capabilities of MPLS and GMPLS protocols 💜. Feedback from network operators during the development of this document showed that node degree (the number of neighbors per node) typically ranges from 3 to 10, and 4-5 is quite common 📊.

4.3. Domain Diversity 🌈

Domain and path diversity may also be needed when computing end-to-end paths 👯. Domain diversity should help you pick paths that share ingress and egress domains but don't share transit domains. That means there must be a way to include or exclude specific domains when computing end-to-end paths 🙌.

4.4. Synchronized Path Computations ⏱️

Sometimes it helps a lot for the operator to rely on the PCE's ability to do synchronized path computation 💅.

Synchronized path computations, called Synchronization VECtors (SVECs), are used for dependent path computations. SVECs are defined in [RFC5440], and [RFC6007] gives an overview of how the PCE SVEC list is used for synchronized path computations when you're computing dependent requests 📝.

In hierarchical PCE (H-PCE) deployments, a child PCE can ask its parent PCE for both dependent and synchronized domain-diverse end-to-end paths 👑.

4.5. Domain Inclusion or Exclusion 🚪

A domain sequence is an ordered list of domains you go through to reach the destination domain 🛣️. You can supply a domain sequence during path computation to guide the PCEs, or it can be derived using hierarchical PCE (H-PCE) 🧩.

During multi-domain path computation, a PCC can ask for specific domains to be included or excluded in the domain sequence, using the Include Route Object (IRO) [RFC5440] and the Exclude Route Object (XRO) [RFC5521] 🎀. The use of Autonomous Number (AS) as an abstract node representing a domain is defined in [RFC3209] 🌸. [RFC7897] defines new subobjects for including or excluding domains like an IGP area or a 4-byte AS number 🦄.

An operator might also need to avoid a path that goes through certain nodes for administrative reasons 🙅‍♀️. And if a connectivity service needs 1+1 protection, two separate disjoint paths have to be set up 🛡️✨. A mechanism called Shared Risk Link Group (SRLG) information can be used to make sure the paths stay diverse 💖.

5. Applicability of the PCE to Inter-area Traffic Engineering 🧠

As networks grow in size and complexity, you might need scaling methods that cut down on the info flooded through the network and keep it manageable 📈. An IGP hierarchy helps IGP scalability by splitting the IGP domain into areas and limiting the flooding scope of topology info to inside area boundaries 🧱. The catch is that this restricts a router's visibility to its own area 👀. If a router needs a route to a destination in another area, there has to be a method for computing a path across area boundaries 🌉.

To support multiple vendors in a network where data or control-plane technologies can't interoperate, it helps to split the network into vendor domains 🏷️. Each vendor domain is an IGP area, and the flooding scope of the topology (and any other relevant info) stays within the area boundaries 🫧.

Per-domain path computation [RFC5152] exists as a way to do inter-area path computation 🪄. The per-domain solution is based on loose hop routing, with Explicit Route Object (ERO) expansion on each Area Border Router (ABR) 🔁. This lets an LSP be set up along a constrained path. But at least two issues come with it 😬:

This method does not guarantee an optimal constrained path 📉.
The method may need several crankback signaling messages, as described in [RFC4920]. That adds signaling traffic and delays the LSP setup 🐢.

The PCE-based architecture [RFC4655] is designed to solve inter-area path computation problems ✨. The limited topology visibility issue gets solved by introducing path computation entities that can cooperate to set up LSPs whose source and destinations sit in different areas 🫶.

5.1. Inter-area Routing 🛣️

An inter-area TE-LSP is an LSP that transits through at least two IGP areas 🦋. In a multi-area network, topology visibility stays local to a given area, for scaling and privacy reasons 🔒. A node in one area can't compute an end-to-end path across multiple areas without a PCE 🙈.

5.1.1. Area Inclusion and Exclusion 🚧

The BRPC method [RFC5441] gives a more optimal way to specify including or excluding an ABR 🎯. With the BRPC procedure, an end-to-end path is recursively computed in reverse, from the destination domain back toward the source domain 🔄. Using this method, an operator can decide whether an area must be included or excluded from the inter-area path computation 💜.

5.1.2. Strict Explicit Path and Loose Path 🧵

A strict explicit path is a set of strict hops, while a loose path is a set of at least one loose hop plus zero or more strict hops 🪡. It can be useful to say whether a strict explicit path is required when making the path computation request 📝. An inter-area path can be strictly explicit or loose (for example, a list of ABRs as loose hops) 🌸.

A PCC request to a PCE can indicate whether a strict explicit path across specific areas ([RFC7897]) is required or desired, or whether the path request is loose 💅.

Okay bestie, let's get into it 💖 Picking up right where we left off!

5.1.3. Inter-Area Diverse Path Computation ✨

5.1.3. Inter-Area Diverse Path Computation

Okay so sometimes you need a path that's partly or totally different from one you already computed 🦋. Why? To stop your primary service and its backup from fate sharing, which is just a fancy way of saying they both die together when one thing breaks 💀. There are different levels of diversity when you're working across areas:

Per-area diversity: the intra-area path segments are link, node, or SRLG disjoint 🌸.
Inter-area diversity: the end-to-end inter-area paths are link, node, or SRLG disjoint 💜.

Here's the tea 🍵: two paths can be disjoint in the backbone but NOT in the peripheral areas. And two paths can be node disjoint inside each area but still share ABRs, which means the segments are node disjoint but the end-to-end paths aren't 🙈. Lowkey tricky!! But the good news is that Per-domain [RFC5152], BRPC [RFC5441], and H-PCE [RFC6805] mechanisms all support computing diverse paths across multi-area topologies 🧚✨.

6. Applicability of the PCE to Inter-AS Traffic Engineering 👑

As we talked about in Section 5 (Applicability of the PCE to Inter-area Traffic Engineering), the network has to be split into smaller administrative domains, aka ASes 🌈. If an LSR inside an AS needs a path that crosses an AS boundary, it MUST also use an inter-AS computation technique. [RFC5152] defines mechanisms for computing inter-domain TE LSPs, using the network elements along the signaling paths to compute per-domain constrained path segments 💅.

The PCE was built to compute MPLS and GMPLS paths across AS boundaries, and this section breaks down the features of a PCE-enabled solution for inter-AS paths 🎀.

6.1. Inter-AS Routing 🦋

6.1.1. AS Inclusion and Exclusion

[RFC5441] lets you specify AS or ASBR inclusion or exclusion. With this, an operator can decide whether an AS MUST be included or excluded from the inter-AS path computation 💖. Inclusion or exclusion can also be specified at any step of the LSP path computation process by a PCE (within the BRPC algorithm), but the best practice would be to specify them at the edge ✨. Unlike strict and loose paths, AS inclusion or exclusion doesn't impose topology disclosure, because ASes and their interconnections are public entities 🫶.

6.2. Inter-AS Bandwidth Guarantees 🔥

Lots of operators with multi-AS domains have deployed MPLS-TE Diffserv either across their whole network or at the domain edges on CE-PE links 🍓. When strict QoS bounds are required, admission control inside the network may also be needed 💅.

When the propagation delay can be bounded, performance targets like maximum one-way transit delay may be guaranteed by providing bandwidth guarantees along the Diffserv-enabled path 🌸. These requirements are described in [RFC4216].

A typical example from [RFC4216] is providing bandwidth guarantees over an end-to-end path for VoIP traffic classified as an EF (Expedited Forwarding) class in a Diffserv-enabled network 📞. When the EF path stretches across multiple ASes, an inter-AS bandwidth guarantee is required 💜.

Another case for an inter-AS bandwidth guarantee is guaranteeing a certain amount of transit bandwidth across one or multiple ASes 🌈.

6.3. Inter-AS Recovery 🛡️

During a path computation process, a PCC request may contain the requirement to compute a backup LSP to protect the primary LSP, such as 1+1 protection 🦋. A single LSP or multiple backup LSPs may also cover a group of primary LSPs, which is typically known as m:n protection ✨.

Other inter-AS recovery mechanisms include [RFC4090], which adds Fast Reroute (FRR) protection to an LSP 💖. So the PCE could be used to trigger computation of backup tunnels to protect inter-AS connectivity 🧚.

Inter-AS recovery clearly requires backup LSPs for service protection. It's also advisable to have multiple PCEs deployed for path computation redundancy, especially for service restoration after a catastrophic network failure 😭.

6.4. Inter-AS PCE Peering Policies 🤝

Just like BGP peering policies, inter-AS PCE peering policies are required for an operator 💅. In an inter-AS BRPC process, the PCE MUST cooperate in order to compute the end-to-end LSP. So the AS path must not only follow technical constraints, e.g., bandwidth availability, but also the policies defined by the operator 👑.

Typically, PCE interconnections at the AS level must follow the agreed contract obligations, also known as peering agreements 📜. The PCE peering policies are the result of contract negotiation and govern the relationship between the different PCEs 🫶.

7. Multi-domain PCE Deployment Options 🌸

7.1. Traffic Engineering Database and Synchronization

An optimal path computation needs knowledge of the available network resources, including nodes and links, constraints, link connectivity, available bandwidth, and link costs 🧠. The PCE operates on a view of the network topology as presented by a TED. As discussed in [RFC4655], the TED used by a PCE may be learned by the relevant IGP extensions 💖.

So the PCE may operate its TED by participating in the IGP running in the network 🦋. In an MPLS-TE network, this would require OSPF-TE [RFC3630] or ISIS-TE [RFC5305]. In a GMPLS network, it would use the GMPLS extensions to OSPF and IS-IS defined in [RFC4203] and [RFC5307]. Inter-AS connectivity information may be populated via [RFC5316] and [RFC5392] 🌈.

An alternative way to provide network topology and resource information is offered by [RFC7752], which is described in the following section ✨.

7.1.1. Applicability of BGP-LS to PCE

The exchange of TE information between Autonomous Systems (ASes) is discussed in [RFC7752] 🌐. The information exchanged 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. That info could be updated frequently (for example, for every new LSP set up across the AS) or only at threshold-crossing events 💅.

In an H-PCE deployment, the parent PCE needs the inter-domain topology and link status between child domains 👑. This information may be learned by a BGP-LS speaker and provided to the parent PCE. Link-state performance, including delay, available bandwidth, and utilized bandwidth, may also be provided to the parent PCE for optimal path link selection 🎀.

7.2. Pre-planning and Management-Based Solutions 📋

Offline path computation is performed ahead of time, before LSP setup is requested. That means it is requested by, or performed as part of, an Operation Support System (OSS) management application 🛠️. This model can be seen in Section 5.5 of [RFC4655].

The offline model is especially appropriate for long-lived LSPs (like those in a transport network) or for planned responses to network failures 🌙. In these scenarios, more planning is normally a feature of LSP provisioning.

The management system may also use a PCE and BRPC to pre-plan an AS sequence, and the source domain PCE and per-domain path computation to be used when the actual end-to-end path is required 🧚. This model may also be used where the operator wants full manual control over LSP placement, using the PCE only as a computation tool to assist the operator and not as part of an automated network 🫶.

In environments where operators peer with each other to provide end-to-end paths, the operator responsible for each domain MUST agree on the extent to which paths must be pre-planned or manually controlled 🤝.

8. Domain Confidentiality 🔒

This section talks about the techniques cooperating PCEs can use to compute inter-domain paths without each domain disclosing sensitive internal topology information (like explicit nodes or links within the domain) to the other domains 💜.

Confidentiality typically applies to inter-provider (inter-AS) PCE communication. When a TE LSP crosses multiple domains (ASes or areas), the path may be computed by multiple PCEs that cooperate, with each local PCE responsible for computing a segment of the path 🦋. With each local PCE responsible for computing a segment of the path.

In situations where ASes are administered by separate Service Providers, it would break confidentiality rules for a PCE to supply path segment details to a PCE responsible for another domain, thus disclosing AS-internal or area topology information 🚨.

8.1. Loose Hops 🎀

A method for preserving the confidentiality of a path segment is for the PCE to return a path containing a loose hop in place of the segment that must be kept confidential ✨. The concept of loose and strict hops for the route of a TE LSP is described in [RFC3209].

[RFC5440] supports the use of paths with loose hops. Whether it returns a full explicit path with strict hops or uses loose hops is a local policy decision at a PCE 💅. A path computation request may require an explicit path with strict hops or may allow loose hops, as detailed in [RFC5440] 🌸.

8.2. Confidential Path Segments and Path-Keys 🗝️

[RFC5520] defines the concept and mechanism of a Path-Key. A Path-Key is a token that replaces the path segment information in an explicit route 🧩. The Path-Key lets the explicit route information be encoded, and it is contained in the Path Computation Element Communication Protocol (PCEP) ([RFC5440]) messages exchanged between the PCE and PCC 💜.

This Path-Key technique lets explicit route information be used for end-to-end path computation without disclosing internal topology information between domains 🫶.

9. Point to Multipoint 🌳

For inter-domain point-to-multipoint application scenarios using MPLS-TE LSPs, the complexity of domain sequences, domain policies, and the choice and number of domain interconnects is magnified compared to point-to-point path computations 😵. As the network grows, the number of leaves and branches increases, which further increases the complexity of the overall path computation problem. A solution for managing point-to-multipoint path computations may be achieved using the PCE inter-domain point-to-multipoint path computation [RFC7334] procedure 🌟.

10. Optical Domains 🌈

okay so the ITU is the one who wrote the ASON architecture in [G-8080] 🧠 and [G-7715] is where the routing side comes in, with a hierarchy 👑 where a parent (higher-level) Routing Area can hold a bunch of child RAs. the lower RAs' connectivity is visible up at the parent level, which is so organized it's giving 🍓

in ASON land, asking for a path computation is called a route query 🫶. it happens before signaling sets up an LSP, which is called a Switched Connection (SC) or a Soft Permanent Connection (SPC) ✨. [G-7715-2] is where the requirements and architecture live for what Routing Controllers (RC) do during remote route queries. and an RC is just another name for a PCE 💖

so an RC that's in charge of an RA can chat with its neighbor RC to ask for an end-to-end path across several RAs 💅 the moving parts are:

Remote route query. an operation where one Routing Controller talks to another Routing Controller that doesn't have the same set of layer resources, so they can work out a routing path together 🤝
Route query requester. the connection controller or RC that sends a route query message to a Routing Controller, asking for one or more routing paths that satisfy a set of routing constraints 🎀
Route query responder. an RC that does the path computation once it gets a route query message from a Routing Controller or connection controller, then sends the answer back when it's done 🦋

when they're building an end-to-end connection, the route can come from one RC or from several RCs working together. those two cases are a centralized remote route query model and a distributed remote route query model 🌸 RCs in ASON can also use the hierarchical PCE [RFC6805] model, which lines up perfectly with the ASON hierarchical routing model 🧚

10.1. Abstraction and Control of TE Networks (ACTN) 🦋

if one operator runs multiple TE domains (optical ones included), the Abstraction and Control of TE Networks (ACTN) framework [RFC8453] can be used to make an abstracted, virtualized view of the domains that are interconnected at the underlay 🌐 that underlay connectivity then gets exposed to higher-layer control entities and applications 💜

ACTN describes how the per-domain Provisioning Network Controllers (PNCs), which may be PCEs, get coordinated through a hierarchical model. the goal is setting up end-to-end connections across interconnected TE domains 🫶

11. Policy 💅

policy is a big deal when new services are being deployed and when the network is being run day to day ✨ [RFC5394] gives a framework for PCE-based, policy-enabled path computation 🎀 that framework is built on the Policy Core Information Model (PCIM) defined in [RFC3060], and [RFC3460] extends it further 🌈

when a PCE is used to compute inter-domain paths, policy can be invoked by specifying the following:

Each PCC must select which computations it will request from a PCE.
Each PCC must select which PCEs it will use.
Each PCE must determine which PCCs are allowed to use its services and for what computations.
The PCE must determine how to collect the information in its TED, whom to trust for that information, and how to refresh/update the information.
Each PCE must determine which objective functions and algorithms to apply.

12. Manageability Considerations 🎀

general PCE management stuff is covered in [RFC4655] 📖 if you've got multiple domains inside one service provider network, that same service provider would most likely be the one handling management for each PCE 🏠 but if you've got multiple ASes spread across different service provider networks, each PCE will likely need to be configured and managed separately by each participating service provider. policy then gets implemented based on a set of principles that everyone agreed on beforehand 🤝

12.1. Control of Function and Policy 🔧

as per [RFC5440], the PCEP implementation lets the user configure a bunch of PCEP session parameters ⚙️ those are detailed in Section 8.1 of [RFC5440] 💖

in H-PCE deployments, the administrative entity running the parent PCEs for multi-areas would typically be one single service provider 👑 with multiple ASes managed by different service providers, it may be necessary for a third party to manage the parent PCE 🫣

12.2. Information and Data Models 📊

a PCEP MIB module is defined in [RFC7420], and it describes managed objects for modeling PCEP communication, including:

PCEP client configuration and status.
PCEP peer configuration and information.
PCEP session configuration and information.
Notifications to indicate PCEP session changes.

a YANG module for PCEP has also been proposed [PCEP-YANG] 🧁

an H-PCE MIB module or YANG data model will be required to report parent PCE and child PCE information, including:

Parent PCE configuration and status.
Child PCE configuration and information.
Notifications to indicate session changes between parent PCEs and child PCEs.
Notification of parent PCE TED updates and changes.

12.3. Liveness Detection and Monitoring 💓

PCEP has a keepalive mechanism to check that a PCEP peer is still alive 💗 it also has a notification procedure that lets a PCE tell a PCC when it's overloaded 🙈 in a multi-domain environment, [RFC5886] gives the procedures for monitoring the liveliness and performance of a given PCE chain 🔍

12.4. Verifying Correct Operation ✅

checking that PCEP is working correctly is a must-do 🫶 [RFC5440] specifies monitoring of key parameters, and those parameters are detailed in [RFC5520] 📈

12.5. Impact on Network Operation 🌊

[RFC5440] says that, to avoid any unacceptable impact on network operations, a PCEP implementation should allow a limit to be placed on the number of sessions that can be set up on a PCEP speaker 🛑 it also says it may be practical to put a limit on the rate of messages sent by a PCC and received by the PCE 🚦

13. Security Considerations 🔐

PCEP security is covered in [RFC5440] and [RFC6952] 🛡️ the potential vulnerabilities are spoofing, snooping, falsification, and using PCEP as a mechanism for denial of service attacks 😭 this is serious, bestie 💀

PCEP runs over TCP, so it can make use of TCP security encryption mechanisms like Transport Layer Security (TLS) and TCP Authentication Option (TCP-AO) 🔒 how to use those security mechanisms for PCEP is described in [RFC8253], and recommendations and best current practices are in [RFC7525] 📚

13.1. Multi-domain Security 🌍

any multi-domain operation has to involve exchanging information across domain boundaries 🚧 that represents a significant security and confidentiality risk 🚨

PCEP is expected to be used between PCCs and PCEs that belong to the same administrative authority, while also using one of the encryption mechanisms mentioned above 🔐 and PCEP lets individual PCEs keep the confidentiality of their domain path information by using path-keys 🗝️✨

14. IANA Considerations 🦋

this document has no IANA actions 🌸

15. References 📚

15.1. Normative References 💫

[RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
           and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
           Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
           <https://www.rfc-editor.org/info/rfc3209>.

[RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
           Switching (GMPLS) Signaling Resource ReserVation Protocol-
           Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
           DOI 10.17487/RFC3473, January 2003,
           <https://www.rfc-editor.org/info/rfc3473>.

[RFC4216]  Zhang, R., Ed. and J.-P. Vasseur, Ed., "MPLS Inter-
           Autonomous System (AS) Traffic Engineering (TE)
           Requirements", RFC 4216, DOI 10.17487/RFC4216, November
           2005, <https://www.rfc-editor.org/info/rfc4216>.

[RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
           Computation Element (PCE)-Based Architecture", RFC 4655,
           DOI 10.17487/RFC4655, August 2006,
           <https://www.rfc-editor.org/info/rfc4655>.

[RFC4726]  Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework
           for Inter-Domain Multiprotocol Label Switching Traffic
           Engineering", RFC 4726, DOI 10.17487/RFC4726, November
           2006, <https://www.rfc-editor.org/info/rfc4726>.

[RFC5152]  Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
           Per-Domain Path Computation Method for Establishing Inter-
           Domain Traffic Engineering (TE) Label Switched Paths
           (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
           <https://www.rfc-editor.org/info/rfc5152>.

[RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
           Element (PCE) Communication Protocol (PCEP)", RFC 5440,
           DOI 10.17487/RFC5440, March 2009,
           <https://www.rfc-editor.org/info/rfc5440>.

[RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
           "A Backward-Recursive PCE-Based Computation (BRPC)
           Procedure to Compute Shortest Constrained Inter-Domain
           Traffic Engineering Label Switched Paths", RFC 5441,
           DOI 10.17487/RFC5441, April 2009,
           <https://www.rfc-editor.org/info/rfc5441>.

[RFC5520]  Bradford, R., Ed., Vasseur, JP., and A. Farrel,
           "Preserving Topology Confidentiality in Inter-Domain Path
           Computation Using a Path-Key-Based Mechanism", RFC 5520,
           DOI 10.17487/RFC5520, April 2009,
           <https://www.rfc-editor.org/info/rfc5520>.

[RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
           Objective Functions in the Path Computation Element
           Communication Protocol (PCEP)", RFC 5541,
           DOI 10.17487/RFC5541, June 2009,
           <https://www.rfc-editor.org/info/rfc5541>.

[RFC6805]  King, D., Ed. and A. Farrel, Ed., "The Application of the
           Path Computation Element Architecture to the Determination
           of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
           DOI 10.17487/RFC6805, November 2012,
           <https://www.rfc-editor.org/info/rfc6805>.

15.2. Informative References ✨

okay bestie, these are the "go read this if you want the deep lore" references 📚🤓 They're not required reading to implement, but they're where the PCE and traffic engineering drama lives 💅

[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, DOI 10.17487/RFC3060, February 2001, https://www.rfc-editor.org/info/rfc3060.
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) Extensions", RFC 3460, DOI 10.17487/RFC3460, January 2003, https://www.rfc-editor.org/info/rfc3460.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, https://www.rfc-editor.org/info/rfc3630.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, https://www.rfc-editor.org/info/rfc4090.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, https://www.rfc-editor.org/info/rfc4203.
[RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, DOI 10.17487/RFC4920, July 2007, https://www.rfc-editor.org/info/rfc4920.
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, https://www.rfc-editor.org/info/rfc5088.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, January 2008, https://www.rfc-editor.org/info/rfc5089.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, https://www.rfc-editor.org/info/rfc5305.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, https://www.rfc-editor.org/info/rfc5307.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, December 2008, https://www.rfc-editor.org/info/rfc5316.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, January 2009, https://www.rfc-editor.org/info/rfc5392.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, DOI 10.17487/RFC5394, December 2008, https://www.rfc-editor.org/info/rfc5394.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 2009, https://www.rfc-editor.org/info/rfc5521.
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, https://www.rfc-editor.org/info/rfc5886.
[RFC6007] Nishioka, I. and D. King, "Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations", RFC 6007, DOI 10.17487/RFC6007, September 2010, https://www.rfc-editor.org/info/rfc6007.
[G-8080] ITU-T, "Architecture for the automatically switched optical network", ITU-T Recommendation G.8080/Y.1304, February 2012.
[G-7715] ITU-T, "Architecture and requirements for routing in the automatically switched optical networks", ITU-T Recommendation G.7715/Y.1706, June 2002.
[G-7715-2] ITU-T, "ASON routing architecture and requirements for remote route query", ITU-T Recommendation G.7715.2/Y.1706.2, February 2007.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, https://www.rfc-editor.org/info/rfc6952.
[RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas, "PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths", RFC 7334, DOI 10.17487/RFC7334, August 2014, https://www.rfc-editor.org/info/rfc7334.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, https://www.rfc-editor.org/info/rfc7420.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, https://www.rfc-editor.org/info/rfc7525.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, https://www.rfc-editor.org/info/rfc7752.
[RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects for the Path Computation Element Communication Protocol (PCEP)", RFC 7897, DOI 10.17487/RFC7897, June 2016, https://www.rfc-editor.org/info/rfc7897.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, https://www.rfc-editor.org/info/rfc8253.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, https://www.rfc-editor.org/info/rfc8453.
[PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-yang-13, 31 October 2019, https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13.

Acknowledgements 💖

Huge thanks to Adrian Farrel 🫶 for reviewing this, and to Meral Shirazipour and Francisco Javier Jiménez Chico 💜 for their comments.

Contributors 🌈

Let's give a shoutout to the people who helped shape this one. 🎀

Dhruv Dhody

Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore 560066
Karnataka
India

Email: dhruv.ietf@gmail.com

Quintin Zhao

Huawei Technologies
125 Nagog Technology Park
Acton, MA 01719
United States of America

Email: qzhao@huawei.com

Julien Meuric

France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France

Email: julien.meuric@orange.com

Olivier Dugeon

France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France

Email: olivier.dugeon@orange.com

Jon Hardwick

Metaswitch Networks
100 Church Street
Enfield
EN2 6BQ
United Kingdom

Email: jonathan.hardwick@metaswitch.com

Óscar González de Dios

Telefonica I+D
Emilio Vargas 6
Madrid
Spain

Email: oscar.gonzalezdedios@telefonica.com

Authors' Addresses 🦋

Daniel King

Old Dog Consulting

Email: daniel@olddog.co.uk

Haomian Zheng

Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan
Guangdong, 523808
China

Email: zhenghaomian@huawei.com

Additional contact information:

郑好棉
中国
523808
广东 东莞
松山湖华为溪流背坡村H1
华为技术有限公司

📦 where this page comes from

ietf: rfc8694 2019-12
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms