idnits 2.17.1 draft-ietf-pce-p2mp-app-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4741 (Obsoleted by RFC 6241) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Yasukawa 3 Internet Draft NTT 4 Category: Informational A. Farrel (Editor) 5 Created: August 17, 2009 Old Dog Consulting 6 Expires: February 17, 2010 8 Applicability of the Path Computation Element (PCE) to 9 Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) 10 and Generalized MPLS (GMPLS) Traffic Engineering (TE) 12 draft-ietf-pce-p2mp-app-02.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 The Path Computation Element (PCE) provides path computation 38 functions in support of traffic engineering in Multiprotocol Label 39 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 41 Extensions to the MPLS and GMPLS signaling and routing protocols have 42 been made in support of point-to-multipoint (P2MP) Traffic Engineered 43 (TE) Label Switched Paths (LSPs). 45 This document examines the applicability of PCE to path computation 46 for P2MP TE LSPs in MPLS and GMPLS networks. It describes the 47 motivation for using a PCE to compute these paths, and examines which 48 of the PCE architectural models are appropriate. 50 Table of Contents 52 1. Introduction ................................................... 3 53 2. Architectural Considerations ................................... 4 54 2.1. Offline Computation .......................................... 4 55 2.2. Online Computation ........................................... 4 56 2.2.1. LSR Loading ................................................ 5 57 2.2.2. PCE Overload ............................................... 6 58 2.2.3. PCE Capabilities ........................................... 6 59 3. Fragmenting the P2MP Tree ...................................... 7 60 4. Central Replication Points ..................................... 8 61 5. Reoptimization and Modification ................................ 9 62 6. Repair ........................................................ 10 63 7. Disjoint Paths ................................................ 11 64 8. Manageability Considerations .................................. 11 65 8.1. Control of Function and Policy .............................. 11 66 8.2. Information and Data Models ................................. 12 67 8.3. Liveness Detection and Monitoring ........................... 12 68 8.4. Verifying Correct Operation ................................. 12 69 8.5. Requirements on Other Protocols and Functional Components ... 12 70 8.6. Impact on Network Operation ................................. 13 71 9. Security Considerations ....................................... 13 72 10. IANA Considerations .......................................... 13 73 11. Acknowledgments .............................................. 13 74 12. References ................................................... 14 75 12.1. Normative Reference ........................................ 14 76 12.2. Informative Reference ...................................... 14 77 13. Authors' Addresses ........................................... 15 78 14. Full Copyright Statement ..................................... 15 80 1. Introduction 82 The Path Computation Element (PCE) defined in [RFC4655] is an entity 83 that is capable of computing a network path or route based on a 84 network graph, and applying computational constraints. The intention 85 is that the PCE is used to compute the path of Traffic Engineered 86 Label Switched Paths (TE LSPs) within Multiprotocol Label Switching 87 (MPLS) and Generalized MPLS (GMPLS) networks. 89 [RFC4655] defines various deployment models that place PCEs 90 differently within the network. The PCEs may be collocated with the 91 Label Switching Routers (LSRs), may be part of the management system 92 that requests the LSPs to be established, or may be positioned as one 93 or more computation servers within the network. 95 Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are 96 documented in [RFC4461] and signaling protocol extensions for 97 setting up P2MP MPLS TE LSPs are defined in [RFC4875]. P2MP MPLS TE 98 networks are considered in support of various features including 99 layer 3 multicast VPNs [RFC4834], video distribution, etc. 101 Fundamental to the determination of the paths for P2MP LSPs within a 102 network is the selection of branch points. Not only is this selection 103 constrained by the network topology and available network resources, 104 but it is determined by the objective functions that may be applied 105 to path computation. For example, one standard objective is to 106 minimize the total cost of the tree (that is, to minimize the sum of 107 the costs of each link traversed by the tree) to produce what is 108 known as a Steiner Tree. Another common objective function requires 109 that the cost to reach each leaf of the P2MP tree is minimized. 111 The selection of branch points within the network is further 112 complicated by the fact that not all LSRs in the network are 113 necessarily capable of performing branching functions. This 114 information may be recorded in the Traffic Engineering Database (TED) 115 that the PCE uses to perform its computations, and may have been 116 distributed using extensions to the Interior Gateway Protocol (IGP) 117 operating within the network [RFC5073]. 119 Additionally, network policies may dictate specific branching 120 behavior. For example, it may be decided that for certain types of 121 LSP in certain types of network, it is important that no branch LSR 122 is responsible for handling more than a certain number of downstream 123 branches for any one LSP. This might arise because the replication 124 mechanism used at the LSRs is a round-robin copying process that 125 delays the data transmission on each downstream branch by the time 126 taken to replicate the data onto each previous downstream branch. 127 Alternatively, administrative policies may dictate that replication 128 should be concentrated on specific key replication nodes behaving 129 like IP multicast rendezvous points (perhaps to ensure appropriate 130 policing of receivers in the P2MP tree, or perhaps to make protection 131 and resiliency easier to implement). 133 Path computation for P2MP TE LSPs presents a significant challenge 134 because of the complexity of the computations described above. 135 Determining disjoint protection paths for P2MP TE LSPs can add 136 considerably to this complexity, while small modifications to a P2MP 137 tree (such as adding or removing just one leaf) can completely change 138 the optimal path. Reoptimization of a network containing multiple 139 P2MP TE LSPs requires considerable computational resources. All of 140 this means that an ingress LSR might not have sufficient processing 141 power to perform the necessary computations, and even if it does, the 142 act of path computation might interfere with the control and 143 management plane operation necessary to maintain existing LSPs. The 144 PCE architecture offers a way to offload such path computations from 145 LSRs. 147 2. Architectural Considerations 149 2.1. Offline Computation 151 Offline path computation is performed ahead of time, before the LSP 152 setup is requested. That means that it is requested by, or performed 153 as part of, a management application. This model can be seen in 154 Section 5.5 of [RFC4655]. 156 The offline model is particularly appropriate to long-lived LSPs 157 (such as those present in a transport network) or for planned 158 responses to network failures. In these scenarios, more planning is 159 normally a feature of LSP provisioning. 161 This model may also be used where the network operator wishes to 162 retain full manual control of the placement of LSPs, using the PCE 163 only as a computation tool to assist the operator, not as part of an 164 automated network. 166 Offline path computation may be applied as a background activity for 167 network reoptimization to determine whether and when the current LSP 168 placements are significantly sub-optimal. See Section 5 for further 169 discussions of reoptimization. 171 2.2. Online Computation 173 Online path computation is performed on-demand as LSRs in the network 174 determine that they need to know the paths to use for LSPs. Thus, 175 each computation is triggered by a request from an LSR. 177 As described in [RFC4655], the path computation function for online 178 computation may be collocated with the LSR that makes the request, or 179 may be present in a computation-capable PCE server within the 180 network. The PCE server may be another LSR in the network, a 181 dedicated server, or a functional component of an NMS. Furthermore, 182 the computation is not necessarily achieved by a single PCE operating 183 on its own, but may be the result of cooperation between several 184 PCEs. 186 The remainder of this document makes frequent reference to these 187 different online models in order to indicate which is more 188 appropriate in different P2MP scenarios. 190 2.2.1. LSR Loading 192 An important feature of P2MP path computation is the processing load 193 that it places on the network element that is determining the path. 194 Roughly speaking, the load to compute a least-cost-to-leaf tree is 195 the same as the cost to compute a single optimal path to each leaf in 196 turn. The load to compute a Steiner tree is approximately an order of 197 magnitude greater although there exist algorithms to approximate 198 Steiner trees in roughly the same order of magnitude of time as for a 199 least-cost-to-leaf tree. 201 Whereas many LSRs are capable of simple Constrained Shortest Path 202 First (CSPF) computations to determine a path for a single point-to- 203 point (P2P) LSP, they rapidly become swamped if called on to perform 204 multiple such computations such as when recovering from a network 205 failure. Thus, it is reasonable to expect that an LSR would struggle 206 to handle a P2MP path computation for a tree with many destinations. 208 The result of an LSR becoming overloaded by a P2MP path computation 209 may be two-fold. First, the LSR may be unable to provide timely 210 computations of paths for P2P LSPs: this may impact LSP setup times 211 for simple demand-based services, and could damage the LSR's ability 212 to recover services after network faults. Secondly, the LSR's 213 processing capabilities may be diverted from other important tasks 214 not the least of which is maintaining the control plane protocols 215 that are necessary to the support of existing LSPs and forwarding 216 state within the network. It is obviously critically important that 217 existing traffic should not be disrupted by the computation of a path 218 for a new LSP. 220 It also not reasonable to expect the ingress LSRs of P2MP LSRs to be 221 specially powerful and capable of P2MP computations. Although a 222 solution to the overloading problem would be to require that all LSRs 223 that form the ingresses to P2MP LSPs should be sufficiently 224 high-capacity to perform P2MP computations, this is not an acceptable 225 solution because in all other senses, the ingress to a P2MP LSP is 226 just a normal ingress LSR. 228 Thus, there is an obvious solution which is to off-load P2MP path 229 computations from LSRs to remotely located PCEs. Such PCE function 230 can be provided on dedicated or high-capacity network elements (such 231 as dedicated servers, or high-end routers that might be located as 232 Autonomous System Border Routers - ASBRs). 234 2.2.2. PCE Overload 236 Since P2MP path computations are resource-intensive, it may be that 237 the introduction of P2MP LSPs into an established PCE network will 238 cause overload at the PCEs. That is, the P2MP computations may block 239 other P2P computations and might even overload the PCE. 241 Several measures can be taken within the PCE architecture to 242 alleviate this situation as described in [RFC4655]. For example, path 243 computation requests can be assigned priorities by the LSRs that 244 issue them. Thus, the LSRs could assign lower priority to the P2MP 245 requests ensuring that P2P requests were serviced in preference. 246 Furthermore, the PCEs are able to apply local and network-wide policy 247 and this may dictate specific processing rules [RFC5394]. 249 But ultimately a network must possess sufficient path computation 250 resources for its needs and this is achieved within the PCE 251 architecture simply by increasing the number of PCEs. 253 Once there are sufficient PCEs available within the network, the LSRs 254 may choose between them, and may use overload notification 255 information supplied by the PCEs to spot which PCEs are currently 256 over-loaded. Additionally, a PCE that is becoming over-loaded may 257 redistribute its queue of computation requests to other less-burdened 258 PCEs within the network using the PCE cooperation model described in 259 [RFC4655]. 261 2.2.3. PCE Capabilities 263 An LSR chooses between available PCEs to select the one most likely 264 to be able to perform the requested path computation. This selection 265 may be based on overload notifications from the PCEs, but could also 266 consider other computational capabilities. 268 For example, it is quite likely that only a subset of the PCEs in the 269 network have the ability to perform P2MP computations since this 270 requires advanced functionality. Some of those PCEs might have the 271 ability to satisfy certain objective functions (for example, least 272 cost to destination), but lack support for other objective functions 273 (for example Steiner). Additionally, some PCEs might not be capable 274 of the more complex P2MP reoptimization functionality. 276 The PCE architecture allows an LSR to discover the capabilities of 277 the PCEs within the network at the same time as it discovers their 278 existence. Further and more detailed exchanges of PCE capabilities 279 can be made directly between the PCEs and the LSRs. This exchange of 280 PCE capabilities information allows a Path Computation Client (PCC) 281 to select thePCE that can best answer its computation requests. 283 3. Fragmenting the P2MP Tree 285 A way to reduce the computational burden on a single PCE of computing 286 a large P2MP tree is to fragment or partition the tree. This may be 287 particularly obvious in a multi-domain network (such as multiple 288 routing areas), but is equally applicable in a single domain. 290 Consider the network topology in Figure 1. A P2MP LSP is required 291 from ingress LSR A to egress LSRs s, t, u, v, w, x, y, and z. Using a 292 single PCE model, LSR A may request the entire path of the tree and 293 this may be supplied by the PCE. Alternatively, the PCE that is 294 consulted by LSR A may only compute the first fragment of the tree 295 (for example from A to K, L, and M) and may rely on other PCEs to 296 compute the three smaller trees from K to t, u and v, from L to w and 297 x, and from M to s, y, and z. 299 The LSR consulted by A may simply return the first subtree and leave 300 LSRs K, L, and M to invoke PCEs in their turn in order to complete 301 the signaling. Alternatively, the first PCE may cooperate with other 302 PCEs to collect the paths for the later subtrees and return them 303 in a single computation response to PCE A. The mechanisms for both of 304 these approaches are described in the PCE architecture [RFC4655]. 306 t 307 / 308 / 309 n--u 310 / 311 / 312 e--f--h--K--o--v 313 / 314 / 315 A--b--c--d--g--i--L--p--w 316 \ \ 317 \ \ 318 j x 319 \ 320 \ 321 M--r--y 322 \ \ 323 \ \ 324 s z 326 Figure 1 : A P2MP Tree with Intermediate Computation Points 328 A further possibility is that LSRs at which the subtrees are stitched 329 together (K, L, and M in this example) are selected from a set of 330 potential such points using a cooperative PCE technique such as the 331 Backward Recursive Path Computation (BRPC) mechanism [RFC5441]. 332 Indeed, if the LSRs K, L, and M were ASBRs or Area Border Routers 333 (ABRs) the BRPC technique would be particularly applicable. 335 Note, however, that while these mechanisms are superficially 336 beneficial, it is far from obvious how the first LSR selects the 337 transit LSRs K, L, and M, nor how the leaf nodes are assigned to be 338 downstream of particular downstream nodes. The computation to 339 determine these questions may be no less intensive than the 340 determination of the full tree unless there is some known property of 341 the leaf node identifiers such as might be provided by address 342 aggregation. 344 4. Central Replication Points 346 A deployment model for P2MP LSPs is to use centralized, well-known 347 replication points. This choice may be made for administrative or 348 security reasons, or because of particular hardware capability 349 limitations within the network. Indeed, this deployment model can be 350 achieved using P2P LSPs between ingress and replication point, and 351 between replication point and each leaf so as to achieve a P2MP 352 service without the use of P2MP MPLS-TE. 354 The motivations for this type of deployment are beyond the scope of 355 this document, but it is appropriate to examine how PCE might be used 356 to support this model. 358 In Figure 2, a P2MP service is required from ingress LSR a to egress 359 LSRs m, n, o, and p. There are four replication-capable LSRs in the 360 network: D, E, J, and K. 362 When LSR a consults a PCE it could be given the full P2MP path from 363 LSR a to the leaves, but in this model, the PCE simply returns a P2P 364 path to the first replication point (in this case LSR D). LSR D will 365 consult a PCE in its turn and determine the P2P LSPs to egress LSRs 366 m and p, and the P2P LSP to the next replication point, LSR J. 367 Finally, LSR J will use a PCE to determine P2P LSPs to egresses n and 368 o. 370 f--i--m 371 / 372 / 373 a--b--c--D--g--J--n 374 \ \ 375 \ \ 376 E h K o 377 \ 378 \ 379 l--p 381 Figure 2 : Using Centralized Replication Points 383 In this model of operation it is quite likely that the PCE function 384 is located at the replication points which will be high-capacity 385 LSRs. One of the main features of the computation activity is the 386 selection of the replication points (for example, why is LSR D 387 selected in preference to LSR E, and why is LSR J chosen over LSR 388 K?). This selection may be made on solely on the basis of path 389 optimization as it would be for a P2MP computation, but may also be 390 influenced by policy issues (for example, LSR D may be able to give 391 better security to protect against rogue leaf attachment) or network 392 loading concerns (for example, LSR E may already be handling a very 393 large amount of traffic replication for other P2MP services). 395 5. Reoptimization and Modification 397 Once established, P2MP LSPs are more sensitive to modification than 398 their P2P counterparts. If an egress is removed from a P2P LSP, the 399 whole LSP is torn down. But egresses may be added to and removed from 400 active P2MP LSPs as receivers come and go. 402 The removal of an egress from a P2MP LSP does not require any new 403 path computation since the tree can be automatically pruned. 405 The addition of a new egress to a P2MP LSP can be handled as the 406 computation of an appropriate branch point and the determination of a 407 P2P path from the branch point to the new egress. This is a 408 relatively simple computation and can be achieved by reverse path 409 CSPF much as in the manner of some multicast IP routing protocols. 411 However, repeated addition to and removal from a P2MP LSP will almost 412 certainly leave it in a suboptimal state. The tree shape that was 413 optimal for the original set of destinations will be distorted by the 414 changes and will not be optimal for the new set of destinations. 416 Further, as resource availability changes in the network due to other 417 LSPs being released or network resources being brought online, the 418 path of the P2MP LSP may become sub-optimal. 420 Computing a new optimal path for the P2MP LSP is as simple as 421 computing any optimal P2MP path, but selecting a path that can be 422 applied within the network as a migration from the existing LSP may 423 be more complex. Additional constraints may be applied by the network 424 administrator so that only subsets of the egresses (or subtrees of 425 the P2MP tree) are optimized at any time. In these cases, the 426 computational load of reoptimization may be considerable, but 427 fortunately reoptimization computations may be performed as 428 background activities. Splitting the P2MP tree into subtrees as 429 described in Section 3 may further reduce the computation load and 430 may assist with administrative preferences for partial tree 431 reoptimization. 433 Network-wide reoptimization of multiple LSPs [RFC5557] can achieve 434 far greater improvements in optimality within overloaded networks 435 than can be achieved by reoptimizing LSPs sequentially. Such 436 computation would typically be performed offline and would usually 437 require a dedicated processor such as a PCE invoked by the NMS. 439 6. Repair 441 LSP repair is necessary when a network fault disrupts the ability of 442 the LSP to deliver data to an egress. For a P2MP LSP, a network fault 443 is (statistically) likely to only impact a small subset of the total 444 set of egresses. Repair activity, therefore, does not need to 445 recompute the path of the entire P2MP tree. Rather, it needs to 446 quickly find suitable new branches that can be grafted onto the 447 existing tree to reconnect the disconnected leaves. 449 In fact, immediately after a network failure there may be a very 450 large number of path computations required in order to restore 451 multiple P2P and P2MP LSPs. The PCEs will be heavily loaded, and it 452 is important that computation requests are restricted to only the 453 'essential'. 455 In this light it is useful to note that the simple repair 456 computations described in the first paragraph of this section may be 457 applied to achieve a first repair of the LSPs, while more 458 sophisticated reoptimization computations can be deferred until the 459 network is stable and the load on the PCEs has been reduced. Those 460 reoptimizations can be computed as described in Section 5. 462 7. Disjoint Paths 464 Disjoint paths are required for end-to-end protection services and 465 sometimes for load balancing. They may require to be fully disjoint 466 (except at the ingress and egress!), link disjoint (allowing common 467 nodes on the paths), or best-effort disjoint (allowing sharing of 468 links or nodes when no other path can be found). 470 It is possible to compute disjoint paths sequentially, but this can 471 lead to blocking problems where the second path cannot be placed. 472 Such issues are more readily avoided if the paths are computed in 473 parallel. 475 The computation of link disjoint P2P paths may be non-trivial and may 476 be the sort of task that an LSR offloads to a PCE because of its 477 complexity. The computation of disjoint P2MP paths is considerably 478 more difficult and is therefore a good candidate to be offloaded to a 479 PCE that has dedicated resources. In fact, it may well be the case 480 that not all P2MP-capable PCEs can handle disjoint path requests and 481 it may be necessary to select between PCEs based on their 482 capabilities. 484 8. Manageability Considerations 486 The use of PCE to compute P2MP paths has many of the same 487 manageability considerations as when it is used for P2P LSPs 488 [RFC5440]. There may be additional manageability implications for the 489 size of P2MP computation requests and the additional loading exerted 490 on the PCEs. 492 8.1. Control of Function and Policy 494 As already described, individual PCEs may choose to not be capable of 495 P2MP computation, and where this function is available, it may be 496 disabled by an operator, or may be automatically withdrawn when the 497 PCE becomes loaded or based on other policy considerations. 499 Further, a PCE may refuse any P2MP computation request or pass it on 500 to another PCE based on policy. 502 8.2. Information and Data Models 504 P2MP computation requests necessitate considerably more information 505 exchange between the LSR and the PCE than is required for P2P 506 computations. This will result in much larger data sets to be 507 controlled and modeled, and will impact the utility of any management 508 data models, such as MIB modules. Care needs to be taken in the 509 design of such data models, and the use of other management protocols 510 and data modelling structures, such as NETCONF / NETMOD [RFC4741] 511 could be considered. 513 8.3. Liveness Detection and Monitoring 515 PCE liveness detection and monitoring is unchanged from P2P 516 operation, but it should be noted that P2MP requests will take longer 517 to process than P2P requests meaning that the time between request 518 and response will be, on average, longer. This increases the chance 519 of a communications failure between request and response and means 520 that liveness detection is more important. 522 8.4. Verifying Correct Operation 524 Correct operation of any communication between LSRs and PCEs is 525 exactly as important as it is for P2P computations. 527 The correct operation of path computation algorithms implemented at 528 PCEs is out of scope, but LSRs that are concerned that PCE algorithms 529 might not be operating correctly may make identical requests to 530 separate PCEs and compare the responses. 532 8.5. Requirements on Other Protocols and Functional Components 534 As is clear from the PCE architecture, a communications protocol is 535 necessary to allow LSRs to send computation requests to PCEs, and for 536 PCEs to cooperate. Requirements for such a protocol to handle P2P 537 path computations are described in [RFC4657] and additional 538 requirements in support of P2MP computations are described in 539 [PCE-P2MP-REQ]. The PCE Communication Protocol (PCEP) is defined in 540 [RFC5440], but extensions will be necessary to support P2MP 541 computation requests. 543 As described in the body of this document, LSRs need to be able to 544 recognize which PCEs can perform P2MP computations. Capability 545 advertisement is already present in the PCE Discovery protocols 546 [RFC5088] and [RFC5089], and can also be exchanged in PCEP [RFC5440], 547 but extensions will be required to describe P2MP capabilities. 549 As also described in this document, the PCE needs to know the branch 550 capabilities of the LSRs and store this information in the TED. This 551 information can be distributed using the routing protocols as 552 described in [RFC5073]. 554 8.6. Impact on Network Operation 556 The use of a PCE to perform P2MP computations may have a beneficial 557 impact on network operation if it can offload processing from the 558 LSRs freeing them up to handle protocol operations. 560 Furthermore, the use of a PCE may enable more dynamic behavior in 561 P2MP LSPs (such as addition of new egresses, reoptimization, and 562 failure recovery) than is possible using more traditional management- 563 based planning techniques. 565 9. Security Considerations 567 The use of PCE to compute P2MP paths does not raise any additional 568 security issues beyond those that generally apply to the PCE 569 architecture. See [RFC4655] for a full discussion. 571 Note, however, that P2MP computation requests are more CPU-intensive 572 and also use more link bandwidth. Therefore if the PCE was attacked 573 by the injection of spurious path computation requests, it would be 574 more vulnerable through a smaller number of such requests. 576 Thus, the use of message integrity and authentication mechanisms 577 within the PCE protocol should be used to mitigate attacks from 578 devices that are not authorized to send requests to the PCE. It would 579 be possible to consider applying different authorization policies for 580 P2MP path computation requests compared to other requests. 582 10. IANA Considerations 584 This document makes no requests for IANA action. 586 11. Acknowledgments 588 The authors would like to thank Jerry Ash and Jean-Louis Le Roux for 589 their thoughtful comments. Lars Eggert, Dan Romascanu, and Tim Polk 590 provided useful comments during IESG review. 592 12. References 594 12.1. Normative Reference 596 [RFC4655] Farrel, A., Vasseur, J.P., and Ash, G., "A Path 597 Computation Element (PCE)-Based Architecture", 598 RFC 4655, August 2006. 600 12.2. Informative Reference 602 [RFC4461] S. Yasukawa, Editor, "Signaling Requirements for 603 Point-to-Multipoint Traffic Engineered MPLS LSPs", 604 RFC4461, April 2006. 606 [RFC4657] Ash, J., and Le Roux, J.L., "Path Computation Element 607 (PCE) Communication Protocol Generic Requirements", 608 RFC 4657, September 2006. 610 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 611 December 2006. 613 [RFC4834] Morin, T., "Requirements for Multicast in Layer 3 614 Provider-Provisioned Virtual Private Networks 615 (PPVPNs)", RFC 4834, April 2007. 617 [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 618 "Extensions to Resource Reservation Protocol - Traffic 619 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 620 Switched Paths (LSPs)", RFC 4875, May 2007. 622 [RFC5073] Vasseur, J.P, and Le Roux, J.L., Editors, "IGP Routing 623 Protocol Extensions for Discovery of Traffic 624 Engineering Node Capabilities", RFC 5073, December 625 2007. 627 [RFC5088] Le Roux, J.L., and Vasseur, J.P., Editors, "OSPF 628 Protocol Extensions for Path Computation Element (PCE) 629 Discovery", RFC 5088, January 2008. 631 [RFC5089] Le Roux, J.L., and Vasseur, J.P., Editors, "IS-IS 632 Protocol Extensions for Path Computation Element (PCE) 633 Discovery", RFC 5089, January 2008. 635 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and Ash, 636 J., "Policy-Enabled Path Computation Framework", 637 RFC 5394, December 2008. 639 [RFC5440] Vasseur, J.P, and Le Roux, J.L., Editors, "Path 640 Computation Element (PCE) Communication Protocol 641 (PCEP)", RFC 5440, March 2009. 643 [RFC5441] J.P. Vasseur, Editor, "A Backward-Recursive PCE-Based 644 Computation (BRPC) Procedure to Compute Shortest 645 Constrained Inter-Domain Traffic Engineering Label 646 Switched Paths", RFC 5441, April 2009. 648 [RFC5557] Lee, Y., Le Roux, JL., King, D., and Oki, E., "Path 649 Computation Element Communication Protocol (PCEP) 650 Requirements and Protocol Extensions in Support of 651 Global Concurrent Optimization", RFC 5557, July 2009. 653 [PCE-P2MP-REQ] Yasukawa, S., and Farrel, A., "PCC-PCE Communication 654 Requirements for Point to Multipoint Multiprotocol 655 Label Switching Traffic Engineering (MPLS-TE)", 656 draft-yasukawa-pce-p2mp-req, work in progress. 658 13. Authors' Addresses 660 Seisho Yasukawa 661 NTT Corporation 662 9-11, Midori-Cho 3-Chome 663 Musashino-Shi, Tokyo 180-8585, 664 Japan 665 Email: yasukawa.seisho@lab.ntt.co.jp 667 Adrian Farrel 668 Old Dog Consulting 669 Email: adrian@olddog.co.uk 671 14. Full Copyright Statement 673 Copyright (c) 2009 IETF Trust and the persons identified as the 674 document authors. All rights reserved. 676 This document is subject to BCP 78 and the IETF Trust's Legal 677 Provisions Relating to IETF Documents in effect on the date of 678 publication of this document (http://trustee.ietf.org/license-info). 679 Please review these documents carefully, as they describe your rights 680 and restrictions with respect to this document.