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