RFC 9689
Use Cases for a PCE as a Central Controller (PCECC)
Internet Engineering Task Force (IETF) Request for Comments 9689 ✨
Okay bestie, let's get into this one 💅 It's RFC 9689: Use Cases for a PCE as a Central Controller (PCECC) 🎀, and it's giving SDN realness 🌈 Written by a whole squad of authors from Huawei, Etheric Networks, Tencent, and MTS Web Services (MWS) 🫶
Here's the title block tea ☕:
- Category: Informational 🦋. This means it is not an Internet Standards Track spec. It's published just to share info 💜
- Date: December 2024 🍓
- ISSN: 2070-1721 🧚
- Authors: Z. Li, D. Dhody, Q. Zhao, K. He, and B. Khasanov ✨
- Obsoletes / Updates: the title block doesn't list any, so this doc isn't replacing or changing anything else 🙈
Abstract ✨
Okay so the PCE (Path Computation Element) is a core piece of an SDN (Software-Defined Networking) system 💖 Its whole job is to figure out the best paths for traffic and to update those paths when the network or traffic demands shift 🔥 The PCE was originally built to derive Traffic Engineering (TE) paths in MPLS networks, and those paths get handed to the headend of each path through the Path Computation Element Communication Protocol (PCEP) 🦋
Here's the thing though: SDN has way more range than just signalled MPLS TE networks 👑 The PCE can help determine paths for a whole bunch of use cases, like static Label-Switched Paths (LSPs), Segment Routing (SR), Service Function Chaining (SFC), and basically most forms of routed or switched networks 🌸 So it makes sense to treat PCEP as a control protocol for these environments, so the PCE can be fully enabled as a central controller 💅
A PCE as a Central Controller (PCECC) can simplify how a distributed control plane gets processed by mixing it with SDN elements 🧚 It doesn't have to completely replace the distributed stuff, which is iconic 😭 This document covers general considerations for deploying PCECC, looks at its applicability, benefits, challenges, and limitations, and walks through a bunch of use cases 🌈 The PCEP extensions needed for the PCECC use cases are covered in separate documents, so don't look for them here 🙈
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 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 IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 for the details 🎀
Info about the current status of this doc, any errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc9689 🦋
Copyright Notice ✨
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the publication date. Please read those carefully, because they spell out your rights and restrictions for this doc 🌸 Code Components pulled from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🔥
Table of Contents 🧚
1. Introduction
2. Terminology
3. Use Cases
3.1. PCECC for Label Management
3.2. PCECC and SR
3.2.1. PCECC SID Allocation for SR-MPLS
3.2.2. PCECC for SR-MPLS Best Effort (BE) Paths
3.2.3. PCECC for SR-MPLS TE Paths
3.2.4. PCECC for SRv6
3.3. PCECC for Static TE LSPs
3.4. PCECC for Load Balancing (LB)
3.5. PCECC and Inter-AS TE
3.6. PCECC for Multicast LSPs
3.6.1. PCECC for the Setup of P2MP/MP2MP LSPs
3.6.2. PCECC for the End-to-End Protection of P2MP/MP2MP LSPs
3.6.3. PCECC for the Local Protection of P2MP/MP2MP LSPs
3.7. PCECC for Traffic Classification
3.8. PCECC for SFC
3.9. PCECC for Native IP
3.10. PCECC for BIER
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Other Use Cases of the PCECC
A.1. PCECC for Network Migration
A.2. PCECC for L3VPN and PWE3
A.3. PCECC for Local Protection (RSVP-TE)
A.4. Using Reliable P2MP TE-Based Multicast Delivery for
Distributed Computations (MapReduce-Hadoop)
Acknowledgments
Contributors
Authors' Addresses1. Introduction 🌸
Okay so the PCE [RFC4655] was originally built to take the path computation job off routers in an MPLS Traffic Engineering (TE) network 💅 It can compute optimal paths for traffic across a network and update them when the network or traffic demands change ✨ Its role has grown to cover other stuff too, like GMPLS [RFC7025] or Multicast, and it can do delegated stateful control [RFC8231] plus PCE-initiated use of network resources [RFC8281] 🦋
According to [RFC7399], Software-Defined Networking (SDN) means a separation between control elements and forwarding components, so software running in a centralized system (called a "controller") can program the network devices to behave in specific ways 🧚 A required piece of an SDN architecture is the component that plans how network resources get used and how devices get programmed 💖 You can think of it as doing specific computations to place traffic flows in the network, given what's available, how other forwarding devices are programmed, and how other flows are routed 🔥 That's the function and purpose of a PCE, and [RFC7491] shows how a PCE fits into a wider network control system (including an SDN system) 🫶
[RFC8283] lays out the architecture for the PCE as a central controller, extending the framework from [RFC4655], and shows how PCEP can act as a general southbound control protocol between the PCE and the Path Computation Client (PCC) 👑 It also digs into the motivations and applicability of PCEP as a Southbound Interface (SBI) and what that means for the protocol 🌈
[RFC9050] brings in the procedures and PCEP extensions that support the PCECC architecture [RFC8283] ⭐
This document describes the various use cases for the PCECC architecture 🎀
2. Terminology 🦋
Here's the terminology used in this doc, bestie 💜
- AS: Autonomous System
- ASBR: Autonomous System Border Router
- BGP-LS: Border Gateway Protocol - Link State [RFC9552]
- IGP: Interior Gateway Protocol (in this document, we assume IGP is either Open Shortest Path First (OSPF) [RFC2328] [RFC5340] or Intermediate System to Intermediate System (IS-IS) [RFC1195]) 🌸
- LSP: Label-Switched Path
- PCC: Path Computation Client (as per [RFC4655], any client application requesting a path computation to be performed by a PCE) 🧚
- PCE: Path Computation Element (as per [RFC4655], an entity such as a component, application, or network node that can compute a network path or route based on a network graph and apply computational constraints) ✨
- PCECC: PCE as a Central Controller (an extension of a PCE to support SDN functions as per [RFC8283]) 💖
- PST: Path Setup Type [RFC8408]
- RR: Route Reflector [RFC4456]
- SID: Segment Identifier [RFC8402]
- SR: Segment Routing [RFC8402]
- SRGB: Segment Routing Global Block [RFC8402]
- SRLB: Segment Routing Local Block [RFC8402]
- TE: Traffic Engineering [RFC9522]
3. Use Cases 🍓
Okay, so [RFC8283] describes a bunch of use cases for PCECC, like:
- using PCECC to set up static TE LSPs (the PCEP extension for this one is in [RFC9050]) 🦋
- using PCECC in SR [RFC8402] 💜
- using PCECC to set up Multicast Point-to-Multipoint (P2MP) LSPs 🌈
- using PCECC to set up Service Function Chaining (SFC) [RFC7665] 👑
- using PCECC in optical networks 🔥
Section 3.1 covers the general case of PCECC being in charge of managing the MPLS label space, which is a prerequisite for the other use cases 🫶 The later sections (SR, Multicast, and so on) show off scenarios where PCECC can be a real game changer 💅
Also, some of these use cases can be supported through BGP instead of PCEP 🙈 But in this doc, we're focused on PCEP 🎀
It's giving a whole lot of options, but that's the vibe 🌸
(Part 1 of 10. More parts coming, so stay tuned, bestie 🧚💖)
3.1. PCECC for Label Management
okay so, as per [RFC8283] 💅, in some cases the PCECC can take responsibility for managing some part of the MPLS label space for each of the routers it controls. It can even take wider responsibility for partitioning the label space for each router, allocating different parts for different uses, and telling the router about those ranges using PCEP 🎀.
[RFC9050] describes a mode where LSPs get provisioned as explicit label instructions at each hop along the end-to-end path 🦋. Each router along the path needs to be told which label forwarding instructions to program and what resources to reserve. The controller uses PCEP to talk to each router along the path of the end-to-end LSP. For this to work, the PCECC takes responsibility for managing some part of the MPLS label space for each router it controls. An extension to PCEP could let a PCC tell the PCE about that label space it's supposed to control (see [PCE-ID] for a possible PCEP extension to support advertising the MPLS label space for the PCE to control) ✨.
[RFC8664] specifies PCEP extensions that let a stateful PCE compute, update, or initiate SR-TE paths 🧚. [PCECC-SR] describes the mechanism for a PCECC to allocate and provision the node/prefix/adjacency label (Segment Routing Identifier (SID)) via PCEP. To make that allocation, the PCE needs to be aware of the label space from the Segment Routing Global Block (SRGB) or Segment Routing Local Block (SRLB) [RFC8402] of the node it controls. PCEP needs a way for a PCC to tell the PCE about that label space it's supposed to control. The full SRGB/SRLB of a node could be learned through existing IGP or BGP-LS [RFC9552] mechanisms 🌸.
There have also been proposals for a global label range in MPLS, as well as using the PCECC architecture to learn the label space of each node so it can figure out and provision that global label range 🌈.
+------------------------------+ +------------------------------+
| PCE DOMAIN 1 | | PCE DOMAIN 2 |
| +--------+ | | +--------+ |
| | | | | | | |
| | PCECC1 | ---------PCEP---------- | PCECC2 | |
| | | | | | | |
| | | | | | | |
| +--------+ | | +--------+ |
| ^ ^ | | ^ ^ |
| / \ PCEP | | PCEP / \ |
| V V | | V V |
| +--------+ +--------+ | | +--------+ +--------+ |
| | Node11 | | Node1n | | | | Node21 | | Node2n | |
| | | ...... | | | | | | ...... | | |
| | PCECC | | PCECC | | | | PCECC | |PCECC | |
| |Enabled | | Enabled| | | |Enabled | |Enabled | |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | |
+------------------------------+ +------------------------------+
Figure 1: PCECC for MPLS Label ManagementAs shown in Figure 1, here's the vibe:
- The PCC will advertise the PCECC capability to the PCECC [RFC9050]. 🫶
- The PCECC could also learn the label range set aside by the PCC (via [PCE-ID]). 👀
- Optionally, the PCECC could determine the shared MPLS global label range for the network. ⭐
- In the case that the shared global label range needs to be negotiated across multiple domains, the central controllers of these domains will also need to negotiate a common global label range across domains. 🤝
- The PCECC will need to set the shared global label range to all PCC nodes in the network. 📣
As per [RFC9050], the PCECC could also rely on the PCC to make label allocations at first and use PCEP to distribute them to wherever they're needed 💖.
3.2. PCECC and SR
SR [RFC8402] leverages the source routing paradigm, and it's giving main character energy 👑. With SR, a source node steers a packet through a path without relying on hop-by-hop signalling protocols such as LDP [RFC5036] or RSVP-TE [RFC3209]. Each path is specified as an ordered list of instructions called "segments". Each segment is an instruction to route the packet to a specific place in the network or to perform a specific service on the packet. A database of segments can be distributed through the network using an intra-domain routing protocol (such as IS-IS or OSPF), an inter-domain protocol (such as BGP), or by any other means. PCEP could also be one of those other protocols 🦋.
[RFC8664] specifies the PCEP extension specific to SR for SR over MPLS (SR-MPLS) 💜. The PCECC may further use PCEP to distribute SR Segment Identifiers (SIDs) to the SR nodes (PCCs), which comes with some perks ✨. If the PCECC allocates and maintains the SIDs in the network for the nodes and adjacencies, and then distributes them straight to the SR nodes over the PCEP session, that's more advantageous than configuring each SR node by hand and flooding the SIDs via IGP, especially in an SDN environment 🔥.
When the PCECC is used to distribute the Node-SID and Adj-SID for SR-MPLS, the Node-SID is allocated from the SRGB of the node and the Adj-SID is allocated from the SRLB of the node, as described in [PCECC-SR] 🎀.
[RFC8355] identifies various protection and resiliency use cases for SR 🛡️. Path protection lets the ingress node be in charge of failure recovery (used for SR-TE [RFC8664]). Protection can also be performed by the node adjacent to the failed component, which is commonly referred to as "local protection techniques" or "fast-reroute (FRR) techniques". In the case of the PCECC, the protection paths can be precomputed and set up by the PCE 🙌.
Figure 2 illustrates the use case where the Node-SID and Adj-SID are allocated by the PCECC for SR-MPLS 🗺️.
192.0.2.1/32
+----------+
| R1(1001) |
+----------+
|
+----------+
| R2(1002) | 192.0.2.2/32
+----------+
* | * *
* | * *
*link1| * *
192.0.2.4/32 * | *link2 * 192.0.2.5/32
+-----------+ 9001| * +-----------+
| R4(1004) | | * | R5(1005) |
+-----------+ | * +-----------+
* | *9003 * +
* | * * +
* | * * +
+-----------+ +-----------+
192.0.2.3/32 | R3(1003) | |R6(1006) |192.0.2.6/32
+-----------+ +-----------+
|
+-----------+
| R8(1008) | 192.0.2.8/32
+-----------+
Figure 2: SR Topology3.2.1. PCECC SID Allocation for SR-MPLS
Each node (PCC) is allocated a Node-SID by the PCECC 🍓. The PCECC needs to update the label mapping of each node to all the other nodes in the domain. After receiving the label mapping, each node (PCC) uses the local routing information to determine the next hop and downloads the label forwarding instructions accordingly. The forwarding behavior and the end result are the same as IGP shortest-path SR forwarding based on Node-SIDs. So from anywhere in the domain, it enforces ECMP-aware shortest-path forwarding of the packet towards the related node 💅.
The PCECC can allocate an Adj-SID for each adjacency in the network. The PCECC sends a PCInitiate message to update the label mapping of each adjacency to the corresponding nodes in the domain. Each node (PCC) downloads the label forwarding instructions accordingly. The forwarding behavior and the end result are similar to IGP-based Adj-SID allocation and usage in SR 🌟.
These mechanisms are described in [PCECC-SR] 📚.
3.2.2. PCECC for SR-MPLS Best Effort (BE) Paths
When using PCECC for SR-MPLS Best Effort (BE) Paths, the PCECC needs to allocate the Node-SID (without calculating the explicit path for the SR path) 🦄. The ingress router of the forwarding path needs to encapsulate the destination Node-SID on top of the packet. All the intermediate nodes forward the packet based on the destination Node-SID. It's basically like the LDP LSP, bestie 🫶.
R1 may send a packet to R8 simply by pushing an SR label with segment {1008} (Node-SID for R8) 💖. The path is based on the routing / next hop calculation on the routers 🛣️.
3.2.3. PCECC for SR-MPLS TE Paths 🛣️
okay so SR-TE paths don't have to follow the IGP shortest path tree (SPT) 🙃 a PCECC can pick one of these non-shortest routes and set it up on the ingress node of the SR-TE path. The SR header is just a list of SIDs (or MPLS labels), and it carries everything the packets need to get from the ingress node all the way to the egress node. So no signalling protocol needed, bestie 💅 For a strict traffic engineering path, every Adj-SID gets stacked. Otherwise you can mix Node-SIDs and Adj-SIDs for the SR-TE paths 🦋
Look at Figure 3: R1 can send a packet to R8 by pushing an SR header with the segment list {1002, 9001, 1008}. 1002 and 1008 are the Node-SIDs of R2 and R8, and 9001 is the Adj-SID for link1. The path is "R1-R2-link1-R3-R8" ✨
To make this happen, the PCECC first allocates and distributes SIDs the way we covered in Section 3.2.1. And [RFC8664] is the one that explains how a PCE computes, updates, or initiates SR-MPLS TE paths 📜
192.0.2.1/32
+----------+
| R1 (1001)|
+----------+
| |
90011 | |90012
link1 | |link2
+----------+
| R2 (1002)| 192.0.2.2/32
+----------+
link3 * | * * link4
90023 * | * * 90024
*link5| * *
192.0.2.4/32 *90025 | *link6 * 192.0.2.5/32
+-----------+ | *90026+-----------+
| R4 (1004) | | * | R5 (1005) |
+-----------+ | * +-----------+
* | * +
link10 * | * link7 +
* | * +
+-----------+ +-----------+
192.0.2.3/32 | R3 (1003) | |R6 (1006) |192.0.2.6/32
+-----------+ +-----------+
| |
|link8 |
| |----------|link9
+-----------+
| R8 (1008) | 192.0.2.8/32
+-----------+
Figure 3: PCECC TE LSP Setup ExamplePeep Figure 3 for the TE topology, where 100x are Node-SIDs and 900xx are Adj-SIDs 🌸
- The SID allocation and distribution is handled by the PCECC for all Node-SIDs (100x) and all Adj-SIDs (900xx) 🧚
- Based on path computation request/delegation or PCE initiation, the PCECC gets a request with constraints and optimization criteria from a PCC 📬
- The PCECC works out the optimal path based on the given constraints (e.g., bandwidth (BW)) 🧠
- The PCECC provisions the SR-MPLS TE LSP path
("R1-link1-R2-link6-R3-R8")at the ingress node:{90011, 1002, 90026, 1003, 1008}🎀 - For end-to-end protection, the PCECC can provision the secondary path
("R1-link2-R2-link4-R5-R8"):{90012, 1002, 90024, 1005, 1008}🛡️
3.2.3.1. PCECC for SR Policy 🍓
okay, so [RFC8402] is where the SR architecture lives, and it uses an SR Policy to steer packets from a node through an ordered list of segments 🦋 The SR Policy could be configured on the headend or set up by an SR controller. The SR architecture doesn't restrict how the controller programs the network. Here we're focusing on PCEP as the protocol that delivers SR Policies from the PCE to the PCC 💜
The SR Policy architecture is described in [RFC9256]. An SR Policy is a framework that lets you instantiate an ordered list of segments on a node, so that node can run a source routing policy and steer traffic for a specific purpose (e.g., for a specific Service Level Agreement (SLA)) ✨
An SR Policy is identified through the tuple <headend, color, endpoint> 🔑
Figure 3 is our example of a PCECC application for SR Policy instantiation for SR-MPLS, where the Node-SIDs are 100x and the Adj-SIDs are 900xx 🌈
Say R1 needs two disjoint SR Policies towards R8, based on different BWs. The possible paths are:
- POL1:
{Headend R1, color 100, Endpoint R8; Candidate Path1: Segment List 1: {90011, 1002, 90023, 1004, 1003, 1008}}💖 - POL2:
{Headend R1, color 200, Endpoint R8; Candidate Path1: Segment List 1: {90012, 1002, 90024, 1005, 1006, 1008}}💖
Each SR Policy (including the candidate path and segment list) gets signalled to a headend (R1) via PCEP [PCEP-POLICY] with an ASSOCIATION object added. A Binding SID (BSID) [RFC8402] can be used to steer labelled traffic into an SR Policy, and a BSID can be provisioned from the PCECC over PCEP too [RFC9604]. For non-labelled traffic steering into the SR Policy POL1 or POL2, you use per-destination traffic steering with the BGP Color Extended Community [RFC9012] 🫶
Here's the procedure:
- The PCECC allocates Node-SIDs and Adj-SIDs using the mechanism in Section 3.2.1 for all nodes and links 🧩
- The PCECC calculates disjoint paths for POL1 and POL2 and creates segment lists for them:
{90011, 1002, 90023, 1004, 1003, 1008};{90012, 1002, 90024, 1005, 1006, 1008}🧮 - The PCECC forms both SR Policies POL1 and POL2 🎉
- The PCECC sends both POL1 and POL2 to R1 via PCEP 📨
- The PCECC optionally allocates BSIDs for the SR Policies 🌟
- Traffic from R1 to R8 that fits color 100 gets steered to POL1 and follows the path
"R1-link1-R2-link3-R4-R3-R8". Traffic from R1 to R8 that fits color 200 gets steered to POL2 and follows the path"R1-link2-R2-link4-R5-R6-R8". Since a candidate path of each POL1/POL2 can hold many segment lists, the PCECC could provision more paths towards R8, and traffic gets balanced either as ECMP or as weighted-ECMP (W-ECMP). This is the advantage of the SR Policy architecture 🚀
Note that an SR Policy can be associated with multiple candidate paths. A candidate path is selected when it is valid and it is determined to be the best path of the SR Policy, as described in [RFC9256] 👑
3.2.4. PCECC for SRv6 🌸
As [RFC8402] says, with SR a node steers a packet through an ordered list of instructions called segments 💅 SR can be applied to the IPv6 architecture using the Segment Routing Header (SRH) [RFC8754]. A segment is encoded as an IPv6 address, and an ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the destination address of the packet. When a segment is completed, a pointer in the new routing header is incremented and points at the next segment 🦋
As [RFC8754] puts it, an SR over IPv6 (SRv6) Segment is a 128-bit value. "SRv6 SID" or just "SID" is often used as a shorter reference for "SRv6 Segment". [RFC8986] defines the SRv6 SID as consisting of LOC:FUNCT:ARG 🧠
[RFC9603] extends [RFC8664] to support SR for the IPv6 data plane 🌈 A PCECC could also be extended to support SRv6 SID allocation and distribution. An example of how PCEP extensions could be extended for SRv6 for a PCECC is described in [PCECC-SRv6] 💜
2001:db8::1
+----------+
| R1 |
+----------+
|
+----------+
| R2 | 2001:db8::2
+----------+
* | * *
* | * *
*link1| * *
2001:db8::4 * | *link2 * 2001:db8::5
+-----------+ | * +-----------+
| R4 | | * | R5 |
+-----------+ | * +-----------+
* | * * +
* | * * +
* | * * +
+-----------+ +-----------+
2001:db8::3 | R3 | |R6 |2001:db8::6
+-----------+ +-----------+
|
+-----------+
| R8 | 2001:db8::8
+-----------+
Figure 4: PCECC for SRv6In this case, as Figure 4 shows, the PCECC could assign the SRv6 SID (in the form of an IPv6 address) to be used for nodes and adjacencies. Later, the SRv6 path, in the form of a list of SRv6 SIDs, could be used at the ingress. A few examples:
- The best path towards R8:
SRv6 SID-List={2001:db8::8}🎯 - The path towards R8 via R5:
SRv6 SID-List={2001:db8::5, 2001:db8::8}🧭
The rest of the procedures and mechanisms remain the same as SR-MPLS 🫶
3.3. PCECC for Static TE LSPs ✨
okay so, as Section 3.1.2 of [RFC8283] explains, the PCECC architecture can totally set up static TE LSPs 🛤️ 💖 Here's the trick: regular PCEP gets used to chat between the PCECC and every node along the path, so it can hand out explicit label instructions at each hop of the end-to-end path. Every router along the way needs to be told which label-forwarding instructions to program and which resources to reserve. The PCECC keeps the big-picture view of the network, works out the paths for the end-to-end LSPs, and then the controller uses PCEP to talk to each router on that path. It's giving organized 🧚
192.0.2.1/32
+----------+
| R1 |
+----------+
| |
|link1 |
| |link2
+----------+
| R2 | 192.0.2.2/32
+----------+
link3 * | * * link4
* | * *
*link5| * *
192.0.2.4/32 * | *link6 * 192.0.2.5/32
+-----------+ | * +-----------+
| R4 | | * | R5 |
+-----------+ | * +-----------+
* | * * +
link10 * | * *link7 +
* | * * +
+-----------+ +-----------+
192.0.2.3/32 | R3 | |R6 |192.0.2.6/32
+-----------+ +-----------+
| |
|link8 |
| |link9
+-----------+
| R8 | 192.0.2.8/32
+-----------+Figure 5: PCECC TE LSP Setup Example
Check out Figure 5 for the example TE topology 🦋
- Based on path computation request/delegation or PCE initiation, the PCECC gets a request with constraints and optimization criteria 📥
- The PCECC is going to calculate the optimal path based on the given constraints (for example, BW) 🧮
- The PCECC provisions each node along the path and assigns incoming and outgoing labels from R1 to R8, with the path being
"R1-link1-R2-link3-R4-link10-R3-link8-R8"💅- R1: Outgoing label
1001on link 1 - R2: Incoming label
1001on link 1 - R2: Outgoing label
2003on link 3 - R4: Incoming label
2003on link 3 - R4: Outgoing label
4010on link 10 - R3: Incoming label
4010on link 10 - R3: Outgoing label
3008on link 8 - R8: Incoming label
3008on link 8
- R1: Outgoing label
- This can also be represented as:
{R1, link1, 1001}, {1001, R2, link3, 2003}, {2003, R4, link10, 4010}, {4010, R3, link8, 3008}, {3008, R8}🌸 - For the end-to-end protection, the PCECC programs each node along the path from R1 to R8 with the secondary path:
{R1, link2, 1002}, {1002, R2, link4, 2004}, {2004, R5, link7, 5007}, {5007, R3, link9, 3009}, {3009, R8}🛡️ - It's also possible to have a bypass path for local protection set up by the PCECC 🙈 For example, use the primary path as above, and then to protect node R4 locally, the PCECC can program the bypass path like this:
{R2, link5, 2005}, {2005, R3}. By doing this, node R4 is locally protected at R2 💜
3.4. PCECC for Load Balancing (LB) 🍓
ngl, a lot of service providers use TE tunnels to deal with non-deterministic paths in their networks 😭 One example is using TEs in the mobile backhaul (MBH). Take a look at the topology in Figure 6, where AGG 1...AGG N are Aggregation routers and Core 1...Core N are Core routers.
TE1 ----------->
+--------+ +------+ +-----+ +-------+ +------+ +---+
|Access |----|Access|----|AGG 1|----|AGG N-1|----|Core 1|--|SR1|
|SubNode1| |Node1 | +-----+ +-------+ +------+ +---+
+--------+ +------+ | | | ^ |
| Access | Access | AGG Ring 1| | |
| SubRing 1 | Ring 1 | | | | |
+--------+ +------+ +-----+ | | |
|Access | |Access| |AGG 2| | | |
|SubNode2| |Node2 | +-----+ | | |
+--------+ +------+ | | | | |
| | | | | | |
| | | +---TE2---|-+ |
+--------+ +------+ +-----+ +-------+ +------+ +---+
|Access | |Access|----|AGG 3|----| AGG N |----|Core N|--|SRn|
|SubNodeN|----|NodeN | +-----+ +-------+ +------+ +---+
+--------+ +------+Figure 6: PCECC LB Use Case
This MBH setup uses L2 access rings and sub-rings, and L3 kicks in at the aggregation layer 🧠 To keep things simple, the figure only shows one access sub-ring. The access ring and aggregation ring are hooked up with Nx10GE interfaces. The aggregation domain runs its own IGP. There are two egress routers, AGG N-1 and AGG N, that connect to the Core domain (Core 1...Core N) over L2 interfaces. The Core also connects to service routers, and RSVP-TE or SR-TE is used for MPLS transport inside the ring. There could be at least two tunnels (one way) from each AGG router to the egress AGG routers. Plus, lots of L2 access rings hook up to the AGG routers 🌈
Service deployment happens through Layer 2 Virtual Private Networks (L2VPNs), Virtual Private LAN Services (VPLSs), Layer 3 Virtual Private Networks (L3VPNs), or Ethernet VPNs (EVPNs). Those services use MPLS TE (or SR-TE) as transport towards the egress AGG routers. TE tunnels can also be used as transport towards service routers when the architecture is based on seamless MPLS [MPLS-SEAMLESS] ✨
Load Balancing (LB) between TE tunnels means spreading network traffic across multiple TE tunnels so you get the most out of your network resources, better performance, and reliability 💪 Some common techniques are Equal-Cost Multipath (ECMP) and Unequal-Cost Multipath (UCMP), which is based on the BW of the TE tunnels.
There are a few things that need solving:
- Perform automatic LB amongst TE tunnels according to current traffic loads 📊
- Manage TE BW by guaranteeing BW for specific services (such as High-Speed Internet (HSI), IPTV, etc.) and enabling time-based BW reservation (such as Bandwidth on Demand (BoD)) 🎬
- Simplify the development of TE tunnels through automation, with no manual intervention needed 🤖
- Provide flexibility for service router placement (anywhere in the network, by creating transport LSPs to them) 🗺️
In this section, the focus is on LB tasks. LB tasks can be solved with the PCECC in the following ways:
- Applications, network services, or operators can ask the SDN controller (PCECC) for LSP-based LB between AGG X and AGG N/AGG N-1 (the egress AGG routers that connect to the core). Each of these comes with associated constraints (such as BW, inclusion or exclusion of specific links or nodes, number of paths, Objective Function (OF), need for disjoint LSP paths, etc.) 🧩
- The PCECC could calculate multiple (say N) LSPs according to the given constraints. The calculation is based on the results of the OF [RFC5541], constraints, endpoints, same or different BW, different links (in case of disjoint paths), and other constraints 🧠
- Depending on the given LSP PST, the PCECC downloads instructions to the PCC. At this stage, it is assumed the PCECC is aware of the label space it controls, and SID allocation and distribution is already done in the case of SR 🔥
- The PCECC sends a PCInitiate message [RFC8281] towards the ingress AGG X router (PCC) for each of the N LSPs, and receives a PCRpt message [RFC8231] back from the PCCs. If the PST is a PCECC-SR, the PCECC includes a SID stack as per [RFC8664]. If the PST is set to "PCECC" type, then the PCECC assigns labels along the calculated path and sets up the path by sending central controller instructions in a PCEP message to each node along the LSP's path, as per [RFC9050]. Then the PCECC sends a PCUpd message to the ingress AGG X router with information about the new LSP. AGG X (PCC) replies with a PCRpt containing the LSP status 💌
- AGG X, as an ingress router, now has N LSPs towards AGG N and AGG N-1. These are available for installation in the router's forwarding table and for LB traffic between them. How traffic gets spread across those LSPs depends on the particular realization of the hash function on that router 🌊
- Since the PCECC is aware of the Traffic Engineering Database (TED) (TE state) and the LSP Database (LSP-DB), it can manage and prevent possible over-subscriptions and limit the number of available load-balance states. Through a PCECC mechanism, the control can take quick actions in the network by directly provisioning the central control instructions ⚡
3.5. PCECC and Inter-AS TE ✨
okay so bestie, let's talk about Inter-AS TE LSPs 🦋 there are a few signalling options for setting these up: contiguous TE LSPs [RFC5151], stitched TE LSPs [RFC5150], and nested TE LSPs [RFC4206]. pick your fighter 💅
the requirements for PCE-based Inter-AS setup [RFC5376] spell out the approach and the PCEP functionality you need to make these LSPs happen. literally the blueprint 🎀
[RFC5376] also gives an Inter-AS and Intra-AS PCE Reference Model (Figure 7 in that doc). here's a shortened version, because simple is iconic 🌸
Inter-AS Inter-AS
PCC <-->PCE1<--------->PCE2
:: :: ::
:: :: ::
R1----ASBR1====ASBR3---R3---ASBR5
| AS1 | | PCC |
| | | AS2 |
R2----ASBR2====ASBR4---R4---ASBR6
:: ::
:: ::
Intra-AS Intra-AS
PCE3 PCE4
Figure 7: Shortened Form of the Inter-AS and Intra-AS PCE
Reference Modelso the PCECCs in different domains can team up to set up Inter-AS TE LSPs 👑 the stateful Hierarchical PCE (H-PCE) mechanism [RFC8751] could also be used to set up a per-domain PCECC LSP first. those can then get stitched together into an Inter-AS TE LSP, as described in [PCE-INTERDOMAIN] ✨
for simplicity we're focusing on a simpler Inter-AS case where AS1 and AS2 belong to the same service provider administration 🧚 in that case, the Inter-AS and Intra-AS PCEs can be combined into one single PCE, if that combined PCE can handle the load. the PCE will need interfaces (PCEP and BGP-LS) to both domains. PCECC redundancy mechanisms are described in [RFC8283] 🫶 so routers (PCCs) in AS1 and AS2 can send PCEP messages to the same PCECC.
in Figure 8, the PCECC keeps a BGP-LS session with Route Reflectors (RRs) in each AS. this lets the RRs pass routes along to other BGP routers (clients) without needing a full mesh 🙈 the RRs act as a BGP-LS Propagator, and the PCECC acts as a BGP-LS Consumer [RFC9552] ✨
+----BGP-LS------+ +------BGP-LS-----+
| | | |
+-PCEP-|----++-+-------PCECC-----PCEP--++-+-|-------+
+-:------|----::-:-+ +--::-:-|-------:---+
| : | :: : | | :: : | : |
| : RR1 :: : | | :: : RR2 : |
| v v: : | LSP1 | :: v v |
| R1---------ASBR1=======================ASBR3--------R3 |
| | v : | | :v | |
| +----------ASBR2=======================ASBR4---------+ |
| | Region 1 : | | : Region 1 | |
|----------------:-| |--:-------------|--|
| | v | LSP2 | v | |
| +----------ASBR5=======================ASBR6---------+ |
| Region 2 | | Region 2 |
+------------------+ <--------------> +-------------------+
MPLS Domain 1 Inter-AS MPLS Domain 2
<=======AS1=======> <========AS2=======>
Figure 8: Particular Case of Inter-AS PCEin this Inter-AS TE scenario from Figure 8, the service provider runs both domains (AS1 and AS2) 💖 each one has its own IGP and MPLS transport. we need Inter-AS LSPs on top of those to carry different services (like Voice, L3VPN, etc.) 🍓 the Inter-AS links come in different capacities across several regions. so the job isn't just provisioning those Inter-AS LSPs with the given constraints. it's also calculating the path and pre-setting up the backup Inter-AS LSPs that get used if the primary LSP fails. big brain stuff 🧠✨
looking at Figure 8: LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and that's your primary Inter-AS LSP 👑 LSP2 from R1 to R3, going via ASBR5 and ASBR6, is the backup 🦋 there could also be a bypass LSP to protect against ASBR or Inter-AS link failures too 🛡️
once PCECC functionality gets added to the PCE (the SDN controller), the PCECC-based Inter-AS TE model should follow the PCECC use case for TE LSPs. that includes the requirements in [RFC5376], with these extra details:
💅 the bullets below are the step-by-step vibe, so read them in order
- the PCECC needs to know the topology of both domains (AS1 and AS2). it can use BGP-LS peering with the BGP routers (or RRs) in both domains 🌸
- the PCECC needs PCEP connectivity with all routers in both domains (see also Section 4 of [RFC5376]) 🔥
- the operator's application or service orchestrator creates a tunnel creation request for a specific service. the PCECC gets that request over the Northbound Interface (NBI). the NBI type is implementation-dependent, so it could be NETCONF/YANG, REST, etc. 💀 then the PCECC calculates the optimal path based on the OF and the given constraints (i.e., PST, BW, etc.). those constraints include the ones from [RFC5376], like priority, AS sequence, preferred ASBR, disjoint paths, and protection type 🎀 at this point, we have two paths: "R1-ASBR1-ASBR3-R3" and "R1-ASBR5-ASBR6-R3" 🧚
- the PCECC uses central control to download instructions to the PCC based on the PST. at this stage, the PCECC is assumed to know the label space it controls. for SR, the SID allocation and distribution is already done 👑
- the PCECC sends a PCInitiate message [RFC8281] to the ingress router R1 (PCC) in AS1, and gets a PCRpt message [RFC8231] back from it.
- if the PST is SR-MPLS, the PCECC includes the SID stack as per [RFC8664]. optionally, a BSID or BGP Peering-SID [RFC9087] can also go on the AS boundary 🦋 the backup SID stack can be installed at ingress R1, but more importantly, each node along the SR path can also do local protection based just on the top segment 🛡️
- if the PST is a PCECC, the PCECC assigns labels along the calculated paths ("R1-ASBR1-ASBR3-R3", "R1-ASBR5-ASBR6-R3") and sets up the path by sending central controller instructions in a PCEP message to each node along the path of the LSPs, as per [RFC9050] ✨ after these steps, the PCECC sends a PCUpd message to the ingress R1 router with info about the new LSPs, and R1 replies with a PCRpt containing the LSP(s) status 💖
- after all that, R1 has primary and backup TEs (LSP1 and LSP2) towards R3. it's up to the router implementation how it switches over to backup LSP2 if LSP1 fails 🫶
3.6. PCECC for Multicast LSPs 🌈
multicast LSPs can be set up via the RSVP-TE P2MP or Multipoint LDP (mLDP) protocols. but setting these up can need manual configuration and complex signalling once protection gets involved 😭 with PCECC, the multicast LSP can be computed and set up through a centralized controller that has the full picture of the topology and BW usage for each link. so it not only cuts down on the complex configuration you'd need with distributed RSVP-TE P2MP or mLDP signalling, it can also compute the disjoint primary path and secondary P2MP path efficiently 💅✨
3.6.1. PCECC for the Setup of P2MP/MP2MP LSPs 🦋
it's assumed the PCECC knows the label space it controls for all nodes, and it makes allocations accordingly 🧚
+----------+
| R1 | Root Node of the multicast LSP
+----------+
|9000 (link0)
+----------+
Transit Node | R2 |
branch +----------+
* | * *
9001* | * *9002
link1 * | * *link2
+-----------+ | * +-----------+
| R4 | | * | R5 | Transit Nodes
+-----------+ | * +-----------+
* | * * +
9003* | * * +9004
link3 * | * * +link4
+-----------+ +-----------+
| R3 | | R6 | Leaf Node
+-----------+ +-----------+
9005| link5
+-----------+
| R8 | Leaf Node
+-----------+
Figure 9: Using a PCECC for the Setup of P2MP/MP2MP LSPshere are the P2MP examples (based on Figure 9), where R1 is the root and routers R8 and R6 are the leaves 🌸
- based on the P2MP path computation request/delegation or PCE initiation, the PCECC gets the request with its constraints and optimization criteria 💖
- the PCECC calculates the optimal P2MP path according to the given constraints (i.e., BW) 🔥
- the PCECC provisions each node along the path and assigns incoming and outgoing labels from R1 to {R6, R8}, with the paths "R1-link0-R2-link2-R5-link4-R6" and "R1-link0-R2-link1-R4-link3-R3-link5-R8":
- R1: Outgoing label 9000 on link0
- R2: Incoming label 9000 on link0
- R2: Outgoing label 9001 on link1 (*)
- R2: Outgoing label 9002 on link2 (*)
- R5: Incoming label 9002 on link2
- R5: Outgoing label 9004 on link4
- R6: Incoming label 9004 on link4
- R4: Incoming label 9001 on link1
- R4: Outgoing label 9003 on link3
- R3: Incoming label 9003 on link3
- R3: Outgoing label 9005 on link5
- R8: Incoming label 9005 on link5
- this can also be written as: {R1, 6000}, {6000, R2, {9001, 9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, R3, 9005}, {9004, R6}, {9005, R8} 🧚 the main difference (*) is the branch node instruction at R2, where two copies of a packet go towards R4 and R5 with labels 9001 and 9002 respectively 🦋
the packet forwarding goes like this 👑
- Step 1. R1 sends a packet to R2 by simply pushing label 9000 onto the packet 💅
- Step 2. when R2 gets the packet with label 9000, it forwards it to R4 by swapping 9000 to 9001. at the same time, it replicates the packet, swaps label 9000 to 9002, and forwards it to R5 🌈
- Step 3. when R4 gets the packet with label 9001, it forwards it to R3 by swapping 9001 to 9003. when R5 gets the packet with label 9002, it forwards it to R6 by swapping 9002 to 9004 ✨
- Step 4. when R3 gets the packet with label 9003, it forwards it to R8 by swapping it to 9005. when R5 gets the packet with label 9002, it gets swapped to 9004 and sent to R6 💀
- Step 5. when R8 gets the packet with label 9005, it pops the label. when R6 gets the packet with label 9004, it pops the label too 🎀
3.6.2. PCECC for the End-to-End Protection of P2MP/MP2MP LSPs 🛡️
okay so this part is about end-to-end managed path protection, plus local protection with operation management in the PCECC network for P2MP/MP2MP LSPs 🦋
the end-to-end protection idea is that you can compute a backup P2MP or MP2MP LSP too ✨ while the PCECC is working out the primary multicast trees, it can also think about a secondary tree. it can compute the primary and backup P2MP (or MP2MP) LSPs together, or one after the other 💅
+----+ +----+
Root Node of LSP | R1 |--| R11|
+----+ +----+
/ +
10/ +20
/ +
+----------+ +-----------+
Transit Node | R2 | | R3 |
+----------+ +-----------+
| \ + +
| \ + +
10| 10\ +20 20+
| \ + +
| \ +
| + \ +
+-----------+ +-----------+ Leaf Nodes
| R4 | | R5 | (Downstream LSR)
+-----------+ +-----------+Figure 10: PCECC for the End-to-End Protection of P2MP/MP2MP LSPs
in Figure 10, the PCECC sets up the primary multicast tree from the root node R1 to the leaves, which is R1->R2->{R4, R5}. at the same time, it can set up the backup tree, which is R1->R11->R3->{R4, R5} 🌸 both trees (the primary forwarding tree and the secondary forwarding tree) get downloaded to each router along the primary path and the secondary path. normally the traffic flows through R1->R2->{R4, R5}, but if a node in the primary tree fails (say R2), the root node R1 switches the flow over to the backup tree, R1->R11->R3->{R4, R5} 🔥 the best part is that path computation, label downloading, and finally forwarding all happen through the PCECC, so there's no complex signalling like you'd need with P2MP RSVP-TE or mLDP 🙌
3.6.3. PCECC for the Local Protection of P2MP/MP2MP LSPs 🧚
this section covers local protection in the PCECC network for P2MP/MP2MP LSPs 💜
while the PCECC sets up the primary multicast tree, it can also build a backup LSP between the Point of Local Repair (PLR), the protected node, and the Merge Points (MPs), which are the downstream nodes of the protected node 🍓 when there are tons of downstream nodes, this avoids unnecessary packet duplication on the PLR and protects the network from traffic congestion risks. literally genius 😭
+------------+
| R1 | Root Node
+------------+
.
.
.
+------------+ Point of Local Repair /
| R10 | Switchover Point
+------------+ (Upstream LSR)
/ +
10/ +20
/ +
+----------+ +-----------+
Protected Node | R20 | | R30 |
+----------+ +-----------+
| \ + +
| \ + +
10| 10\ +20 20+
| \ + +
| \ +
| + \ +
+-----------+ +-----------+ Merge Point
| R40 | | R50 | (Downstream LSR)
+-----------+ +-----------+
. .
. .Figure 11: PCECC for the Local Protection of P2MP/MP2MP LSPs
in Figure 11, the PCECC sets up the primary multicast path around the PLR node R10 to protect node R20, which is R10->R20->{R40, R50}. it can also set up the backup path R10->R30->{R40, R50} at the same time 💅 both the primary forwarding path and the secondary bypass forwarding path get downloaded to each router along the primary path and the secondary bypass path. traffic normally goes through R10->R20->{R40, R50}, and if node R20 fails, the PLR node R10 switches the flow to the backup path, R10->R30->{R40, R50} ✨ and yes, once again, path computation, label downloading, and forwarding happen through the PCECC with no complex P2MP RSVP-TE or mLDP signalling 🦋
3.7. PCECC for Traffic Classification 🎀
okay traffic classification is a big deal in traffic engineering 👑 as described in [RFC8283], it's basically the process of looking into a packet to figure out how it should be treated while it's forwarded through the network 🌈 it shows up in a bunch of places:
- MPLS traffic engineering (where it decides what traffic gets forwarded into which LSPs),
- SR (where it's used to pick which set of forwarding instructions (SIDs) to add to a packet), and
- SFC (where it says how a packet should go across which service function path).
when you pair it with traffic engineering, classification becomes a huge enabler for LB 🫶 it's super tightly linked to the computational stuff used to plan network functions, because it decides how traffic gets balanced and spread across the network. so picking which traffic classification mechanism a router should use is a major part of the PCECC's job 💖
the way traffic flows get described by combining multiple Flow Specification components, and then disseminated as traffic Flow Specifications, is described for BGP in [RFC8955] 🌸 when a PCECC uses PCEP to initiate tunnels (like TE LSPs or SR paths), it's really important that the headend of the tunnel knows what traffic to put on each tunnel 😭 [RFC9168] defines a set of PCEP extensions for this, so the instructions get passed from the PCECC to the routers over PCEP 🧚
there are also a few more questions about the tunnels the PCECC sets up that need thinking through ✨
- how to use it,
- whether it is a virtual link,
- whether to advertise it in the IGP as a virtual link, and
- what bits of this information to signal to the tail end.
these are out of the scope of this document 🙈
3.8. PCECC for SFC 🍓
Service Function Chaining (SFC) is described in [RFC7665] 🌈 it's the process of steering traffic through specific hardware devices or virtual machines (called service function nodes) that can do particular useful things to the traffic 💅 the set of functions, and the order they run in, is called a service function chain. add the locations where those functions happen and you get a Service Function Path (SFP) ✨ each packet gets marked as belonging to a specific SFP, and that marking tells each service function node which functions to run and which node to send the packet to next 🦋 to run an SFC network, the service function nodes have to be configured to understand those markings, and the edge nodes have to be told how to mark packets coming in. sometimes you also need tunnels between service function nodes to carry the traffic 🌸 planning an SFC network needs LB between service function nodes plus traffic engineering across the network connecting them. as per [RFC8283], these are all things a PCECC can do, and it can use PCEP to program the network, install the service function chains, and set up any tunnels that are needed 👑
a possible mechanism could add support for SFC-based central control instructions 💜 the PCECC will be able to instruct each Service Function Forwarder (SFF) along the SFP, including:
- Service Path Identifier (SPI): Uniquely identifies an SFP.
- Service Index (SI): Provides location within the SFP.
- Provide SFC Proxy handling instruction.
the PCECC can set the traffic classification rules (per Section 3.7) at the classifier so it imposes the Network Service Header (NSH) [RFC8300] 🔥 it can also download forwarding instructions to each SFF along the way so they can process the NSH and forward accordingly 🫶 that includes instructions for the service classifier that handles the context header, metadata, and so on. this metadata/context gets shared among SFs and classifiers, between SFs, and between external systems (like a PCECC) and SFs ✨ as [RFC7665] explains, the SFC encapsulation is what enables sharing metadata/context information along the SFP 🌈
SFC can also work with SR, with or without an NSH, as described in [RFC9491] and [SR-SERVICE] 🦋 PCECC techniques can also be used for service-function-related segments and SR service policies 💖
3.9. PCECC for Native IP ✨
okay so bestie, [RFC8735] is the one that walks through the scenarios and simulation results for the "Centralized Control Dynamic Routing (CCDR)" solution 🦋 it's giving "best of both worlds" because it keeps the distributed protocols (IGP/BGP) and adds the power of centralized control (PCE/SDN) 💅 the goal is traffic engineering for native IP networks 🌸 [RFC8821] then defines the framework for CCDR traffic engineering inside a native IP network, using multiple BGP sessions and a PCE as the centralized controller 💜
the PCECC has to send instructions to the PCCs so they can build multiple BGP sessions, distribute different prefixes on those established sessions, and assign different paths to the BGP next hops 🔥 PCEP carries the key parameters between the PCE and the underlying network devices (the PCCs) when you're using the PCECC technique 🎀 the central control instructions from the PCECC to the PCC tell the router which prefix gets advertised on which BGP session, so it's super precise ✨ the PCEP extensions for all of this are defined in [PCEP-NATIVE] 🧚
+------+
+----------+ PCECC+-------+
| +------+ |
| |
PCEP | BGP Session 1(lo11/lo21)| PCEP
+-------------------------+
| |
| BGP Session 2(lo12/lo22)|
+-------------------------+
PF12 | | PF22
PF11 | | PF21
+---+ +-----+-----+ +-----+-----+ +---+
|SW1+---------+(lo11/lo12)+-------------+(lo21/lo22)+-----------+SW2|
+---+ | R1 +-------------+ R2 | +---+
+-----------+ +-----------+Figure 12: PCECC for Native IP 🌈
in the setup shown in Figure 12, the PCECC instructs both R1 and R2 on how to form BGP sessions with each other via PCEP, and on which IP prefixes need to be advertised via which BGP session 💖 main character energy for the controller, honestly 👑
3.10. PCECC for BIER
okay this one's a bit of a brain-melter, but I got you 🧠✨ [RFC8279] defines Bit Index Explicit Replication (BIER), an architecture where every intended multicast receiver gets encoded as a BitMask in the multicast packet header, inside different encapsulations 🌸 a router that gets one of these packets forwards it based on the bit position in the header toward the receiver(s), following a precomputed tree for each of the bits in the packet 🦋 each receiver is represented by its own unique bit in the BitMask, so it's giving very organized 💅
[RFC9262] is BIER-TE, and it shares the architecture and packet formats with BIER 🫶 BIER-TE forwards and replicates packets based on a BitString in the packet header, but here every BitPosition in the BitString of a BIER-TE packet indicates one or more adjacencies 😭 BIER-TE paths can be derived from a PCE and used at the ingress (a possible mechanism is described in [PCEP-BIER]) 🍓
the PCECC mechanism could be used to allocate bits for the BIER router for BIER, and also for the adjacencies for BIER-TE 💜 PCECC-based controllers can use PCEP to instruct BIER-capable routers on the meaning of the bits, plus other fields needed for BIER encapsulation ✨ the PCECC could also program the BIER router with various parameters used in the BIER encapsulation (things like the BIER sub-domain-id, BFR-id, etc.) for both the node and the adjacency 🔥
a possible way to use the PCECC and PCEP extension is described in [PCECC-BIER] 🎀
4. IANA Considerations ✨
This document has no IANA actions. 🌸
5. Security Considerations 💀
okay security is SERIOUS bestie, so read this one carefully 🫶 [RFC8283] explains how the security considerations for a PCECC are a little different from those for any other PCE system 😭 PCECC operations rely heavily on the use and security of PCEP, so due consideration should be given to the security features discussed in [RFC5440] and the additional mechanisms described in [RFC8253] 🔐 it also lists the vulnerabilities of a central controller architecture, like a central point of failure, denial of service, and a focus on interception and modification of messages sent to individual Network Elements (NEs) 🙈 scary but important!
as per [RFC9050], Transport Layer Security (TLS) in PCEP is recommended, because it provides support for peer authentication, message encryption, and integrity 💖 it also provides mechanisms for associating peer identities with different levels of access and/or authoritativeness, via an attribute in X.509 certificates or a local policy with a specific accept-list of X.509 certificates 👑 this can be used to check the authority for PCECC operations 🧚
it is expected that each new document produced for a specific use case will also include considerations of the security impacts of using a PCECC on the network type and services being managed 🌈
6. References
6.1. Normative References
[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>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[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>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
Architecture for Use of PCE and the PCE Communication
Protocol (PCEP) in a Network with Central Control",
RFC 8283, DOI 10.17487/RFC8283, December 2017,
<https://www.rfc-editor.org/info/rfc8283>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.6.2. Informative References
[MAP-REDUCE]
Lee, K., Choi, T., Ganguly, A., Wolinsky, D., Boykin, P.,
and R. Figueiredo, "Parallel Processing Framework on a P2P
System Using Map and Reduce Primitives",
DOI 10.1109/IPDPS.2011.315, May 2011,
<https://leeky.me/publications/mapreduce_p2p.pdf>.
[MPLS-DC] Afanasiev, D. and D. Ginsburg, "MPLS in DC and inter-DC
networks: the unified forwarding mechanism for network
programmability at scale", March 2014,
<https://www.slideshare.net/DmitryAfanasiev1/yandex-
nag201320131031>.
[MPLS-SEAMLESS]
Leymann, N., Ed., Decraene, B., Filsfils, C.,
Konstantynowicz, M., Ed., and D. Steinberg, "Seamless MPLS
Architecture", Work in Progress, Internet-Draft, draft-
ietf-mpls-seamless-mpls-07, 28 June 2014,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
seamless-mpls-07>.
[PCE-ID] Li, C., Shi, H., Ed., Wang, A., Cheng, W., and C. Zhou,
"Path Computation Element Communication Protocol (PCEP)
extension to advertise the PCE Controlled Identifier
Space", Work in Progress, Internet-Draft, draft-ietf-pce-
controlled-id-space-01, 21 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
controlled-id-space-01>.
[PCE-INTERDOMAIN]
Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
Extension for Stateful Inter-Domain Tunnels", Work in
Progress, Internet-Draft, draft-ietf-pce-stateful-
interdomain-05, 5 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
stateful-interdomain-05>.
[PCE-PROTECTION]
Barth, C. and R. Torvi, "PCEP Extensions for RSVP-TE
Local-Protection with PCE-Stateful", Work in Progress,
Internet-Draft, draft-cbrt-pce-stateful-local-protection-
01, 29 June 2018, <https://datatracker.ietf.org/doc/html/
draft-cbrt-pce-stateful-local-protection-01>.
[PCECC-BIER]
Chen, R., Zhu, C., Xu, B., Chen, H., and A. Wang, "PCEP
Procedures and Protocol Extensions for Using PCE as a
Central Controller (PCECC) of BIER", Work in Progress,
Internet-Draft, draft-chen-pce-pcep-extension-pce-
controller-bier-06, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-chen-pce-
pcep-extension-pce-controller-bier-06>.
[PCECC-SR] Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, "PCE
Communication Protocol (PCEP) Extensions for Using PCE as
a Central Controller (PCECC) for Segment Routing (SR) MPLS
Segment Identifier (SID) Allocation and Distribution.",
Work in Progress, Internet-Draft, draft-ietf-pce-pcep-
extension-pce-controller-sr-09, 4 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
pcep-extension-pce-controller-sr-09>.
[PCECC-SRv6]
Li, Z., Peng, S., Geng, X., and M. S. Negi, "PCE
Communication Protocol (PCEP) Extensions for Using the PCE
as a Central Controller (PCECC) for Segment Routing over
IPv6 (SRv6) Segment Identifier (SID) Allocation and
Distribution.", Work in Progress, Internet-Draft, draft-
ietf-pce-pcep-extension-pce-controller-srv6-03, 18 August
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-extension-pce-controller-srv6-03>.
[PCEP-BIER]
Chen, R., Zhang, Z., Chen, H., Dhanaraj, S., Qin, F., and
A. Wang, "PCEP Extensions for Tree Engineering for Bit
Index Explicit Replication (BIER-TE)", Work in Progress,
Internet-Draft, draft-ietf-pce-bier-te-01, 10 October
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-bier-te-01>.
[PCEP-NATIVE]
Wang, A., Khasanov, B., Fang, S., Tan, R., and C. Zhu,
"Path Computation Element Communication Protocol (PCEP)
Extensions for Native IP Networks", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-extension-native-ip-
40, 10 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
pcep-extension-native-ip-40>.Okay, the receipts 📚✨ Here are all the references, every single citation kept exactly as written, bestie 💅
[PCEP-POLICY] Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. Bidgoli, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths", Work in Progress, Internet-Draft, draft-ietf-pce-segment-routing-policy-cp-18, 14 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-18>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[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>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, <https://www.rfc-editor.org/info/rfc4206>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <https://www.rfc-editor.org/info/rfc4456>.
[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>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008, <https://www.rfc-editor.org/info/rfc5150>.
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, DOI 10.17487/RFC5151, February 2008, <https://www.rfc-editor.org/info/rfc5151>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, DOI 10.17487/RFC5376, November 2008, <https://www.rfc-editor.org/info/rfc5376>.
[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>.
[RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. Margaria, "Requirements for GMPLS Applications of PCE", RFC 7025, DOI 10.17487/RFC7025, September 2013, <https://www.rfc-editor.org/info/rfc7025>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, <https://www.rfc-editor.org/info/rfc7399>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for Application-Based Network Operations", RFC 7491, DOI 10.17487/RFC7491, March 2015, <https://www.rfc-editor.org/info/rfc7491>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.
[RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. Shakir, "Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks", RFC 8355, DOI 10.17487/RFC8355, March 2018, <https://www.rfc-editor.org/info/rfc8355>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. Hardwick, "Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, July 2018, <https://www.rfc-editor.org/info/rfc8408>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, <https://www.rfc-editor.org/info/rfc8664>.
[RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi, "Scenarios and Simulation Results of PCE in a Native IP Network", RFC 8735, DOI 10.17487/RFC8735, February 2020, <https://www.rfc-editor.org/info/rfc8735>.
[RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, "Hierarchical Stateful Path Computation Element (PCE)", RFC 8751, DOI 10.17487/RFC8751, March 2020, <https://www.rfc-editor.org/info/rfc8751>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.
[RFC8821] Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "PCE-Based Traffic Engineering (TE) in Native IP Networks", RFC 8821, DOI 10.17487/RFC8821, April 2021, <https://www.rfc-editor.org/info/rfc8821>.
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/info/rfc8955>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021, <https://www.rfc-editor.org/info/rfc9012>.
[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs", RFC 9050, DOI 10.17487/RFC9050, July 2021, <https://www.rfc-editor.org/info/rfc9050>.
[RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August 2021, <https://www.rfc-editor.org/info/rfc9087>.
[RFC9168] Dhody, D., Farrel, A., and Z. Li, "Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification", RFC 9168, DOI 10.17487/RFC9168, January 2022, <https://www.rfc-editor.org/info/rfc9168>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/info/rfc9256>.
[RFC9262] Eckert, T., Ed., Menth, M., and G. Cauchie, "Tree Engineering for Bit Index Explicit Replication (BIER-TE)", RFC 9262, DOI 10.17487/RFC9262, October 2022, <https://www.rfc-editor.org/info/rfc9262>.
[RFC9491] Guichard, J., Ed. and J. Tantsura, Ed., "Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC)", RFC 9491, DOI 10.17487/RFC9491, November 2023, <https://www.rfc-editor.org/info/rfc9491>.
[RFC9522] Farrel, A., Ed., "Overview and Principles of Internet Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, January 2024, <https://www.rfc-editor.org/info/rfc9522>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, December 2023, <https://www.rfc-editor.org/info/rfc9552>.
[RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M., and Y. Zhu, "Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing", RFC 9603, DOI 10.17487/RFC9603, July 2024, <https://www.rfc-editor.org/info/rfc9603>.
[RFC9604] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S., and C. Li, Ed., "Carrying Binding Label/SID in PCE-Based Networks", RFC 9604, DOI 10.17487/RFC9604, August 2024, <https://www.rfc-editor.org/info/rfc9604>.
[SR-SERVICE] Clad, F., Ed., Xu, X., Ed., Filsfils, C., Bernier, D., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and S. Salsano, "Service Programming with Segment Routing", Work in Progress, Internet-Draft, draft-ietf-spring-sr-service-programming-10, 23 August 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-service-programming-10>.
Appendix A. Other Use Cases of the PCECC ✨
Okay bestie, bonus round 🎀 This appendix is a little list of extra PCECC use cases that operators came up with and the working group chatted about. None of them are in active development at the time of publication, but they're parked here for future consideration 🧚💜
A.1. PCECC for Network Migration
Okay, the best part about PCECC is that it plays nicely with what's already there 💖 The PCE server can act as a proxy node of the MPLS network for all the new nodes that don't support the signalling protocols anymore 🫶
So the network doesn't have to switch over all at once. It can migrate to a fully PCECC-controlled network bit by bit, just by swapping out the legacy nodes one at a time ✨ During the migration, the legacy nodes still use the existing MPLS signalling protocols, like LDP and RSVP-TE, while the new nodes set up their part of the forwarding path through the PCECC directly. With the PCECC acting as proxy for those new nodes, MPLS signalling can still spread through the network for both old and new nodes. It's giving smooth transition 🦋
The example in this section is based on the network configuration in Figure 13:
+------------------------------------------------------------------+
| PCE DOMAIN |
| +-----------------------------------------------------+ |
| | PCECC | |
| +-----------------------------------------------------+ |
| ^ ^ ^ ^ |
| | PCEP | | PCEP | |
| V V V V |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| | Node1 | | Node2 | | Node3 | | Node4 | | Node5 | |
| | |...| |...| |...| |...| | |
| | Legacy |if1| Legacy |if2|Legacy |if3| PCECC |if4| PCECC | |
| | Node | | Node | |Enabled | |Enabled | | Enabled| |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| |
+------------------------------------------------------------------+Figure 13: PCECC-Initiated LSP Setup in the Network Migration
In this example there are five nodes on the TE LSP, going from the headend (Node1) to the tail end (Node5). Node4 and Node5 are centrally controlled, and the rest are legacy nodes 🌸
- Node1 sends a path request message to set up the LSP, with the destination as Node5 💌
- The PCECC replies to Node1 for the LSP setup with the path:
(Node1, if1),(Node2, if2),(Node3, if3),(Node4, if4), Node5 🧚 - Node1, Node2, and Node3 set up the LSP to Node5 using their local labels as usual. With the help of the PCECC, Node3 can proxy the signalling 🎀
- Then the PCECC programs the out-segment of Node3, the in-segment/out-segment of Node4, and the in-segment for Node5 🔥
A.2. PCECC for L3VPN and PWE3
So as described in [RFC8283], there are all kinds of network services that can be offered over a network 🌈 These include protection services, including Virtual Private Network (VPN) services such as L3VPN [RFC4364] or EVPNs [RFC7432], or pseudowires [RFC3985]. Delivering these services in an optimal way means coordinating how network resources get allocated to support them, which is a lot ngl 💀 A PCECC can look at the whole network and every component of a service at once when it's planning how to deliver the service. Then it can use PCEP to manage the network resources and install the necessary associations between them ✨
For L3VPN, VPN labels can also be assigned and distributed through PCEP among the Provider Edge (PE) routers, instead of using the BGP protocols 💜
The example in this section is based on the network configuration in Figure 14:
+-------------------------------------------+
| PCE DOMAIN |
| +-----------------------------------+ |
| | PCECC | |
| +-----------------------------------+ |
| ^ ^ ^ |
| PWE3/L3VPN|PCEP PCEP|LSP PWE3/L3VPN|PCEP |
| V V V |
+--------+ | +--------+ +--------+ +--------+ | +--------+
| CE | | | PE1 | | Node x | | PE2 | | | CE |
| |...... | |...| |...| |.....| |
| Legacy | |if1 | PCECC |if2|PCECC |if3| PCECC |if4 | Legacy |
| Node | | | Enabled| |Enabled | |Enabled | | | Node |
+--------+ | +--------+ +--------+ +--------+ | +--------+
| |
+-------------------------------------------+Figure 14: PCECC for L3VPN and PWE3
For PWE3, instead of using the LDP signalling protocols, the label and port pairs assigned to each pseudowire can be assigned through the PCECC among the PE routers. The matching forwarding entries then get distributed into each PE router through the extended PCEP and PCECC mechanism 🦋
A.3. PCECC for Local Protection (RSVP-TE)
Okay so [PCE-PROTECTION] says the PCE needs to be able to maintain and associate the local protection paths for the RSVP-TE LSP 👑 Local protection requires setting up a bypass at the PLR. That bypass can be PCC-initiated and delegated, or PCE-initiated. Either way, the PLR needs to keep a PCEP session open with the PCE 🫶 The bypass LSPs need to be mapped to the primary LSP. The PLR could do this locally based on a local policy, but there's also a need for a PCE to do the mapping, for greater control 🌸
This mapping can be done through PCECC procedures, where the PCE tells the PLR about the mapping and identifies the primary LSP the bypass should be used for ✨
A.4. Using Reliable P2MP TE-Based Multicast Delivery for Distributed Computations (MapReduce-Hadoop) 🐘✨
okay so the MapReduce model for distributed computations in computing clusters is everywhere 💅 It's widely deployed, and it's giving big data energy. In Hadoop (https://hadoop.apache.org/) 1.0 architecture, MapReduce operations run on big data in the Hadoop Distributed File System (HDFS). The NameNode knows about the cluster's resources and where the actual data (chunks) for a particular task lives, meaning which DataNode. Each chunk of data (64 MB or more) should have three saved copies in different DataNodes based on how close they are to each other 🧚
The proximity level currently gets a semi-manual allocation and is based on Rack IDs. The vibe is that closer data is better because of access speed and smaller latency 🌸
The JobTracker node handles computation tasks and scheduling across DataNodes, and it also has Rack awareness 🦋 Right now, the transport protocols between NameNode/JobTracker and DataNodes are based on IP unicast. Simplicity is its big win, but it has numerous drawbacks because of how flat that approach is 😭
There's a need to go beyond one data center (DC) for Hadoop cluster creation and move toward distributed clusters, which is a whole new era 🌈 That means handling performance and latency issues. Latency depends on the speed of light in the fiber links and on the latency added by intermediate devices in between. The second part is closely correlated with network device architecture and performance. The current performance of routers based on Network Processing Units (NPUs) should be enough to create distributed Hadoop clusters with predicted latency 🔥 Software-based routers (mainly Virtual Network Functions (VNFs)) with extra hardware features like the Data Plane Development Kit (DPDK) look promising, but they need more research and testing 👀
So the main question is how to create a simple but effective architecture for a distributed Hadoop cluster 🤔
There's research [MAP-REDUCE] showing how a multicast tree could speed up discovering resources or cluster members inside the cluster, and also increase redundancy in communications between cluster nodes 💜
Conventional IP-based multicast may not be appropriate, though. It needs an extra control plane (IGMP, PIM) and a lot of signalling, which is not suitable for high-performance computations that are super sensitive to latency 💀
P2MP TE tunnels are a more suitable candidate for multicast-based communications between NameNode as the root and DataNodes as the leaves inside the cluster 🍓 These P2MP tunnels can be dynamically created and torn down, with no manual intervention. This is where the PCECC comes in, with the main goal of creating an optimal topology for each particular MapReduce computation request, and creating P2MP tunnels with the parameters needed, like BW and delay ✨
This solution requires MPLS label-based forwarding inside the cluster. Using label-based forwarding inside a DC was proposed by Yandex [MPLS-DC]. It's already technically possible, because MPLS on switches is supported by some vendors, and MPLS also exists on Linux and Open vSwitch (OVS) 🎀
A possible framework for this task is shown in Figure 15 👇
+--------+
| APP |
+--------+
| NBI (REST API,...)
|
PCEP +----------+ REST API
+---------+ +---| PCECC |----------+
| Client |---|---| | |
+---------+ | +----------+ |
| | | | | |
+-----|---+ |PCEP| |
+--------+ | | | | |
| | | | | |
| REST API | | | | |
| | | | | |
+-------------+ | | | | +----------+
| Job Tracker | | | | | | NameNode |
| | | | | | | |
+-------------+ | | | | +----------+
+------------------+ | +-----------+
| | | |
|---+-----P2MP TE--+-----|-----------| |
+-----------+ +-----------+ +-----------+
| DataNode1 | | DataNode2 | | DataNodeN |
|TaskTracker| |TaskTracker| .... |TaskTracker|
+-----------+ +-----------+ +-----------+
Figure 15: Using Reliable P2MP TE-Based Multicast Delivery for
Distributed Computations (MapReduce-Hadoop)Communication between the JobTracker, NameNode, and PCECC can be done via REST API directly, or via a cluster manager such as Mesos 🫶
- Phase 1: Distributed cluster resource discovery happens here 🔍 The JobTracker and NameNode should identify and find available DataNodes according to computing requests from the application (APP). The NameNode should query the PCECC about available DataNodes, and it may give the PCECC extra constraints like topological proximity and redundancy level.
The PCECC should analyze the topology of the distributed cluster and do a constraint-based path calculation from the client towards the most suitable NameNodes. Then it should reply to the NameNode with the list of the most suitable DataNodes and their resource capabilities. The topology discovery mechanism for the PCECC will be added to that framework later 🚧
- Phase 2: The PCECC should create P2MP LSPs from the client towards those DataNodes using PCEP messages, following the path it calculated earlier 🛤️
- Phase 3: The NameNode should send this info to the client, and the PCECC should tell the client about the optimal P2MP path towards the DataNodes via a PCEP message 📬
- Phase 4: The client sends data blocks to those DataNodes for writing through the created P2MP tunnel 🚀
And once this task is finished, the P2MP tunnel could be turned down 🧹✨
Acknowledgments ✨
Thanks to Adrian Farrel, Aijun Wang, Robert Tao, Changjiang Yan, Tieying Huang, Sergio Belotti, Dieter Beller, Andrey Elperin, and Evgeniy Brodskiy for their useful comments and suggestions 🫶
Thanks to Mach Chen and Carlos Pignataro for the RTGDIR review. Thanks to Derrell Piper for the SECDIR review. Thanks to Sue Hares for the GENART review 💖
Thanks to Vishnu Pavan Beeram for being the document shepherd, and Jim Guichard for being the responsible AD 👑
Thanks to Roman Danyliw for the IESG review comments 🌟
Contributors 💜
Here are the wonderful people who contributed to this work 🦋
Luyuan Fang
United States of America
Email: luyuanf@gmail.comChao Zhou
HPE
Email: chaozhou_us@yahoo.comBoris Zhang
Amazon
Email: zhangyud@amazon.comArtsiom Rachytski
AWS
Germany
Email: arachyts@gmail.comAnton Hulida
AWS
Australia
Email: hulidant@amazon.comAuthors' Addresses 🎀
And here's where to find the authors 🌈
Zhenbin (Robin) Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing
100095
China
Email: lizhenbin@huawei.comDhruv Dhody
Huawei Technologies
India
Email: dhruv.ietf@gmail.comQuintin Zhao
Etheric Networks
1009 S Claremont St.
San Mateo, CA 94402
United States of America
Email: quintinzhao@gmail.comKing He
Tencent Holdings Ltd.
Shenzhen
China
Email: kinghe@tencent.comBoris Khasanov
MTS Web Services (MWS)
Andropova Ave. 18, building 9
Moscow
Russian Federation
Email: bhassanov@yahoo.com📦 where this page comes from
- ietf: rfc9689 2024-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms