TEAS Working Group Q. Zhao
Internet-Draft Z. Li
Intended status: Informational B. Khasanov
Expires: April 22, 2019 D. Dhody
Huawei Technologies
K. Ke
Tencent Holdings Ltd.
L. Fang
Expedia, Inc.
C. Zhou
Cisco Systems
B. Zhang
Telus Communications
A. Rachitskiy
Mobile TeleSystems JLLC
A. Gulida
LLC "Lifetech"
October 19, 2018

The Use Cases for Path Computation Element (PCE) as a Central Controller (PCECC).


The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP).

SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.

This document describes general considerations for PCECC deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCEP extensions required for stateful PCE usage are covered in separate documents.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 22, 2019.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

An Architecture for Use of PCE and PCEP [RFC5440] in a Network with Central Control [RFC8283] describes SDN architecture where the Path Computation Element (PCE) determines paths for variety of different usecases, with PCEP as a general southbound communication protocol with all the nodes along the path..

[I-D.zhao-pce-pcep-extension-for-pce-controller] introduces the procedures and extensions for PCEP to support the PCECC architecture [RFC8283].

This draft describes the various usecases for the PCECC architecture.

2. Terminology

The following terminology is used in this document.

Interior Gateway Protocol. Either of the two routing protocols, Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS).
Path Computation Client: any client application requesting a path computation to be performed by a Path Computation Element.
Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE as a central controller. Extension of PCE to support SDN functions as per [RFC8283].
Traffic Engineering.

3. Application Scenarios

In the following sections, several use cases are described, showcasing scenarios that benefit from the deployment of PCECC.

3.1. Use Cases of PCECC for Label Management

As per [RFC8283], 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 taker 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.

[I-D.zhao-pce-pcep-extension-for-pce-controller] describe 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.

[I-D.ietf-pce-segment-routing] specifies extensions to PCEP that allow a stateful PCE to compute, update or initiate SR-TE paths. [I-D.zhao-pce-pcep-extension-pce-controller-sr] describes the mechanism for PCECC to allocate and provision the node/prefix/ adjacency label (SID) via PCEP. To make such allocation PCE needs to be aware of the label space from 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 PCEP. The full SRGB/SRLB of a node could be learned via existing IGP or BGP-LS mechanism too.

[I-D.li-pce-controlled-id-space] defines a PCEP extension to support advertisement of the MPLS label space to the PCE to control.

There have been various proposals for Global Labels, the PCECC architecture could be used as means to learn the label space of nodes, and could also be used to determine and provision the global label range.

+------------------------------+    +------------------------------+
|         PCE DOMAIN 1         |    |         PCE DOMAIN 2         |
|          +--------+          |    |          +--------+          |
|          |        |          |    |          |        |          |
|          | PCECC1 |  ---------PCEP---------- | PCECC2 |          |
|          |        |          |    |          |        |          |
|          |        |          |    |          |        |          |
|          +--------+          |    |          +--------+          |
|         ^          ^         |    |         ^          ^         |
|        /            \  PCEP  |    |  PCEP  /            \        |
|       V              V       |    |       V              V       |
| +--------+        +--------+ |    | +--------+        +--------+ |
| |NODE 11 |        | NODE 1n| |    | |NODE 21 |        | NODE 2n| |
| |        | ...... |        | |    | |        | ...... |        | |
| | PCECC  |        |  PCECC | |    | | PCECC  |        |PCECC   | |
| |Enabled |        | Enabled|      | |Enabled |        |Enabled | |
| +--------+        +--------+ |    | +--------+        +--------+ |
|                              |    |                              |
+------------------------------+    +------------------------------+

Figure 1: PCECC for Label Management

3.2. Using PCECC for SR

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 signaling 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 routing protocol (such as IS-IS or OSPF) or by any other means. PCEP (and PCECC) could be one such means.

