idnits 2.17.1 draft-ietf-pce-p2mp-app-01.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 ---------------------------------------------------------------------------- No issues found here. 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: February 13, 2009 Old Dog Consulting 6 Expires: August 13, 2009 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-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with 17 the 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 22 Internet-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 Congestion ............................................. 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 ................................................... 13 75 12.1. Normative Reference ........................................ 13 76 12.2. Informative Reference ...................................... 14 77 13. Authors' Addresses ........................................... 15 78 14. Intellectual Property Statement .............................. 15 79 15. Full Copyright Statement ..................................... 16 81 1. Introduction 83 The Path Computation Element (PCE) defined in [RFC4655] is an entity 84 that is capable of computing a network path or route based on a 85 network graph, and applying computational constraints. The intention 86 is that the PCE is used to compute the path of Traffic Engineered 87 Label Switched Paths (TE LSPs) within Multiprotocol Label Switching 88 (MPLS) and Generalized MPLS (GMPLS) networks. 90 [RFC4655] defines various deployment models that place PCEs 91 differently within the network. The PCEs may be collocated with the 92 Label Switching Routers (LSRs), may be part of the management system 93 that requests the LSPs to be established, or may be positioned as one 94 or more computation servers within the network. 96 Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are 97 documented in [RFC4461] and signaling protocol extensions for 98 setting up P2MP MPLS TE LSPs are defined in [RFC4875]. P2MP MPLS TE 99 networks are considered in support of various features including 100 layer 3 multicast VPNs [RFC4834], video distribution, etc. 102 Fundamental to the determination of the paths for P2MP LSPs within a 103 network is the selection of branch points. Not only is this selection 104 constrained by the network topology and available network resources, 105 but it is determined by the objective functions that may be applied 106 to path computation. For example, one standard objective is to 107 minimize the total cost of the tree (that is, to minimize the sum of 108 the costs of each link traversed by the tree) to produce what is 109 known as a Steiner Tree. Another common objective function requires 110 that the cost to reach each leaf of the P2MP tree is minimized. 112 The selection of branch points within the network is further 113 complicated by the fact that not all LSRs in the network are 114 necessarily capable of performing branching functions. This 115 information may be recorded in the Traffic Engineering Database (TED) 116 that the PCE uses to perform its computations, and may have been 117 distributed using extensions to the Interior Gateway Protocol (IGP) 118 operating within the network [RFC5073]. 120 Additionally, network policies may dictate specific branching 121 behavior. For example, it may be decided that for certain types of 122 LSP in certain types of network, it is important that no branch LSR 123 is responsible for handling more than a certain number of downstream 124 branches for any one LSP. This might arise because the replication 125 mechanism used at the LSRs is a round-robin copying process that 126 delays the data transmission on each downstream branch by the time 127 taken to replicate the data onto each previous downstream branch. 128 Alternatively, administrative policies may dictate that replication 129 should be concentrated on specific key replication nodes behaving 130 like IP multicast rendezvous points (perhaps to ensure appropriate 131 policing of receivers in the P2MP tree, or perhaps to make protection 132 and resiliency easier to implement). 134 Path computation for P2MP TE LSPs presents a significant challenge 135 because of the complexity of the computations described above. 136 Determining disjoint protection paths for P2MP TE LSPs can add 137 considerably to this complexity, while small modifications to a P2MP 138 tree (such as adding or removing just one leaf) can completely change 139 the optimal path. Reoptimization of a network containing multiple 140 P2MP TE LSPs requires considerable computational resources. All of 141 this means that an ingress LSR might not have sufficient processing 142 power to perform the necessary computations, and even if it does, the 143 act of path computation might interfere with the control and 144 management plane operation necessary to maintain existing LSPs. The 145 PCE architecture offers a way to offload such path computations from 146 LSRs. 148 2. Architectural Considerations 150 2.1. Offline Computation 152 Offline path computation is performed ahead of time, before the LSP 153 setup is requested. That means that it is requested by, or performed 154 as part of, a management application. This model can be seen in 155 Section 5.5 of [RFC4655]. 157 The offline model is particularly appropriate to long-lived LSPs 158 (such as those present in a transport network) or for planned 159 responses to network failures. In these scenarios, more planning is 160 normally a feature of LSP provisioning. 162 This model may also be used where the network operator wishes to 163 retain full manual control of the placement of LSPs, using the PCE 164 only as a computation tool to assist the operator, not as part of an 165 automated network. 167 Offline path computation may be applied as a background activity for 168 network reoptimization to determine whether and when the current LSP 169 placements are significantly sub-optimal. See Section 5 for further 170 discussions of reoptimization. 172 2.2. Online Computation 174 Online path computation is performed on-demand as LSRs in the network 175 determine that they need to know the paths to use for LSPs. Thus, 176 each computation is triggered by a request from an LSR. 178 As described in [RFC4655], the path computation function for online 179 computation may be collocated with the LSR that makes the request, or 180 may be present in a computation-capable PCE server within the 181 network. The PCE server may be another LSR in the network, a 182 dedicated server, or a functional component of an NMS. Furthermore, 183 the computation is not necessarily achieved by a single PCE operating 184 on its own, but may be the result of cooperation between several 185 PCEs. 187 The remainder of this document makes frequent reference to these 188 different online models in order to indicate which is more 189 appropriate in different P2MP scenarios. 191 2.2.1. LSR Loading 193 An important feature of P2MP path computation is the processing load 194 that it places on the network element that is determining the path. 195 Roughly speaking, the load to compute a least-cost-to-leaf tree is 196 the same as the cost to compute a single optimal path to each leaf in 197 turn. The load to compute a Steiner tree is approximately an order of 198 magnitude greater although there exist algorithms to approximate 199 Steiner trees in roughly the same order of magnitude of time as for a 200 least-cost-to-leaf tree. 202 Whereas many LSRs are capable of simple Constrained Shortest Path 203 First (CSPF) computations to determine a path for a single point-to- 204 point (P2P) LSP, they rapidly become swamped if called on to perform 205 multiple such computations such as when recovering from a network 206 failure. Thus, it is reasonable to expect that an LSR would struggle 207 to handle a P2MP path computation for a tree with many destinations. 209 The result of an LSR becoming overloaded by a P2MP path computation 210 may be two-fold. First, the LSR may be unable to provide timely 211 computations of paths for P2P LSPs: this may impact LSP setup times 212 for simple demand-based services, and could damage the LSR's ability 213 to recover services after network faults. Secondly, the LSR's 214 processing capabilities may be diverted from other important tasks 215 not the least of which is maintaining the control plane protocols 216 that are necessary to the support of existing LSPs and forwarding 217 state within the network. It is obviously critically important that 218 existing traffic should not be disrupted by the computation of a path 219 for a new LSP. 221 It also not reasonable to expect the ingress LSRs of P2MP LSRs to be 222 specially powerful and capable of P2MP computations. Although a 223 solution to the overloading problem would be to require that all LSRs 224 that form the ingresses to P2MP LSPs should be sufficiently 225 high-capacity to perform P2MP computations, this is not an acceptable 226 solution because in all other senses, the ingress to a P2MP LSP is 227 just a normal ingress LSR. 229 Thus, there is an obvious solution which is to off-load P2MP path 230 computations from LSRs to remotely located PCEs. Such PCE function 231 can be provided on dedicated or high-capacity network elements (such 232 as dedicated servers, or high-end routers that might be located as 233 Autonomous System Border Routers - ASBRs). 235 2.2.2. PCE Congestion 237 Since P2MP path computations are resource-intensive, it may be that 238 the introduction of P2MP LSPs into an established PCE network will 239 cause congestion at the PCEs. That is, the P2MP computations may 240 block other P2P computations and might even overload the PCE. 242 Several measures can be taken within the PCE architecture to 243 alleviate this situation as described in [RFC4655]. For example, path 244 computation requests can be assigned priorities by the LSRs that 245 issue them. Thus, the LSRs could assign lower priority to the P2MP 246 requests ensuring that P2P requests were serviced in preference. 247 Furthermore, the PCEs are able to apply local and network-wide policy 248 and this may dictate specific processing rules [RFC5394]. 250 But ultimately a network must possess sufficient path computation 251 resources for its needs and this is achieved within the PCE 252 architecture simply by increasing the number of PCEs. 254 Once there are sufficient PCEs available within the network, the LSRs 255 may choose between them, and may use congestion notification 256 information supplied by the PCEs to spot which PCEs are currently 257 over-loaded. Additionally, a PCE that is becoming over-loaded may 258 redistribute its queue of computation requests to other less-burdened 259 PCEs within the network using the PCE cooperation model described in 260 [RFC4655]. 262 2.2.3. PCE Capabilities 264 An LSR chooses between available PCEs to select the one most likely 265 to be able to perform the requested path computation. This selection 266 may be based on congestion notifications from the PCEs, but could 267 also consider other computational capabilities. 269 For example, it is quite likely that only a subset of the PCEs in the 270 network have the ability to perform P2MP computations since this 271 requires advanced functionality. Some of those PCEs might have the 272 ability to satisfy certain objective functions (for example, least 273 cost to destination), but lack support for other objective functions 274 (for example Steiner). Additionally, some PCEs might not be capable 275 of the more complex P2MP reoptimization functionality. 277 The PCE architecture allows an LSR to discover the capabilities of 278 the PCEs within the network at the same time as it discovers their 279 existence. Further and more detailed exchanges of PCE capabilities 280 can be made directly between the PCEs and the LSRs. 282 3. Fragmenting the P2MP Tree 284 A way to reduce the computational burden on a single PCE of computing 285 a large P2MP tree is to fragment or partition the tree. This may be 286 particularly obvious in a multi-domain network (such as multiple 287 routing areas), but is equally applicable in a single domain. 289 Consider the network topology in Figure 1. A P2MP LSP is required 290 from ingress LSR A to egress LSRs s, t, u, v, w, x, y, and z. Using a 291 single PCE model, LSR A may request the entire path of the tree and 292 this may be supplied by the PCE. Alternatively, the PCE that is 293 consulted by LSR A may only compute the first fragment of the tree 294 (for example from A to K, L, and M) and may rely on other PCEs to 295 compute the three smaller trees from K to t, u and v, from L to w and 296 x, and from M to s, y, and z. 298 The LSR consulted by A may simply return the first subtree and leave 299 LSRs K, L, and M to invoke PCEs in their turn in order to complete 300 the signaling. Alternatively, the first PCE may cooperate with other 301 PCEs to collect the paths for the later subtrees and return them 302 in a single computation response to PCE A. The mechanisms for both of 303 these approaches are described in the PCE architecture [RFC4655]. 305 t 306 / 307 / 308 n--u 309 / 310 / 311 e--f--h--K--o--v 312 / 313 / 314 A--b--c--d--g--i--L--p--w 315 \ \ 316 \ \ 317 j x 318 \ 319 \ 320 M--r--y 321 \ \ 322 \ \ 323 s z 325 Figure 1 : A P2MP Tree with Intermediate Computation Points 327 A further possibility is that LSRs at which the subtrees are stitched 328 together (K, L, and M in this example) are selected from a set of 329 potential such points using a cooperative PCE technique such as the 330 Backward Recursive Path Computation (BRPC) mechanism [BRPC]. Indeed, 331 if the LSRs K, L, and M were ASBRs or Area Border Routers (ABRs) the 332 BRPC technique would be particularly applicable. 334 Note, however, that while these mechanisms are superficially 335 beneficial, it is far from obvious how the first LSR selects the 336 transit LSRs K, L, and M, nor how the leaf nodes are assigned to be 337 downstream of particular downstream nodes. The computation to 338 determine these questions may be no less intensive than the 339 determination of the full tree unless there is some known property of 340 the leaf node identifiers such as might be provided by address 341 aggregation. 343 4. Central Replication Points 345 A deployment model for P2MP LSPs is to use centralized, well-known 346 replication points. This choice may be made for administrative or 347 security reasons, or because of particular hardware capability 348 limitations within the network. Indeed, this deployment model can be 349 achieved using P2P LSPs between ingress and replication point, and 350 between replication point and each leaf so as to achieve a P2MP 351 service without the use of P2MP MPLS-TE. 353 The motivations for this type of deployment are beyond the scope of 354 this document, but it is appropriate to examine how PCE might be used 355 to support this model. 357 In Figure 2, a P2MP service is required from ingress LSR a to egress 358 LSRs m, n, o, and p. There are four replication-capable LSRs in the 359 network: D, E, J, and K. 361 When LSR a consults a PCE it could be given the full P2MP path from 362 LSR a to the leaves, but in this model, the PCE simply returns a P2P 363 path to the first replication point (in this case LSR D). LSR D will 364 consult a PCE in its turn and determine the P2P LSPs to egress LSRs 365 m and p, and the P2P LSP to the next replication point, LSR J. 366 Finally, LSR J will use a PCE to determine P2P LSPs to egresses n and 367 o. 369 f--i--m 370 / 371 / 372 a--b--c--D--g--J--n 373 \ \ 374 \ \ 375 E h K o 376 \ 377 \ 378 l--p 380 Figure 2 : Using Centralized Replication Points 382 In this model of operation it is quite likely that the PCE function 383 is located at the replication points which will be high-capacity 384 LSRs. One of the main features of the computation activity is the 385 selection of the replication points (for example, why is LSR D 386 selected in preference to LSR E, and why is LSR J chosen over LSR 387 K?). This selection may be made on solely on the basis of path 388 optimization as it would be for a P2MP computation, but may also be 389 influenced by policy issues (for example, LSR D may be able to give 390 better security to protect against rogue leaf attachment) or network 391 loading concerns (for example, LSR E may already be handling a very 392 large amount of traffic replication for other P2MP services). 394 5. Reoptimization and Modification 396 Once established, P2MP LSPs are more sensitive to modification than 397 their P2P counterparts. If an egress is removed from a P2P LSP, the 398 whole LSP is torn down. But egresses may be added to and removed from 399 active P2MP LSPs as receivers come and go. 401 The removal of an egress from a P2MP LSP does not require any new 402 path computation since the tree can be automatically pruned. 404 The addition of a new egress to a P2MP LSP can be handled as the 405 computation of an appropriate branch point and the determination of a 406 P2P path from the branch point to the new egress. This is a 407 relatively simple computation and can be achieved by reverse path 408 CSPF much as in the manner of some multicast IP routing protocols. 410 However, repeated addition to and removal from a P2MP LSP will almost 411 certainly leave it in a suboptimal state. The tree shape that was 412 optimal for the original set of destinations will be distorted by the 413 changes and will not be optimal for the new set of destinations. 415 Further, as resource availability changes in the network due to other 416 LSPs being released or network resources being brought online, the 417 path of the P2MP LSP may become sub-optimal. 419 Computing a new optimal path for the P2MP LSP is as simple as 420 computing any optimal P2MP path, but selecting a path that can be 421 applied within the network as a migration from the existing LSP may 422 be more complex. Additional constraints may be applied by the network 423 administrator so that only subsets of the egresses (or subtrees of 424 the P2MP tree) are optimized at any time. In these cases, the 425 computational load of reoptimization may be considerable, but 426 fortunately reoptimization computations may be performed as 427 background activities. Splitting the P2MP tree into subtrees as 428 described in Section 3 may further reduce the computation load and 429 may assist with administrative preferences for partial tree 430 reoptimization. 432 Network-wide reoptimization of multiple LSPs [GCO] can achieve far 433 greater improvements in optimality within congested networks than can 434 be achieved by reoptimizing LSPs sequentially. Such computation would 435 typically be performed offline and would usually require a dedicated 436 processor such as a PCE invoked by the NMS. 438 6. Repair 440 LSP repair is necessary when a network fault disrupts the ability of 441 the LSP to deliver data to an egress. For a P2MP LSP, a network fault 442 is (statistically) likely to only impact a small subset of the total 443 set of egresses. Repair activity, therefore, does not need to 444 recompute the path of the entire P2MP tree. Rather, it needs to 445 quickly find suitable new branches that can be grafted onto the 446 existing tree to reconnect the disconnected leaves. 448 In fact, immediately after a network failure there may be a very 449 large number of path computations required in order to restore 450 multiple P2P and P2MP LSPs. The PCEs will be heavily loaded, and it 451 is important that computation requests are restricted to only the 452 'essential'. 454 In this light it is useful to note that the simple repair 455 computations described in the first paragraph of this section may be 456 applied to achieve a first repair of the LSPs, while more 457 sophisticated reoptimization computations can be deferred until the 458 network is stable and the load on the PCEs has been reduced. Those 459 reoptimizations can be computed as described in Section 5. 461 7. Disjoint Paths 463 Disjoint paths are required for end-to-end protection services and 464 sometimes for load balancing. They may require to be fully disjoint 465 (except at the ingress and egress!), link disjoint (allowing common 466 nodes on the paths), or best-effort disjoint (allowing sharing of 467 links or nodes when no other path can be found). 469 It is possible to compute disjoint paths sequentially, but this can 470 lead to blocking problems where the second path cannot be placed. 471 Such issues are more readily avoided if the paths are computed in 472 parallel. 474 The computation of link disjoint P2P paths may be non-trivial and may 475 be the sort of task that an LSR offloads to a PCE because of its 476 complexity. The computation of disjoint P2MP paths is considerably 477 more difficult and is therefore a good candidate to be offloaded to a 478 PCE that has dedicated resources. In fact, it may well be the case 479 that not all P2MP-capable PCEs can handle disjoint path requests and 480 it may be necessary to select between PCEs based on their 481 capabilities. 483 8. Manageability Considerations 485 The use of PCE to compute P2MP paths has many of the same 486 manageability considerations as when it is used for P2P LSPs. There 487 may be additional manageability implications for the size of P2MP 488 computation requests and the additional loading exerted on the PCEs. 490 8.1. Control of Function and Policy 492 As already described, individual PCEs may choose to not be capable of 493 P2MP computation, and where this function is available, it may be 494 disabled by an operator, or may be automatically withdrawn when the 495 PCE becomes loaded or based on other policy considerations. 497 Further, a PCE may refuse any P2MP computation request or pass it on 498 to another PCE based on policy. 500 8.2. Information and Data Models 502 P2MP computation requests necessitate considerably more information 503 exchange between the LSR and the PCE than is required for P2P 504 computations. This will result in much larger data sets to be 505 controlled and modeled and will impact the utility of any management 506 data models, such as MIB modules. 508 8.3. Liveness Detection and Monitoring 510 PCE liveness detection and monitoring is unchanged from P2P 511 operation, but it should be noted that P2MP requests will take longer 512 to process than P2P requests meaning that the time between request 513 and response will be, on average, longer. this increases the chance 514 of a communications failure between request and response and means 515 that liveness detection is more important. 517 8.4. Verifying Correct Operation 519 Correct operation of any communication between LSRs and PCEs is 520 exactly as important as it is for P2P computations. 522 The correct operation of path computation algorithms implemented at 523 PCEs is out of scope, but nervous LSRs may make identical requests 524 to separate PCEs and compare the responses. 526 8.5. Requirements on Other Protocols and Functional Components 528 As is clear from the PCE architecture, a communications protocol is 529 necessary to allow LSRs to send computation requests to PCEs, and for 530 PCEs to cooperate. Requirements for such a protocol to handle P2P 531 path computations are described in [RFC4657] and additional 532 requirements in support of P2MP computations are described in 533 [PCE-P2MP-REQ]. The PCE Communication Protocol (PCEP) is defined in 534 [PCEP], but extensions will be necessary to support P2MP computation 535 requests. 537 As described in the body of this document, LSRs need to be able to 538 recognize which PCEs can perform P2MP computations. Capability 539 advertisement is already present in the PCE Discovery protocols 540 [RFC5088] and [RFC5089], and can also be exchanged in PCEP [PCEP], 541 but extensions will be required to describe P2MP capabilities. 543 As also described in this document, the PCE needs to know the branch 544 capabilities of the LSRs and store this information in the TED. This 545 information can be distributed using the routing protocols as 546 described in [RFC5073]. 548 8.6. Impact on Network Operation 550 The use of a PCE to perform P2MP computations may have a beneficial 551 impact on network operation if it can offload processing from the 552 LSRs freeing them up to handle protocol operations. 554 Furthermore, the use of a PCE may enable more dynamic behavior in 555 P2MP LSPs (such as addition of new egresses, reoptimization, and 556 failure recovery) than is possible using more traditional management- 557 based planning techniques. 559 9. Security Considerations 561 The use of PCE to compute P2MP paths does not raise any additional 562 security issues beyond those that generally apply to the PCE 563 architecture. See [RFC4655] for a full discussion. 565 Note, however, that P2MP computation requests are more CPU-intensive 566 and also use more link bandwidth. Therefore if the PCE was attacked 567 by the injection of spurious path computation requests, it would be 568 more vulnerable through a smaller number of such requests. 570 It would be possible to consider applying different authorization 571 policies for P2MP path computation requests compared to other 572 requests. 574 10. IANA Considerations 576 This document makes no requests for IANA action. 578 11. Acknowledgments 580 The authors would like to thank Jerry Ash and Jean-Louis Le Roux for 581 their thoughtful comments. 583 12. References 585 12.1. Normative Reference 587 [RFC4655] Farrel, A., Vasseur, J.P., and Ash, G., "A Path 588 Computation Element (PCE)-Based Architecture", 589 RFC 4655, August 2006. 591 12.2. Informative Reference 593 [RFC4461] S. Yasukawa, Editor, "Signaling Requirements for 594 Point-to-Multipoint Traffic Engineered MPLS LSPs", 595 RFC4461, April 2006. 597 [RFC4657] Ash, J., and Le Roux, J.L., "Path Computation Element 598 (PCE) Communication Protocol Generic Requirements", 599 RFC 4657, September 2006. 601 [RFC4834] Morin, T., "Requirements for Multicast in Layer 3 602 Provider-Provisioned Virtual Private Networks 603 (PPVPNs)", RFC 4834, April 2007. 605 [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 606 "Extensions to Resource Reservation Protocol - Traffic 607 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 608 Switched Paths (LSPs)", RFC 4875, May 2007. 610 [RFC5073] Vasseur, J.P, and Le Roux, J.L., Editors, "IGP Routing 611 Protocol Extensions for Discovery of Traffic 612 Engineering Node Capabilities", RFC 5073, December 613 2007. 615 [RFC5088] Le Roux, J.L., and Vasseur, J.P., Editors, "OSPF 616 Protocol Extensions for Path Computation Element (PCE) 617 Discovery", RFC 5088, January 2008. 619 [RFC5089] Le Roux, J.L., and Vasseur, J.P., Editors, "IS-IS 620 Protocol Extensions for Path Computation Element (PCE) 621 Discovery", RFC 5089, January 2008. 623 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and Ash, 624 J., "Policy-Enabled Path Computation Framework", 625 RFC 5394, December 2008. 627 [BRPC] J.P. Vasseur, Editor, "A Backward Recursive PCE-based 628 Computation (BRPC) procedure to compute shortest 629 inter-domain Traffic Engineering Label Switched 630 Paths", draft-ietf-pce-brpc, work in progress. 632 [GCO] Lee, Y., Le Roux, JL., King, D., and Oki, E., "Path 633 Computation Element Communication Protocol (PCECP) 634 Requirements and Protocol Extensions In Support of 635 Global Concurrent Optimization", draft-ietf-pce- 636 global-concurrent-optimization, work in progress. 638 [PCE-P2MP-REQ] Yasukawa, S., and Farrel, A., "PCC-PCE Communication 639 Requirements for Point to Multipoint Multiprotocol 640 Label Switching Traffic Engineering (MPLS-TE)", 641 draft-yasukawa-pce-p2mp-req, work in progress. 643 [PCEP] Vasseur, J.P, and Le Roux, J.L., Editors, "Path 644 Computation Element (PCE) communication Protocol 645 (PCEP) - Version 1", draft-ietf-pce-pcep, work in 646 progress. 648 13. Authors' Addresses 650 Seisho Yasukawa 651 NTT Corporation 652 (R&D Strategy Department) 653 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 654 Phone: +81 3 5205 5341 655 Email: s.yasukawa@hco.ntt.co.jp 657 Adrian Farrel 658 Old Dog Consulting 659 Email: adrian@olddog.co.uk 661 14. Intellectual Property Statement 663 The IETF Trust takes no position regarding the validity or scope of 664 any Intellectual Property Rights or other rights that might be 665 claimed to pertain to the implementation or use of the technology 666 described in any IETF Document or the extent to which any license 667 under such rights might or might not be available; nor does it 668 represent that it has made any independent effort to identify any 669 such rights. 671 Copies of Intellectual Property disclosures made to the IETF 672 Secretariat and any assurances of licenses to be made available, or 673 the result of an attempt made to obtain a general license or 674 permission for the use of such proprietary rights by implementers or 675 users of this specification can be obtained from the IETF on-line IPR 676 repository at http://www.ietf.org/ipr 678 The IETF invites any interested party to bring to its attention any 679 copyrights, patents or patent applications, or other proprietary 680 rights that may cover technology that may be required to implement 681 any standard or specification contained in an IETF Document. Please 682 address the information to the IETF at ietf-ipr@ietf.org. 684 The definitive version of an IETF Document is that published by, or 685 under the auspices of, the IETF. Versions of IETF Documents that are 686 published by third parties, including those that are translated into 687 other languages, should not be considered to be definitive versions 688 of IETF Documents. The definitive version of these Legal Provisions 689 is that published by, or under the auspices of, the IETF. Versions of 690 these Legal Provisions that are published by third parties, including 691 those that are translated into other languages, should not be 692 considered to be definitive versions of these Legal Provisions. 694 For the avoidance of doubt, each Contributor to the IETF Standards 695 Process licenses each Contribution that he or she makes as part of 696 the IETF Standards Process to the IETF Trust pursuant to the 697 provisions of RFC 5378. No language to the contrary, or terms, 698 conditions or rights that differ from or are inconsistent with the 699 rights and licenses granted under RFC 5378, shall have any effect and 700 shall be null and void, whether published or posted by such 701 Contributor, or included with or in such Contribution. 703 15. Full Copyright Statement 705 Copyright (c) 2009 IETF Trust and the persons identified as the 706 document authors. All rights reserved. 708 This document is subject to BCP 78 and the IETF Trust's Legal 709 Provisions Relating to IETF Documents 710 (http://trustee.ietf.org/license-info) in effect on the date of 711 publication of this document. Please review these documents 712 carefully, as they describe your rights and restrictions with respect 713 to this document. 715 All IETF Documents and the information contained therein are provided 716 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 717 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 718 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 719 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 720 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 721 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 722 FOR A PARTICULAR PURPOSE.