idnits 2.17.1 draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 17, 2014) is 3591 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6006 (Obsoleted by RFC 8306) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group Q. Zhao 2 Internet-Draft D. Dhody 3 Intended status: Experimental Huawei Technology 4 Expires: December 17, 2014 D. King 5 Old Dog Consulting 6 Z. Ali 7 Cisco Systems 8 R. Casellas 9 CTTC 10 June 17, 2014 12 PCE-based Computation Procedure To Compute Shortest Constrained P2MP 13 Inter-domain Traffic Engineering Label Switched Paths 14 draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08 16 Abstract 18 The ability to compute paths for constrained point-to-multipoint 19 (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across 20 multiple domains has been identified as a key requirement for the 21 deployment of P2MP services in MPLS and GMPLS-controlled networks. 22 The Path Computation Element (PCE) has been recognized as an 23 appropriate technology for the determination of inter-domain paths of 24 P2MP TE LSPs. 26 This document describes an experiment to provide procedures and 27 extensions to the PCE communication Protocol (PCEP) for the 28 computation of inter-domain paths for P2MP TE LSPs. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 17, 2014. 47 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .2 64 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . .2 65 1.2. Requirements Language . . . . . . . . . . . . . . . . . .2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .2 67 3. Examination of Existing Mechanisms . . . . . . . . . . . . .3 68 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . .5 69 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . .5 70 6. Objective Functions and Constraints. . . . . . . . . . . . . .7 71 7. P2MP Path Computation Procedures . . . . . . . . . . . . . . .8 72 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . .8 73 7.2. Core-Trees . . . . . . . . . . . . . . . . . . . . . . . .9 74 7.3. Optimal Core-Tree Computation Procedure. . . . . . . . . .12 75 7.4. Sub-tree Computation Procedures . . . . . . . . . . . . .13 76 7.5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . .13 77 7.5.1. The Extension of RP Object . . . . . . . . . . . . . .13 78 7.5.2. Domain and PCE Sequence . . . . . . . . . . . . . . .14 79 7.6. Relationship with Hierarchical PCE . . . . . . . . . . . .14 80 7.7. Parallelism . . . . . . . . . . . . . . . . . . . . . . .15 81 8. Protection . . . . . . . . . . . . . . . . . . . . . . . . . .15 82 8.1. End-to-end Protection . . . . . . . . . . . . . . . . . .15 83 8.2. Domain Protection . . . . . . . . . . . . . . . . . . . .15 84 9. Manageability Considerations . . . . . . . . . . . . . . . . .16 85 9.1. Control of Function and Policy . . . . . . . . . . . . . .16 86 9.2. Information and Data Models . . . . . . . . . . . . . . .16 87 9.3. Liveness Detection and Monitoring . . . . . . . . . . . .16 88 9.4. Verifying Correct Operation . . . . . . . . . . . . . . .16 89 9.5. Requirements on Other Protocols and Functional Components.17 90 9.6. Impact on Network Operation . . . . . . . . . . . . . . .17 91 9.7. Policy Control . . . . . . . . . . . . . . . . . . . . . .17 92 10. Security Considerations . . . . . . . . . . . . . . . . . . .17 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .18 94 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .19 95 13. References . . . . . . . . . . . . . . . . . . . . . . . . . .19 96 13.1. Normative References . . . . . . . . . . . . . . . . . . .19 97 13.2. Informative References . . . . . . . . . . . . . . . . . .19 98 14. Contributors' Addresses . . . . . . . . . . . . . . . . . . .21 99 15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .21 101 1. Introduction 103 Multicast services are increasingly in demand for high-capacity 104 applications such as multicast Virtual Private Networks (VPNs), IP- 105 television (IPTV) which may be on-demand or streamed, and content- 106 rich media distribution (for example, software distribution, 107 financial streaming, or database-replication). The ability to 108 compute constrained Traffic Engineering Label Switched Paths (TE 109 LSPs) for point-to-multipoint (P2MP) LSPs in Multiprotocol Label 110 Switching (MPLS) and Generalized MPLS (GMPLS) networks across 111 multiple domains are therefore required. 113 The applicability of the PCE [RFC4655] for the computation of such 114 paths is discussed in [RFC5671], and the requirements placed on the 115 PCE communications Protocol (PCEP) for this are given in [RFC5862]. 117 This document details the requirements for inter-domain P2MP path 118 computation, it then describes the experimental procedure 119 "core-tree" path computation, developed to address the requirements 120 and objectives for inter-domain P2MP path computation. 122 When results of implementation and deployment are available, this 123 document will be updated and refined, and then moved from 124 Experimental status to Standards Track. 126 1.2. Scope 128 The inter-domain P2MP path computation procedures described in this 129 document is experimental. The experiment is intended to enable 130 research for the usage of the PCE to support inter-domain P2MP path 131 computation. 133 This document is not intended to replace the intra-domain P2MP path 134 computation approach defined by [RFC6006], and will not impact 135 existing PCE procedures and operations. 137 1.3. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 2. Terminology 144 Terminology used in this document is consistent with the related 145 MPLS/GMPLS and PCE documents [RFC4461], [RFC4655], [RFC4875], 146 [RFC5376], [RFC5440], [RFC5441], [RFC5671] and [RFC5862]. 148 The additional terms Core-Tree, Leaf Domain, Path Tree, Path Domain 149 Sequence, Path Domain Tree, Root Domain, Sub-Tree and Transit/branch 150 Domain are further defined below. 152 Core-Tree: a P2MP tree where the root is the ingress Label Switching 153 Router (LSR), and the leaf nodes are the entry BNs of the leaf 154 domains. 156 Entry BN of domain(n): a Boundary Node (BN) connecting domain(n-1) to 157 domain(n) along a determined sequence of domains. 159 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 160 a determined sequence of domains. 162 H-PCE: Hierarchical PCE (as per [RFC6805]). 164 Leaf Domain: a domain with one or more leaf nodes. 166 Path Tree: a set of LSRs and TE links that comprise the path 167 of a P2MP TE LSP from the ingress LSR to all egress LSRs (the leaf 168 nodes). 170 Path Domain Sequence: the known sequence of domains for a path 171 between the root domain and a leaf domain. 173 Path Domain Tree: the tree formed by the domains that the P2MP path 174 crosses, where the source (ingress) domain is the root domain. 176 PCE(i): a PCE that performs path computations for domain(i). 178 Root Domain: the domain that includes the ingress (root) LSR. 180 Sub-tree: a P2MP tree where the root is the selected entry BN of the 181 leaf domain and the leaf nodes are the destinations (leaves) in 182 that domain. The sub-trees are grafted to the core-tree. 184 Transit/branch Domain: a domain that has an upstream and one or more 185 downstream neighbor domain. 187 3. Examination of Existing Mechanisms 189 The Path Computation Element (PCE) defined in [RFC4655] is an entity 190 that is capable of computing a network path or route based on a 191 network graph, and applying computational constraints. A Path 192 Computation Client (PCC) may make requests to a PCE for paths to be 193 computed. 195 [RFC4875] describes how to set up P2MP TE LSPs for use in MPLS and 196 GMPLS-controlled networks. The PCE is identified as a suitable 197 application for the computation of paths for P2MP TE LSPs [RFC5671]. 199 [RFC5441] specifies a procedure relying on the use of multiple PCEs 200 to compute Point to Point (P2P) inter-domain constrained shortest 201 paths across a predetermined sequence of domains, using a Backward 202 Recursive Path Computation (BRPC) technique. The technique can be 203 combined with the use of Path-Keys [RFC5520] to preserve 204 confidentiality across domains, which is sometimes required when 205 domains are managed by different Service Providers. 207 PCEP [RFC5440] was extended for point-to-multipoint (P2MP) path 208 computation requests in [RFC6006]. 210 As discussed in [RFC4461], a P2MP tree is the ordered set of LSRs and 211 TE links that comprise the path of a P2MP TE LSP from its ingress LSR 212 to all of its egress LSRs. A P2MP LSP is set up with TE constraints 213 and allows efficient packet or data replication at various branching 214 points in the network. As per [RFC5671] branch point selection is 215 fundamental to the determination of the paths for a P2MP TE LSP. Not 216 only is this selection constrained by the network topology and 217 available network resources, but it is determined by the objective 218 functions (OF) that may be applied to path computation. 220 Generally, an inter-domain P2MP tree (i.e., a P2MP tree with source 221 and at least one destination residing in different domains) is 222 particularly difficult to compute even for a distributed PCE 223 architecture. For instance, while the BRPC may be well-suited for 224 P2P paths, P2MP path computation involves multiple branching path 225 segments from the source to the multiple destinations. As such, 226 inter-domain P2MP path computation may result in a plurality of 227 per-domain path options that may be difficult to coordinate 228 efficiently and effectively between domains. That is, when one or 229 more domains have multiple ingress and/or egress boundary nodes 230 (i.e., when the domains are multiply inter-connected), existing 231 techniques may be convoluted when used to determine which boundary 232 node of another domain will be utilized for the inter-domain P2MP 233 tree, and no way to limit the computation of the P2MP tree to 234 those utilized boundary nodes. 236 A trivial solution to the computation of inter-domain P2MP tree would 237 be to compute shortest inter-domain P2P paths from source to each 238 destination and then combine them to generate an inter-domain, 239 shortest-path-to-destination P2MP tree. This solution, however, 240 cannot be used to trade cost to destination for overall tree cost 241 (i.e., it cannot produce a Minimum Cost Tree (MCT)) and in the 242 context of inter-domain P2MP TE LSPs it cannot be used to reduce the 243 number of domain boundary nodes that are transited. Computing P2P TE 244 LSPs individually does not guarantee the generation of an optimal 245 P2MP tree for every definition of "optimal" in every topology. 247 Per Domain path computation [RFC5152] may be used to compute P2MP 248 multi-domain paths, but may encounter the issues previously 249 described. Furthermore, this approach may also be considered to have 250 scaling issues during LSP setup. That is, the LSP to each leaf is 251 signaled separately, and each boundary node needs to perform path 252 computation for each leaf. 254 P2MP Minimum Cost Tree (MCT), i.e. a computation which guarantees the 255 least cost resulting tree, typically is an NP-complete problem. 256 Moreover, adding and/or removing a single destination to/from the 257 tree may result in an entirely different tree. In this case, 258 frequent MCT path computation requests may prove computationally 259 intensive, and the resulting frequent tunnel reconfiguration may 260 even cause network destabilization. 262 This document presents a solution, procedures and extensions to 263 PCEP to support P2MP inter-domain path computation. 265 4. Assumptions 267 Within this document we make the following assumptions: 269 o Due to deployment and commercial limitations (e.g., inter-AS 270 (Autonomous System) peering agreements), the path domain tree will 271 be known in advance; 273 o Each PCE knows about any leaf LSRs in the domain it serves; 275 Additional assumptions are documented in [RFC5441] and are not 276 repeated here. 278 5. Requirements 280 This section summarizes the requirements specific to computing inter- 281 domain P2MP paths. In these requirements we note that the actual 282 computation time taken by any PCE implementation is outside the scope 283 of this document, but we observe that reducing the complexity of the 284 required computations has a beneficial effect on the computation time 285 regardless of implementation. Additionally, reducing the number of 286 message exchanges and the amount of information exchanged will reduce 287 the overall computation time for the entire P2MP tree. We refer to 288 the "complexity of the computation" as the impact on these aspects of 289 path computation time as various parameters of the topology and the 290 P2MP TE LSP are changed. 292 It is also important that the solution can preserve confidentiality 293 across domains, which is required when domains are managed by 294 different Service Providers via Path-Key mechanism [RFC5520]. 296 Other than the requirements specified in [RFC5862], a number of 297 requirements specific to inter-domain P2MP are detailed below: 299 1. The complexity of the computation for each sub-tree within each 300 domain SHOULD be dependent only on the topology of the domain and 301 it SHOULD be independent of the domain sequence. 303 2. The number of PCReq (Path Computation Request) and PCRep (Path 304 Computation Reply) messages SHOULD be independent of the number 305 of multicast destinations in each domain. 307 3. It SHOULD be possible to specify the domain entry and exit nodes 308 in the PCReq. 310 4. Specifying which nodes are be used as branch nodes SHOULD be 311 supported in the PCReq. 313 5. Reoptimization of existing sub-trees SHOULD be supported. 315 6. It SHOULD be possible to compute diverse P2MP paths from existing 316 P2MP paths. 318 6. Objective Functions and Constraints 320 For the computation of a single or a set of P2MP TE LSPs, a request 321 to meet specific optimization criteria, called an Objective Function 322 (OF), MAY be used. Using an OF to select the "best" candidate path, 323 include: 325 o The sub-tree within each domain SHOULD be optimized using minimum 326 cost tree [RFC5862], or shortest path tree [RFC5862]. 328 In addition to the OFs, the following constraints MAY also be 329 beneficial for inter-domain P2MP path computation: 331 1. The computed P2MP "core-tree" SHOULD be optimal when only 332 considering the paths to the leaf domain entry BNs. 334 2. Grafting and pruning of multicast destinations (sub-tree) within 335 a leaf domain SHOULD ensure minimal impact on other domains 336 and on the core-tree. 338 3. It SHOULD be possible to choose to optimize the core-tree. 340 4. It SHOULD be possible to choose optimize the entire tree (P2MP 341 LSP). 343 5. It SHOULD be possible to combine the aforementioned OFs and 344 constraints for P2MP path computation. 346 When implementing and operating P2MP LSPs, following needs to be 347 taken into consideration: 349 o The complexity of computation. 351 o The optimality of the tree (core-tree as well as full P2MP LSP 352 tree). 354 o The stability of the core-tree. 356 The solution SHOULD allow these trade-offs to be made at computation 357 time. 359 The algorithms used to compute optimal paths using a combination of 360 OFs and multiple constraints is out of scope of this document. 362 7. P2MP Path Computation Procedures 364 7.1. General 366 A P2MP path computation can be broken down into two steps of 367 core-tree computation and grafting of sub-trees. Breaking the 368 procedure into these specific steps has the following impact: 370 o The core-tree and sub-tree are smaller in comparison to 371 the full P2MP Tree and are thus easier to compute. 373 o An implementation MAY choose to keep the core-tree fairly static 374 or computed offline (trade-off with optimality). 376 o Adding/Pruning of leaves which require changes to sub-tree in leaf- 377 domain only. 379 o The PCEP message size is smaller in comparison. 381 Allowing the core-tree based solution to provide an optimal 382 inter-domain P2MP TE LSP. 384 The following sub-sections describe the core-tree based 385 mechanism, including procedures and PCEP extensions, that satisfy 386 the requirements and objectives specified in Section 5 and Section 6 387 of this document. 389 7.2. Core-Trees 391 A core-tree is defined as a tree that satisfies the following 392 conditions: 394 o The root of the core-tree is the ingress LSR in the root domain; 396 o The leaves of the core-tree are the entry boundary nodes in the 397 leaf domains. 399 To support confidentiality these nodes and links MAY be hidden using 400 the path-key mechanism [RFC5520], but they MUST be computed and be a 401 part of core-tree. 403 For example, consider the Domain Tree in Figure 1 below, 404 representing a domain tree of 6 domains, and part of the resulting 405 core-tree which satisfies the aforementioned conditions. 407 +----------------+ 408 | |Domain D1 409 | R | 410 | | 411 | A | 412 | | 413 +-B------------C-+ 414 / \ 415 / \ 416 / \ 417 Domain D2 / \ Domain D3 418 +-------------D--+ +-----E----------+ 419 | | | | 420 | F | | | 421 | G | | H | 422 | | | | 423 | | | | 424 +-I--------------+ +-J------------K-+ 425 /\ / \ 426 / \ / \ 427 / \ / \ 428 / \ / \ 429 / \ / \ 430 / \ / \ 431 / Domain D4 \ Domain D5 / Domain D6 \ 432 +-L-------------W+ +------P---------+ +-----------T----+ 433 | | | | | | 434 | | | Q | | U | 435 | M O | | S | | | 436 | | | | | V | 437 | N | | R | | | 438 +----------------+ +----------------+ +----------------+ 440 Figure 1: Domain Tree Example 441 (R) 442 | 443 (A) 444 / \ 445 / \ 446 (B) (C) 447 / \ 448 / \ 449 (D) (E) 450 / | 451 / | 452 (G) (H) 453 / / \ 454 / / \ 455 (I) (J) (K) 456 / \ / \ 457 / \ / \ 458 (L) (W) (P) (T) 460 Figure 2: Core-Tree 462 A core-tree is computed such that root of the tree is R and the leaf 463 node are the entry nodes of the destination domains (L, W, P and T). 464 Path-key mechanism can be used to hide the internal nodes and links 465 (node G and H are hidden via Path-Key PK1 and PK2 respectively) in 466 the final core-tree as shown below for domain D2 and D3. 468 (R) 469 | 470 (A) 471 / \ 472 / \ 473 (B) (C) 474 / \ 475 / \ 476 (D) (E) 477 / | 478 / | 479 |PK1| |PK2| 480 / / \ 481 / / \ 482 (I) (J) (K) 483 / \ / \ 484 / \ / \ 485 (L) (W) (P) (T) 487 Figure 3: Core-Tree with Path-Key 489 7.3. Optimal Core-Tree Computation Procedure 491 Applying the core-tree procedure to large groups of domains, such as 492 the Internet, is not considered feasible or desirable, and is out of 493 scope for this document. 495 The following extended BRPC-based procedure can be used to compute 496 the core-tree. Note that a root PCE MAY further use its own enhanced 497 optimization techniques in future to compute the core-tree. 499 A BRPC-based core-tree path computation procedure is described below: 501 1. Using the BRPC procedures to compute the VSPT(i) (Virtual 502 Shortest Path Tree) for each leaf BN(i), i=1 to n, where n is the 503 total number of entry nodes for all the leaf domains. In each 504 VSPT(i), there are a number of P(i) paths. 506 2. When the root PCE has computed all the VSPT(i), i=1 to n, take 507 one path from each VSPT and form all possible sets of paths, we 508 call them PathSet(j), j=1 to M, where M=P(1)xP(2)...xP(n); 510 3. For each PathSet(j), there are n S2L (Source-to-Leaf) BN paths 511 and form these n paths into a core-tree(j); 513 4. There will be M number core-trees computed from step 3. An 514 optimal core-tree is selected based on the OF and constraints. 516 Note that, since point to point BRPC procedure is used to compute 517 VSPT, the path request and response message format defined in 518 [RFC5440] are used. 520 Also note that the application of BRPC in the aforementioned 521 procedure differs from the typical one since paths returned from a 522 downstream PCE are not necessarily pruned from the solution set 523 (extended VSPT) by intermediate PCEs. The reason for this is that if 524 the PCE in a downstream domain does the pruning and returns the 525 single optimal sub-path to the upstream PCE, the combination of these 526 single optimal sub-paths into a core-tree is not necessarily optimal 527 even if each S2L (Source-to-Leaf) sub-path is optimal. 529 Without trimming, the ingress PCE will obtain all the possible S2L 530 sub-paths set for the entry boundary nodes of the leaf domain. The 531 PCE will then, by looking through all the combinations and taking one 532 sub-path from each set to build one tree, can select the optimal 533 core-tree. 535 A PCE MAY add equal cost paths within the domain while constructing 536 an extended VSPT. This will provide the ingress PCE more candidate 537 paths for an optimal core-tree. 539 The proposed method may present a scalability problem for the 540 dynamic computation of the core-tree (by iterative checking of all 541 combinations of the solution space), specially with dense/meshed 542 domains. Considering a domain sequence D1, D2, D3, D4, where the 543 Leaf Boundary Node is at domain D4, PCE(4) will return 1 path. 544 PCE(3) will return N paths, where N is E(3) x X(3), where E(k) x 545 X(k) denotes the number of entry nodes times the number of exit 546 nodes for that domain. PCE(2) will return M paths, where M = E(2) 547 x X(2) x N = E(2) x X(2) x E(3) x X(3) x 1, etc. Generally 548 speaking the number of potential paths at the ingress PCE Q = 549 prod E(k) x X(k). 551 Consequently, it is expected that the core-tree will be typically 552 computed offline, without precluding the use of dynamic, online 553 mechanisms such as the one presented here, in which case it SHOULD be 554 possible to configure transit PCEs to control the number of paths 555 sent upstream during BRPC (trading trimming for optimality at the 556 point of trimming and downwards). 558 7.4. Sub-tree Computation Procedures 560 Once the core-tree is built, the grafting of all the leaf nodes from 561 each domain to the core-tree can be achieved by a number of 562 algorithms. One algorithm for doing this phase is that the root PCE 563 will send the request with C bit set (as defined in section 7.4.1 of 564 this document) for the path computation to the destination(s) 565 directly to the PCE where the destination(s) belong(s) along with the 566 core-tree computed from section 7.2. 568 This approach requires that the root PCE manage a potentially large 569 number of adjacencies (either in persistent or non-persistent mode), 570 including PCEP adjacencies to PCEs that are not within neighbor 571 domains. 573 An alternative would involve establishing PCEP adjacencies that 574 correspond to the PCE domain tree. This would require that branch 575 PCEs forward requests and responses from the root PCE towards the 576 leaf PCEs and vice-versa. 578 Note that the P2MP path request and response format is as per 579 [RFC6006], where Record Route Object (RRO) are used to carry the 580 core-tree paths in the P2MP grafting request. 582 The algorithms to compute the optimal large sub-tree are outside 583 scope of this document. 585 7.5. PCEP Protocol Extensions 587 7.5.1. The Extension of RP Object 588 This experiment will be carried out by extending the RP (Request 589 Parameters) object (defined in [RFC5440]) used in PCEP requests 590 and responses. 592 The extended format of the RP object body to include the C bit is as 593 follows: 595 The C bit is added in the flag bits field of the RP object to signal 596 the receiver of the message that the request/reply is for inter- 597 domain P2MP core-tree or not. 599 The following flag is added in this draft: 601 Bit Number Name Flag 602 TBA Core-tree computation (C-bit) 604 C bit (Core-Tree bit - 1 bit): 606 0: This indicates that this is not for an inter-domain P2MP 607 core-tree. 609 1: This indicates that this is a PCEP request or a response 610 for the computation of a inter-domain core-tree or for the 611 grafting of a sub-tree to a inter-domain core-tree. 613 7.5.2. Domain and PCE Sequence 615 The procedure described in this document requires the domain-tree 616 to be known in advance. This information MAY be either 617 administratively predetermined or dynamically discovered by some 618 means such as Hierarchical PCE (H-PCE) [RFC6805] framework, or 619 derived through the IGP/BGP routing information. 621 Examples of ways to encode the domain path tree include [RFC5886] 622 using PCE-ID Object and [DOMAIN-SEQ]. 624 7.6. Using H-PCE for Scalability 626 The ingress/root PCE is responsible for the core-tree computation as 627 well as grafting of sub-trees into the multi-domain tree. Therefore, 628 the ingress/root PCE will receive all computed path segments from all 629 the involved domains. When the ingress/root PCE chooses to have a 630 PCEP session with all involved PCEs, this may cause an excessive 631 number of sessions or added complexity in implementations. 633 The use of the H-PCE framework [RFC6805] may be used to establish a 634 dedicated PCE with the capability (memory and CPU) and knowledge to 635 maintain the necessary PCEP sessions. The parent PCE would be 636 responsible to request intra-domain path computation request to the 637 PCEs, combine them and return the overall P2MP tree. 639 7.7. Parallelism 641 In order to minimize latency in path computation in multi-domain 642 networks, intra-domain path segments and intra-domain sub-trees 643 can be computed in parallel when possible. The proposed 644 procedures in this draft present opportunities for parallelism: 646 1. The BRPC procedure for each leaf boundary node can be launched in 647 parallel by the ingress/root PCE for dynamic computation of 648 core-tree. 650 2. The grafting of sub-trees can be triggered in parallel once the 651 core-tree is computed. 653 One of the potential issues of parallelism is that the ingress PCE 654 would require a potentially high number of PCEP adjacencies to 655 "remote" PCEs at the same time and that may not be desirable. 657 8. Protection 659 It is envisaged that protection may be required when deploying and 660 using inter-domain P2MP TE LSPs. The procedures and mechanisms 661 defined in this document do not prohibit the use of existing and 662 proposed types of protection, including: end-to-end protection 663 [RFC4875] and domain protection schemes. 665 Segment or facility (link and node) protection is problematic in 666 inter-domain environment due to the limit of Fast-reroute (FRR) 667 [RFC4875] requiring knowledge of its next-hop across domain 668 boundaries whilst maintaining domain confidentiality. Although the 669 FRR protection might be implemented if next-hop information was known 670 in advance. 672 8.1. End-to-end Protection 674 An end-to-end protection (for nodes and links) principle can be 675 applied for computing backup P2MP TE LSPs. During computation of the 676 core-tree and sub-trees, may also be taken into consideration. A 677 PCE may compute the primary and backup P2MP TE LSP together or 678 sequentially. 680 8.2. Domain Protection 682 In this protection scheme, backup P2MP Tree can be computed which 683 excludes the transit/branch domain completely. A backup domain path 684 tree is needed with the same source domain and destinations domains 685 and a new set of transit domains. The backup path tree can be 686 applied to the above procedure to obtain the backup P2MP TE LSP with 687 disjoint transit domains. 689 9. Manageability Considerations 691 [RFC5862] describes various manageability requirements in support of 692 P2MP path computation when applying PCEP. This section describes how 693 manageability requirements mentioned in [RFC5862] are supported in 694 the context of PCEP extensions specified in this document. 696 Note that [RFC5440] describes various manageability considerations in 697 PCEP, and most of manageability requirements mentioned in [RFC6006] 698 are already covered there. 700 9.1. Control of Function and Policy 702 In addition to PCE configuration parameters listed in [RFC5440] and 703 [RFC6006], the following additional parameters might be required: 705 o The ability to enable or disable multi-domain P2MP path 706 computations on the PCE. 708 o The PCE may be configured to enable or disable the advertisement 709 of its multi-domain P2MP path computation capability. 711 9.2. Information and Data Models 713 A number of MIB objects have been defined for general PCEP control 714 and monitoring of P2P computations in [PCEP-MIB]. [RFC5862] 715 specifies that MIB objects will be required to support the control 716 and monitoring of the protocol extensions defined in this document. 717 [PCEP-P2MP-MIB] describes managed objects for modeling of PCEP 718 communications between a PCC and PCE, and PCE to PCE, P2MP path 719 computation requests and responses. 721 9.3. Liveness Detection and Monitoring 723 No changes are necessary to the liveness detection and monitoring 724 requirements as already embodied in [RFC4657]. 726 It should be noted that multi-domain P2MP computations are likely to 727 take longer than P2P computations, and single domain P2MP 728 computations. The liveness detection and monitoring features of the 729 PCEP SHOULD take this into account. 731 9.4. Verifying Correct Operation 732 There are no additional requirements beyond those expressed in 733 [RFC4657] for verifying the correct operation of the PCEP. Note that 734 verification of the correct operation of the PCE and its algorithms 735 is out of scope for the protocol requirements, but a PCC MAY send the 736 same request to more than one PCE and compare the results. 738 9.5. Requirements on Other Protocols and Functional Components 740 A PCE operates on a topology graph that may be built using 741 information distributed by TE extensions to the routing protocol 742 operating within the network. In order that the PCE can select a 743 suitable path for the signaling protocol to use to install the P2MP 744 TE LSP, the topology graph MUST include information about the P2MP 745 signaling and branching capabilities of each LSR in the network. 747 Mechanisms for the knowledge of other domains, the discovery of 748 corresponding PCEs and their capabilities SHOULD be provided and that 749 this information MAY be collected by other mechanisms. 751 Whatever means is used to collect the information to build the 752 topology graph, the graph MUST include the requisite information. If 753 the TE extensions to the routing protocol are used, these SHOULD be 754 as described in [RFC5073]. 756 9.6. Impact on Network Operation 758 The use of a PCE to compute P2MP paths is not expected to have 759 significant impact on network operations. However, it should be 760 noted that the introduction of P2MP support to a PCE that already 761 provides P2P path computation might change the loading of the PCE 762 significantly, and that might have an impact on the network behavior, 763 especially during recovery periods immediately after a network 764 failure. 766 The dynamic computation of core-trees might also have an impact on 767 the load of the involved PCEs as well as path computation times. 769 It should be noted that pre-computing and maintaining domain-trees 770 might be a considerable administration effort on the operator. 772 9.7. Policy Control 774 [RFC5394] provides additional details on policy within the PCE 775 architecture and also provides context for the support of PCE Policy. 776 They are also applicable to Inter-domain P2MP Path computation via 777 the core-tree mechanism. 779 10. Security Considerations 780 As described in [RFC5862], P2MP path computation requests are more 781 CPU-intensive and also utilize more link bandwidth. In the event of 782 an unauthorized P2MP path computation request, or a denial of service 783 attack, the subsequent PCEP requests and processing may be disruptive 784 to the network. Consequently, it is important that implementations 785 conform to the relevant security requirements of [RFC5440] that 786 specifically help to minimize or negate unauthorized P2MP path 787 computation requests and denial of service attacks. These mechanisms 788 include: 790 o Securing the PCEP session requests and responses using TCP 791 security techniques (Section 10.2 of [RFC5440]). 793 o Authenticating the PCEP requests and responses to ensure the 794 message is intact and sent from an authorized node (Section 10.3 795 of [RFC5440]). 797 o Providing policy control by explicitly defining which PCCs, via IP 798 access-lists, are allowed to send P2MP path requests to the PCE 799 (Section 10.6 of [RFC5440]). 801 PCEP operates over TCP, so it is also important to secure the PCE and 802 PCC against TCP denial of service attacks. Section 10.7.1 of 803 [RFC5440] outlines a number of mechanisms for minimizing the risk of 804 TCP-based denial of service attacks against PCEs and PCCs. 806 PCEP implementations SHOULD also consider the additional security 807 provided by the TCP Authentication Option (TCP-AO) [RFC5925]. 809 Finally, any multi-domain operation necessarily involves the exchange 810 of information across domain boundaries. This may represent a 811 significant security and confidentiality risk especially when the 812 domains are controlled by different commercial entities. PCEP 813 allows individual PCEs to maintain confidentiality of their domain 814 path information by using path-keys [RFC5520] and would allow for 815 securing of domain path information when performing core-tree 816 based path computations. 818 11. IANA Considerations 820 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 821 registry with the "RP Object Flag Field" sub-registry. 823 IANA is requested to allocate a new bit from this registry as 824 follows: 826 Bit Description Reference 827 TBA Core-tree computation (C-bit) [This.I-D] 829 12. Acknowledgements 831 The authors would like to thank Adrian Farrel, Dan Tappan, Olufemi 832 Komolafe, Oscar Gonzalez de Dios and Julien Meuric for their 833 valuable comments on this document. 835 13. References 837 13.1. Normative References 839 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 840 Requirement Levels", BCP 14, RFC 2119, March 1997. 842 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation 843 Element (PCE) Communication Protocol (PCEP)", 844 RFC 5440, March 2009. 846 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, 847 "A Backward-Recursive PCE-Based Computation (BRPC) 848 Procedure to Compute Shortest Constrained Inter- 849 Domain Traffic Engineering Label Switched Paths", 850 RFC 5441, April 2009. 852 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, 853 Z., and J. Meuric, "Extensions to the Path 854 Computation Element Communication Protocol (PCEP) 855 for Point-to-Multipoint Traffic Engineering Label 856 Switched Paths", RFC 6006, September 2010. 858 13.2. Informative References 860 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 861 Multipoint Traffic-Engineered MPLS Label Switched 862 Paths (LSPs)", RFC 4461, April 2006. 864 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path 865 Computation Element (PCE)-Based Architecture", 866 RFC 4655, August 2006. 868 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element 869 (PCE) Communication Protocol Generic Requirements", 870 RFC 4657, September 2006. 872 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 873 "Extensions to Resource Reservation Protocol - 874 Traffic Engineering (RSVP-TE) for Point-to- 875 Multipoint TE Label Switched Paths (LSPs)", 876 RFC 4875, May 2007. 878 [RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol 879 Extensions for Discovery of Traffic Engineering Node 880 Capabilities", RFC 5073, December 2007. 882 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per- 883 Domain Path Computation Method for Establishing 884 Inter-Domain Traffic Engineering (TE) Label Switched 885 Paths (LSPs)", RFC 5152, February 2008. 887 [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS 888 Requirements for the Path Computation Element 889 Communication Protocol (PCECP)", RFC 5376, 890 November 2008. 892 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. 893 Ash, "Policy-Enabled Path Computation Framework", 894 RFC 5394, December 2008. 896 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, 897 "Preserving Topology Confidentiality in Inter-Domain 898 Path Computation Using a Path-Key-Based Mechanism", 899 RFC 5520, April 2009. 901 [RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the 902 Path Computation Element (PCE) to Point-to- 903 Multipoint (P2MP) MPLS and GMPLS Traffic Engineering 904 (TE)", RFC 5671, October 2009. 906 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation 907 Clients (PCC) - Path Computation Element (PCE) 908 Requirements for Point-to-Multipoint MPLS-TE", 909 RFC 5862, June 2010. 911 [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set 912 of Monitoring Tools for Path Computation Element 913 (PCE)-Based Architecture", RFC 5886, June 2010. 915 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 916 Authentication Option", RFC 5925, June 2010. 918 [RFC6805] King, D. and A. Farrel, "The Application of the Path 919 Computation Element Architecture to the 920 Determination of a Sequence of Domains in MPLS and 921 GMPLS", RFC 6805, November 2012. 923 [PCEP-MIB] Koushik, K., Stephan, E., Zhao, Q., King, D., and J. 924 Hardwick, "PCE communication protocol (PCEP) 925 Management Information Base (Work in Progress)", 926 April 2014. 928 [PCEP-P2MP-MIB] Zhao, Q., Dhody, D., Palle, U., and D. King, 929 "Management Information Base for the PCE 930 Communications Protocol (PCEP) When Requesting 931 Point-to-Multipoint Services (Work in Progress)", 932 Aug 2012. 934 [DOMAIN-SEQ] Dhody, D., Palle, U., and R. Casellas, "Standard 935 Representation Of Domain Sequence (Work in 936 Progress)", July 2014. 938 14. Contributor Addresses 940 Siva Sivabalan 941 Cisco Systems 942 2000 Innovation Drive 943 Kanata, Ontario K2K 3E8 944 CANADA 946 EMail: msiva@cisco.com 948 Tarek Saad 949 Cisco Systems, Inc. 950 2000 Innovation Drive 951 Kanata, Ontario K2K 3E8 952 CANADA 954 EMail: tsaad@cisco.com 956 15. Authors' Addresses 958 Quintin Zhao 959 Huawei Technology 960 125 Nagog Technology Park 961 Acton, MA 01719 962 US 964 EMail: quintin.zhao@huawei.com 966 Dhruv Dhody 967 Huawei Technology 968 Leela Palace 969 Bangalore, Karnataka 560008 970 INDIA 972 EMail: dhruv.dhody@huawei.com 974 Zafar Ali 975 Cisco Systems 976 2000 Innovation Drive 977 Kanata, Ontario K2K 3E8 978 CANADA 980 EMail: zali@cisco.com 982 Daniel King 983 Old Dog Consulting 984 UK 986 EMail: daniel@olddog.co.uk 988 Ramon Casellas 989 CTTC 990 Av. Carl Friedrich Gauss n7 991 Castelldefels, Barcelona 08860 992 SPAIN 994 EMail: ramon.casellas@cttc.es