[I-D.ietf-pce-segment-routing] specify the SR specific PCEP extensions. PCECC may further use PCEP protocol for SR SID (Segment Identifier) distribution to the SR nodes (PCC) with some benefits. If the PCECC allocates and maintains the SID in the network for the nodes and adjacencies; and further distributes them to the SR nodes directly via the PCEP session has some advantage over the configurations on each SR node and flooding via IGP, especially in a SDN environment.

When the PCECC is used for the distribution of the node segment ID and adjacency segment ID, the node segment ID is allocated from the SRGB of the node. For the allocation of adjacency segment ID, the allocation is from the SRLB of the node as described in [I-D.zhao-pce-pcep-extension-pce-controller-sr].

[RFC8355] 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 case of PCECC, the protection paths can be pre-computed and setup by the PCE.

The following example illustrate the use case where the node SID and adjacency SID are allocated by the PCECC.

                       | R1(1001) |
                       | R2(1002) |
                      *   |   *    *
                     *    |   *     *
                    *link1|   *      *  *      |   *link2  *
        +-----------+ 9001|   *     +-----------+
        | R4(1004)  |     |   *     | R5(1005)  |
        +-----------+     |   *     +-----------+
                   *      |   *9003  *   +
                    *     |   *     *    +
                     *    |   *    *     +
                     +-----------+   +-----------+ | R3(1003)  |   |R6(1006)   |
                     +-----------+   +-----------+
                     | R8(1008)  |

3.2.1. PCECC SID Allocation

Each node (PCC) is allocated a node-SID by the PCECC. The PCECC needs to update the label map of each node to all the nodes in the domain. On receiving the label map, each node (PCC) uses the local routing information to determine the next-hop and download the label forwarding instructions accordingly. The forwarding behavior and the end result is same as IGP based Node-SID in SR. 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, PCECC can allocate an Adj-SID. The PCECC sends PCInitiate message to update the label map of each Adj to the corresponding nodes in the domain. Each node (PCC) download the label forwarding instructions accordingly. The forwarding behavior and the end result is similar to IGP based "Adj-SID" in SR.

The various mechanism are described in [I-D.zhao-pce-pcep-extension-pce-controller-sr].

3.2.2. Use Cases of PCECC for SR Best Effort (BE) Path

In this mode of the solution, the PCECC just need to allocate the node segment ID and adjacency ID (without calculating the explicit path for the SR path). The ingress of the forwarding path just need to encapsulate the destination node segment ID 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 header with segment list {1008} (Node SID for R8). The path would be the based on the routing/nexthop calculation on the routers.

3.2.3. Use Cases of PCECC for SR Traffic Engineering (TE) Path

SR-TE paths may not follow an IGP 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 signaling protocol. For the case where strict traffic engineering path is needed, all the adjacency SID are stacked, otherwise a combination of node-SID or adj-SID can be used for the SR-TE paths.

Note that the bandwidth reservations is only guaranteed through the enforce of the bandwidth admission control. As for the RSVP-TE LSP case, the control plane signaling also does the link bandwidth reservation in each hop of the path.

The SR traffic engineering path examples are explained as bellow:

Note that the node SID for each node is allocated from the SRGB and adjacency SID for each link are allocated from the SRLB for each node.

Example 1:

R1 may send a packet P1 to R8 simply by pushing an SR header with segment list {1008}. Based on the best path, it could be: R1-R2-R3-R8.

Example 2:

R1 may send a packet P2 to R8 by pushing an SR header with segment list {1002, 9001, 1008}. The path should be: R1-R2-(1)link-R3-R8.

Example 3:

R1 may send a packet P3 to R8 via R4 by pushing an SR header with segment list {1004, 1008}. The path could be : R1-R2-R4-R3-R8

The local protection examples for SR TE path are explained as below:

Example 4: local link protection:

Example 5: local node protection:

3.3. Use Cases of PCECC for TE LSP

In the previous sections, we have discussed the cases where the SR path is setup through the PCECC. Although those cases give the simplicity and scalability, but there are existing functionalities for the traffic engineering path such as the bandwidth guarantee, monitoring where SR based solution are complex. Also there are cases where the depth of the label stack is an issue for existing deployment and certain vendors.

