RFC 7334
PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths
PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths 🦋
okay bestie, let's get into this one 💅 It's an RFC from the Internet Engineering Task Force (IETF) with the number 7334, and it came out in August 2014. The authors are Q. Zhao and D. Dhody (both at Huawei Technology), D. King (Old Dog Consulting), Z. Ali (Cisco Systems), and R. Casellas (CTTC). It's categorised as Experimental, and its ISSN is 2070-1721. It doesn't list anything it obsoletes or updates, so it's standing on its own 🌸
Abstract
okay so the big thing is that you need to be able to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains. That's been flagged as a key requirement for deploying P2MP services in MPLS- and GMPLS-controlled networks 🔥 The Path Computation Element (PCE) is recognised as the right tech for figuring out inter-domain paths for P2MP TE LSPs, and it's giving main character energy ✨
This document describes an experiment that adds procedures and extensions to the PCE Communication Protocol (PCEP) so it can compute inter-domain paths for P2MP TE LSPs 🧚
Status of This Memo
this one is not an Internet Standards Track specification 🙈 It's published so people can look at it, try out experimental implementations, and evaluate it.
It defines an Experimental Protocol for the Internet community. It's a product of the IETF, it reflects the consensus of the IETF community, and it went through public review and got approved by the Internet Engineering Steering Group (IESG). Not every IESG-approved document can become an Internet Standard, though. See Section 2 of RFC 5741 for that 💅
Info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7334.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 🎀
This document is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the date it was published. Read those carefully, because they spell out your rights and restrictions for this document 👀 If you pull Code Components out of this document, they have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says.
Table of Contents
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Requirements Language ......................................4
2. Terminology .....................................................5
3. Examination of Existing Mechanisms ..............................6
4. Assumptions .....................................................7
5. Requirements ....................................................8
6. Objective Functions and Constraints .............................9
7. P2MP Path Computation Procedures ...............................10
7.1. General ...................................................10
7.2. Core-Trees ................................................10
7.3. Optimal Core-Tree Computation Procedure ...................13
7.4. Sub-tree Computation Procedures ...........................15
7.5. PCEP Protocol Extensions ..................................15
7.5.1. Extension of RP Object .............................15
7.5.2. Domain and PCE Sequence ............................16
7.6. Using H-PCE for Scalability ...............................16
7.7. Parallelism ...............................................17
8. Protection .....................................................17
8.1. End-to-End Protection .....................................17
8.2. Domain Protection .........................................18
9. Manageability Considerations ...................................18
9.1. Control of Function and Policy ............................18
9.2. Information and Data Models ...............................18
9.3. Liveness Detection and Monitoring .........................19
9.4. Verifying Correct Operation ...............................19
9.5. Requirements on Other Protocols and Functional
Components ................................................19
9.6. Impact on Network Operation ...............................19
9.7. Policy Control ............................................20
10. Security Considerations .......................................20
11. IANA Considerations ...........................................21
12. Acknowledgements ..............................................21
13. References ....................................................21
13.1. Normative References .....................................21
13.2. Informative References ...................................22
14. Contributors' Addresses .......................................241. Introduction ✨
multicast is in high demand for heavy-hitter stuff like multicast VPNs, IPTV (on-demand or streamed), and content-rich media distribution, think software distribution, financial streaming, or database replication 📺 So being able to compute constrained Traffic Engineering Label Switched Paths (TE LSPs) for point-to-multipoint (P2MP) LSPs in MPLS and GMPLS networks across multiple domains is required, full stop 💖
The PCE [RFC4655] and how it applies to computing these paths gets covered in [RFC5671], and the requirements the PCE Communication Protocol (PCEP) has to meet for this are in [RFC5862] 🫶
This document lays out the requirements for inter-domain P2MP path computation. Then it describes the experimental "core-tree" path computation procedure, which was built to meet those requirements and objectives 🌈
When implementation and deployment results come in, this document is going to be updated and refined, and then it'll move from Experimental status to Standards Track 🔥
1.1. Scope
the inter-domain P2MP path computation procedures in this document are experimental 🧪 The point of the experiment is to research how the PCE can support inter-domain P2MP path computation.
This document is not meant to replace the intra-domain P2MP path computation approach defined by [RFC6006]. It also won't impact existing PCE procedures and operations 💅
1.2. Requirements Language
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119] 🎀
2. Terminology 🌸
okay so the terminology here lines up with the related MPLS/GMPLS and PCE docs, which are [RFC4461], [RFC4655], [RFC4875], [RFC5376], [RFC5440], [RFC5441], [RFC5671], and [RFC5862] 📚
These are the extra terms it defines:
Core-Tree: a P2MP tree where the root is the ingress Label Switching Router (LSR) and the leaf nodes are the entry boundary nodes of the leaf domains. ✨
Entry BN of domain(n): a boundary node (BN) connecting domain(n-1) to domain(n) along a determined sequence of domains. 🚪
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along a determined sequence of domains. 🚪
H-PCE: Hierarchical PCE (as per [RFC6805]). 🧚
Leaf Domain: a domain with one or more leaf nodes. 🍓
Path Tree: a set of LSRs and TE links that make up the path of a P2MP TE LSP from the ingress LSR to all egress LSRs (the leaf nodes). 🌳
Path Domain Sequence: the known sequence of domains for a path between the root domain and a leaf domain. 🗺️
Path Domain Tree: the tree formed by the domains the P2MP path crosses, where the source (ingress) domain is the root domain. 🌲
PCE(i): a PCE that performs path computations for domain(i). 💜
Root Domain: the domain that includes the ingress (root) LSR. 👑
Sub-tree: a P2MP tree where the root is the selected entry BN of the leaf domain and the leaf nodes are the destinations (leaves) in that domain. The sub-trees get grafted onto the core-tree 🌿
Transit/Branch Domain: a domain that has an upstream and one or more downstream neighbour domains. 🦋
3. Examination of Existing Mechanisms ✨
okay so the Path Computation Element (PCE) from [RFC4655] is basically the brain 🧠 that can work out a network path or route from a network graph while applying computational constraints. A Path Computation Client (PCC) can send requests to a PCE asking it to compute paths. 💅
[RFC4875] explains how to set up P2MP TE LSPs for MPLS- and GMPLS-controlled networks. The PCE is named as a suitable application for computing paths for P2MP TE LSPs [RFC5671]. literally the PCE is giving main character energy here 🎀
[RFC5441] describes a procedure that uses multiple PCEs to compute point-to-point (P2P) inter-domain constrained shortest paths across a predetermined sequence of domains, using a Backward-Recursive PCE-Based Computation (BRPC) technique. The technique can be combined with Path-Keys [RFC5520] to keep confidentiality across domains, which is sometimes required when domains are managed by different Service Providers. bestie this is the privacy part and it matters 🔒
PCEP [RFC5440] was extended for point-to-multipoint (P2MP) path computation requests in [RFC6006]. ✨
As discussed in [RFC4461], a P2MP tree is the ordered set of LSRs and TE links that make up the path of a P2MP TE LSP from its ingress LSR to all of its egress LSRs. A P2MP LSP is set up with TE constraints and allows efficient packet or data replication at various branching points in the network. As per [RFC5671], choosing branch points is fundamental to determining the paths for a P2MP TE LSP. This choice is constrained by the network topology and available network resources, and it is also determined by the objective functions (OFs) that may be applied to path computation. the vibes are very layered 🌈
Generally, an inter-domain P2MP tree (i.e., a P2MP tree with a source and at least one destination residing in different domains) is particularly difficult to compute, even for a distributed PCE architecture. 😭 For instance, while BRPC may be well-suited for P2P paths, P2MP path computation involves multiple branching path segments from the source to the multiple destinations. So inter-domain P2MP path computation may result in a plurality of per-domain path options that are hard to coordinate efficiently and effectively between domains. Like, when one or more domains have multiple ingress and/or egress boundary nodes (i.e., when the domains are multiply inter-connected), existing techniques can get super convoluted when figuring out which boundary node of another domain will be used for the inter-domain P2MP tree. And there is no way to limit the computation of the P2MP tree to those utilized boundary nodes. iykyk 🙈
A trivial solution would be to compute shortest inter-domain P2P paths from the source to each destination, then combine them to make an inter-domain, shortest-path-to-destination P2MP tree. ngl this one sounds simple but it doesn't fully work. It cannot trade cost to destination for overall tree cost (i.e., it cannot produce a Minimum Cost Tree (MCT)). And for inter-domain P2MP TE LSPs, it cannot reduce the number of domain boundary nodes that are transited. Computing P2P TE LSPs individually does not guarantee an optimal P2MP tree for every definition of "optimal" in every topology. 💀
Per-domain path computation [RFC5152] may be used to compute P2MP multi-domain paths, but it may run into the issues described above. Furthermore, this approach may be considered to have scaling issues during LSP setup. The LSP to each leaf is signaled separately, and each boundary node needs to perform path computation for each leaf. that is a lot of work for the boundary nodes 😩
P2MP MCT, which is a computation that guarantees the least cost resulting tree, typically is an NP-complete problem. Moreover, adding and/or removing a single destination to or from the tree may result in an entirely different tree. In this case, frequent MCT path computation requests may prove computationally intensive, and the resulting frequent tunnel reconfiguration may even cause network destabilization. no thank you 🙅♀️
This document presents a solution, procedures, and extensions to PCEP to support P2MP inter-domain path computation. 👑
4. Assumptions
okay so within this document we make the following assumptions 📝
- Due to deployment and commercial limitations (e.g., inter-AS (Autonomous System) peering agreements), the path domain tree will be known in advance.
- Each PCE knows about any leaf LSRs in the domain it serves.
Additional assumptions are documented in [RFC5441] and are not repeated here. 🦋
5. Requirements
this section sums up the requirements that are specific to computing inter-domain P2MP paths 🎯 In these requirements, we note that the actual computation time taken by any PCE implementation is outside the scope of this document. But we observe that reducing the complexity of the required computations has a beneficial effect on computation time regardless of implementation. Also, reducing the number of message exchanges and the amount of information exchanged will reduce the overall computation time for the entire P2MP tree. We refer to the "complexity of the computation" as the impact on these aspects of path computation time as various parameters of the topology and the P2MP TE LSP are changed. ⏱️
It is also important that the solution can preserve confidentiality across domains, which is required when domains are managed by different Service Providers via the Path-Key mechanism [RFC5520]. 🔐
Other than the requirements specified in [RFC5862], there are a number of requirements specific to inter-domain P2MP, detailed below: 💖
- The complexity of the computation for each sub-tree within each domain SHOULD be dependent only on the topology of the domain, and it SHOULD be independent of the domain sequence.
- The number of PCReq (Path Computation Request) and PCRep (Path Computation Reply) messages SHOULD be independent of the number of multicast destinations in each domain.
- It SHOULD be possible to specify the domain entry and exit nodes in the PCReq.
- Specifying which nodes are to be used as branch nodes SHOULD be supported in the PCReq.
- Reoptimization of existing sub-trees SHOULD be supported.
- It SHOULD be possible to compute diverse P2MP paths from existing P2MP paths.
6. Objective Functions and Constraints
for computing a single P2MP TE LSP or a set of them, a request to meet specific optimization criteria, called an objective function (OF), MAY be used. SPT (Shortest Path Tree) and MCT (Minimum Cost Tree), defined in [RFC6006], are two such OF optimization criteria for the sub-tree within each domain. They are used to select the "best" candidate path. 🍓
In addition to the OFs, the following constraints MAY also be beneficial for inter-domain P2MP path computation: 🧚
- The computed P2MP "core-tree" SHOULD be optimal when only considering the paths to the leaf domain entry BNs.
- Grafting and pruning of multicast destinations (sub-trees) within a leaf domain SHOULD ensure minimal impact on other domains and on the core-tree.
- It SHOULD be possible to choose to optimize the core-tree.
- It SHOULD be possible to choose to optimize the entire tree (P2MP LSP).
- It SHOULD be possible to combine the aforementioned OFs and constraints for P2MP path computation.
When implementing and operating P2MP LSPs, the following need to be taken into consideration: 🤔
- The complexity of computation.
- The optimality of the tree (core-tree as well as full P2MP LSP tree).
- The stability of the core-tree.
The solution SHOULD allow these trade-offs to be made at computation time. ⚖️
The algorithms used to compute optimal paths using a combination of OFs and multiple constraints are out of the scope of this document. 🌸
7. P2MP Path Computation Procedures
7.1. General
okay the P2MP path computation can be broken down into two steps: core-tree computation and grafting of sub-trees. Splitting it up into these specific steps has the following impact, which lets the core-tree-based solution provide an optimal inter-domain P2MP TE LSP: 💅
- The core-tree and sub-tree are smaller in comparison to the full P2MP tree and are thus easier to compute.
- An implementation MAY choose to keep the core-tree fairly static or computed offline (trade-off with optimality).
- Adding/pruning of leaves requires changes to the sub-tree in the leaf-domain only.
- The PCEP message size is smaller in comparison.
The following sub-sections describe the core-tree-based mechanism, including the procedures and PCEP extensions that satisfy the requirements and objectives specified in Sections 5 and 6 of this document. ✨
7.2. Core-Trees ✨
okay so a core-tree is basically a tree that has to pass two checks, bestie 🌳💅
- the root is the ingress LSR sitting in the root domain 👑
- the leaves are the entry boundary nodes in the leaf domains 🍓
for confidentiality, those nodes and links MAY be hidden using the Path-Key mechanism [RFC5520] 🙈 but they MUST still get computed and be part of the core-tree. hidden doesn't mean skipped, periodt 💀
here's the vibe. Figure 1 shows a domain tree with 6 domains, plus part of the core-tree that passes both checks ✨
+----------------+
| |Domain D1
| R |
| |
| A |
| |
+-B------------C-+
/ \
/ \
/ \
Domain D2 / \ Domain D3
+-------------D--+ +-----E----------+
| | | |
| F | | |
| G | | H |
| | | |
| | | |
+-I--------------+ +-J------------K-+
/\ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ Domain D4 \ Domain D5 / Domain D6 \
+-L-------------W+ +------P---------+ +-----------T----+
| | | | | |
| | | Q | | U |
| M O | | S | | |
| | | | | V |
| N | | R | | |
+----------------+ +----------------+ +----------------+
Figure 1: Domain Tree Example
(R)
|
(A)
/ \
/ \
(B) (C)
/ \
/ \
(D) (E)
/ |
/ |
(G) (H)
/ / \
/ / \
(I) (J) (K)
/ \ / \
/ \ / \
(L) (W) (P) (T)
Figure 2: Core-Treeso the core-tree gets built with root R, and the leaf nodes are the entry nodes of the destination domains (L, W, P, and T) 🎯 the Path-Key mechanism can hide the internal nodes and links in the final core-tree, like in domains D2 and D3 below (G and H are hidden via PK1 and PK2, respectively) 🦋
(R)
|
(A)
/ \
/ \
(B) (C)
/ \
/ \
(D) (E)
/ |
/ |
|PK1| |PK2|
/ / \
/ / \
(I) (J) (K)
/ \ / \
/ \ / \
(L) (W) (P) (T)
Figure 3: Core-Tree with Path-Key7.3. Optimal Core-Tree Computation Procedure
ngl this part is giving big scale problems 😭 applying the core-tree procedure to huge groups of domains, like the Internet, is not considered feasible or desirable, so it's out of scope for this doc 🙅♀️
the following extended BRPC-based procedure CAN be used to compute the core-tree 💜 also, a root PCE MAY further use its own enhanced optimization techniques in the future to compute the core-tree ✨
here's the BRPC-based core-tree path computation procedure, step by step 🧚
- use the BRPC procedures to compute the VSPT(i) (Virtual Shortest Path Tree) for each leaf BN(i), where i=1 to n and n is the total number of entry nodes for all the leaf domains. each VSPT(i) has a number of P(i) paths.
- once the root PCE has computed all the VSPT(i), i=1 to n, take one path from each VSPT and form all possible sets of paths. we call these PathSet(j), where j=1 to M and M=
P(1)xP(2)...xP(n). - for each PathSet(j) there are n S2L (Source-to-Leaf) BN paths. form these n paths into a core-tree(j).
- step 3 gives M core-trees. an optimal core-tree is selected based on the OF and constraints 🏆
since the point-to-point BRPC procedure is used to compute the VSPT, the path request and response message formats defined in [RFC5440] are used 📨
also, BRPC is applied a bit differently here than usual 🤔 paths returned from a downstream PCE are not necessarily pruned from the solution set (extended VSPT) by intermediate PCEs. why? if the downstream PCE prunes and only returns the single optimal sub-path to the upstream PCE, combining those single optimal sub-paths into a core-tree is not necessarily optimal, even when each S2L (Source-to-Leaf) sub-path is optimal. the logic is a little plot twist, but it's real 🎭
without trimming, the ingress PCE gets all the possible S2L sub-path sets for the entry boundary nodes of the leaf domain. then it looks through all the combinations, takes one sub-path from each set to build one tree, and selects the optimal core-tree 🔥
a PCE MAY add equal-cost paths within the domain while building an extended VSPT. that gives the ingress PCE more candidate paths for an optimal core-tree 💖
the proposed method may present a scalability problem for dynamic core-tree computation (checking every combination of the solution space over and over), especially with dense or meshed domains 🥺 picture a domain sequence D1, D2, D3, D4, where the leaf boundary node is in domain D4. PCE(4) returns 1 path. PCE(3) returns N paths, where N is E(3) x X(3), and E(k) x X(k) is the number of entry nodes times the number of exit nodes for that domain. PCE(2) returns M paths, where M = E(2) x X(2) x N = E(2) x X(2) x E(3) x X(3) x 1, and so on. generally, the number of potential paths at the ingress PCE Q = prod E(k) x X(k).
so it's EXPECTED that the core-tree will typically be computed offline 📴 that doesn't rule out dynamic, online mechanisms like the one here. in that case, transit PCEs SHOULD be configurable so they can control how many paths get sent upstream during BRPC (trading trimming for optimality at the point of trimming and downwards) 🎀
7.4. Sub-tree Computation Procedures
once the core-tree is built, grafting all the leaf nodes from each domain onto it can be done by a bunch of different algorithms 🧩 one option is that the root PCE sends the request with the C-bit set (as defined in Section 7.5.1 of this document) for the path computation to the destination(s) directly to the PCE where the destination(s) belong(s), along with the core-tree computed per Section 7.2 💌
the catch? the root PCE has to manage a potentially large number of adjacencies (persistent or non-persistent mode), including PCEP adjacencies to PCEs that aren't in neighbor domains 😵💫
an alternative is setting up PCEP adjacencies that match the PCE domain tree. that means branch PCEs would need to forward requests and responses from the root PCE toward the leaf PCEs, and vice versa 🌿
note that the P2MP path request and response format follows [RFC6006], where Record Route Objects (RROs) carry the core-tree paths in the P2MP grafting request 🛤️
the algorithms for computing the optimal large sub-tree are outside the scope of this document 🙃
7.5. PCEP Protocol Extensions
7.5.1. Extension of RP Object
this experiment gets carried out by extending the RP (Request Parameters) object (defined in [RFC5440]) used in PCEP requests and responses 🧪
here's the extended format of the RP object body, with the C-bit included:
the C-bit gets added to the flag bits field of the RP object to tell the receiver whether or not the request/reply is for an inter-domain P2MP core-tree 🚦
this document adds the following flag:
Bit Number Name Flag
17 Core-tree computation (C-bit)C-bit (Core-Tree bit - 1 bit):
- 0: means this is NOT for an inter-domain P2MP core-tree 🙅
- 1: means this is a PCEP request or a response for computing an inter-domain core-tree, or for grafting a sub-tree onto an inter-domain core-tree 💜
7.5.2. Domain and PCE Sequence
the procedure in this document needs the domain tree to be known in advance 🗺️ this info MAY be administratively predetermined, or dynamically discovered by some means, like the Hierarchical PCE (H-PCE) framework [RFC6805], or derived through IGP/BGP routing information 🌐
examples of ways to encode the domain path tree are in [RFC5886], which uses PCE-ID Objects, and [DOMAIN-SEQ] 📚
7.6. Using H-PCE for Scalability
the ingress/root PCE handles the core-tree computation AND the grafting of sub-trees into the multi-domain tree 💪 so it receives all computed path segments from every involved domain. if the ingress/root PCE decides to have a PCEP session with all involved PCEs, that could mean an excessive number of sessions or extra complexity in implementations 😩
the H-PCE framework [RFC6805] may be used to set up a dedicated PCE with the capability (memory and CPU) and knowledge to maintain the necessary PCEP sessions 🦸♀️ the parent PCE would send an intra-domain path computation request to the PCEs, combine the results, and return the overall P2MP tree 🌳✨
7.7. Parallelism 🧚
okay so, to keep path computation fast across multiple domains, the path segments inside each domain and the intra-domain sub-trees can be computed at the same time, whenever that's possible 🏃♀️ The procedures in this document give us a few chances to do that:
- The BRPC procedure for each leaf boundary node can be launched in parallel by the ingress/root PCE when it dynamically computes the core-tree 🌳
- The grafting of sub-trees can be triggered in parallel once the core-tree is computed ✨
BUT (and this is a big but 😬) if the ingress PCE is talking to a bunch of "remote" PCEs at once, it may need a potentially high number of PCEP adjacencies all at the same time. That situation may not be desirable, so keep it in mind before you go parallel-crazy 💅
8. Protection 🛡️
protection is something you might really need when you're deploying and using inter-domain P2MP TE LSPs 🫶 The procedures and mechanisms in this document don't block any existing or proposed kinds of protection, including end-to-end protection [RFC4872] and domain protection schemes.
Segment or facility protection (link and node) is kinda problematic in inter-domain setups, though 😭 Fast reroute (FRR) [RFC4875] needs to know its next hop across domain boundaries, and that clashes with keeping domain confidentiality. The FRR protection might still be implemented if the next-hop information is known in advance 🔐
8.1. End-to-End Protection 🧷
An end-to-end protection principle (covering both nodes and links) can be applied when computing backup P2MP TE LSPs 🔁 While you compute the core-tree and sub-trees, protection may also be taken into consideration. A PCE may compute the primary and backup P2MP TE LSP together, or it may do them one after the other 💖
8.2. Domain Protection 🌍
In this protection scheme, a backup P2MP tree can be computed that completely excludes the transit/branch domain 🙈 You need a backup domain path tree with the same source and destination domains, but with a new set of transit domains. You can then run the backup path tree through the above procedure to get a backup P2MP TE LSP with disjoint transit domains ✨
9. Manageability Considerations 📋
[RFC5862] describes various manageability requirements that support P2MP path computation when you're using PCEP 🦋 This section explains how those manageability requirements from [RFC5862] are supported by the PCEP extensions specified in this document.
Also, [RFC5440] already describes various manageability considerations in PCEP, and most of the manageability requirements from [RFC6006] are already covered there 🌸
9.1. Control of Function and Policy 🎛️
On top of the PCE configuration parameters listed in [RFC5440] and [RFC6006], you might also need these extra ones:
- The ability to enable or disable multi-domain P2MP path computations on the PCE 💜
- Configuration of the PCE to enable or disable the advertisement of its multi-domain P2MP path computation capability 📣
9.2. Information and Data Models 📊
There are a bunch of MIB objects already defined for general PCEP control and monitoring of P2P computations in [PCEP-MIB]. [RFC5862] says MIB objects will be required to support the control and monitoring of the protocol extensions in this document. [PCEP-P2MP-MIB] describes managed objects for modeling PCEP communications between a PCC and PCE, communication between PCEs, and P2MP path computation requests and responses 🧠
9.3. Liveness Detection and Monitoring 💓
No changes are necessary to the liveness detection and monitoring requirements that are already embodied in [RFC4657] ✅
It should be noted that multi-domain P2MP computations are likely to take longer than P2P computations and single-domain P2MP computations ⏳ So the liveness detection and monitoring features of the PCEP SHOULD take this into account 🫶
9.4. Verifying Correct Operation 🔍
There are no additional requirements beyond the ones in [RFC4657] for verifying correct PCEP operation 🙌 Verifying that the PCE and its algorithms are working correctly is out of scope for the protocol requirements, but a PCC MAY send the same request to more than one PCE and compare the results. Big brain move 🧠✨
9.5. Requirements on Other Protocols and Functional Components 🧩
A PCE works on a topology graph that may be built from information distributed by TE extensions to the routing protocol running in the network 🗺️ So that the PCE can pick a suitable path for the signaling protocol to install the P2MP TE LSP, the topology graph MUST include information about the P2MP signaling and branching capabilities of each LSR in the network. No skipping that one, bestie 💅
Mechanisms for knowing about other domains and discovering their corresponding PCEs and capabilities SHOULD be provided, and this information MAY be collected by other mechanisms 🔭
Whatever means you use to collect the info for building the topology graph, the graph MUST include the requisite information 📥 If the TE extensions to the routing protocol are used, these SHOULD be as described in [RFC5073].
9.6. Impact on Network Operation ⚡
Using a PCE to compute P2MP paths is not expected to have significant impact on network operations 😌 However, it's worth knowing that adding P2MP support to a PCE that already does P2P path computation might change the load on that PCE significantly. That could affect the network, especially during recovery periods right after a network failure 😬
The dynamic computation of core-trees might also affect the load on the PCEs involved, as well as path computation times ⏱️
Also, pre-computing and maintaining domain trees might create a lot of administrative effort for the operator 🥲
9.7. Policy Control 📜
[RFC5394] gives extra details on policy within the PCE architecture, and it also provides context for supporting PCE Policy 🧾 Those details also apply to inter-domain P2MP path computation via the core-tree mechanism 🌈
10. Security Considerations 🚨
Okay this section is SERIOUS, so read it carefully 🫣 As described in [RFC5862], P2MP path computation requests are more CPU-intensive and also use more link bandwidth. If there's an unauthorized P2MP path computation request or a denial-of-service attack, the PCEP requests and processing that follow may be disruptive to the network 💀 So it's important that implementations conform to the relevant security requirements of [RFC5440] that specifically help minimize or negate unauthorized P2MP path computation requests and denial-of-service attacks. These mechanisms include:
- Securing the PCEP session requests and responses using TCP security techniques (Section 10.2 of [RFC5440]) 🔒
- Authenticating the PCEP requests and responses to make sure the message is intact and was sent from an authorized node (Section 10.3 of [RFC5440]) 🪪
- Providing policy control by explicitly defining which PCCs, via IP access lists, are allowed to send P2MP path requests to the PCE (Section 10.6 of [RFC5440]) 🚧
PCEP runs over TCP, so it's also important to secure the PCE and PCC against TCP denial-of-service attacks 🥶 Section 10.7.1 of [RFC5440] outlines a number of mechanisms for minimizing the risk of TCP-based denial-of-service attacks against PCEs and PCCs.
PCEP implementations SHOULD also consider the additional security provided by the TCP Authentication Option (TCP-AO) [RFC5925] 🔐
Last but definitely not least 😤 any multi-domain operation necessarily involves exchanging information across domain boundaries. That can be a significant security and confidentiality risk, especially when the domains are controlled by different commercial entities 🏢 PCEP lets individual PCEs keep their domain path information confidential by using Path-Keys [RFC5520], and it would allow for securing domain path information when performing core-tree-based path computations 💜
11. IANA Considerations 🧾
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry and the "RP Object Flag Field" sub-registry 📚
IANA has allocated a new bit from this registry as follows 🎀
Bit Description Reference
17 Core-tree computation (C-bit) [RFC7334]12. Acknowledgements 🫶
The authors would like to thank Adrian Farrel, Dan Tappan, Olufemi Komolafe, Oscar Gonzalez de Dios, and Julien Meuric for their valuable comments on this document 💖
13. References 📚
13.1. Normative References 🌟
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
- [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
- [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, September 2010.
13.2. Informative References
okay bestie, these are the "read this if you wanna go deeper" docs 📚💖 they're the background reading for everything above. the references are below exactly as written, so you can look up any of them 🫶
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for
Point-to-Multipoint Traffic-Engineered MPLS Label
Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC
4655, August 2006.
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, September 2006.
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D.
Papadimitriou, Ed., "RSVP-TE Extensions in Support
of End-to-End Generalized Multi-Protocol Label
Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-
to-Multipoint TE Label Switched Paths (LSPs)", RFC
4875, May 2007.
[RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing
Protocol Extensions for Discovery of Traffic
Engineering Node Capabilities", RFC 5073, December
2007.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang,
"A Per-Domain Path Computation Method for
Establishing Inter-Domain Traffic Engineering (TE)
Label Switched Paths (LSPs)", RFC 5152, February
2008.
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
Requirements for the Path Computation Element
Communication Protocol (PCECP)", RFC 5376, November
2008.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J.
Ash, "Policy-Enabled Path Computation Framework",
RFC 5394, December 2008.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel,
"Preserving Topology Confidentiality in Inter-Domain
Path Computation Using a Path-Key-Based Mechanism",
RFC 5520, April 2009.
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of
the Path Computation Element (PCE) to Point-to-
Multipoint (P2MP) MPLS and GMPLS Traffic Engineering
(TE)", RFC 5671, October 2009.
[RFC5862] Yasukawa, S. and A. Farrel, "Path Computation
Clients (PCC) - Path Computation Element (PCE)
Requirements for Point-to-Multipoint MPLS-TE", RFC
5862, June 2010.
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A
Set of Monitoring Tools for Path Computation Element
(PCE)-Based Architecture", RFC 5886, June 2010.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[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, November 2012.
[PCEP-MIB] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
Hardwick, "Path Computation Element Protocol (PCEP)
Management Information Base", Work in Progress,
July 2014.
[PCEP-P2MP-MIB] Zhao, Q., Dhody, D., Palle, U., and D. King,
"Management Information Base for the PCE
Communications Protocol (PCEP) When Requesting
Point-to-Multipoint Services", Work in Progress,
August 2012.
[DOMAIN-SEQ] Dhody, D., Palle, U., and R. Casellas, "Standard
Representation Of Domain-Sequence", Work in
Progress, July 2014.14. Contributors' Addresses ✨
these are the contributors, the people who helped shape the spec behind the scenes 🌸 their contact details are right here, exactly as listed
Siva Sivabalan
Cisco Systems
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
EMail: msiva@cisco.com
Tarek Saad
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
EMail: tsaad@cisco.comAuthors' Addresses 🦋
and these are the authors, the main girlies who wrote it 👑 same deal, here are their details verbatim
Quintin Zhao
Huawei Technology
125 Nagog Technology Park
Acton, MA 01719
US
EMail: quintin.zhao@huawei.com
Dhruv Dhody
Huawei Technology
Leela Palace
Bangalore, Karnataka 560008
India
EMail: dhruv.dhody@huawei.com
Daniel King
Old Dog Consulting
UK
EMail: daniel@olddog.co.uk
Zafar Ali
Cisco Systems
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
EMail: zali@cisco.com
Ramon Casellas
CTTC
Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860
Spain
EMail: ramon.casellas@cttc.es📦 where this page comes from
- ietf: rfc7334 2014-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms