Use Cases for a PCE as a Central Controller (PCECC)

describes various use cases for PCECC such as: Use of PCECC to set up Static TE LSPs. The PCEP extension for this use case is in . Use of PCECC in Segment Routing . Use of PCECC to set up Multicast Point-to-Multipoint (P2MP) LSP. Use of PCECC to set up Service Function Chaining (SFC) . Use of PCECC in Optical Networks. describes the general case of PCECC being in charge of managing MPLS label space which is a prerequisite for further use cases. Further, various use cases (SR, Multicast etc) are described in the following sections to showcase scenarios that can benefit from the use of PCECC. It is interesting to note that some of the use cases listed can also be supported via BGP instead of PCEP. However, within the scope of this document, the focus is on the use of PCEP.

As per , in some cases, the PCE-based controller 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. 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 PCE-based controller 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 for a possible PCEP extension to support the advertisement of the MPLS label space to the PCE to control.) specifies extensions to PCEP that allow a stateful PCE to compute, update or initiate SR-TE paths. describes the mechanism for PCECC to allocate and provision the node/prefix/ adjacency label (Segment Routing Identifier (SID)) via PCEP. To make such an allocation PCE needs to be aware of the label space from the Segment Routing Global Block (SRGB) or Segment Routing Local Block (SRLB) 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 mechanisms. Further, there have been proposals for a global label range in MPLS, the PCECC architecture could be used as a means to learn the label space of nodes, and could also be used to determine and provision the global label range.

As shown in , PCC will advertise the PCECC capability to the PCE central controller (PCECC) . The PCECC could also learn the label range set aside by the PCC (via ). 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 , PCECC could also rely on the PCC to make label allocations initially and use PCEP to distribute it to where it is needed.

Segment Routing (SR) 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 or RSVP-TE . 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 a intra-domain routing protocol (such as IS-IS or OSPF) or an inter-domain protocol (BGP), or by any other means. PCEP could also be one of other protocols. specifies the SR-specific PCEP extension for SR-MPLS. PCECC may further use PCEP protocol for SR SIDs (Segment Identifiers) distribution 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. For the allocation of Adj-SID, the allocation is from the SRLB of the node as described in . identifies various protection and resiliency usecases for SR. Path protection lets the ingress node be in charge of the failure recovery (used for SR-TE ). 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 PCECC, the protection paths can be pre-computed and set up by the PCE. The illustrates the use case where the Node-SID and Adj-SID are allocated by the PCECC 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 nexthop and download the label forwarding instructions accordingly. The forwarding behaviour and the end result are the same as IGP shortest-path SR forwarding based on Node-SID. Thus, from anywhere in the domain, it enforces the ECMP-aware shortest-path forwarding of the packet towards the related node. For each adjacency in the network, a PCECC can allocate an Adj-SID. 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 behaviour and the end result are similar to IGP-based Adj-SID allocation and usage in SR. These mechanisms are described in .

In this use case, 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 will forward the packet based on the destination Node-SID. It is similar to the LDP LSP. R1 may send a packet to R8 simply by pushing an SR label with segment {1008} (Node-SID for R8). The path will be based on the routing/nexthop calculation on the routers.

SR-TE paths may not follow an IGP shortest path tree (SPT). Such paths may be chosen by a PCECC and provisioned on the ingress node of the SR-TE path. The SR header consists of a list of SIDs (or MPLS labels). The header has all necessary information so that the packets can be guided from the ingress node to the egress node of the path. Hence, there is no need for any signalling protocol. For the case where a strict traffic engineering path is needed, all the Adj-SID are stacked, otherwise, a combination of node-SID or adj-SID can be used for the SR-TE paths. As shown in , R1 may send a packet to R8 by pushing an SR header with segment list {1002, 9001, 1008}. Where 1002 and 1008 are the Node-SID of R2 and R8 respectively. 9001 is the Adj-SID for link1. The path should be: R1-R2-link1-R3-R8. To achieve this, the PCECC first allocates and distributes SIDs as described in . describes the mechanism for a PCE to compute, update, or initiate SR-MPLS TE paths.

Refer to for an example of TE topology, where, 100x - are Node-SIDs and 900xx - are Adj-SIDs. The SID allocation and distribution are done by the PCECC with all Node-SIDs (100x) and all Adj-SIDs (900xx). Based on path computation request/delegation or PCE initiation, the PCECC receives a request with constraints and optimization criteria from a PCC. PCECC will calculate the optimal path according to the given constraints (e.g. bandwidth). PCECC will provision SR-MPLS TE LSP (path R1-link1-R2-link6-R3-R8) at the ingress node: {90011,1002,90026,1003,1008} For the end-to-end protection, PCECC can provision the secondary path (R1-link2-R2-link4-R5-R8): {90012,1002,90024,1005,1008}.

defines Segment Routing architecture, which 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 instantiated by an SR controller. The SR architecture does not restrict how the controller programs the network. In this case, the focus is on PCEP as the protocol for SR Policy delivery from PCE to PCC. An SR Policy architecture is described in . An SR Policy is a framework that enables the instantiation of an ordered list of segments on a node for implementing a source routing policy for the steering of traffic for a specific purpose (e.g. for a specific SLA) from that node. An SR Policy is identified through the tuple <headend, color, endpoint>. is used as an example of PCECC application for SR Policy instantiation for SR-MPLS, where, 100x - are Node-SIDs and 900xx - are Adj-SIDs. Let's assume that R1 needs to have two disjoint SR Policies towards R8 based on different bandwidths, 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 candidate path and segment list) will be signalled to a headend (R1) via PCEP with the addition of an ASSOCIATION object. Binding SID (BSID) can be used for traffic steering of labelled traffic into SR Policy, BSID can be provisioned from PCECC also via PCEP . For non-labelled traffic steering into the SR Policy POL1 or POL2, a per-destination traffic steering will be used by means of the BGP Color extended community The procedure: PCECC allocates Node-SIDs and Adj-SIDs using the mechanism described in for all nodes and links. PCECC will calculate disjoint paths for POL1 and POL2 and create Segment Lists for them:{90011,1002,90023,1004,1003,1008};{90012,1002,90024,1005,1006,1008}. PCECC will form both SR Policies POL1 and POL2. PCECC will send both POL1 and POl2 to R1 via PCEP. PCECC optionally can allocate BSIDs for the SR Policies. The traffic from R1 to R8 which fits to color 100 will be steered to POL1 and follows the path: R1-link1-R2-link3-R4-R3-R8. The traffic from R1 to R8 which fits color 200 will be steered to POL2 and follows the path: R1-link2-R2-link4-R5-R6-R8. Due to the possibility of having many Segment Lists in the same Candidate Path of each POL1/POL2, PCECC could provision more paths towards R8 and traffic will be balanced either as ECMP or as w/ECMP. This is the advantage of 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 .

As per , with Segment Routing (SR), a node steers a packet through an ordered list of instructions, called segments. Segment Routing can be applied to the IPv6 architecture with the Segment Routing Header (SRH) . A segment is encoded as an IPv6 address. 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. Upon completion of a segment, a pointer in the new routing header is incremented and indicates the next segment. As per , an SRv6 Segment is a 128-bit value. "SRv6 SID" or simply "SID" are often used as a shorter reference for "SRv6 Segment". defines the SRv6 SID as consisting of LOC:FUNCT:ARG. extends to support SR for the IPv6 data plane. Further, a PCECC could be extended to support SRv6 SID allocation and distribution. An example of how PCEP extensions could be extended for SRv6 for PCECC is described in .

In this case, as shown in , PCECC could assign the SRv6 SID (in the form of an IPv6 address) to be used for node and adjacency. Later, the SRv6 path in the form of a list of SRv6 SIDs could be used at the ingress. Some examples - SRv6 SID-List={2001:db8::8} - The best path towards R8 SRv6 SID-List={2001:db8::5, 2001:db8::8} - The path towards R8 via R5 The rest of the procedures and mechanisms remain the same as SR-MPLS.

As described in Section 3.1.2 of , PCECC architecture supports the provisioning of static TE LSP. 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 PCE-based controller 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.

Refer to for an example TE topology. Based on path computation request/delegation or PCE initiation, the PCECC receives a request with constraints and optimization criteria. PCECC will calculate the optimal path according to the given constraints (e.g. bandwidth). PCECC will provision each node along the path and assign incoming and outgoing labels from R1 to R8 with the path as "R1-link1-R2-link3-R4-link10-R3-link8-R8": R1: Outgoing label 1001 on link 1 R2: Incoming label 1001 on link 1 R2: Outgoing label 2003 on link 3 R4: Incoming label 2003 on link 3 R4: Outgoing label 4010 on link 10 R3: Incoming label 4010 on link 10 R3: Outgoing label 3008 on link 8 R8: Incoming label 3008 on link 8 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, 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 is also possible to have a bypass path for the local protection set up by the PCECC. For example, the primary path as above, then to protect the node R4 locally, PCECC can program the bypass path like this: {R2, link5, 2005}, {2005, R3}. By doing this, the node R4 is locally protected at R2.

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 (AGG1...AGGN are Aggregation Routers, Core 1...Core N are Core routers) -