So to address these issues, PCECC architecture also support the TE LSP functionalities. To achieve this, the existing PCEP can be used to communicate between the PCECC and nodes along the path. This is similar to static LSPs, where LSPs can be 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 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.

                      | R1       |
                        |       |
                        |link1  |
                        |       |link2
                       | R2       |
                link3 *   |   *    * link4
                     *    |   *     *
                    *link5|   *      *  *      |   *link6  *
        +-----------+     |   *     +-----------+
        | R4        |     |   *     | R5        |
        +-----------+     |   *     +-----------+
                   *      |   *      *       +
            link10  *     |   *     *link7   +
                     *    |   *    *         +
                     +-----------+   +-----------+ | R3        |   |R6         |
                     +-----------+   +-----------+
                      |         |
                      |link8    |
                      |         |link9
                     | R8        |

Figure 2: PCECC TE LSP Setup Example

3.3.1. PCECC Load Balancing (LB) Use Case

Very often many service providers use TE tunnels for solving issues with non-deterministic paths in their networks. One example of such applications is usage of TEs in the mobile backhaul (MBH). Let's consider the following typical topology.

                              TE1 -------------->
+---------+    +--------+    +--------+    +--------+    +------+  +---+
| 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 subrings. L3 starts at aggregation. For the sake of simplicity here we have only one access subring, access ring and aggregation ring (AGG1...AGGN), connected by Nx10GE interfaces. Aggregation domain runs its own IGP. There are two Egress routers (AGG N-1,AGG N) that are connected to the Core domain via L2 interfaces. Core also have connections to service routers, RSVP TEs are 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 made by means of either L2VPNs (VPLS) or L3VPNs. Those services use MPLS TE as transport towards egress AGG routers. TE tunnels could be also used as transport towards service routers in case of seamless MPLS based architecture in the future.

There is a need to solve the following tasks:

Since other tasks are considered in other PCECC use cases above, hereafter we will focus only on load balancing (LB) task. LB task could be solved by means of PCECC in the following way:

3.3.2. PCECC and Inter-AS TE

There are various signaling options for establishing Inter-AS TE LSP: contiguous TE LSP [RFC5151], stitched TE LSP [RFC5150], nested TE LSP [RFC4206].

Requirements for PCE-based Inter-AS setup [RFC5376] describe the approach and PCEP functionality that are needed for establishing Inter-AS TE LSPs.

[RFC5376] also gives Inter- and Intra-AS PCE Reference Model that is provided below in shorten form for the sake of simplicity.

           Inter-AS       Inter-AS
     PCC <-->PCE1<--------->PCE2
      ::      ::             ::
      ::      ::             ::
      |   AS1 |        |    PCC     |
      |       |        |    AS2     |
      ::                     ::
      ::                     ::
   Intra-AS               Intra-AS
      PCE3                   PCE4

 Shorten form of Inter- and Intra-AS PCE Reference Model [RFC5376]

The PCECC belonging to different domain can co-operate to setup inter-AS TE LSP. The stateful H-PCE [I-D.ietf-pce-stateful-hpce] mechanism could be used to first establish a per-domain PCECC LSP. These could be stitched together to form inter-AS TE LSP as described in [I-D.dugeon-pce-stateful-interdomain].

Hereatfter we will focus 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 for handling all Path Computation Requests. Even more in that particular case we potentially could use single PCE for both ASes if the scalability and performance are enough, we require interfaces (PCEP and BGP-LS) to both domains. PCECC redundancy mechanisms are described in [RFC8283]. Thus routers in AS1 and AS2 (PCCs) can send Path Computation messages towards same PCECC.

             +----BGP-LS------+ +------BGP-LS-----+
             |                | |                 |
    +-:------|----::-:-+                  +--::-:-|-------:---+
    | :      |    :: : |                  |  :: : |       :   |
    | :     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=======>

               Particular case of Inter-AS PCE

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

