idnits 2.17.1 draft-ietf-pce-pcep-inter-domain-p2mp-procedures-05.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 (July 14, 2013) is 3939 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. -------------------------------------------------------------------------------- 2 PCE Working Group Q. Zhao 3 Internet-Draft D. Dhody 4 Intended status: Experimental Huawei Technology 5 Expires: January 14, 2014 Z. Ali 6 Cisco Systems 7 D. King 8 Old Dog Consulting 9 R. Casellas 10 CTTC - Centre Tecnologic de 11 Telecomunicacions de Catalunya 12 July 14, 2013 14 PCE-based Computation Procedure To Compute Shortest Constrained P2MP 15 Inter-domain Traffic Engineering Label Switched Paths 16 draft-ietf-pce-pcep-inter-domain-p2mp-procedures-05 18 Abstract 20 The ability to compute paths for constrained point-to-multipoint 21 (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across 22 multiple domains has been identified as a key requirement for the 23 deployment of P2MP services in MPLS and GMPLS-controlled networks. 24 The Path Computation Element (PCE) has been recognized as an 25 appropriate technology for the determination of inter-domain paths of 26 P2MP TE LSPs. 28 This document describes an experiment to provide procedures and 29 extensions to the PCE communication Protocol (PCEP) for the 30 computation of inter-domain paths for P2MP TE LSPs. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 14, 2013. 49 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 6. Objective Functions and Constraints. . . . . . . . . . . . . . 8 74 7. P2MP Path Computation Procedures . . . . . . . . . . . . . . . 8 75 7.1. Core Trees . . . . . . . . . . . . . . . . . . . . . . . . 8 76 7.2. Core Tree Computation Procedures . . . . . . . . . . . . .10 77 7.3. Sub-tree Computation Procedures . . . . . . . . . . . . .11 78 7.4. PCEP Protocol Extensions . . . . . . . . . . . . . . . . .12 79 7.4.1. The Extension of RP Object . . . . . . . . . . . . . .12 80 7.4.2. Domain and PCE Sequence . . . . . . . . . . . . . . .12 81 7.5. Relationship with Hierarchical PCE . . . . . . . . . . . .13 82 7.6. Parallelism . . . . . . . . . . . . . . . . . . . . . . .13 83 8. Protection . . . . . . . . . . . . . . . . . . . . . . . . . .13 84 8.1. End-to-end Protection . . . . . . . . . . . . . . . . . .14 85 8.2. Domain Protection . . . . . . . . . . . . . . . . . . . .14 86 9. Manageability Considerations . . . . . . . . . . . . . . . . .14 87 9.1. Control of Function and Policy . . . . . . . . . . . . . .14 88 9.2. Information and Data Models . . . . . . . . . . . . . . .15 89 9.3. Liveness Detection and Monitoring . . . . . . . . . . . .15 90 9.4. Verifying Correct Operation . . . . . . . . . . . . . . .15 91 9.5. Requirements on Other Protocols and Functional 92 Components . . . . . . . . . . . . . . . . . . . . . . . .15 93 9.6. Impact on Network Operation . . . . . . . . . . . . . . .16 94 9.7. Policy Control . . . . . . . . . . . . . . . . . . . . . .16 95 10. Security Considerations . . . . . . . . . . . . . . . . . . .16 96 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .17 97 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .17 98 13. References . . . . . . . . . . . . . . . . . . . . . . . . . .17 99 13.1. Normative References . . . . . . . . . . . . . . . . . . .17 100 13.2. Informative References . . . . . . . . . . . . . . . . . .17 101 14. Contributors' Addresses . . . . . . . . . . . . . . . . . . .19 102 15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . .19 104 1. Introduction 106 Multicast services are increasingly in demand for high-capacity 107 applications such as multicast Virtual Private Networks (VPNs), IP- 108 television (IPTV) which may be on-demand or streamed, and content- 109 rich media distribution (for example, software distribution, 110 financial streaming, or database-replication). The ability to 111 compute constrained Traffic Engineering Label Switched Paths (TE 112 LSPs) for point-to-multipoint (P2MP) LSPs in Multiprotocol Label 113 Switching (MPLS) and Generalized MPLS (GMPLS) networks across 114 multiple domains are therefore required. 116 The applicability of the Path Computation Element (PCE) [RFC4655] for 117 the computation of such paths is discussed in [RFC5671], and the 118 requirements placed on the PCE communications Protocol (PCEP) for 119 this are given in [RFC5862]. 121 This document details the requirements for inter-domain P2MP path 122 computation, it then describes the experimental procedure 123 "core-tree" path computation, developed to address the requirements 124 and objectives for inter-domain P2MP path computation. 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 Path Computation Element (PCE) to support 131 inter-domain P2MP path computation. 133 This document is not intended to replace the intra-domain P2MP path 134 computation approach supported 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 ABR: Area Border Router. Router used to connect two IGP domains 149 (areas in OSPF or levels in IS-IS). 151 ASBR: Autonomous System Border Router. Router used to connect 152 together ASes of the same or different Service Providers via one or 153 more Inter-AS links. 155 Boundary Node (BN): is either an ABR in the context 156 of inter-area Traffic Engineering or an ASBR in the context of 157 inter-AS Traffic Engineering. 159 Core Tree: a P2MP tree where the root is the ingress 160 LSR, and the leaf nodes are the entry BNs of the leaf domains. 162 Domain: a collection of network elements within a common sphere of 163 address management or path computational responsibility such as an 164 IGP area or an Autonomous System (AS). 166 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along 167 a determined sequence of domains. 169 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 170 a determined sequence of domains. 172 Leaf Domain: a domain with one or more leaf nodes. 174 OF: Objective Function. a set of one or more optimization criterion 175 (criteria) used for the computation of paths either for single or for 176 synchronized requests (e.g. path cost minimization), or the 177 synchronized computation of a set of paths (e.g. aggregate bandwidth 178 consumption minimization, etc.). See [RFC4655] and [RFC5541]. 180 Path Tree: a set of LSRs and TE links that comprise the path 181 of a P2MP TE LSP from the ingress LSR to all egress LSRs. 183 Path Domain Sequence: the known sequence of domains for a path 184 between root and leaf. 186 Path Domain Tree: the tree formed by the domains that the P2MP path 187 crosses, where the source (ingress) domain is the root domain. 189 PCE(i): a PCE that performs path computations for domain(i). 191 Root Domain: the domain that includes the ingress (root) LSR. 193 Sub-tree: used to minimize packet duplication when P2P 194 TE sub-LSPs traverse common links. 196 Transit/branch Domain: a domain that has an upstream and one or more 197 downstream neighbor domain. 199 VSPT: Virtual Shortest Path Tree [RFC5441]. 201 3. Problem Statement 203 The Path Computation Element (PCE) defined in [RFC4655] is an entity 204 that is capable of computing a network path or route based on a 205 network graph, and applying computational constraints. A Path 206 Computation Client (PCC) may make requests to a PCE for paths to be 207 computed. 209 [RFC4875] describes how to set up P2MP TE LSPs for use in MPLS and 210 GMPLS-controlled networks. The PCE is identified as a suitable 211 application for the computation of paths for P2MP TE LSPs [RFC5671]. 213 [RFC5441] specifies a procedure relying on the use of multiple PCEs 214 to compute (P2P) inter-domain constrained shortest paths across a 215 predetermined sequence of domains, using a Backward Recursive Path 216 Computation (BRPC) technique. The technique can be combined with the 217 use of path keys [RFC5520] to preserve confidentiality across 218 domains, which is sometimes required when domains are managed by 219 different Service Providers. 221 The PCE communication Protocol (PCEP) [RFC5440] is extended for 222 point-to-multipoint(P2MP) path computation requests in [RFC6006]. 223 However, [RFC6006] does not provide the necessary mechanisms and 224 procedures to request the computation of inter-domain P2MP TE LSPs. 226 As discussed in [RFC4461], a P2MP tree is a graphical representation 227 of all TE links that are committed for a particular P2MP TE LSP. In 228 other words, a P2MP tree is a representation of the corresponding 229 P2MP tunnel on the TE network topology. A sub-tree is used to 230 minimize packet duplication when P2P TE sub-LSPs traverse common 231 links. As described in [RFC5671] the computation of a P2MP tree 232 requires three major pieces of information. The first is the path 233 from the ingress LSR of a P2MP TE LSP to each of the egress LSRs, the 234 second is the traffic engineering related parameters, and the third 235 is the branch capability information. 237 Generally, an inter-domain P2MP tree (i.e., a P2MP tree with source 238 and at least one destination residing in different domains) is 239 particularly difficult to compute even for a distributed PCE 240 architecture. For instance, while the BRPC may be well-suited for 241 P2P paths, P2MP path computation involves multiple branching path 242 segments from the source to the multiple destinations. As such, 243 inter-domain P2MP path computation may result in a plurality of 244 per-domain path options that may be difficult to coordinate 245 efficiently and effectively between domains. 247 That is, when one or more domains have multiple ingress and/or egress 248 boundary nodes, there is currently no known technique for one domain 249 to determine which boundary node of another domain will be utilized 250 for the inter-domain P2MP tree, and no way to limit the computation 251 of the P2MP tree to those utilized boundary nodes. 253 A trivial solution to the computation of inter-domain P2MP tree would 254 be to compute shortest inter-domain P2P paths from source to each 255 destination and then combine them to generate an inter-domain, 256 shortest-path-to-destination P2MP tree. This solution, however, 257 cannot be used to trade cost to destination for overall tree cost 258 (i.e., it cannot produce a Minimum Cost Tree (MCT)) and in the 259 context of inter- domain P2MP TE LSPs it cannot be used to reduce the 260 number of domain boundary nodes that are transited. Computing P2P TE 261 LSPs individually is not an acceptable solution for computing a P2MP 262 tree. 264 Even per domain path computation [RFC5152] 265 can be used to compute P2P multi-domain paths, but it does not 266 guarantee to find the optimal path which crosses multiple domains. 267 Furthermore, constructing a P2MP tree from individual source to leaf 268 P2P TE LSPs does not guarantee to produce a Minimum Cost Tree (MCT). 269 This approach may also be considered to have scaling issues during 270 LSP setup. That is, the LSP to each leaf is signaled separately, and 271 each boundary node must perform path computation for each leaf. 273 P2MP Minimum Cost Tree (MCT), i.e. a computation which guarantees the 274 least cost resulting tree, is an NP-complete problem. Moreover, 275 adding and/or removing a single destination to/from the tree may 276 result in an entirely different tree. In this case, frequent MCT 277 path computation requests may prove computationally intensive, and 278 the resulting frequent tunnel reconfiguration may even cause network 279 destabilization. 281 This document presents a solution, procedures and extensions to 282 PCEP to support P2MP inter-domain path computation. 284 4. Assumptions 286 Within this document we make the following assumptions: 288 o Due to deployment and commercial limitations (e.g., inter-AS 289 peering agreements), the path domain tree will be known in 290 advance; 292 o Each PCE knows about any leaf LSRs in the domain it serves; 294 Additional assumptions are documented in [RFC5441] and will 295 not be repeated here. 297 5. Requirements 299 This section summarizes the requirements specific to computing inter- 300 domain P2MP paths. In these requirements we note that the actual 301 computation time taken by any PCE implementation is outside the scope 302 of this document, but we observe that reducing the complexity of the 303 required computations has a beneficial effect on the computation time 304 regardless of implementation. Additionally, reducing the number of 305 message exchanges and the amount of information exchanged will reduce 306 the overall computation time for the entire P2MP tree. We refer to 307 the "complexity of the computation" as the impact on these aspects of 308 path computation time as various parameters of the topology and the 309 P2MP TE LSP are changed. 311 It is also important that the solution preserves confidentiality 312 across domains, which is required when domains are managed by 313 different Service Providers. 315 Other than the requirements specified in [RFC5862], a number of 316 requirements specific to P2MP are detailed below: 318 1. The computed P2MP TE LSP SHOULD be optimal when only considering 319 the paths among the BNs. 321 2. Grafting and pruning of multicast destinations in a domain SHOULD 322 have no impact on other domains and on the paths among BNs. 324 3. The complexity of the computation for each sub-tree within each 325 domain SHOULD be dependent only on the topology of the domain and 326 it SHOULD be independent of the domain sequence. 328 4. The number of PCReq and PCReq messages SHOULD be independent of 329 the number of multicast destinations in each domain. 331 5. It SHOULD be possible to specify the domain entry and exit nodes. 333 6. Specifying which nodes are be used as branch nodes SHOULD be 334 supported. 336 7. Reoptimization of existing sub-trees SHOULD be supported. 338 8. It SHOULD be possible to compute diverse P2MP paths from existing 339 P2MP paths. 341 6. Objective Functions and Constraints 343 For the computation of a single or a set of P2MP TE LSPs, a request 344 to meet specific optimization criteria, called an Objective Function 345 (OF), may be used. Using an OF to select the "best" candidate path, 346 include: 348 o The sub-tree within each domain SHOULD be optimized using minimum 349 cost tree [RFC5862], or shortest path tree [RFC5862]. 351 In addition to the OFs, the following constraint optimization may 352 also be beneficial for P2MP path computation: 354 1. The core tree SHOULD be optimal. 356 2. It SHOULD be possible to limit the number of entry points to a 357 domain. 359 3. It SHOULD be possible to force the branches for all leaves within 360 a domain to be in that domain. 362 4. It SHOULD be possible to combine the aforementioned OFs and 363 constraints for P2MP path computation. 365 The algorithms used to compute optimal paths using a combination of 366 OFs and multiple constraints is out of scope of this document. 368 7. P2MP Path Computation Procedures 370 The following sections describe the core tree-based procedures to 371 satisfy the requirements specified in the previous section. A core 372 tree-based solution provides an optimal inter-domain P2MP TE LSP. 374 7.1. Core Trees 376 A core tree is defined as a tree that satisfies the following 377 conditions: 379 o The root of the core tree is the ingress LSR in the root domain; 381 o The leaves of the core tree are the entry nodes in the leaf 382 domains. 384 To support confidentiality these nodes and links may be hidden using 385 the path-key mechanism [RFC5520], but they MUST be computed and be a 386 part of core-tree. 388 For example, consider the Domain Tree in Figure 1 below, 389 representing a domain tree of 6 domains, and part of the resulting 390 core tree which satisfies the aforementioned conditions. 392 +----------------+ 393 | |Domain D1 394 | R | 395 | | 396 | A | 397 | | 398 +-B------------C-+ 399 / \ 400 / \ 401 / \ 402 Domain D2 / \ Domain D3 403 +-------------D--+ +-----E----------+ 404 | | | | 405 | F | | | 406 | G | | H | 407 | | | | 408 | | | | 409 +-I--------------+ +-J------------K-+ 410 / / \ 411 / / \ 412 / / \ 413 / / \ 414 / / \ 415 / / \ 416 / Domain D4 Domain D5 / Domain D6 \ 417 +-L--------------+ +------P---------+ +-----------T----+ 418 | | | | | | 419 | | | Q | | U | 420 | M O | | S | | | 421 | | | | | V | 422 | N | | R | | | 423 +----------------+ +----------------+ +----------------+ 425 Figure 1: Domain Tree Example 426 (R) 427 | 428 (A) 429 / \ 430 / \ 431 (B) (C) 432 / \ 433 / \ 434 (D) (E) 435 / | 436 / | 437 (G) (H) 438 / / \ 439 / / \ 440 (I) (J) (K) 441 / / \ 442 / / \ 443 (L) (P) (T) 445 Figure 2: Core Tree 447 A core tree is computed such that root of the tree is R and the leaf 448 node are the entry nodes of the destination domains (L, P and T). 449 Path-key mechanism can be used to hide the internal nodes and links 450 in the final core tree. 452 7.2. Core Tree Computation Procedures 454 The algorithms to compute the optimal large core tree are outside 455 scope of this document. The following extended BRPC-based procedure 456 can be used to compute the core tree. 458 A BRPC-based core tree path computation procedure is described below: 460 1. Using the BRPC procedures to compute the VSPT(i) for each leaf 461 BN(i), i=1 to n, where n is the total number of entry nodes for 462 all the leaf domains. In each VSPT(i), there are a number of 463 P(i) paths. 465 2. When the root PCE has computed all the VSPT(i), i=1 to n, take 466 one path from each VSPT and form all possible sets of paths, we 467 call them PathSet(j), j=1 to M, where M=P(1)xP(2)...xP(n); 469 3. For each PathSet(j), there are n S2L (Source to Leaf BN) paths 470 and form these n paths into a core tree(j); 472 4. There will be M number of core trees computed from step3. Apply 473 the OF to each of these M core trees and find the optimal Core 474 Tree. 476 Note that, since point to point BRPC procedure is used to compute 477 VSPT, the path request and response messages as per [RFC5440] are 478 used. 480 Also note that the application of BRPC in the aforementioned 481 procedure differs from the typical one since paths returned from a 482 downstream PCE are not necessarily pruned from the solution set by 483 intermediate PCEs. The reason for this is that if the PCE in a 484 downstream domain does the pruning and returns the single optimal 485 sub-path to the upstream PCE, BRPC insures that the ingress PCE will 486 get all the best optimal sub-paths for each LN (Leaf Boundary 487 Nodes), but the combination of these single optimal sub-paths into 488 a P2MP tree is not necessarily optimal even if each S2L 489 (Source-to-Leaf) sub-path is optimal. 491 Without trimming, the ingress PCE will obtain all the possible S2L 492 sub-paths set for LN. The PCE will then, by looking through all 493 the combinations and taking one sub-path from each set to build one 494 P2MP tree, can find the optimal tree. 496 A PCE MAY add equal cost paths within the domain while constructing 497 an extended VSPT. This will provide the ingress PCE more candidate 498 paths for an optimal P2MP tree. 500 The proposed method may present a scalability problem for the dynamic 501 computation of the core tree (by iterative checking of all 502 combinations of the solution space), specially with dense/meshed 503 domains. Considering a domain sequence D1, D2, D3, D4, where the 504 Leaf Boundary Node is at domain D4, PCE(4) will return 1 path. 505 PCE(3) will return N paths, where N is E(3) x X(3), where E(k) x X(k) 506 denotes the number of entry nodes times the number of exit nodes for 507 that domain. PCE(2) will return M paths, where M = E(2) x X(2) x N = 508 E(2) x X(2) x E(3) x X(3) x 1, etc. Generally speaking the number of 509 potential paths at the ingress PCE Q = \prod E(k) x X(k). 511 Consequently, it is expected that the Core Path will be typically 512 computed offline, without precluding the use of dynamic, online 513 mechanisms such as the one presented here, in which case it SHOULD be 514 possible to configure transit PCEs to control the number of paths 515 sent upstream during BRPC (trading trimming for optimality at the 516 point of trimming and downwards). 518 7.3. Sub-tree Computation Procedures 520 Once the core tree is built, the grafting of all the leaf nodes from 521 each domain to the core tree can be achieved by a number of 522 algorithms. One algorithm for doing this phase is that the root PCE 523 will send the request with C bit set (as defined in section 7.4.1 of 524 this document) for the path computation to the destination(s) 525 directly to the PCE where the destination(s) belong(s) along with the 526 core tree computed from section 7.1. 528 This approach requires that the root PCE manage a potentially large 529 number of adjacencies (either in persistent or non-persistent mode), 530 including PCEP adjacencies to PCEs that are not within neighbor 531 domains. 533 A first alternative would involve establishing PCEP adjacencies that 534 correspond to the PCE domain tree. This would require that branch 535 PCEs forward requests and responses from the root PCE towards the 536 leaf PCEs and vice-versa. 538 Note that the P2MP path request and response format is as per 539 [RFC6006], where Record Route Object (RRO) are used to carry the 540 core-tree paths in the P2MP grafting request. 542 The algorithms to compute the optimal large sub-tree are outside 543 scope of this document. 545 7.4. PCEP Protocol Extensions 547 7.4.1. The Extension of RP Object 549 This experiment will be carried out by extending the RP (Request 550 Parameters) object (defined in [RFC5440]) used in Path Request and 551 Reply messages. 553 The extended format of the RP object body to include the C bit is as 554 follows: 556 The C bit is added in the flag bits field of the RP object to signal 557 the receiver of the message that the request/reply is for inter- 558 domain P2MP core tree or not. 560 The following flag is added in this draft: 562 C bit ( P2MP Core Tree bit - 1 bit): 564 0: This indicates that this is normal PCReq/PCRrep for P2MP. 566 1: This indicates that this is PCReq or PCRep message for inter- 567 domain core tree P2MP. When the C bit is set, then the request 568 message MUST contain the core tree passed along with the 569 destinations to be grafted to the tree. 571 7.4.2. Domain and PCE Sequence 573 The procedure as described in this document requires the domain-tree 574 to be known in advance. This information may be provided dynamically 575 as documented in the Hierarchical PCE (H-PCE) [RFC6805] framework, or 576 obtained through the IGP/BGP routing information. 578 [DOMAIN-SEQ] describes the representation of domain in P2MP 579 scenarios. The use of PCE sequence rather than domain-sequence, is 580 based on deployment and implementation preference. 582 7.5. Using H-PCE for Scalability 584 The ingress/root PCE is responsible for the grafting of sub-trees 585 into the multi-domain tree. Therefore, the ingress/root PCE will 586 receive all computed sub-trees from all the involved domains. This 587 will require the ingress/root PCE to have a PCEP session with all 588 PCEs providing sub-trees. This may cause an excessive number of 589 sessions or added complexity in implementations. 591 The use of the H-PCE framework [RFC6805] may be used to establish a 592 dedicated PCE with the capability (memory and CPU) and knowledge to 593 maintain the necessary PCEP sessions. The parent PCE would be 594 responsible to request intra-domain sub-trees to the PCEs, combine 595 them and return the overall P2MP tree. 597 7.6. Parallelism 599 In order to minimize latency in path computation in multi-domain 600 networks, intra-domain path segments and intra-domain sub-trees 601 SHOULD be computed in parallel when possible. The proposed 602 procedures in this draft present opportunities for parallelism: 604 1. The BRPC procedure for each leaf node can be launched in parallel 605 by the ingress/root PCE if the dynamic computation of the Core 606 Tree is enabled. 608 2. Intra-domain P2MP paths can also be computed in parallel by the 609 PCEs once the entry and exit nodes within a domain are known 611 One of the potential issues of parallelism is that the ingress PCE 612 would require a potentially high number of PCEP adjacencies to 613 "remote" PCEs and that may not be desirable, but a given PCE would 614 only receive requests for the destinations that are in its domain (+ 615 the core nodes), without PCEs forwarding requests. 617 8. Protection 619 It is envisaged that protection may be required when deploying and 620 using inter-domain P2MP TE LSPs. The procedures and mechanisms 621 defined in this document do not prohibit the use of existing and 622 proposed types of protection, including: end-to-end protection 623 [RFC4875] and domain protection schemes. 625 Segment or facility (link and node) protection is problematic in 626 inter-domain environment due to the limit of Fast-reroute (FRR) 627 [RFC4875] requiring knowledge of its next-hop across domain 628 boundaries whilst maintaining domain confidentiality. Although the 629 FRR protection might be implemented if next-hop information was known 630 in advance. 632 8.1. End-to-end Protection 634 An end-to-end protection (for nodes and links) principle can be 635 applied for computing backup P2MP TE LSPs. During computation of the 636 core-tree and sub-trees, may also be taken into consideration. A 637 PCE may compute the primary and backup P2MP TE LSP together or 638 sequentially. 640 8.2. Domain Protection 642 In this protection scheme, backup P2MP Tree can be computed which 643 excludes the transit/branch domain completely. A backup domain path 644 tree is needed with the same source domain and destinations domains 645 and a new set of transit domains. The backup path tree can be 646 applied to the above procedure to obtain the backup P2MP TE LSP with 647 disjoint transit domains. 649 9. Manageability Considerations 651 [RFC5862] describes various manageability requirements in support of 652 P2MP path computation when applying PCEP. This section describes how 653 manageability requirements mentioned in [RFC5862] are supported in 654 the context of PCEP extensions specified in this document. 656 Note that [RFC5440] describes various manageability considerations in 657 PCEP, and most of manageability requirements mentioned in [RFC6006] 658 are already covered there. 660 9.1. Control of Function and Policy 662 In addition to PCE configuration parameters listed in [RFC5440], the 663 following additional parameters might be required: 665 o The ability to enable or disable single domain P2MP path 666 computations on the PCE. 668 o The ability to enable or disable multi-domain P2MP path 669 computations on the PCE. 671 o The PCE may be configured to enable or disable the advertisement 672 of its single domain and multi-domain P2MP path computation 673 capability. 675 9.2. Information and Data Models 677 A number of MIB objects have been defined for general PCEP control 678 and monitoring of P2P computations in [PCEP-MIB]. [RFC5862] 679 specifies that MIB objects will be required to support the control 680 and monitoring of the protocol extensions defined in this document. 681 [PCEP-P2MP-MIB] describes managed objects for modeling of PCEP 682 communications between a PCC and PCE, and PCE to PCE, P2MP path 683 computation requests and responses. 685 9.3. Liveness Detection and Monitoring 687 No changes are necessary to the liveness detection and monitoring 688 requirements as already embodied in [RFC4657]. 690 It should be noted that multi-domain P2MP computations are likely to 691 take longer than P2P computations, and single domain P2MP 692 computations. The liveness detection and monitoring features of the 693 PCEP SHOULD take this into account. 695 9.4. Verifying Correct Operation 697 There are no additional requirements beyond those expressed in 698 [RFC4657] for verifying the correct operation of the PCEP. Note that 699 verification of the correct operation of the PCE and its algorithms 700 is out of scope for the protocol requirements, but a PCC MAY send the 701 same request to more than one PCE and compare the results. 703 9.5. Requirements on Other Protocols and Functional Components 705 A PCE operates on a topology graph that may be built using 706 information distributed by TE extensions to the routing protocol 707 operating within the network. In order that the PCE can select a 708 suitable path for the signaling protocol to use to install the P2MP 709 TE LSP, the topology graph MUST include information about the P2MP 710 signaling and branching capabilities of each LSR in the network. 712 Mechanisms for the knowledge of other domains, the discovery of 713 corresponding PCEs and their capabilities should be provided and that 714 this information MAY be collected by other mechanisms. 716 Whatever means is used to collect the information to build the 717 topology graph, the graph MUST include the requisite information. If 718 the TE extensions to the routing protocol are used, these SHOULD be 719 as described in [RFC5073]. 721 9.6. Impact on Network Operation 723 The use of a PCE to compute P2MP paths is not expected to have 724 significant impact on network operations. However, it should be 725 noted that the introduction of P2MP support to a PCE that already 726 provides P2P path computation might change the loading of the PCE 727 significantly, and that might have an impact on the network behavior, 728 especially during recovery periods immediately after a network 729 failure. 731 The dynamic computation of core trees might also have an impact on 732 the load of the involved PCEs as well as path computation times. 734 9.7. Policy Control 736 [RFC5394] provides additional details on policy within the PCE 737 architecture and also provides context for the support of PCE Policy. 738 They are also applicable to Inter-domain P2MP Path computation via 739 the core tree mechanism. 741 10. Security Considerations 743 As described in [RFC5862], P2MP path computation requests are more 744 CPU-intensive and also utilize more link bandwidth. In the event of 745 an unauthorized P2MP path computation request, or a denial of service 746 attack, the subsequent PCEP requests and processing may be disruptive 747 to the network. Consequently, it is important that implementations 748 conform to the relevant security requirements of [RFC5440] that 749 specifically help to minimize or negate unauthorized P2MP path 750 computation requests and denial of service attacks. These mechanisms 751 include: 753 o Securing the PCEP session requests and responses using TCP 754 security techniques (Section 10.2 of [RFC5440]). 756 o Authenticating the PCEP requests and responses to ensure the 757 message is intact and sent from an authorized node (Section 10.3 758 of [RFC5440]). 760 o Providing policy control by explicitly defining which PCCs, via IP 761 access-lists, are allowed to send P2MP path requests to the PCE 762 (Section 10.6 of [RFC5440]). 764 PCEP operates over TCP, so it is also important to secure the PCE and 765 PCC against TCP denial of service attacks. Section 10.7.1 of 766 [RFC5440] outlines a number of mechanisms for minimizing the risk of 767 TCP-based denial of service attacks against PCEs and PCCs. 769 PCEP implementations SHOULD also consider the additional security 770 provided by the TCP Authentication Option (TCP-AO) [RFC5925]. 772 11. IANA Considerations 774 Due to the experimental status of this document. No IANA 775 considerations have been requested. 777 12. Acknowledgements 779 The authors would like to thank Adrian Farrel, Dan Tappan, Olufemi 780 Komolafe, Oscar Gonzalez de Dios and Julien Meuric for their 781 valuable comments on this document. 783 13. References 785 13.1. Normative References 787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 788 Requirement Levels", BCP 14, RFC 2119, March 1997. 790 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation 791 Element (PCE) Communication Protocol (PCEP)", 792 RFC 5440, March 2009. 794 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, 795 "A Backward-Recursive PCE-Based Computation (BRPC) 796 Procedure to Compute Shortest Constrained Inter- 797 Domain Traffic Engineering Label Switched Paths", 798 RFC 5441, April 2009. 800 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 801 Objective Functions in the Path Computation Element 802 Communication Protocol (PCEP)", RFC 5541, June 2009. 804 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, 805 Z., and J. Meuric, "Extensions to the Path 806 Computation Element Communication Protocol (PCEP) 807 for Point-to-Multipoint Traffic Engineering Label 808 Switched Paths", RFC 6006, September 2010. 810 13.2. Informative References 812 [RFC4461] Yasukawa, S., "Signaling Requirements for Point-to- 813 Multipoint Traffic-Engineered MPLS Label Switched 814 Paths (LSPs)", RFC 4461, April 2006. 816 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path 817 Computation Element (PCE)-Based Architecture", 818 RFC 4655, August 2006. 820 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element 821 (PCE) Communication Protocol Generic Requirements", 822 RFC 4657, September 2006. 824 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 825 "Extensions to Resource Reservation Protocol - 826 Traffic Engineering (RSVP-TE) for Point-to- 827 Multipoint TE Label Switched Paths (LSPs)", 828 RFC 4875, May 2007. 830 [RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol 831 Extensions for Discovery of Traffic Engineering Node 832 Capabilities", RFC 5073, December 2007. 834 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per- 835 Domain Path Computation Method for Establishing 836 Inter-Domain Traffic Engineering (TE) Label Switched 837 Paths (LSPs)", RFC 5152, February 2008. 839 [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS 840 Requirements for the Path Computation Element 841 Communication Protocol (PCECP)", RFC 5376, 842 November 2008. 844 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. 845 Ash, "Policy-Enabled Path Computation Framework", 846 RFC 5394, December 2008. 848 [RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, 849 "Preserving Topology Confidentiality in Inter-Domain 850 Path Computation Using a Path-Key-Based Mechanism", 851 RFC 5520, April 2009. 853 [RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the 854 Path Computation Element (PCE) to Point-to- 855 Multipoint (P2MP) MPLS and GMPLS Traffic Engineering 856 (TE)", RFC 5671, October 2009. 858 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation 859 Clients (PCC) - Path Computation Element (PCE) 860 Requirements for Point-to-Multipoint MPLS-TE", 861 RFC 5862, June 2010. 863 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 864 Authentication Option", RFC 5925, June 2010. 866 [RFC6805] King, D. and A. Farrel, "The Application of the Path 867 Computation Element Architecture to the 868 Determination of a Sequence of Domains in MPLS and 869 GMPLS", RFC 6805, November 2012. 871 [PCEP-MIB] Koushik, K., Stephan, E., Zhao, Q., King, D., and J. 872 Hardwick, "PCE communication protocol (PCEP) 873 Management Information Base (Work in Progress)", 874 July 2012. 876 [PCEP-P2MP-MIB] Zhao, Q., Dhody, D., Palle, U., and D. King, 877 "Management Information Base for the PCE 878 Communications Protocol (PCEP) When Requesting 879 Point-to-Multipoint Services (Work in Progress)", 880 Aug 2012. 882 [DOMAIN-SEQ] Dhody, D., Palle, U., and R. Casellas, "Standard 883 Representation Of Domain Sequence (Work in 884 Progress)", Feb 2013. 886 14. Contributor Addresses 888 Siva Sivabalan 889 Cisco Systems 890 2000 Innovation Drive 891 Kanata, Ontario K2K 3E8 892 CANADA 894 EMail: msiva@cisco.com 896 Tarek Saad 897 Cisco Systems, Inc. 898 2000 Innovation Drive 899 Kanata, Ontario K2K 3E8 900 CANADA 902 EMail: tsaad@cisco.com 904 15. Authors' Addresses 906 Quintin Zhao 907 Huawei Technology 908 125 Nagog Technology Park 909 Acton, MA 01719 910 US 912 EMail: quintin.zhao@huawei.com 913 Dhruv Dhody 914 Huawei Technology 915 Leela Palace 916 Bangalore, Karnataka 560008 917 INDIA 919 EMail: dhruv.dhody@huawei.com 921 Zafar Ali 922 Cisco Systems 923 2000 Innovation Drive 924 Kanata, Ontario K2K 3E8 925 CANADA 927 EMail: zali@cisco.com 929 Daniel King 930 Old Dog Consulting 931 UK 933 EMail: daniel@olddog.co.uk 935 Ramon Casellas 936 CTTC - Centre Tecnologic de Telecomunicacions de Catalunya 937 Av. Carl Friedrich Gauss n7 938 Castelldefels, Barcelona 08860 939 SPAIN 941 EMail: ramon.casellas@cttc.es