RFC 9689: Use Cases for a PCE as a Central Controller (PCECC)

3.1. PCECC for Label Management

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 that it controls, and it may take wider responsibility for partitioning the label space for each router and allocating different parts for different uses, communicating the ranges to the router using PCEP.¶

[RFC9050] describes a mode where LSPs are provisioned as explicit label instructions at each hop on the end-to-end path. Each router along the path must be told what label forwarding instructions to program and what resources to reserve. The controller uses PCEP to communicate with each router along the path of the end-to-end LSP. For this to work, the PCECC will take responsibility for managing some part of the MPLS label space for each of the routers that it controls. An extension to PCEP could be done to allow a PCC to inform the PCE of such a label space to control (see [PCE-ID] for a possible PCEP extension to support the advertisement of the MPLS label space for the PCE to control).¶

[RFC8664] specifies extensions to PCEP that allow a stateful PCE to 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 such an 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 that it controls. A mechanism for a PCC to inform the PCE of such a label space to control is needed within the PCEP. The full SRGB/SRLB of a node could be learned via existing IGP or BGP-LS [RFC9552] mechanisms.¶

Further, there have been proposals for a global label range in MPLS as well as the use of PCECC architecture to learn the label space of each node to determine and provision the 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 | |
| +--------+        +--------+ |    | +--------+        +--------+ |
|                              |    |                              |
+------------------------------+    +------------------------------+

As shown in Figure 1:¶

As per [RFC9050], the PCECC could also rely on the PCC to make label allocations initially and use PCEP to distribute it to where it is needed.¶

3.2. PCECC and SR

SR [RFC8402] leverages the source routing paradigm. Using 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 other protocols.¶

[RFC8664] specifies the PCEP extension specific to SR for SR over MPLS (SR-MPLS). The PCECC may further use the PCEP for distributing SR Segment Identifiers (SIDs) to the SR nodes (PCC) with some benefits. If the PCECC allocates and maintains the SIDs in the network for the nodes and adjacencies, and further distributes them to the SR nodes directly via the PCEP session, then it is more advantageous over the configurations on each SR node and flooding them via IGP, especially in an SDN environment.¶

When the PCECC is used for the distribution of 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 the failure recovery (used for SR-TE [RFC8664]). Also, protection can be performed by the node adjacent to the failed component, 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
                     +-----------+

                      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
                     +-----------+

                       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
                     +-----------+

3.3. PCECC for Static TE LSPs

As described in Section 3.1.2 of [RFC8283], the PCECC architecture supports the provisioning of static TE LSPs. To achieve this, the existing PCEP can be used to communicate between the PCECC and nodes along the path to provision explicit label instructions at each hop on the end-to-end path. Each router along the path must be told what label-forwarding instructions to program and what resources to reserve. The PCECC keeps a view of the network and determines the paths of the end-to-end LSPs, and the controller uses PCEP to communicate with each router along the path of the end-to-end LSP.¶

                       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
                     +-----------+

Refer to Figure 5 for an example TE topology.¶

3.4. PCECC for Load Balancing (LB)

Very often, many service providers use TE tunnels for solving issues with non-deterministic paths in their networks. One example of such applications is the usage of TEs in the mobile backhaul (MBH). Consider the topology as shown 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 |    +-----+    +-------+    +------+  +---+
+--------+    +------+

This MBH architecture uses L2 access rings and sub-rings. L3 starts at the aggregation layer. For the sake of simplicity, the figure shows only one access sub-ring. The access ring and aggregation ring are connected by Nx10GE interfaces. The aggregation domain runs its own IGP. There are two egress routers (AGG N-1 and AGG N) that are connected to the Core domain (Core 1...Core N) via L2 interfaces. The Core also has connections to service routers; 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 egress AGG routers. There are also many L2 access rings connected to AGG routers.¶

Service deployment is made by means of 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 egress AGG routers. TE tunnels could be used as transport towards service routers in case of architecture based on seamless MPLS [MPLS-SEAMLESS].¶

Load Balancing (LB) between TE tunnels involves distributing network traffic across multiple TE tunnels to optimize the use of available network resources, enhance performance, and ensure reliability. Some common techniques include Equal-Cost Multipath (ECMP) and Unequal-Cost Multipath (UCMP) based on the BW of the TE tunnels.¶