For the figure above it would be that LSP1 from R1 to R3 may go via ASBR1 and ASBR3, and it is the primary Inter-AS LSP. R1-R3 LSP2 that go via ASBR5 and ASBR6 is the backup one. In addition there could be bypass LSP setup to protect against ASBR or inter-AS link failure.

After the addition of PCECC functionality to PCE (SDN controller), PCECC based Inter-AS TE model SHOULD follow as PCECC usecase for TE LSP as requirements of [RFC5376] with the following details:

3.4. Use Cases of PCECC for Multicast LSPs

The current multicast LSPs are setup either using the RSVP-TE P2MP or mLDP protocols. The setup of these LSPs may require manual configurations and complex signaling when the protection is considered. By using the PCECC solution, the multicast LSP can be computed and setup through 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 signaling, but also it can compute the disjoint primary path and secondary P2MP path efficiently.

3.4.1. Using PCECC for P2MP/MP2MP LSPs' Setup

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

                       |    R1    | Root node of the multicast LSP
        Transit Node   |    R2    |
        branch         +----------+
                       *  |   *  *
                  9001*   |   *   *9002
                     *    |   *    *
        +-----------+     |   *     +-----------+
        |    R4     |     |   *     |    R5     | Transit Nodes
        +-----------+     |   *     +-----------+
                   *      |   *      *     +
                9003*     |   *     *      +9004
                     *    |   *    *       +
                     +-----------+  +-----------+
                     |    R3     |  |    R6     | Leaf Node
                     +-----------+  +-----------+
                     |    R8     | Leaf Node

The P2MP examples are explained here, where R1 is root and R8 and R6 are the leaves.

The packet forwarding involves -

3.4.2. Use Cases of PCECC for the Resiliency of P2MP/MP2MP LSPs PCECC for the End-to-End Protection of the P2MP/MP2MP LSPs

In this section we describe 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 computation of the primary multicast trees, PCECC server may also take the computation of a secondary tree into consideration. A PCE may compute the primary and backup P2MP (or MP2MP) LSP together or sequentially.

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

In the example above, when the PCECC setup the primary multicast tree from the root node R1 to the leaves, which is R1->R2->{R4, R5}, at same time, it can setup the backup tree, which is R1->R11->R3->{R4, R5}. Both the these two primary forwarding tree and secondary forwarding tree will be downloaded to each routers along the primary path and the secondary path. The traffic will be forwarded through the R1->R2->{R4, R5} path normally, and when there is a node in the primary tree fails (say R2), then the root node R1 will switch the flow to the backup tree, which is R1->R11->R3->{R4, R5}. By using the PCECC, the path computation and forwarding path downloading can all be done without the complex signaling used in the P2MP RSVP-TE or mLDP. PCECC for the Local Protection of the P2MP/MP2MP LSPs

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 back LSP among PLR, the protected node, and MPs (the downstream nodes of the protected node). In the cases where the amount of downstream nodes are huge, this mechanism can avoid unnecessary packet duplication on PLR and protect the network from traffic congestion risk.

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

In the example above, when the PCECC setup the primary multicast path around the PLR node R10 to protect node R20, which is R10->R20->{R40, R50}, at same time, it can setup the backup path R10->R30->{R40, R50}. Both the these two primary forwarding path and secondary bypass forwarding path will be downloaded to each routers 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, then the PLR node R10 will switch the flow to the backup path, which is R10->R30->{R40, R50}. By using the PCECC, the path computation and forwarding path downloading can all be done without the complex signaling used in the P2MP RSVP-TE or mLDP.

3.5. Use Cases of PCECC for LSP in the Network Migration

One of the main advantages for PCECC solution is that it has backward compatibility naturally since the PCE server itself can function as a proxy node of MPLS network for all the new nodes which may no longer support the signaling protocols.

As it is illustrated in the following example, the current network could migrate to a total PCECC controlled network gradually by replacing the legacy nodes. During the migration, the legacy nodes still need to signal using the existing MPLS protocol such as LDP and RSVP-TE, and the new nodes setup their portion of the forwarding path through PCECC directly. With the PCECC function as the proxy of these new nodes, MPLS signaling can populate through network as normal.

