idnits 2.17.1 draft-zhao-teas-pcecc-use-cases-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 26) being 86 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 79 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 12 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 125 has weird spacing: '...network with ...' == Line 926 has weird spacing: '...ay from manua...' == Line 929 has weird spacing: '...tion of trans...' == Line 945 has weird spacing: '...ination route...' == Line 958 has weird spacing: '...message to...' == (2 more instances...) -- The document date (October 26, 2016) is 2739 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC7334' is mentioned on line 1076, but not defined == Missing Reference: 'RFC5151' is mentioned on line 1096, but not defined == Missing Reference: 'RFC5150' is mentioned on line 1096, but not defined == Missing Reference: 'RFC4206' is mentioned on line 1097, but not defined == Unused Reference: 'RFC5440' is defined on line 1228, but no explicit reference was found in the text == Unused Reference: 'RFC5441' is defined on line 1235, but no explicit reference was found in the text == Unused Reference: 'RFC5541' is defined on line 1242, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 1278, but no explicit reference was found in the text == Unused Reference: 'I-D.li-mpls-global-label-usecases' is defined on line 1297, but no explicit reference was found in the text == Unused Reference: 'I-D.li-mpls-global-label-framework' is defined on line 1302, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-14 -- Unexpected draft version: The latest known version of draft-crabbe-pce-pce-initiated-lsp is -03, but you're referring to -05. == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-06 == Outdated reference: A later version (-08) exists of draft-zhao-pce-pcep-extension-for-pce-controller-03 == Outdated reference: A later version (-12) exists of draft-ietf-spring-resiliency-use-cases-02 Summary: 3 errors (**), 0 flaws (~~), 23 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group Quintin Zhao 3 Internet-Draft Robin Li 4 Intended status: Experimental Boris Khasanov, Ed. 5 Expires: May 25, 2017 Huawei Technologies 6 King Ke 7 Tencent Holdings Ltd. 8 Luyuan Fang 9 Microsoft 10 Chao Zhou 11 Cisco Systems 12 Boris Zhang 13 Telus Communications 14 Artem Rachitskiy 15 Anton Gulida 16 Mobile TeleSystems JLLC 17 October 26, 2016 19 The Use Cases for Using PCE as the Central Controller(PCECC) of LSPs 20 draft-zhao-teas-pcecc-use-cases-02 22 Abstract 24 In certain networks deployment scenarios, service providers would 25 like to keep all the existing MPLS functionalities in both MPLS and 26 GMPLS network while reducing existing complexity.In this document, 27 we propose to use the PCE as a central controller so that LSP can be 28 calculated/signaled/initiated/downloaded/managed through a 29 centralized PCE server to each network devices along the LSP path 30 while leveraging the existing PCE technologies as much as possible. 32 This draft describes the use cases for using the PCE as the central 33 controller where LSPs are calculated/setup/initiated/downloaded/ 34 maintained through extending the current PCE architectures and 35 extending the PCEP. 37 Requirements Language 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in [RFC2119]. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on May 25, 2017. 59 Copyright Notice 61 Copyright (c) 2016 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 78 1.2. Using the PCE as the Central Controller (PCECC) Approach 4 79 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 3. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 7 81 4. Use Cases of PCECC for Label Resource Reservations . . . . . 8 82 5. Using PCECC for SR without the IGP Extension . . . . . . . . 9 83 5.1. Use Cases of PCECC for SR Best Effort(BE) Path . . . . . 10 84 5.2. Use Cases of PCECC for SR Traffic Engineering (TE) Path . 11 85 6. Use Cases of PCECC for TE LSP . . . . . . . . . . . . . . . . 12 86 7. Use Cases of PCECC for Multicast LSPs . . . . . . . . . . . . 14 87 7.1. Using PCECC for P2MP/MP2MP LSPs' Setup . . . . . . . . . 14 88 7.2. Use Cases of PCECC for the Resiliency of P2MP/MP2MP LSPs 15 89 7.2.1. PCECC for the End-to-End Protection of the P2MP/MP2MP 90 LSPs . . . . . . . . . . . . . . . . . . . . . . . . 15 91 7.2.2. PCECC for the Local Protection of the P2MP/MP2MP LSPs 16 92 8. Use Cases of PCECC for LSP in the Network Migration . . . . . 17 93 9. Use Cases of PCECC for L3VPN and PWE3 . . . . . . . . . . . . 19 94 10. Using PCECC for Traffic Classification Informations . . . . . 19 95 11. Use case of PCECC for load balancing . . . . . . . . . . . . 20 96 12. Using reliable P2MP TE based multicast delivery for distributed 97 computations (MapReduce-Hadoop). . . . . . . . . . . . . . . 22 98 13. PCECC and Inter-AS TE . . . . . . . . . . . . . . . . . . . . 24 99 14. The Considerations for PCECC Procedure and PCEP extensions . 25 100 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 101 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 102 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 103 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 17.1. Normative References . . . . . . . . . . . . . . . . . . 25 105 17.2. Informative References . . . . . . . . . . . . . . . . . 25 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 108 1. Introduction 110 1.1. Background 112 In many network deployment scenarios, service providers would like 113 to have the ability to dynamically adapt to a wide range of 114 customer's requests for the sake of flexible network service 115 delivery. SDN provides such flexibility and programmability for 116 that case. 118 By migrating to the SDN enabled network from the existing network, 119 service providers and network operators must have a solution which 120 they can easily evolve from the existing network into the fully SDN 121 enabled network while keeping scalability of the network services, 122 guarantee robustness, availability, flexibility etc. 124 Taking into account the smooth transition from existing network 125 to the new SDN enabled network with optimal cost, 126 re-usage of the existing PCE components in network to be 127 function of the central (SDN) controller is one choice, 128 that not only achieves the goal of having centralized control 129 but also leverages the existing PCE network components. 131 The Path Computation Element communication Protocol (PCEP) provides 132 mechanisms for Path Computation Elements (PCEs) to perform route 133 computations in response to Path Computation Clients (PCCs) requests. 134 PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model 135 draft [I-D. draft-ietf-pce-stateful-pce] describes a set of 136 extensions to PCEP to enable active control of MPLS-TE and GMPLS 137 tunnels. 139 [I-D.crabbe-pce-pce-initiated-lsp] describes the setup and teardown 140 of PCE-initiated LSPs under the active stateful PCE model, without 141 the need for local configuration on the PCC, thus allowing for a 142 dynamic MPLS network that is centrally controlled and deployed. 144 [I-D.ali-pce-remote-initiated-gmpls-lsp] complements [I-D. draft- 145 crabbe-pce-pce-initiated-lsp] by addressing the requirements for 146 remote-initiated GMPLS LSPs. 148 Segment Routing (SR) technology leverages the source routing and 149 tunneling paradigms. A source node can choose a path without relying 150 on hop-by-hop signaling protocols such as LDP or RSVP-TE. Each path 151 is specified as a set of "segments" advertised by link-state routing 152 protocols (IS-IS or OSPF). [I-D.filsfils-spring-segment-routing] 153 provides an introduction to SR technology. The corresponding IS-IS 154 and OSPF extensions are specified in [I-D.ietf-isis-segment-routing- 155 extensions] and [I-D.psenak-ospf-segment-routing-extensions], 156 respectively. 158 A Segment Routed path (SR path) can be derived from an IGP Shortest 159 Path Tree (SPT). Segment Routed Traffic Engineering paths (SR-TE 160 paths) may not follow IGP SPT. Such paths may be chosen by a 161 suitable network planning tool and provisioned on the source node of 162 the SR-TE path. 164 It is possible to use a stateful PCE for computing one or more SR-TE 165 paths taking into account various constraints and objective 166 functions. Once a path is chosen, the stateful PCE can instantiate 167 an SR-TE path on a PCC using PCEP extensions specified in [I- 168 D.crabbe-pce-pce-initiated-lsp] using the SR specific PCEP extensions 169 described in [I-D.sivabalan-pce-segment-routing]. 171 By using the solutions provided from above drafts, LSP in both MPLS 172 and GMPLS network can be setup/delete/maintained/synchronized through 173 a centrally controlled MPLS network. 175 The PCECC solution proposed in this document allows creation of dynamic 176 MPLS network that is eventually controlled and deployed without the 177 RSVP-TE protocol or extended IGP protocol with node/adjacency segment 178 identifiers while providing all the key MPLS functionalities needed by 179 the service providers. 180 These key MPLS features include MPLS P2P LSP, P2MP/MP2MP LSP, MPLS 181 protection mechanism etc. In the case that one LSP path consists 182 legacy network nodes and the new network nodes which are centrally 183 controlled, the PCECC solution provides a smooth transition way for 184 users. 186 1.2. Using the PCE as the Central Controller (PCECC) Approach 188 PCECC not only can remove the existing MPLS signaling totally 189 from the control plane without losing any MPLS functionalities, 190 but also will achieve this goal through utilizing the existing PCEP 191 without introducing a new protocol into the network. 193 The following diagram illustrates the PCECC architecture. 195 +----------------------------------------------------------------+ 196 | PCECC | 197 | +-----------------------------------------------------+ | 198 | | LSP-Database RSVP-TE Signal Control Module | | 199 | | TE-Database LDP signaling Control Module | | 200 | | Label-Database LSP/label/TE MGRs | | 201 | +-----------------------------------------------------+ | 202 | ^ ^ ^ ^ ^ | 203 | IGP|LDP/RSVP-TE |PCEP |PCEP PCEP| IGP|LDP/ | 204 | |PCEP | | | |RSVP-TE/ | 205 | V V V V V PCE | 206 | +--------+ +--------+ +--------+ +--------+ +--------+ | 207 | |NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | | 208 | | |...| |...| |...| |...| | | 209 | | Legacy |IGP| |IGP| |IGP| PCC4 |IGP| Legacy | | 210 | | Node | | | | | | | | Node | | 211 | +--------+ +--------+ +--------+ +--------+ +--------+ | 212 | | 213 +----------------------------------------------------------------+ 215 Through the draft, we call the combination of the functionality for 216 global label range signaling and the functionality of LSP 217 setup/download/cleanup using the combination of global labels and 218 local labels as PCECC functionality. 220 Current MPLS label has local meaning. That is, MPLS label allocated 221 locally and signaled through the LDP/RSVP-TE/BGP etc. dynamic 222 signaling protocol. 224 As the SDN(Service-Driven Network) technology develops, MPLS global 225 label has been proposed again for new solutions. [I-D.li-mpls- 226 global-label-usecases] proposes possible usecases of MPLS global 227 label. MPLS global label can be used for identification of the 228 location, the service and the network in different application 229 scenarios. From these usecases we can see that no matter SDN or 230 traditional application scenarios, the new solutions based on MPLS 231 global label can facilitate service provisions. 232 The solution choices are described in [I-D.li-mpls-global-label- 233 framework]. 235 To ease the label allocation and signaling mechanism, also with the 236 new applications such as concentrated LSP controller is introduced, 237 PCE can be conveniently used as a central controller and MPLS global 238 label range negotiator. 240 The later section of this draft describes the user cases for PCE 241 server and PCE clients to have the global label range negotiation and 242 local label range negotiation functionality. 244 To empower networking with centralized controllable modules, there 245 are many choices for downloading the forwarding entries to the data 246 plane, one way is the use of the OpenFlow protocol, which helps 247 devices to populate their forwarding tables according to a set of 248 instructions to the data plane. There are other candidate protocols 249 to convey specific configuration information towards devices also. 250 Since the PCEP protocol is already deployed in some of the service 251 providers networks, leverage the PCEP to populated the MPLS forwarding 252 table is a possible good choice. 254 For the centralized network, the performance achieved through 255 distributed system can not be easy matched if all of the forwarding 256 path is computed, downloaded and maintained by the centralized 257 controller. The performance can be improved by supporting part of 258 the forwarding path in the PCECC network through the segment routing 259 mechanism except that the adjacency IDs for all the network nodes and 260 links are propagated through the centralized controller instead of 261 using the IGP extension. 263 The node and link adjacency IDs can be negotiated through the PCECC 264 with each PCECC clients and these IDs can be just taken from the 265 global label range which has been negotiated already. 267 With the capability of supporting SR within the PCECC architecture, 268 all the p2p forwarding path protection use cases described in the 269 draft [I-D.ietf-spring-resiliency-use-cases] will be supported too 270 within the PCECC network. These protection alternatives include end- 271 to-end path protection, local protection without operator management 272 and local protection with operator management. 274 With the capability of global label and local label existing at the 275 same time in the PCECC network, PCECC will use compute, setup and 276 maintain the P2MP and MP2MP LSP using the local label range for each 277 network nodes. 279 With the capability of setting up/maintaining the P2MP/MP2MP LSP 280 within the PCECC network, it is easy to provide the end-end managed 281 path protection service and the local protection with the operation 282 management in the PCECC network for the P2MP/MP2MP LSP, which 283 includes both the RSVP-TE P2MP based LSP and also the mLDP based LSP. 285 2. Terminology 287 The following terminology is used in this document. 289 IGP: Interior Gateway Protocol. Either of the two routing 290 protocols, Open Shortest Path First (OSPF) or Intermediate System 291 to Intermediate System (IS-IS). 293 PCC: Path Computation Client: any client application requesting a 294 path computation to be performed by a Path Computation Element. 296 PCE: Path Computation Element. An entity (component, application, 297 or network node) that is capable of computing a network path or 298 route based on a network graph and applying computational 299 constraints. 301 TE: Traffic Engineering. 303 3. PCEP Requirements 305 Following key requirements associated PCECC should be considered when 306 designing the PCECC based solution: 308 1. Path Computation Element (PCE) clients supporting this draft MUST 309 have the capability to advertise its PCECC capability to the 310 PCECC. 312 2. Path Computation Element (PCE) supporting this draft MUST have 313 the capability to negotiate a global label range for a group of 314 clients. 316 3. Path Computation Client (PCC) MUST be able ask for global label 317 range assigned in path request message . 319 4. PCE are not required to support label reserve service. 320 Therefore, it MUST be possible for a PCE to reject a Path 321 Computation Request message with a reason code that indicates no 322 support for label reserve service. 324 5. PCEP SHOULD provide a means to return global label range and LSP 325 label assignments of the computed path in the reply message. 327 6. PCEP SHOULD provide a means to download the MPLS forwarding entry 328 to the PCECC's clients. 330 4. Use Cases of PCECC for Label Resource Reservations 332 Example 1 to 2 are based on network configurations illustrated using 333 the following figure: 335 +------------------------------+ +------------------------------+ 336 | PCE DOMAIN 1 | | PCE DOMAIN 2 | 337 | +--------+ | | +--------+ | 338 | | | | | | | | 339 | | PCECC1 | ----------------------- | PCECC2 | | 340 | | | | | | | | 341 | | | | | | | | 342 | +--------+ | | +--------+ | 343 | ^ ^ | | ^ ^ | 344 | / \ | | / \ | 345 | V V | | V V | 346 | +--------+ +--------+ | | +--------+ +--------+ | 347 | |NODE 11 | | NODE 1n| | | |NODE 21 | | NODE 2n| | 348 | | | ...... | | | | | | ...... | | | 349 | | PCECC | | PCECC | | | | PCECC | |PCECC | | 350 | |Enabled | | Enabled| | |Enabled | |Enabled | | 351 | +--------+ +--------+ | | +--------+ +--------+ | 352 | | | | 353 +------------------------------+ +------------------------------+ 355 Example 1: Shared Global Label Range Reservation 357 o PCECC Clients nodes report MPLS label capability to the central 358 controller PCECC. 360 o The central controller PCECC collects MPLS label capability of all 361 nodes. Then PCECC can calculate the shared MPLS global label 362 range for all the PCECC client nodes. 364 o In the case that the shared global label range need to be 365 negotiated across multiple domains, the central controllers of 366 these domains need to be communicate to negotiate a common global 367 label range. 369 o The central controller PCECC notifies the shared global label 370 range to all PCECC client nodes. 372 Example 2: Global Label Allocation 374 o PCECC Client node1 send global label allocation request to the 375 central controller PCECC1. 377 o The central controller PCECC1 allocates the global label for FEC1 378 from the shared global label range and sends the reply to the 379 client node1. 381 o The central controller PCECC1 notifies the allocated label for 382 FEC1 to all PCECC client nodes within domain 1. 384 5. Using PCECC for SR without the IGP Extension 386 For the centralized network, the performance achieved through 387 distributed system can not be easy matched if all of the forwarding 388 path is computed, downloaded and maintained by the centralized 389 controller. The performance can be improved by supporting part of 390 the forwarding path in the PCECC network through the segment routing 391 mechanism except that node segment ids and adjacency segment IDs for 392 all the network are allocated dynamically and propagated through the 393 centralized controller instead of using the IGP extension. 395 When the PCECC is used for the distribution of the node segment ID 396 and adjacency segment ID, the node segment ID is allocated from the 397 global label pool. For the allocation of adjacency segment ID, there 398 are two choices, the first choice is that it is allocated from the 399 local label pool, the second choice is that it is allocated from the 400 global label pool. The advantage for the second choice is that the 401 depth of the label stack for the forwarding path encoding will be 402 reduced since adjacency segment ID can signal the forwarding path 403 without adding the node segment ID in front of it. In this version 404 of the draft, we use the fist choice for now. We may update the 405 draft to reflect the use of the second choice. 407 Same as the SR solutions, when PCECC is used as the central 408 controller, the support of FRR on any topology can be pre-computated 409 and setup without any additional signaling (other than the regular 410 IGP/BGP protocols) including the support of shared risk constraints, 411 support of node and link protection and support of microloop 412 avoidance. 414 The following example illustrate the use case where the node segment 415 ID and adjacency segment ID are allocated from the global label 416 allocated for SR path. 418 192.0.2.1/32 419 +----------+ 420 | R1(1001) | 421 +----------+ 422 | 423 +----------+ 424 | R2(1002) | 192.0.2.2/32 425 +----------+ 426 * | * * 427 * | * * 428 *link1| * * 429 192.0.2.4/32 * | *link2 * 192.0.2.5/32 430 +-----------+ 9001| * +-----------+ 431 | R4(1004) | | * | R5(1005) | 432 +-----------+ | * +-----------+ 433 * | *9003 * + 434 * | * * + 435 * | * * + 436 +-----------+ +-----------+ 437 192.0.2.3/32 | R3(1003) | |R6(1006) |192.0.2.6/32 438 +-----------+ +-----------+ 439 | 440 +-----------+ 441 | R8(1008) | 192.0.2.8/32 442 +-----------+ 444 5.1. Use Cases of PCECC for SR Best Effort(BE) Path 446 In this mode of the solution, the PCECC just need to allocate the 447 node segment ID and adjacency ID without calculating the explicit 448 path for the SR path. The ingress of the forwarding path just need 449 to encapsulate the destination node segment ID on top of the packet. 450 All the intermediate nodes will forward the packet based on the final 451 destination node segment id. It is similar to the LDP LSP forwarding 452 except that label swapping is using the same global label both for 453 the in segment and out segment in each hop. 455 The p2p SR BE path examples are explained as bellow: 457 Note that the node segment id for each node from the shared global 458 labels ranges negotiated already. 460 Example 1: 462 R1 may send a packet to R8 simply by pushing an SR header with 463 segment list {1008}. The path can be: R1-R2-R3-R8 or R1-R2-R5-R8 464 depending on the route calculation on node R2. 466 Example 2: local link/node protection: 468 For the packet which has destination of R3 and after that, R2 may 469 preinstalled the backup forwarding entry to protect the R4 node, the 470 pre-installed the backup path can go through either node5 or link1 or 471 link2 between R2 and R3. The backup path calculation is locally 472 decided by R2 and any existing IP FRR algorithms can be used here. 474 5.2. Use Cases of PCECC for SR Traffic Engineering (TE) Path 476 In the case of traffic engineering path is needed, the PCECC need to 477 allocate the node segment ID and adjacency ID, and at the same time 478 PCECC calculates the explicit path for the SR path and pass this 479 explicit path represented with a sequence of node segment id and 480 adjacency id. The ingress of the forwarding path need to encapsulate 481 the stack of node segment id and adjacency id on top of the packet. 482 For the case where strict traffic engineering path is needed, all the 483 intermediate nodes and links will be specified through the stack of 484 labels so that the packet is forwarded exactly as it is wanted. 486 Even though it is similar to TE LSP forwarding where forwarding path 487 is engineered, but the Qos is only guaranteed through the enforce of 488 the bandwidth admission control. As for the RSVP-TE LSP case, Qos is 489 guaranteed through the link bandwidth reservation in each hop of the 490 forwarding path. 492 The p2p SR traffic engineering path examples are explained as bellow: 494 Note that the node segment id for each node is allocated from the 495 shared global labels ranges negotiated already and adjacency segment 496 ids for each link are allocated from the local label pool for each 497 node. 499 Example 1: 501 R1 may send a packet P1 to R8 simply by pushing an SR header with 502 segment list {1008}. The path should be: R1-R2-R3-R8. 504 Example 2: 506 R1 may send a packet P2 to R8 by pushing an SR header with segment 507 list {1002, 9001, 1008}. The path should be: R1-R2-(1)link-R3-R8. 509 Example 3: 511 R1 may send a packet P3 to R8 while avoiding the links between R2 and 512 R3 by pushing an SR header with segment list {1004, 1008}. The path 513 should be : R1-R2-R4-R3-R8 514 The p2p local protection examples for SR TE path are explained as 515 below: 517 Example 4: local link protection: 519 o R1 may send a packet P4 to R8 by pushing an SR header with segment 520 list {1002, 9001, 1008}. The path should be: R1-R2-(1)link-R3-R8. 522 o When node R2 receives the packet from R1 which has the header of 523 R2- (1)link-R3-R8, and also find out there is a link failure of 524 link1, then it will send out the packet with header of R3-R8 525 through link2. 527 Example 5: local node protection: 529 o R1 may send a packet P5 to R8 by pushing an SR header with segment 530 list {1004, 1008}. The path should be : R1-R2-R4-R3-R8. 532 o When node R2 receives the packet from R1 which has the header of 533 {1004, 1008}, and also find out there is a node failure for node4, 534 then it will send out the packet with header of {1005, 1008} to 535 node5 instead of node4. 537 6. Use Cases of PCECC for TE LSP 539 In the previous sections, we have discussed the cases where the SR 540 path is setup through the PCECC. Although those cases give the 541 simplicity and scalability, but there are existing functionalities 542 for the traffic engineering path such as the bandwidth guarantee 543 through the full forwarding path and the multicast forwarding path 544 which SR based solution cannot solve. Also there are cases where the 545 depth of the label stack may have been an issue for existing 546 deployment and certain vendors. 548 So to address these issues, PCECC architecture should also support 549 the TE LSP and multicast LSP functionalities. To achieve this, the 550 existing PCEP can be used to communicate between the PCE server and 551 PCE's client PCC for exchanging the path request and reply 552 information regarding to the TE LSP info. In this case, the TE LSP 553 info is not only the path info itself, but it includes the full 554 forwarding info. Instead of letting the ingress of LSP to initiate 555 the LSP setup through the RSVP-TE signaling protocol, with minor 556 extensions, we can use the PCEP to download the complete TE LSP 557 forwarding entries for each node in the network. 559 192.0.2.1/32 560 +----------+ 561 | R1(1001) | 562 +----------+ 563 | | 564 6001|link1 | 565 | 6002|link2 566 +----------+ 567 | R2(1002) | 192.0.2.2/32 568 +----------+ 569 link3 * | * * link4 570 7002 * | * *7001 571 *link1| * * 572 192.0.2.4/32 * | *link2 * 192.0.2.5/32 573 +-----------+ 5001| * +-----------+ 574 | R4(1004) | | * | R5(1005) | 575 +-----------+ | * +-----------+ 576 * | *5003 * + 577 9001* | * *link1 + 578 * | * *9002 + 579 +-----------+ +-----------+ 580 192.0.2.3/32 | R3(1003) | |R6(1006) |192.0.2.6/32 581 +-----------+ +-----------+ 582 | | 583 3001|link1 | 584 | 3002|link2 585 +-----------+ 586 | R8(1008) | 192.0.2.8/32 587 +-----------+ 589 TE LSP Setup Example 591 o Node1 sends a path request message for the setup of TE LSP from R1 592 to R8. 594 o PCECC program each node along the path from R1 to R8 with the 595 primary path: {R1, link1, 6001}, {R2, link3, 7002], {R4, link0, 596 9001}, {R3, link1, 3001}, {R8}. 598 o For the end to end protection, PCECC program each node along the 599 path from R1 to R8 with the secondary path: {R1, link2, 6002}, 600 {R2, link4, 7001], {R5, link1, 9002}, {R3, link2, 3002}, {R8}. 602 o It is also possible to have a secondary backup path for the local 603 node protection setup by PCECC. For example, the primary path is 604 still same as what we have setup so far, then to protect the node 605 R4 locally, PCECC can program the secondary path like this: {R1, 606 link1, 6001}, {R2, link1, 5001}, {R3, link1, 3001}, {R8}. By doing 607 this, the node R4 is locally protected. 609 7. Use Cases of PCECC for Multicast LSPs 611 The current multicast LSPs are setup either using the RSVP-TE P2MP or 612 mLDP protocols. The setup of these LSPs not only need a lot of 613 manual configurations, but also it is also complex when the 614 protection is considered. By using the PCECC solution, the multicast 615 LSP can be computed and setup through centralized controller which 616 has the full picture of the topology and bandwidth usage for each 617 link. It not only reduces the complex configurations comparing the 618 distributed RSVP-TE P2MP or mLDP signal lings, but also it can 619 compute the disjoint primary path and secondary path efficiently. 621 7.1. Using PCECC for P2MP/MP2MP LSPs' Setup 623 With the capability of global label and local label existing at the 624 same time in the PCECC network, PCECC will use compute, setup and 625 maintain the P2MP and MP2MP lsp using the local label range for each 626 network nodes. 628 +----------+ 629 | R1 | Root node of the multicast LSP 630 +----------+ 631 |6000 632 +----------+ 633 Transit Node | R2 | 634 +----------+ 635 * | * * 636 9001* | * *9002 637 * | * * 638 +-----------+ | * +-----------+ 639 | R4 | | * | R5 | Transit Nodes 640 +-----------+ | * +-----------+ 641 * | * * + 642 9003* | * * +9004 643 * | * * + 644 +-----------+ +-----------+ 645 | R3 | | R5 | Leaf Node 646 +-----------+ +-----------+ 647 9005| 648 +-----------+ 649 | R8 | Leaf Node 650 +-----------+ 652 The P2MP examples are explained here: 654 Step1: R1 may send a packet P1 to R2 simply by pushing an label of 655 6000 to the packet. 657 Step2: After R2 receives the packet with label 6000, it will 658 forwarding to R4 by pushing header of 9001 and R5 by pusing header of 659 9002. 661 Step3: After R4 receives the packet with label 9001, it will 662 forwarding to R3 by pushing header of 9003. After R5 receives the 663 packet with label 9002, it will forwarding to R5 by pushing header of 664 9004. 666 Step3: After R3 receives the packet with label 9003, it will 667 forwarding to R8 by pushing header of 9005 669 7.2. Use Cases of PCECC for the Resiliency of P2MP/MP2MP LSPs 671 7.2.1. PCECC for the End-to-End Protection of the P2MP/MP2MP LSPs 673 In this section we describe the end-end managed path protection 674 service and the local protection with the operation management in the 675 PCECC network for the P2MP/MP2MP LSP, which includes both the RSVP-TE 676 P2MP based LSP and also the mLDP based LSP. 678 An end-to-end protection (for nodes and links) principle can be 679 applied for computing backup P2MP or MP2MP LSPs. During computation 680 of the primarily multicast trees, PCECC server may also be taken into 681 consideration to compute a secondary tree. A PCE may compute the 682 primary and backup P2MP or MP2Mp LSP together or sequentially. 684 +----+ +----+ 685 Root node of LSP | R1 |--| R11| 686 +----+ +----+ 687 / + 688 10/ +20 689 / + 690 +----------+ +-----------+ 691 Transit Node | R2 | | R3 | 692 +----------+ +-----------+ 693 | \ + + 694 | \ + + 695 10| 10\ +20 20+ 696 | \ + + 697 | \ + 698 | + \ + 699 +-----------+ +-----------+ Leaf Nodes 700 | R4 | | R5 | (Downstream LSR) 701 +-----------+ +-----------+ 703 In the example above, when the PCECC setup the primary multicast tree 704 from the root node R1 to the leafs, which is R1->R2->{R4, R5}, at 705 same time, it can setup the backup tree, which is R11->R3->{R4, R5}. 706 Both the these two primary forwarding tree and secondary forwarding 707 tree will be downloaded to each routers along the primary path and 708 the secondary path. The traffic will be forwarded through the 709 R1->R2->{R4, R5} path normally, and when there is a node in the 710 primary tree, then the root node R1 will switch the flow to the 711 backup tree, which is R11->R3->{R4, R5}. By using the PCECC, the 712 path computation and forwarding path downloading can all be done 713 without the complex signaling used in the P2MP RSVP-TE or mLDP. 715 7.2.2. PCECC for the Local Protection of the P2MP/MP2MP LSPs 717 In this section we describe the local protection service in the PCECC 718 network for the P2MP/MP2MP LSP. 720 While the PCECC sets up the primary multicast tree, it can also build 721 the back LSP among PLR, the protected node, and MPs (the downstream 722 nodes of the protected node). In the cases where the amount of 723 downstream nodes are huge, this mechanism can avoid unnecessary 724 packet duplication on PLR, so that protect the network from traffic 725 congestion risk. 727 +------------+ 728 | R1 | Root Node 729 +------------+ 730 . 731 . 732 . 733 +------------+ Point of Local Repair/ 734 | R10 | Switchover Point 735 +------------+ (Upstream LSR) 736 / + 737 10/ +20 738 / + 739 +----------+ +-----------+ 740 Protected Node | R20 | | R30 | 741 +----------+ +-----------+ 742 | \ + + 743 | \ + + 744 10| 10\ +20 20+ 745 | \ + + 746 | \ + 747 | + \ + 748 +-----------+ +-----------+ Merge Point 749 | R40 | | R50 | (Downstream LSR) 750 +-----------+ +-----------+ 751 . . 752 . . 754 In the example above, when the PCECC setup the primary multicast path 755 around the PLR node R10 to protect node R20, which is R10->R20->{R40, 756 R50}, at same time, it can setup the backup path R10->R30->{R40, 757 R50}. Both the these two primary forwarding path and secondary 758 forwarding path will be downloaded to each routers along the primary 759 path and the secondary path. The traffic will be forwarded through 760 the R10->R20->{R40, R50} path normally, and when there is a node 761 failure for node R20, then the PLR node R10 will switch the flow to 762 the backup path, which is R10->R30->{R40, R50}. By using the PCECC, 763 the path computation and forwarding path downloading can all be done 764 without the complex signaling used in the P2MP RSVP-TE or mLDP. 766 8. Use Cases of PCECC for LSP in the Network Migration 768 One of the main advantages for PCECC solution is that it has backward 769 compatibility naturally since the PCE server itself can function as a 770 proxy node of MPLS network for all the new nodes which don't support 771 the existing MPLS signaling protocol anymore. 773 As it is illustrated in the following example, the current network 774 will migrate to a total PCECC controlled network gradually by 775 replacing the legacy nodes. During the migration, the legacy nodes 776 still need to signal using the existing MPLS protocol such as LDP and 777 RSVP-TE, and the new nodes setup their portion of the forwarding path 778 through PCECC directly. With the PCECC function as the proxy of 779 these new nodes, MPLS signaling can populate through network as 780 normal. 782 Example described in this section is based on network configurations 783 illustrated using the following figure: 785 +------------------------------------------------------------------+ 786 | PCE DOMAIN | 787 | +-----------------------------------------------------+ | 788 | | PCECC | | 789 | +-----------------------------------------------------+ | 790 | ^ ^ ^ | 791 | | PCEP | PCEP | | 792 | V <-----RSVP------> V V | 793 | +--------+ +--------+ +--------+ +--------+ +--------+ | 794 | | NODE 1 | | NODE 2 | | NODE 3 | | NODE 4 | | NODE 5 | | 795 | | |...| |...| |...| |...| | | 796 | | Legacy |if1| Legacy |if2|Legacy |if3| PCECC |if4| PCECC | | 797 | | Node | | Node | |Enabled | |Enabled | | Enabled| | 798 | +--------+ +--------+ +--------+ +--------+ +--------+ | 799 | | 800 +------------------------------------------------------------------+ 802 Example: PCECC Initiated LSP Setup In the Network Migration 804 In this example, there are five nodes for the TE LSP from head end 805 (Node1) to the tail end (Node5). Where the Node4 and Node5 are centrally 806 controlled and other nodes are legacy nodes. 808 o Node1 sends a path request message towards PCECC for the setup of LSP 809 destinating to Node5. 811 o PCECC sends to node1 a reply message for LSP setup with the path: 812 (Node1, if1),(Node2, if2), (Node3, if3), (Node4, if4), Node5. 814 o Node1, Node2, Node3 will setup the LSP to Node5 using the local 815 labels as usual. 817 o Then the PCECC will program the outsegment of Node3, the insegment/ 818 ousegment of Node4, and the insegment for Node5. 820 9. Use Cases of PCECC for L3VPN and PWE3 822 The existing services using MPLS LSP tunnels based on MPLS signalling 823 mechanism such L3VPN, PWE3 and IPv6 can be simplified by using the 824 PCECC to negoitate the label assignments for the L3VPN, PWE3 and 825 Ipv6. 827 In the case of L3VPN, VPN labels can be negotiated and distributed 828 through the PCECC PCEP among the PE router instead of using the BGP 829 protocols. 831 Example described in this section is based on network configurations 832 illustrated using the following figure: 834 +-------------------------------------------+ 835 | PCE DOMAIN | 836 | +-----------------------------------+ | 837 | | PCECC | | 838 | +-----------------------------------+ | 839 | ^ ^ ^ | 840 |PWE3/L3VPN | PCEP PCEP|LSP PWE3/L3VPN|PCEP | 841 | V V V | 842 +--------+ | +--------+ +--------+ +--------+ | +--------+ 843 | CE | | | PE1 | | NODE x | | PE2 | | | CE | 844 | |...... | |...| |...| |.....| | 845 | Legacy | |if1 | PCECC |if2|PCCEC |if3| PCECC |if4 | Legacy | 846 | Node | | | Enabled| |Enabled | |Enabled | | | Node | 847 +--------+ | +--------+ +--------+ +--------+ | +--------+ 848 | | 849 +-------------------------------------------+ 851 Example: Using PCECC for L3VPN and PWE3 853 In the cast PWE3, instead of using the LDP signalling protocols, the 854 lable and port pairs assigned to each pseudowire can be negotiated 855 through PCECC among the PE rotuers and the corresponding forwarding 856 entries will be distributed into each PE routers through the extended 857 PCEP protocols. 859 10. Using PCECC for Traffic Classification Information 861 When a TE-LSP is set up, the head end needs to know: 863 o how to use it 864 o What traffic to send on the LSP 866 o Whether it is a virtual link 868 o Whether to advertise it in the IGP 870 o What bits of this information to signal to the tail end 872 PCEP allows an Active PCE to set up or modify LSPs. But we have no 873 way to tell the head end how to use the LSP. This is because of 874 history. It used to be the LER that made the request of the PCE, so 875 it knew why it wanted the LSP. 877 With the PCECC architecture by extending the PCEP protocols, it is 878 easy to carry this information such as how to use the LSP, how to 879 advertise the LSP and other extra signaling information. 881 11. PCECC Load Balancing (LB) Use Case 883 Very often many service providers use TE tunnels for solving issues 884 with non-deterministic paths in their networks. One example of such 885 applications is usage of TEs in the mobile backhaul (MBH). 886 Let's consider the following typicall topology. 888 TE1 --------------> 889 +---------+ +--------+ +--------+ +--------+ +------+ +---+ 890 | Access |----| Access |----| AGG 1 |----| AGG N-1|----|Core 1|--|SR1| 891 | SubNode1| | Node 1 | +--------+ +--------+ +------+ +---+ 892 +---------+ +--------+ | | | ^ | 893 | Access | Access | AGG Ring 1 | | | 894 | SubRing 1 | Ring 1 | | | | | 895 +---------+ +--------+ +--------+ | | | 896 | Access | | Access | | AGG 2 | | | | 897 | SubNode2| | Node 2 | +--------+ | | | 898 +---------+ +--------+ | | | | | 899 | | | | | | | 900 | | | +----TE2----|-+ | 901 +---------+ +--------+ +--------+ +--------+ +------+ +---+ 902 | Access | | Access |----| AGG 3 |----| AGG N |----|Core N|--|SRn| 903 | SubNodeN|----| Node N | +--------+ +--------+ +------+ +---+ 904 +---------+ +--------+ 906 This MBH architecture uses L2 access rings and subrings. L3 starts at 907 aggregation. For the sake of simplicity here we have only one access 908 subring,access ring and aggregation ring (AGG1...AGGN), connected 909 by Nx10GE interfaces. Aggregation domain runs its own IGP. There are 910 two Egress routers (AGG N-1,AGG N) that are connected to the Core 911 domain via L2 interfaces. Core also have connections to service routers, 912 RSVP TEs are used for MPLS transport inside the ring. There could be 913 at least 2 tunnels (one way) from each AGG router to egress AGG 914 routers. There are also many L2 access rings connected to AGG routers. 916 Service deployment made by means of either L2VPNs (VPLS) or L3VPNs. 917 Those services use MPLS TE as transport towards egress AGG routers. 918 TE tunnels could be also used as transport towards service routers in 919 case of seamless MPLS based architecture in the future. 921 There is a need to solve the following tasks: 922 o Perform automatic LB amongst TE tunnels according to current 923 traffic load 924 o TE bandwidth (BW) management: Provide guaranteed BW for specific 925 service: HSI,IPTV, etc., provide time-based BW reservation (BoD) 926 o Simplify development of TE tunnels (go away from manual 927 provisioning) 928 o Provide flexibility for Service Router placement (anywhere 929 in the network by creation of transport LSPs to them) 931 Since other tasks are considered in other PCECC use cases above, 932 hereafter we will focus only on load balancing (LB) task. LB task 933 could be solved by means of PCECC in the following way: 935 o After application or network service or operator will ask SDN 936 controller (PCECC) for LSP based LB between AGG X and AGG N/AGG N-1 937 (egress AGG routers which have connections to core) via North 938 Bound Interface (NBI such as REST API), PCECC SHOULD ask for 939 constrains for that particular calculation (i.e. LSP type: traditional 940 CR-LSP or SR-TE LSP, bandwidth, inclusion or exclusion specific links 941 or nodes, number of paths, shortest path or minimum cost tree, need 942 for disjoint LSP paths etc.). 943 o PCECC MUST calculate N P2P LSPs according to given constrains, 944 calculation is based on results of Objective Function (OF), that 945 includes same source and destination routers IDs, same or different 946 bandwidth (BW) , different links (in case of disjoint paths) and other 947 constrains from Step 1. 948 o Depending on given LSP type (CR-LSP or SR-TE), PCECC SHOULD create 949 different labels (aka different label spaces, it MAY also require 950 label space negotiation procedure between PCECC and PCCs) for 951 calculated LSPs from egress nodes AGG N-1 and AGG N towards ingress 952 AGG X node. 953 o PCECC SHOULD send PCInitiate PCEP message [I-D.crabbe-pce-pce- 954 initiated-lsp] towards ingress AGG X router(PCC) for each of N LSPs 955 and receives PCRpt PCEP message [I-D.ietf-pce-stateful-pce] back from 956 him. 957 o If LSP type is CR-LSP, PCECC MUST send PCLabelUpd 958 [I-D.zhao-pce-pcep-extension-for-pce-controller] PCEP message to 959 each node along the path with label information for each of N LSPs. 960 If LSP type is SR-TE, PCECC also MUST send PCLabelUpd PCEP message 961 to each node along the path with label information (Node-ID and 962 Adjacency-ID segment (label) list) specific to that node. Then PCECC 963 SHOULD send PCUpd PCEP message to the ingress AGG X router with 964 information about new LSP and AGG X(PCC) SHOULD send PCEP PCRpt back 965 with LSP status:Up. 966 o Now each router along the LSP has corresponding label forwarding 967 state for each of N LSPs. 968 o AGG X as ingress router now have N LSPs towards AGG N and AGG N-1 969 which are available for installing to router's RIB and LB of traffic 970 between them. Traffic distribution between those LSPs depends on 971 particular realization of hash-function on that router. 972 o Since PCECC MUST know as LSDB as TEDB (TE state) he can manage and 973 prevent possible oversubscriptions and limit number of available LB 974 states. 976 12. Using reliable P2MP TE based multicast delivery for distributed 977 computations (MapReduce-Hadoop) 979 MapReduce model of distributed computations in computing clusters is 980 widely deployed. In Hadoop 1.0 architecture MapReduce operations on 981 big data performs by means of Master-Slave architecture in the Hadoop 982 Distributed File System (HDFS),where NameNode has the knowledge about 983 resources of the cluster and where actual data (chunks) for particular 984 task are located (which DataNode). Each chunk of data (64MB or more) 985 should have 3 saved copies in different DataNodes based on their 986 proximity. 988 Proximity level currently has semi-manual allocation and based on 989 Rack IDs (Assumption is that closer data are better because of access 990 speed/smaller latency). 992 JobTracker node is responsible for computation tasks, scheduling across 993 DataNodes and also have Rack-awareness. Currently transport protocols 994 between NameNode/JobTracker and DataNodes are based on IP unicast. 995 It has simplicity as pros but has numerous drawbacks related with 996 its flat approach. 998 It is clear that we should go beyond of one DC for Hadoop cluster creation 999 and move towards distributed clusters. In that case we need to handle 1000 performance and latency issues. 1001 Latency depends on speed of light in fiber links and also latency 1002 introduced by intermediate devices in between. The last one is 1003 closely correlated with network device architecture and performance. 1004 Current performance of NPU based routers should be enough for creating 1005 distribute Hadoop clusters with predicted latency. Performance of SW 1006 based routers (mainly as VNF) together with additional HW features such 1007 as DPDK are promising but require additional research and testing. 1009 Main question is how can we create simple but effective architecture for 1010 distributed Hadoop cluster? 1012 There are number of researches [Multicast Tree Map-Reduce...] which show 1013 how usage of multicast tree could improve speed of resource or cluster 1014 members discovery inside the cluster as well as increase redundancy in 1015 communications between cluster nodes. 1017 Is traditional IP based multicast enough for that? We doubt it because it 1018 requires additional control plane (IGMP, PIM) and a lot of signaling, that 1019 is not suitable for high performance computations, that are very sensitive 1020 to latency. 1022 P2MP TE tunnels looks much more suitable as potential solution for creation 1023 of multicast based communications between Master and Slave nodes inside 1024 cluster. Obviously these P2MP tunnels should be dynamically created and 1025 turned down (no manual intervention). Here is there PCECC comes to play. 1026 His main task is to create optimal topology of each partucular request for 1027 MapReduce computation and also create P2MP tunnels with needed parameters 1028 such as badnwidth and delay. 1030 This solution would require to use MPLS label based forwarding inside the 1031 cluster. Usage of label based forwarding inside DC was proposed by Yandex 1032 [MPLS in DC...] Technically it is already possible because mpls on switches 1033 is already supported by some vendors, mpls aslo exists on Linux and OVS. 1035 The following framework can make this task: 1037 +--------+ 1038 | APP | 1039 +--------+ 1040 | NBI (REST API,...) 1041 | 1042 PCEP +----------+ REST API 1043 +---------+ +---| PCECC |----------+ 1044 | Client |---|---| | | 1045 +---------+ | +----------+ | 1046 | | | | | | 1047 +-----|---+ |PCEP| | 1048 +--------+ | | | | | 1049 | | | | | | 1050 | REST API | | | | | 1051 | | | | | | 1052 +-------------+ | | | | +----------+ 1053 | Job Tracker | | | | | | NameNode | 1054 | | | | | | | | 1055 +-------------+ | | | | +----------+ 1056 +------------------+ | +-----------+ 1057 | | | | 1058 |---+-----P2MP TE--+-----|-----------| | 1059 +-----------+ +-----------+ +-----------+ 1060 | DataNode1 | | DataNode2 | | DataNodeN | 1061 |TaskTracker| |TaskTracker| .... |TaskTracker| 1062 +-----------+ +-----------+ +-----------+ 1064 Communication between Master nodes (JobTracker and NameNode) 1065 and PCECC via REST API MAY be either done directly or via 1066 cluster manager such as Mesos. 1068 Phase 1: Distributed cluster resources discovery 1069 During this phase Master Nodes SHOULD identify and find available 1070 Slave nodes according to computing request from application (APP). 1071 NameNode SHOULD query PCECC about available DataNodes, NameNode MAY 1072 provide additional constrains to PCECC such as topological proximity, 1073 redundancy level. 1075 PCECC SHOULD analyze the topology of distributed cluster and perform 1076 constrain based path calculation [RFC7334] from client towards most 1077 suitable NameNodes. PCECC SHOULD reply to NameNode the list of most 1078 suitable DataNodes and their resource capabilities. Topology discovery 1079 mechanism for PCECC will be added later to that framework. 1081 Phase 2: PCECC SHOULD create P2MP LSP from client towards those 1082 DataNodes by means of PCLabelUpd [I-D.zhao-pce-pcep-extension-for-pce 1083 -controller] PCEP messages following previously calculated path. 1085 Phase 3. NameNode SHOULD send this information to client, PCECC informs 1086 client about optimal P2MP path towards DataNodes via PCEP PCUpd message. 1088 Phase 4. Client sends data blocks to those DataNodes for writing via 1089 created P2MP tunnel. 1091 When this task will be finished, P2MP tunnel MAY be turned down. 1093 13. PCECC and Inter-AS TE 1095 There are three signalling options for establishing Inter-AS TE LSP: 1096 contiguous TE LSP [RFC5151], stitched inter-AS TE LSP [RFC5150], 1097 nested TE LSP [RFC4206]. 1099 Requirements for PCE-based Inter-AS setup [RFC5376] describe the approach 1100 and PCEP fucntionality that are needed for establishing Inter-AS TE LSPs. 1102 [RFC5376] also gives Inter- and Intra-AS PCE Reference Model that is 1103 provided below in shorten form for the sake of simplicity. 1105 Inter-AS Inter-AS 1106 PCC <-->PCE1<--------->PCE2 1107 :: :: :: 1108 :: :: :: 1109 R1----ASBR1====ASBR3---R3---ASBR5 1110 | AS1 | | PCC | 1111 | | | AS2 | 1112 R2----ASBR2====ASBR4---R4---ASBR6 1113 :: :: 1114 :: :: 1115 Intra-AS Intra-AS 1116 PCE PCE 1118 Shorten form of Inter- and Intra-AS PCE Reference Model [RFC5376] 1120 Hereatfter we will discuss a simplified Inter-AS case when both AS1 and 1121 AS2 belong to the same service provider administration. In that case Inter 1122 and Intra-AS PCEs could be combined in one single PCE if such combined PCE 1123 performance is enough for handling all Path Computation Requests. Even 1124 more in that particular case we potentially could use single PCE for both 1125 ASes if his scalability and performance are enough, we just will need 1126 interfaces (PCEP and BGP-LS) to both domains. SDN controller's redundancy 1127 mechanisms are out of scope in our case. Thus routers in AS1 and AS2 (PCCs) 1128 will send Path Computation Requests towards same PCE. 1130 +----BGP-LS------+ +------BGP-LS-----+ 1131 | | | | 1132 +-PCEP-|----++-+-------PCECC-----PCEP--++-+-|-------+ 1133 +-:------|----::-:-+ +--::-:-|-------:---+ 1134 | : v :: : | | :: : v : | 1135 | : RR1 :: : | | :: : RR2 : | 1136 | v v: : | LSP1 | :: v v | 1137 | R1---------ASBR1=======================ASBR3--------R3 | 1138 | | v : | | :v | | 1139 | +----------ASBR2=======================ASBR4---------+ | 1140 | | Region 1 : | | : Region 1 | | 1141 |----------------:-| |--:-------------|--| 1142 | | v | LSP2 | v | | 1143 | +----------ASBR5=======================ASBR6---------+ | 1144 | Region 2 | | Region 2 | 1145 +------------------+ <--------------> +-------------------+ 1146 MPLS Domain 1 Inter-AS MPLS Domain 2 1147 <=======AS1=======> <========AS2=======> 1149 Particular case of Inter-AS PCE Reference Model 1151 In one particular case of PCECC Inter-AS TE scenario service provider 1152 controls both domains (AS1 and AS2), each of them have own IGP and MPLS 1153 transport. The need is to setup Inter-AS LSPs for transporting different 1154 services on top of them (Voice,L3 VPN etc.) Inter-AS links with different 1155 capacity exist in several regions. The task is not only to provision 1156 those Inter-AS LSPs with given constrains but also calculate the path 1157 and pre-setup the backup Inter-AS LSPs that will be used if main LSP fails. 1159 For the figure above it would be that LSP1 from R1 to R3 SHOULD go via ASBR1 1160 and ASBR3, and it is the main Inter-AS LSP. R1-R3 LSP2 that SHOULD go via 1161 ASBR5 and ASBR6 is the backup one. Depending on Inter-AS TE type, backup LSP 1162 could be used either by head-end R1 or ASBR1. 1164 After the addition of PCECC functionality to PCE (SDN controller), PCECC 1165 based Inter-AS TE model SHOULD follow as PCECC usecase for TE LSP (case 6 1166 above) as requirements of [RFC5376] with the following details: 1167 o Since PCECC MUST know the topology of both domains AS1 and AS2, PCECC 1168 MUST establish BGP-LS peering with routers (or RRs) in both domains 1169 o PCECC MUST have SBI (PCEP) connectivity towards all routers in both 1170 domains (see also section 4 in [RFC5376]) 1171 o After operator's application or service orchetsrator will create request 1172 for topology of specific service, PCECC SHOULD receive that request via NBI 1173 (NBI type is implementation dependent, MAY be NETCONF/Yang, REST etc.). Then 1174 PCECC SHOULD calculate Objective Function (OF) for optimal path with given 1175 constrains (i.e. LSP type, bandwidth etc.), including those from [RFC5376]: 1176 priority, AS sequence, preffered ASBR, disjoint paths, protection. On this 1177 step we would have two paths: R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3 1178 o Depending on given LSP type (CR-LSP or SR-TE), PCECC SHOULD create 1179 different labels (aka different label spaces, it MAY also require 1180 label space negotiation procedure between PCECC and PCCs) for 1181 calculated LSPs from egress node in one AS towards ingress in another AS. 1182 o PCECC SHOULD send PCInitiate PCEP message [I-D.crabbe-pce-pce- 1183 initiated-lsp] towards ingress router R1 (PCC) in AS1 1184 and receive PCRpt PCEP message [I-D.ietf-pce-stateful-pce] back from 1185 him. 1186 o If LSP type is CR-LSP, PCECC MUST send PCLabelUpd 1187 [I-D.zhao-pce-pcep-extension-for-pce-controller] PCEP message to 1188 each node along the path (ASBR1-ASBR3-R3, ASBR5-ASBR6-R3) in both ASes with 1189 label information for that LSP. 1190 If LSP type is SR-TE, PCECC also MUST send PCLabelUpd PCEP message 1191 to each node along the path in aboth Ases with label information (Node-ID and 1192 Adjacency-ID segment (label) list) specific to that node. 1193 o Then PCECC SHOULD send PCUpd PCEP message to the ingress router R1 in AS1 1194 with information about new LSP and the R1 router SHOULD send PCEP PCRpt back 1195 with LSP1 and LSP2 status:Up. 1196 o After that step R1 SHOULD have main and backup TEs (LSP1 and LSP2) towards 1197 R3 up. It is up to implementation how to put this TEs to R1's RIB and how to 1198 make switchover to backup LSP2 if LSP1 fails. 1200 14. The Considerations for PCECC Procedure and PCEP extensions 1202 The PCECC's procedures and PCEP extensions is defined in [I-D.zhao- 1203 pce-pcep-extension-for-pce-controller]. 1205 15. IANA Considerations 1207 This document does not require any action from IANA. 1209 16. Security Considerations 1211 TBD. 1213 17. Acknowledgments 1215 We would like to thank Robert Tao, Changjiang Yan, Tieying Huang, 1216 Adrian Farrel, Sergio Belotti and Dieter Beller, Andrey Elperin and Evgeniy 1217 Brodskiy for their useful comments and suggestions. 1219 18. References 1221 18.1. Normative References 1223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1224 Requirement Levels", BCP 14, RFC 2119, 1225 DOI 10.17487/RFC2119, March 1997, 1226 . 1228 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1229 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1230 DOI 10.17487/RFC5440, March 2009, 1231 . 1233 18.2. Informative References 1235 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 1236 "A Backward-Recursive PCE-Based Computation (BRPC) 1237 Procedure to Compute Shortest Constrained Inter-Domain 1238 Traffic Engineering Label Switched Paths", RFC 5441, 1239 DOI 10.17487/RFC5441, April 2009, 1240 . 1242 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1243 Objective Functions in the Path Computation Element 1244 Communication Protocol (PCEP)", RFC 5541, 1245 DOI 10.17487/RFC5541, June 2009, 1246 . 1248 [RFC5376] N. Bitar, R. Zhang, K. Kumaki "Inter-AS Requirements for the 1249 Path Computation Element Communication Protocol (PCECP)", 1250 RFC 5376, DOI 10.17487/RFC5376, November 2008 1251 . 1253 [I-D.filsfils-spring-segment-routing] 1254 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1255 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1256 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1257 "Segment Routing Architecture", draft-filsfils-spring- 1258 segment-routing-04 (work in progress), July 2014. 1260 [I-D.ietf-pce-stateful-pce] 1261 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 1262 Extensions for Stateful PCE", draft-ietf-pce-stateful- 1263 pce-14 (work in progress), May 2016. 1265 [I-D.crabbe-pce-pce-initiated-lsp] 1266 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 1267 Extensions for PCE-initiated LSP Setup in a Stateful PCE 1268 Model", draft-crabbe-pce-pce-initiated-lsp-05 (work in 1269 progress), October 2015. 1271 [I-D.ali-pce-remote-initiated-gmpls-lsp] 1272 Ali, Z., Sivabalan, S., Filsfils, C., Varga, R., Lopez, 1273 V., Dios, O., and X. Zhang, "Path Computation Element 1274 Communication Protocol (PCEP) Extensions for remote- 1275 initiated GMPLS LSP Setup", draft-ali-pce-remote- 1276 initiated-gmpls-lsp-03 (work in progress), February 2014. 1278 [I-D.ietf-isis-segment-routing-extensions] 1279 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 1280 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 1281 Extensions for Segment Routing", draft-ietf-isis-segment- 1282 routing-extensions-06 (work in progress), December 2015. 1284 [I-D.psenak-ospf-segment-routing-extensions] 1285 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 1286 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1287 Extensions for Segment Routing", draft-psenak-ospf- 1288 segment-routing-extensions-05 (work in progress), June 1289 2014. 1291 [I-D.sivabalan-pce-segment-routing] 1292 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 1293 Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions 1294 for Segment Routing", draft-sivabalan-pce-segment- 1295 routing-03 (work in progress), July 2014. 1297 [I-D.li-mpls-global-label-usecases] 1298 Li, Z., Zhao, Q., Yang, T., Raszuk, R., and L. Fang, 1299 "Usecases of MPLS Global Label", draft-li-mpls-global- 1300 label-usecases-03 (work in progress), October 2015. 1302 [I-D.li-mpls-global-label-framework] 1303 Li, Z., Zhao, Q., Chen, X., Yang, T., and R. Raszuk, "A 1304 Framework of MPLS Global Label", draft-li-mpls-global- 1305 label-framework-02 (work in progress), July 2014. 1307 [I-D.zhao-pce-pcep-extension-for-pce-controller] 1308 Zhao, Q., Li, Z., Dhody, D., and C. Zhou, "PCEP Procedures 1309 and Protocol Extensions for Using PCE as a Central 1310 Controller (PCECC) of LSPs", draft-zhao-pce-pcep- 1311 extension-for-pce-controller-03 (work in progress), March 1312 2016. 1314 [I-D.ietf-spring-resiliency-use-cases] 1315 Francois, P., Filsfils, C., Decraene, B., and R. Shakir, 1316 "Use-cases for Resiliency in SPRING", draft-ietf-spring- 1317 resiliency-use-cases-02 (work in progress), December 2015. 1319 [MPLS in DC...] 1320 Afanasiev, D., Ginsburg, D., "MPLS in DC and inter-DC 1321 networks: the unified forwarding mechanism for network 1322 programmability at scale " 1324 [Multicast Tree Map-Reduce...] 1325 Lee, Kyungyong., Dr. Boykin, P. Oscar., Dr.Figueiredo, Renato J., 1326 "Multicast Tree Map-Reduce: Self-organizing Resource Discovery 1327 and Monitoring using Structured P2P Systems" 1329 Authors' Addresses 1331 Quintin Zhao 1332 Huawei Technologies 1333 125 Nagog Technology Park 1334 Acton, MA 01719 1335 US 1337 EMail: quintin.zhao@huawei.com 1338 Robin Li 1339 Huawei Technologies 1340 Huawei Bld., No.156 Beiqing Rd. 1341 Beijing 100095 1342 China 1344 EMail: lizhenbin@huawei.com 1346 Boris Khasanov 1347 Huawei Technologies 1348 Moskovskiy Prospekt 97A 1349 St.Petersburg 196084 1350 Russia 1352 EMail: khasanov.boris@huawei.com 1354 King Ke 1355 Tencent Holdings Ltd. 1356 Shenzhen 1357 China 1359 EMail: kinghe@tencent.com 1361 Luyuan Fang 1362 Microsoft 1364 EMail: lufang@microsoft.com 1366 Chao Zhou 1367 Cisco Systems 1369 EMail: chao.zhou@cisco.com 1371 Boris Zhang 1372 Telus Communications 1374 EMail: Boris.zhang@telus.com 1376 Artem Rachitskiy 1377 Mobile TeleSystems JLLC 1378 Nezavisimosti ave., 95 1379 Minsk 220043 1380 Belarus 1382 EMail: arachitskiy@mts.by 1384 Anton Gulida 1385 Mobile TeleSystems JLLC 1386 Nezavisimosti ave., 95 1387 Minsk 220043 1388 Belarus 1390 EMail: agulida@mts.by