+---------+ +--------+ +--------+ +--------+ +------+ +---+ | Access |----| Access |----| AGG 1 |----| AGG N-1|----|Core 1|--|SR1| | SubNode1| | Node 1 | +--------+ +--------+ +------+ +---+ +---------+ +--------+ | | | ^ | | Access | Access | AGG Ring 1 | | | | SubRing 1 | Ring 1 | | | | | +---------+ +--------+ +--------+ | | | | Access | | Access | | AGG 2 | | | | | SubNode2| | Node 2 | +--------+ | | | +---------+ +--------+ | | | | | | | | | | | | | | | +----TE2----|-+ | +---------+ +--------+ +--------+ +--------+ +------+ +---+ | Access | | Access |----| AGG 3 |----| AGG N |----|Core N|--|SRn| | SubNodeN|----| Node N | +--------+ +--------+ +------+ +---+ +---------+ +--------+ ]]> 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, AGG N) that are connected to the Core domain (Core 1...Core N) via L2 interfaces. 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 2 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 (VPLS)), 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 seamless MPLS () based architecture. Load balancing 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 Multi-Path (ECMP) and Unequal-Cost Multi-Path (UCMP) based on the bandwidth of the TE tunnels. There is a need to solve the following tasks: Perform automatic load-balance amongst TE tunnels according to current traffic load. TE bandwidth (BW) management: Provide guaranteed BW for specific services: High-Speed Data Service (HSI)), IPTV, etc., and provide time-based BW reservation (BW on demand (BoD)) for other services. Simplify the development of TE tunnels by automation without any manual intervention. Provide flexibility for Service Router placement (anywhere in the network by the creation of transport LSPs to them). In this section, the focus is on load balancing (LB) tasks. LB task could be solved by means of PCECC in the following way: Application or network service or operator can ask the SDN controller (PCECC) for LSP-based load balancing between AGG X and AGG N/AGG N-1 (egress AGG routers that have connections to the core). Each of these will have associated constraints (i.e. bandwidth, inclusion or exclusion specific links or nodes, number of paths, objective function (OF), need for disjoint LSP paths etc.); PCECC could calculate multiple (say N) LSPs according to given constraints, the calculation is based on results of Objective Function (OF) , constraints, endpoints, same or different bandwidth (BW), different links (in case of disjoint paths) and other constraints. Depending on the given LSP Path setup type (PST), PCECC will download 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. PCECC will send PCInitiate message towards ingress AGG X router(PCC) for each of N LSPs and receive PCRpt message back from PCCs. If PST is PCECC-SR, the PCECC will include a SID stack as per . If PST is PCECC (basic), then the PCECC will assign labels along the calculated path and set up the path by sending central controller instructions in a PCEP message to each node along the path of the LSP as per and then send PCUpd message to the ingress AGG X router with information about new LSP. AGG X(PCC) will respond with PCRpt with LSP status. AGG X as an ingress router now has N LSPs towards AGG N and AGG N-1 which are available for installation to the router's forwarding table and load-balance traffic between them. Traffic distribution between those LSPs depends on the particular realization of the hash-function on that router. Since PCECC is aware of TEDB (TE state) and LSP-DB, it can manage and prevent possible over-subscriptions and limit the number of available load-balance states. Via PCECC mechanism the control can take quick actions into the network by directly provisioning the central control instructions.

There are various signalling options for establishing Inter-AS TE LSP: contiguous TE LSP , stitched TE LSP , and nested TE LSP . Requirements for PCE-based Inter-AS setup describe the approach and PCEP functionality that is needed for establishing Inter-AS TE LSPs. also gives Inter- and Intra-AS PCE Reference Model (as shown in ) that is provided below in shortened form for the sake of simplicity.

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 LSP. The stateful H-PCE mechanism could also be used to establish a per-domain PCECC LSP first. These could be stitched together to form inter-AS TE LSP as described in . 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 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 . Thus routers (PCCs) in AS1 and AS2 can send PCEP messages towards the same PCECC. In , 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 BGP-LS Propagator and PCECC act as a BGP-LS Consumer .