Example described in this section is based on network configurations illustrated using the following figure:

|                         PCE DOMAIN                               |
|    +-----------------------------------------------------+       |
|    |                       PCECC                         |       |
|    +-----------------------------------------------------+       |
|     ^              ^                      ^            ^         |
|     |      PCEP    |                      |   PCEP     |         |
|     V              V                      V            V         |
| +--------+   +--------+   +--------+   +--------+   +--------+   |
| | NODE 1 |   | NODE 2 |   | NODE 3 |   | NODE 4 |   | NODE 5 |   |
| |        |...|        |...|        |...|        |...|        |   |
| | Legacy |if1| Legacy |if2|Legacy  |if3| PCECC  |if4| PCECC  |   |
| |  Node  |   |  Node  |   |Enabled |   |Enabled |   | Enabled|   |
| +--------+   +--------+   +--------+   +--------+   +--------+   |
|                                                                  |

Example: PCECC Initiated LSP Setup In the Network Migration

In this example, there are five nodes for the TE LSP from head end (Node1) to the tail end (Node5). Where the Node4 and Node5 are centrally controlled and other nodes are legacy nodes.

3.6. Use Cases of PCECC for L3VPN and PWE3

As described in [RFC8283], various network services may be offered over a network. These include protection services (including Virtual Private Network (VPN) services (such as Layer 3 VPNs [RFC4364] or Ethernet VPNs [RFC7432]); or Pseudowires [RFC3985]. Delivering services over a network in an optimal way requires coordination in the way that network resources are allocated to support the services. A PCE-based central controller can consider the whole network and all components of a service at once when planning how to deliver the service. It can then use PCEP to manage the network resources and to install the necessary associations between those resources.

In the case of L3VPN, VPN labels can be assigned and distributed through the PCECC PCEP among the PE router instead of using the BGP protocols.

Example described in this section is based on network configurations illustrated using the following figure:

            |                   PCE DOMAIN              |
            |    +-----------------------------------+  |
            |    |                PCECC              |  |
            |    +-----------------------------------+  |
            |           ^          ^              ^     |
            |           V          V              V     |
 +--------+ |     +--------+   +--------+   +--------+  |  +--------+
 |  CE    | |     | PE1    |   | NODE x |   | PE2    |  |  |   CE   |
 |        |...... |        |...|        |...|        |.....|        |
 | Legacy | |if1  | PCECC  |if2|PCCEC   |if3| PCECC  |if4  | Legacy |
 |  Node  | |     | Enabled|   |Enabled |   |Enabled |  |  |  Node  |
 +--------+ |     +--------+   +--------+   +--------+  |  +--------+
            |                                           |

Example: Using PCECC for L3VPN and PWE3

In the case PWE3, instead of using the LDP signaling protocols, the label and port pairs assigned to each pseudowire can be assigned through PCECC among the PE routers and the corresponding forwarding entries will be distributed into each PE routers through the extended PCEP protocols and PCECC mechanism.

3.7. Using PCECC for Traffic Classification Information

As described in [RFC8283], traffic classification is an important part of traffic engineering. It is the process of looking at a packet to determine how it should be treated as it is forwarded through the network. It applies in many scenarios including MPLS traffic engineering (where it determines what traffic is forwarded onto which LSPs); segment routing (where it is used to select which set of forwarding instructions to add to a packet); and SFC (where it indicates along which service function path a packet should be forwarded). 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 just listed because it determines how traffic load is balanced and distributed through the network. Therefore, selecting what traffic classification should be performed by a router is an important part of the work done by a PCECC.

Instructions can be passed from the controller to the routers using PCEP. These instructions tell the routers how to map traffic to paths or connections. Refer [I-D.ietf-pce-pcep-flowspec].

Along with traffic classification, there are few more question -

3.8. Use Cases of PCECC for SRv6

As per [RFC8402], 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) [I-D.ietf-6man-segment-routing-header]. 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 [I-D.ietf-6man-segment-routing-header], an SRv6 Segment is a 128-bit value. "SRv6 SID" or simply "SID" are often used as a shorter reference for "SRv6 Segment". Further details are in An illustration is provided in [I-D.filsfils-spring-srv6-network-programming] where SRv6 SID is represented as LOC:FUNCT.