There is a need to solve the following tasks:¶

In this section, the focus is on LB tasks. LB tasks could be solved by means of the PCECC in the following ways:¶

3.5. PCECC and Inter-AS TE

There are various signalling options for establishing Inter-AS TE LSPs: contiguous TE LSPs [RFC5151], stitched TE LSPs [RFC5150], and nested TE LSPs [RFC4206].¶

The requirements for PCE-based Inter-AS setup [RFC5376] describe the approach and PCEP functionality that is needed for establishing Inter-AS TE LSPs.¶

[RFC5376] also gives an Inter-AS and Intra-AS PCE Reference Model (as shown in Figure 7) that is provided below in shortened form for the sake of simplicity.¶

           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

The PCECC belonging to the different domains can cooperate to set up Inter-AS TE LSPs. The stateful Hierarchical PCE (H-PCE) mechanism [RFC8751] could also be used to establish a per-domain PCECC LSP first. These could be stitched together to form an Inter-AS TE LSP as described in [PCE-INTERDOMAIN].¶

For the sake of simplicity, here the focus is on a simplified Inter-AS case when both AS1 and AS2 belong to the same service provider administration. In that case, Inter-AS and Intra-AS PCEs could be combined in one single PCE if such combined PCE performance is enough to handle the load. The PCE will require interfaces (PCEP and BGP-LS) to both domains. PCECC redundancy mechanisms are described in [RFC8283]. Thus, routers (PCCs) in AS1 and AS2 can send PCEP messages towards the same PCECC. In Figure 8, the PCECC maintains a BGP-LS session with Route Reflectors (RRs) in each AS. This allows the RRs to redistribute routes to other BGP routers (clients) without requiring 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=======>

In the case of the PCECC Inter-AS TE scenario (as shown in Figure 8), where the service provider controls both domains (AS1 and AS2), each of them has its own IGP and MPLS transport. There is a need to set up Inter-AS LSPs for transporting different services on top of them (such as Voice, L3VPN, etc.). Inter-AS links with different capacities exist in several regions. The task is not only to provision those Inter-AS LSPs with given constraints but also to calculate the path and pre-setup the backup Inter-AS LSPs that will be used if the primary LSP fails.¶

As per Figure 8, LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and it is the primary Inter-AS LSP. LSP2 from R1 to R3 that goes via ASBR5 and ASBR6 is the backup one. In addition, there could also be a bypass LSP setup to protect against ASBR or Inter-AS link failures.¶

After the addition of PCECC functionality to the PCE (SDN controller), the PCECC-based Inter-AS TE model should follow the PCECC use case for TE LSP including the requirements described in [RFC5376] with the following details:¶

3.6. PCECC for Multicast LSPs

The multicast LSPs can be set up via the RSVP-TE P2MP or Multipoint LDP (mLDP) protocols. The setup of these LSPs may require manual configurations and complex signalling when the protection is considered. By using the PCECC solution, 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. It not only reduces the complex configurations comparing the distributed RSVP-TE P2MP or mLDP signalling, but also it can compute the disjoint primary path and secondary P2MP path efficiently.¶

                       +----------+
                       |    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
                     +-----------+

                            +----+  +----+
           Root Node of LSP | R1 |--| R11|
                            +----+  +----+
                              /         +
                           10/           +20
                            /             +
                    +----------+        +-----------+
     Transit Node   |    R2    |        |     R3    |
                    +----------+        +-----------+
                      |        \       +         +
                      |         \     +          +
                    10|        10\   +20       20+
                      |           \ +            +
                      |            \             +
                      |           + \            +
                    +-----------+      +-----------+ Leaf Nodes
                    |    R4     |      |    R5     | (Downstream LSR)
                    +-----------+      +-----------+

                            +------------+
                            |     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)
                    +-----------+      +-----------+
                          .                  .
                          .                  .

3.7. PCECC for Traffic Classification

As described in [RFC8283], traffic classification is an important part of traffic engineering. It is the process of looking into a packet to determine how it should be treated while it is forwarded through the network. It applies in many scenarios, including the following:¶

In conjunction with traffic engineering, traffic classification is an important enabler for LB. Traffic classification is closely linked to the computational elements of planning for the network functions because it determines how traffic is balanced and distributed through the network. Therefore, selecting what traffic classification mechanism should be performed by a router is an important part of the work done by a PCECC.¶