+-------------------+ MPLS Domain 1 Inter-AS MPLS Domain 2 <=======AS1=======> <========AS2=======> ]]> In the case of the PCECC Inter-AS TE scenario (as shown in ) 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 (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 , LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and it is the primary Inter-AS LSP. R1-R3 LSP2 that goes via ASBR5 and ASBR6 are the backup ones. 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 PCE (SDN controller), the PCECC-based Inter-AS TE model should follow the PCECC use case for TE LSP including requirements of with the following details: Since PCECC needs to know the topology of both domains AS1 and AS2, PCECC can utilize the BGP-LS peering with BGP routers (or RRs) in both domains. PCECC needs to establish PCEP connectivity with all routers in both domains (see also section 4 in ). After the operator's application or service orchestrator creates a request for tunnel creation of a specific service, PCECC will receive that request via NBI (NBI type is implementation dependent, it could be NETCONF/Yang, REST etc.). Then PCECC will calculate the optimal path based on Objective Function (OF) and given constraints (i.e. path setup type, bandwidth etc.), including those from : priority, AS sequence, preferred ASBR, disjoint paths, and protection type. In this step, we will have two paths: R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3 PCECC will use central control download instructions to the PCC based on the PST. At this stage, it is assumed the PCECC is aware of the label space it controls and in the case of SR the SID allocation and distribution is already done. PCECC will send PCInitiate message towards the ingress router R1 (PCC) in AS1 and receive the PCRpt message back from it. If the PST is SR-MPLS, the PCECC will include the SID stack as per . Optionally, a binding SID or BGP Peering-SID can also be included on the AS boundary. The backup SID stack can be installed at ingress R1 but more importantly, each node along the SR path could also do the local protection just based on the top segment. If the PST is PCECC, the PCECC will assign labels along the calculated paths (R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3) and sets up the path by sending central controller instructions in PCEP message to each node along the path of the LSPs as per . After these steps, the PCECC will send a PCUpd message to the ingress R1 router with information about new LSPs and R1 will respond by PCRpt with LSP(s) status. After that step, R1 now have primary and backup TEs (LSP1 and LSP2) towards R3. It is up to router implementation how to make switchover to backup LSP2 if LSP1 fails.

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 which has the full picture of the topology and bandwidth 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.

It is assumed the PCECC is aware of the label space it controls for all nodes and makes allocations accordingly.

The P2MP examples (based on ) are explained here, where R1 is the root and the router R8 and R6 are the leaves. Based on the P2MP path computation request/delegation or PCE initiation, the PCECC receives the request with constraints and optimization criteria. PCECC will calculate the optimal P2MP path according to given constraints (i.e.bandwidth). PCECC will provision each node along the path and assign incoming and outgoing labels from R1 to {R6, R8} with the path as "R1-L0-R2-L2-R5-L4-R6" and "R1-L0-R2-L1-R4-L3-R3-L5-R8": R1: Outgoing label 9000 on link L0 R2: Incoming label 9000 on link L0 R2: Outgoing label 9001 on link L1 (*) R2: Outgoing label 9002 on link L2 (*) R5: Incoming label 9002 on link L2 R5: Outgoing label 9004 on link L4 R6: Incoming label 9004 on link L4 R4: Incoming label 9001 on link L1 R4: Outgoing label 9003 on link L3 R3: Incoming label 9003 on link L3 R3: Outgoing label 9005 on link L5 R8: Incoming label 9005 on link L5 This can also be represented as : {R1, 6000}, {6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, R3, 9005}, {9004, R6}, {9005, R8}. The main difference (*) is in the branch node instruction at R2 where two copies of a packet are sent towards R4 and R5 with 9001 and 9002 labels respectively. The packet forwarding involves - Step 1: R1 sends a packet to R2 simply by pushing the label of 9000 to the packet. Step 2: When R2 receives the packet with label 9000, it will forward it to R4 by swapping label 9000 to 9001 and at the same time, it will replicate the packet and swap the label 9000 to 9002 and forward it to R5. Step 3: When R4 receives the packet with label 9001, it will forward it to R3 by swapping 9001 to 9003. When R5 receives the packet with the label 9002, it will forward it to R6 by swapping 9002 to 9004. Step 4: When R3 receives the packet with label 9003, it will forward it to R8 by swapping it to 9005 and when R5 receives the packet with label 9002, it will be swapped to 9004 and sent to R6. Step 5: When R8 receives the packet with label 9005, it will pop the label; when R6 receives the packet with label 9004, it will pop the label.

In this section, the end-to-end managed path protection service as well as the local protection with the operation management in the PCECC network for the P2MP/MP2MP LSP. An end-to-end protection principle can be applied for computing backup P2MP or MP2MP LSPs. During the computation of the primary multicast trees, PCECC could also take the computation of a secondary tree into consideration. A PCECC could compute the primary and backup P2MP (or MP2MP) LSPs together or sequentially.

In , when the PCECC setups the primary multicast tree from the root node R1 to the leaves, which is R1->R2->{R4, R5}, at the same time, it can setup the backup tree, which is R1->R11->R3->{R4, R5}. Both of them (primary forwarding tree and secondary forwarding tree) will be downloaded to each router along the primary path and the secondary path. The traffic will be forwarded through the R1->R2->{R4, R5} path normally, but when a node in the primary tree fails (say R2) the root node R1 will switch the flow to the backup tree, which is R1->R11->R3->{R4, R5}. By using the PCECC a path computation, label downloading and finally forwarding can be done without complex signalling used in the P2MP RSVP-TE or mLDP.

In this section, we describe the local protection service in the PCECC network for the P2MP/MP2MP LSP. While the PCECC sets up the primary multicast tree, it can also build the backup LSP between the Point of Local Repair (PLR), the protected node and Merge Points (MPs) (the downstream nodes of the protected node). In the cases where the amount of downstream nodes is huge, this mechanism can avoid unnecessary packet duplication on PLR and protect the network from traffic congestion risk.

In , when the PCECC setups the primary multicast path around the PLR node R10 to protect node R20, which is R10->R20->{R40, R50}, at the same time, it can set up the backup path R10->R30->{R40, R50}. Both the primary forwarding path and secondary bypass forwarding path will be downloaded to each router along the primary path and the secondary bypass path. The traffic will be forwarded through the R10->R20->{R40, R50} path normally and when there is a node failure for node R20, the PLR node R10 will switch the flow to the backup path, which is R10->R30->{R40, R50}. By using the PCECC, path computation, label downloading and finally forwarding can be done without complex signalling used in the P2MP RSVP-TE or mLDP.

As described in , 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: MPLS traffic engineering (where it determines what traffic is forwarded into which LSPs), Segment Routing (where it is used to select which set of forwarding instructions (SIDs) to add to a packet), SFC (where it indicates how a packet should be forwarded across which service function path ). In conjunction with traffic engineering, traffic classification is an important enabler for load balancing. 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 (Flow Specifications) is described for BGP in . When a PCECC is used to initiate tunnels (such as TE-LSPs or SR paths) using PCEP, it is important that the head end of the tunnels understands what traffic to place on each tunnel. 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 that need to be considered after path setup: how to use it Whether it is a virtual link Whether to advertise it in the IGP as a virtual link What bits of this information to signal to the tail end These are out of the scope of this document.

Service Function Chaining (SFC) is described in . 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 load balancing between service function nodes and traffic engineering across the network that connects them. As per , these are operations that can be performed by a PCE-based controller, 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. PCECC will be able to instruct each SFF along the SFP. Service Path Identifier (SPI): Uniquely identifies an SFP. Service Index (SI): Provides location within the SFP. SFC Proxy handling PCECC can play the role of setting the traffic classification rules (as per ) at the classifier to impose the Network Service Header (NSH) as well as downloading the forwarding instructions to each SFF along the way so that they could process the NSH and forward accordingly. Including 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 PCECC) and SFs. As described in , 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 NSH such as and . PCECC technique can also be used for service function-related segments and SR service policies.

describes the scenarios and simulation results for the "Centrally 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. 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. PCEP protocol is used to transfer the key parameters between PCE and the underlying network devices (PCC) using the PCECC technique. The central control instructions from PCECC to PCC will identify which prefix should be advertised on which BGP session. There are PCEP extensions defined in for it.

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

Bit Index Explicit Replication (BIER) 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 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 ). 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 subdomain-ID, BFR-ID, BIER Encapsulation etc. for both node and adjacency. A possible way for the PCECC usage and PCEP extension is described in .