[I-D.negi-pce-segment-routing-ipv6] extends [I-D.ietf-pce-segment-routing] to support SR for IPv6 data plane. Further a PCECC could be extended to support SRv6 SID allocation and distribution.

[Editor's Note - more details to be added]

3.9. Use Cases of 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 load balancing 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 PCE-based controller, and that controller can use PCEP to program the network and install the service function chains and any required tunnels.

PCECC can play the role for setting the traffic classification rules at the classifier as well as downloading the forwarding instructions to the SFFs so that they could process the NSH and forward accordingly.

[Editor's Note - more details to be added]

3.10. Use Cases of PCECC for Native IP

[I-D.ietf-teas-native-ip-scenarios] describes the scenarios, and suggestions for the "Centrally Control Dynamic Routing (CCDR)" architecture, which integrates the merit of traditional distributed protocols (IGP/BGP), and the power of centrally control technologies (PCE/SDN) to provide one feasible traffic engineering solution in various complex scenarios for the service provider. [I-D.ietf-teas-pce-native-ip] defines the framework for CCDR traffic engineering within Native IP network, using Dual/Multi-BGP session strategy and CCDR architecture. PCEP protocol can be used to transfer the key parameters between PCE and the underlying network devices (PCC) using PCECC technique. The central control instructions from PCECC to identify which prefix should be advertised on which BGP session.

3.11. Use Cases of PCECC for Local Protection (RSVP-TE)

[I-D.cbrt-pce-stateful-local-protection] describes the need for the PCE to maintain and associate the local protection paths for the RSVP-TE LSP. Local protection requires the setup of a bypass at the PLR. This bypass can be PCC-initiated and delegated, or PCE-initiated. In either case, the PLR MUST maintain a PCEP session to the PCE. The Bypass LSPs need to mapped to the primary LSP. This could be done locally at the PLR based on a local policy but there is a need for a PCE to do the mapping as well to exert greater control.

This mapping can be done via PCECC procedures where the PCE could instruct the PLR to the mapping and identify the primary LSP for which bypass should be used.

4. IANA Considerations

This document does not require any action from IANA.

5. Security Considerations


6. Acknowledgments

We would like to thank Adrain Farrel, Aijun Wang, Robert Tao, Changjiang Yan, Tieying Huang, Sergio Belotti, Dieter Beller, Andrey Elperin and Evgeniy Brodskiy for their useful comments and suggestions.

7. References

7.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
[RFC8283] Farrel, A., Zhao, Q., 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.

7.2. Informative References

[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005.
[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.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006.
[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.
[RFC5151] Farrel, A., 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.
[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.
[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.
[RFC7432] Sajassi, A., 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.
[RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015.
[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.
[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.
[RFC8355] Filsfils, C., Previdi, S., Decraene, B. and R. Shakir, "Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks", RFC 8355, DOI 10.17487/RFC8355, March 2018.
[RFC8402] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018.
[I-D.ietf-pce-segment-routing] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W. and J. Hardwick, "PCEP Extensions for Segment Routing", Internet-Draft draft-ietf-pce-segment-routing-14, October 2018.
[I-D.ietf-pce-stateful-hpce] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D. and O. Dios, "Hierarchical Stateful Path Computation Element (PCE).", Internet-Draft draft-ietf-pce-stateful-hpce-05, June 2018.
[I-D.ietf-pce-pcep-flowspec] Dhody, D., Farrel, A. and Z. Li, "PCEP Extension for Flow Specification", Internet-Draft draft-ietf-pce-pcep-flowspec-02, October 2018.
[I-D.zhao-pce-pcep-extension-for-pce-controller] Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A. and C. Zhou, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs", Internet-Draft draft-zhao-pce-pcep-extension-for-pce-controller-08, June 2018.
[I-D.zhao-pce-pcep-extension-pce-controller-sr] Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A. and C. Zhou, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of SR-LSPs", Internet-Draft draft-zhao-pce-pcep-extension-pce-controller-sr-03, June 2018.
[I-D.li-pce-controlled-id-space] Li, C., Chen, M., Dong, J., Li, Z. and D. Dhody, "PCE Controlled ID Space", Internet-Draft draft-li-pce-controlled-id-space-00, June 2018.
[I-D.dugeon-pce-stateful-interdomain] Dugeon, O., Meuric, J., Lee, Y., Dhody, D. and D. Ceccarelli, "PCEP Extension for Stateful Inter-Domain Tunnels", Internet-Draft draft-dugeon-pce-stateful-interdomain-01, July 2018.
[I-D.cbrt-pce-stateful-local-protection] Barth, C. and R. Torvi, "PCEP Extensions for RSVP-TE Local-Protection with PCE-Stateful", Internet-Draft draft-cbrt-pce-stateful-local-protection-01, June 2018.
[I-D.filsfils-spring-srv6-network-programming] Filsfils, C., Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., Matsushima, S. and Z. Li, "SRv6 Network Programming", Internet-Draft draft-filsfils-spring-srv6-network-programming-05, July 2018.
[I-D.negi-pce-segment-routing-ipv6] Negi, M., Kaladharan, P., Dhody, D. and S. Sivabalan, "PCEP Extensions for Segment Routing leveraging the IPv6 data plane", Internet-Draft draft-negi-pce-segment-routing-ipv6-02, June 2018.
[I-D.ietf-6man-segment-routing-header] Filsfils, C., Previdi, S., Leddy, J., Matsushima, S. and d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header (SRH)", Internet-Draft draft-ietf-6man-segment-routing-header-14, June 2018.
[I-D.ietf-teas-pce-native-ip] Wang, A., Zhao, Q., Khasanov, B., Chen, H., Mi, P., Mallya, R. and S. Peng, "PCE in Native IP Network", Internet-Draft draft-ietf-teas-pce-native-ip-01, June 2018.
[I-D.ietf-teas-native-ip-scenarios] Wang, A., Huang, X., Qou, C., Li, Z., Huang, L. and P. Mi, "CCDR Scenario, Simulation and Suggestion", Internet-Draft draft-ietf-teas-native-ip-scenarios-01, June 2018.
[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", , may 2011.
[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.

Appendix A. Using reliable P2MP TE based multicast delivery for distributed computations (MapReduce-Hadoop)

MapReduce model of distributed computations in computing clusters is widely deployed. In Hadoop 1.0 architecture MapReduce operations on big data performs by means of Master-Slave architecture in the Hadoop Distributed File System (HDFS), where NameNode has the knowledge about resources of the cluster and where actual data (chunks) for particular task are located (which DataNode). Each chunk of data (64MB or more) should have 3 saved copies in different DataNodes based on their proximity.

Proximity level currently has semi-manual allocation and based on Rack IDs (Assumption is that closer data are better because of access speed/smaller latency).

JobTracker node is responsible for computation tasks, scheduling across DataNodes and also have Rack-awareness. Currently transport protocols between NameNode/JobTracker and DataNodes are based on IP unicast. It has simplicity as pros but has numerous drawbacks related with its flat approach.

It is clear that we should go beyond of one DC for Hadoop cluster creation and move towards distributed clusters. In that case we need to handle performance and latency issues. Latency depends on speed of light in fiber links and also latency introduced by intermediate devices in between. The last one is closely correlated with network device architecture and performance. Current performance of NPU based routers should be enough for creating distribute Hadoop clusters with predicted latency. Performance of SW based routers (mainly as VNF) together with additional HW features such as DPDK are promising but require additional research and testing.

Main question is how can we create simple but effective architecture for distributed Hadoop cluster?

There is research [MAP-REDUCE] which show how usage of multicast tree could improve speed of resource or cluster members discovery inside the cluster as well as increase redundancy in communications between cluster nodes.

Is traditional IP based multicast enough for that? We doubt it because it requires additional control plane (IGMP, PIM) and a lot of signaling, that is not suitable for high performance computations, that are very sensitive to latency.

P2MP TE tunnels looks much more suitable as potential solution for creation of multicast based communications between Master and Slave nodes inside cluster. Obviously these P2MP tunnels should be dynamically created and turned down (no manual intervention). Here, the PCECC comes to play with main objective to create optimal topology of each particular request for MapReduce computation and also create P2MP tunnels with needed parameters such as bandwidth and delay.

This solution would require to use MPLS label based forwarding inside the cluster. Usage of label based forwarding inside DC was proposed by Yandex [MPLS-DC]. Technically it is already possible because MPLS on switches is already supported by some vendors, MPLS also exists on Linux and OVS.

The following framework can make this task:

                   |  APP   |
                        | NBI (REST API,...)
            PCEP       +----------+  REST API
     +---------+   +---|  PCECC   |----------+
     | Client  |---|---|          |          |
     +---------+   |   +----------+          |
             |     |       | |  |            |
             +-----|---+   |PCEP|            |
          +--------+   |   | |  |            |
          |            |   | |  |            |
          | REST API   |   | |  |            |
          |            |   | |  |            |
+-------------+        |   | |  |           +----------+
| Job Tracker |        |   | |  |           | NameNode |
|             |        |   | |  |           |          |
+-------------+        |   | |  |           +----------+
        +------------------+ |  +-----------+
        |              |     |              |
    |---+-----P2MP TE--+-----|-----------|  |
+----------+       +----------+      +----------+
| DataNode1|       | DataNode2|      | DataNodeN|
|TaskTraker|       |TaskTraker| .... |TaskTraker|
+----------+       +----------+      +----------+

Communication between Master nodes (JobTracker and NameNode) and PCECC via REST API MAY be either done directly or via cluster manager such as Mesos.

Phase 1: Distributed cluster resources discovery During this phase Master Nodes SHOULD identify and find available Slave nodes according to computing request from application (APP). NameNode SHOULD query PCECC about available DataNodes, NameNode MAY provide additional constrains to PCECC such as topological proximity, redundancy level.

PCECC SHOULD analyze the topology of distributed cluster and perform constrain based path calculation from client towards most suitable NameNodes. PCECC SHOULD reply to NameNode the list of most suitable DataNodes and their resource capabilities. Topology discovery mechanism for PCECC will be added later to that framework.

Phase 2: PCECC SHOULD create P2MP LSP from client towards those DataNodes by means of PCEP messages following previously calculated path.

Phase 3. NameNode SHOULD send this information to client, PCECC informs client about optimal P2MP path towards DataNodes via PCEP message.

Phase 4. Client sends data blocks to those DataNodes for writing via created P2MP tunnel.

When this task will be finished, P2MP tunnel could be turned down.

Authors' Addresses

Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 US EMail: quintin.zhao@huawei.com
Zhenbin (Robin) Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing, 100095 China EMail: lizhenbin@huawei.com
Boris Khasanov Huawei Technologies Moskovskiy Prospekt 97A St.Petersburg, 196084 Russia EMail: khasanov.boris@huawei.com
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India EMail: dhruv.ietf@gmail.com
King Ke Tencent Holdings Ltd. Shenzhen, China EMail: kinghe@tencent.com
Luyuan Fang Expedia, Inc. USA EMail: luyuanf@gmail.com
Chao Zhou Cisco Systems EMail: chao.zhou@cisco.com
Boris Zhang Telus Communications EMail: Boris.zhang@telus.com
Artem Rachitskiy Mobile TeleSystems JLLC Nezavisimosti ave., 95 Minsk, 220043 Belarus EMail: arachitskiy@mts.by
Anton Gulida LLC "Lifetech" Krasnoarmeyskaya str., 24 Minsk, 220030 Belarus EMail: anton.gulida@life.com.by