The description of traffic flows by the combination of multiple Flow Specification components and their dissemination as traffic Flow Specifications is described for BGP in [RFC8955]. When a PCECC is used to initiate tunnels (such as TE LSPs or SR paths) using PCEP, it is important that the headend of the tunnels understands what traffic to place on each tunnel. [RFC9168] specifies a set of extensions to PCEP to support the dissemination of Flow Specification components where the instructions are passed from the PCECC to the routers using PCEP.¶

Along with traffic classification, there are a few more questions about the tunnels set up by the PCECC that need to be considered:¶

These are out of the scope of this document.¶

3.8. PCECC for SFC

Service Function Chaining (SFC) is described in [RFC7665]. It is the process of directing traffic in a network such that it passes through specific hardware devices or virtual machines (known as service function nodes) that can perform particular desired functions on the traffic. The set of functions to be performed and the order in which they are to be performed is known as a service function chain. The chain is enhanced with the locations at which the service functions are to be performed to derive a Service Function Path (SFP). Each packet is marked as belonging to a specific SFP, and that marking lets each successive service function node know which functions to perform and to which service function node to send the packet next. To operate an SFC network, the service function nodes must be configured to understand the packet markings, and the edge nodes must be told how to mark packets entering the network. Additionally, it may be necessary to establish tunnels between service function nodes to carry the traffic. Planning an SFC network requires LB between service function nodes and traffic engineering across the network that connects them. As per [RFC8283], these are operations that can be performed by a PCECC, and that controller can use PCEP to program the network and install the service function chains and any required tunnels.¶

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.¶

The PCECC can play the role of setting the traffic classification rules (as per Section 3.7) at the classifier to impose the Network Service Header (NSH) [RFC8300]. It can also download the forwarding instructions to each SFF along the way so that they could process the NSH and forward accordingly. This includes instructions for the service classifier that handles the context header, metadata, etc. This metadata/context is shared amongst SFs and classifiers, between SFs, and between external systems (such as a PCECC) and SFs. As described in [RFC7665], the SFC encapsulation enables the sharing of metadata/context information along the SFP.¶

It is also possible to support SFC with SR in conjunction with or without an NSH such 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

[RFC8735] describes the scenarios and simulation results for the "Centralized Control Dynamic Routing (CCDR)" solution, which integrates the advantage of using distributed protocols (IGP/BGP) and the power of a centralized control technology (PCE/SDN), providing traffic engineering for native IP networks. [RFC8821] defines the framework for CCDR traffic engineering within a native IP network, using multiple BGP sessions and a PCE as the centralized controller. It requires the PCECC to send the instructions to the PCCs to build multiple BGP sessions, distribute different prefixes on the established BGP sessions, and assign the different paths to the BGP next hops. The PCEP is used to transfer the key parameters between the PCE and the underlying network devices (PCC) using the PCECC technique. The central control instructions from the PCECC to PCC will identify which prefix should be advertised on which BGP session. There are PCEP extensions defined in [PCEP-NATIVE] for it.¶

                               +------+
                    +----------+ 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     |           +---+
              +-----------+             +-----------+

In the case as shown in Figure 12, the PCECC will instruct both R1 and R2 how to form BGP sessions with each other via PCEP and which IP prefixes need to be advertised via which BGP session.¶

3.10. PCECC for BIER

Bit Index Explicit Replication (BIER) [RFC8279] defines an architecture where all intended multicast receivers are encoded as a BitMask in the multicast packet header within different encapsulations. A router that receives such a packet will forward that packet based on the bit position in the packet header towards the receiver(s) following a precomputed tree for each of the bits in the packet. Each receiver is represented by a unique bit in the BitMask.¶

BIER-TE [RFC9262] shares architecture and packet formats with BIER. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of 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 for the allocation of bits for the BIER router for BIER as well as for the adjacencies for BIER-TE. PCECC-based controllers can use PCEP to instruct the BIER-capable routers on the meaning of the bits as well as other fields needed for BIER encapsulation. The PCECC could be used to program the BIER router with various parameters used in the BIER encapsulation (such as BIER sub-domain-id, BFR-id, etc.) for both node and adjacency.¶

A possible way to use the PCECC and PCEP extension is described in [PCECC-BIER].¶