idnits 2.17.1 draft-yasukawa-pce-p2mp-app-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 671. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 655. 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 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 (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Yasukawa 2 Internet Draft NTT 3 Category: Informational A. Farrel (Editor) 4 Created: February 15, 2008 Old Dog Consulting 5 Expires: August 15, 2008 7 Applicability of the Path Computation Element (PCE) to 8 Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS) 9 and Generalized MPLS (GMPLS) Traffic Engineering (TE) 11 draft-yasukawa-pce-p2mp-app-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 The Path Computation Element (PCE) provides path computation 39 functions in support of traffic engineering in Multiprotocol Label 40 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 42 Extensions to the MPLS and GMPLS signaling and routing protocols have 43 been made in support of point-to-multipoint (P2MP) Traffic Engineered 44 (TE) Label Switched Paths (LSPs). 46 This document examines the applicability of PCE to path computation 47 for P2MP TE LSPs in MPLS and GMPLS networks. It describes the 48 motivation for using a PCE to compute these paths, and examines which 49 of the PCE architectural models are appropriate. 51 1. Introduction 53 The Path Computation Element (PCE) defined in [RFC4655] is an entity 54 that is capable of computing a network path or route based on a 55 network graph, and applying computational constraints. The intention 56 is that the PCE is used to compute the path of Traffic Engineered 57 Label Switched Paths (TE LSPs) within Multiprotocol Label Switching 58 (MPLS) and Generalized MPLS (GMPLS) networks. 60 [RFC4655] defines various deployment models that place PCEs 61 differently within the network. The PCEs may be colocated with the 62 Label Switching Routers (LSRs), may be part of the management system 63 that requests the LSPs to be established, or may be positioned as one 64 or more computation servers within the network. 66 Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are 67 documented in [RFC4461] and signaling protocol extensions for 68 setting up P2MP MPLS TE LSPs are defined in [RFC4875]. P2MP MPLS TE 69 networks are considered in support of various features including 70 layer 3 multicast VPNs [RFC4834], video distribution, etc. 72 Fundamental to the determination of the paths for P2MP LSPs within a 73 network is the selection of branch points. Not only is this selection 74 constrainted by the network topology and available network resources, 75 but it is determined by the objective functions that may be applied 76 to path computation. For example, one standard objective is to 77 minimize the total cost of the tree (that is, to minimize the sum of 78 the costs of each link traversed by the tree) to produce what is 79 known as a Steiner Tree. Another common objective function requires 80 that the cost to reach each leaf of the P2MP tree is minimized. 82 The selection of branch points within the network is further 83 complicated by the fact that not all LSRs in the network are 84 necessarily capable of performing branching functions. This 85 information may be recorded in the Traffic Engineering Database (TED) 86 that the PCE uses to perform its computations, and may have been 87 distributed using extensions to the Interior Gateway Protocol (IGP) 88 operating within the network [RFC5073]. 90 Additionally, network policies may dictate specific branching 91 behavior. For example, it may be decided that for certain types of 92 LSP in certain types of network, it is important that no branch LSR 93 is responsible for handling more than a certain number of downstream 94 branches for any one LSP. This might arise because the replication 95 mechanism used at the LSRs is a round-robin copying process that 96 delays the data transmission on each downstream branch by the time 97 taken to replicate the data onto each previous downstream branch. 98 Alternatively, administrative policies may dictate that replication 99 should be concentrated on specific key replication nodes behaving 100 like IP mlticast rendezvous points (perhaps to ensure appropriate 101 policing of receivers in the P2MP tree, or perhaps to make protection 102 and resilliency easier to implement). 104 Path computation for P2MP TE LSPs presents a significant challenge 105 because of the complexity of the computations described above. 106 Determining disjoint protection paths for P2MP TE LSPs can add 107 considerably to this complexity, while small modifications to a P2MP 108 tree (such as adding or removing just one leaf) can completely change 109 the optimal path. Reoptimization of a network containing multiple 110 P2MP TE LSPs requires considerable computational resources. All of 111 this means that an ingress LSR might not have sufficient processing 112 power to perform the necessary computations, and even if it does, the 113 act of path computation might interfere with the control and 114 management plane operation necessary to maintain existing LSPs. The 115 PCE architecture offers a way to offload such path computations from 116 LSRs. 118 2. Architectural Considerations 120 2.1. Offline Computation 122 Offline path computation is performed ahead of time, before the LSP 123 setup is requested. That means that it is requested by, or performed 124 as part of, a management application. This model can be seen in 125 Section 5.5 of [RFC4655]. 127 The offline model is particularly appropriate to long-lived LSPs 128 (such as those present in a transport network) or for planned 129 responses to network failures. In these scenarios, more planning is 130 normally a feature of LSP provisioning. 132 This model may also be used where the network operator wishes to 133 retain full manual control of the placement of LSPs, using the PCE 134 only as a computation tool to assist the operator, not as part of an 135 automated network. 137 Offline path computation may be applied as a background activity for 138 network reoptimization to determine whether and when the current LSP 139 placements are significantly sub-optimal. See Section 5 for further 140 discussions of reoptimization. 142 2.2. Online Computation 144 Online path computation is performed on-demand as LSRs in the network 145 determine that they need to know the paths to use for LSPs. Thus, 146 each computation is triggered by a request from an LSR. 148 As described in [RFC4655], the path computation function for online 149 computation may be colocated with the LSR that makes the request, or 150 may be present in a computation-capable PCE server within the 151 network. The PCE server may be another LSR in the network, a 152 dedicated server, or a functional component of an NMS. Furthermore, 153 the computation is not necessarily achieved by a single PCE operating 154 on its own, but may be the result of cooperation between several 155 PCEs. 157 The remainder of this document makes frequent reference to these 158 different online models in order to indicate which is more 159 appropriate in different P2MP scenarios. 161 2.2.1. LSR Loading 163 An important feature of P2MP path computation is the processing load 164 that it places on the network element that is determining the path. 165 Roughly speaking, the load to compute a least-cost-to-leaf tree is 166 the same as the cost to compute a single optimal path to each leaf in 167 turn. The load to compute a Steiner tree is approximately an order of 168 magnitude greater although there exist algorithms to approximate 169 Steiner trees in roughly the same order of magnitude of time as for a 170 least-cost-to-leaf tree. 172 Whereas many LSRs are capable of simple Constrained Shortest Path 173 First (CSPF) computations to determine a path for a single point-to- 174 point (P2P) LSP, they rapidly become swamped if called on to perform 175 multiple such computations such as when recovering from a network 176 failure. Thus, it is reasonable to expect that an LSR would struggle 177 to handle a P2MP path computation for a tree with many destinations. 179 The result of an LSR becoming overloaded by a P2MP path computation 180 may be two-fold. First, the LSR may be unable to provide timely 181 computations of paths for P2P LSPs: this may impact LSP setup times 182 for simple demand-based services, and could damage the LSR's ability 183 to recover services after network faults. Secondly, the LSR's 184 processing capabilities may be diverted from other important tasks 185 not the least of which is maintaining the control plane protocols 186 that are necessary to the support of existing LSPs and forwarding 187 state within the network. It is obviously critically important that 188 existing traffic should not be disrupted by the computation of a path 189 for a new LSP. 191 It also not reasonable to expect the ingress LSRs of P2MP LSRs to be 192 specially powerful and capable of P2MP computations. Although a 193 solution to the overloading problem would be to require that all LSRs 194 that form the ingresses to P2MP LSPs should be sufficiently 195 high-capacity to perform P2MP computations, this is not an acceptable 196 solution because in all other senses, the ingress to a P2MP LSP is 197 just a normal ingress LSR. 199 Thus, there is an obvious solution which is to off-load P2MP path 200 computations from LSRs to remotely located PCEs. Such PCE function 201 can be provided on dedicated or high-capacity network elements (such 202 as dedicated servers, or high-end routers that might be located as 203 Autonomous System Border Routers - ASBRs). 205 2.2.2. PCE Congestion 207 Since P2MP path computations are resource-intensive, it may be that 208 the introduction of P2MP LSPs into an established PCE network will 209 cause congestion at the PCEs. That is, the P2MP computations may 210 block other P2P computations and might even overload the PCE. 212 Several measures can be taken within the PCE architecture to 213 alleviate this situation as described in [RFC4655]. For example, path 214 computation requests can be assigned priorities by the LSRs that 215 issue them. Thus, the LSRs could assign lower priority to the P2MP 216 requests ensuring that P2P requests were serviced in preference. 217 Furthermore, the PCEs are able to apply local and network-wide policy 218 and this may dictate specific processing rules [PCE-POLICY]. 220 But ultimately a network must possess sufficient path computation 221 resources for its needs and this is achieved within the PCE 222 architecture simply by increasing the number of PCEs. 224 Once there are sufficient PCEs available within the network, the LSRs 225 may choose between them, and may use congestion notification 226 information supplied by the PCEs to spot which PCEs are currently 227 over-loaded. Additionally, a PCE that is becoming over-loaded may 228 redistribute its queue of computation requests to other less-burdened 229 PCEs within the network using the PCE cooperation model described in 230 [RFC4655]. 232 2.2.3. PCE Capabilities 234 An LSR chooses between available PCEs to select the one most likely 235 to be able to perform the requested path computation. This selection 236 may be based on congestion notifications from the PCEs, but could 237 also consider other computational capabilities. 239 For example, it is quite likely that only a subset of the PCEs in the 240 network have the ability to perform P2MP computations since this 241 requires advanced functionality. Some of those PCEs might have the 242 ability to satisfy certain objective functions (for example, least 243 cost to destination), but lack support for other objective functions 244 (for example Steiner). Additionally, some PCEs might not be capable 245 of the more complex P2MP reoptimization functionality. 247 The PCE architecture allows an LSR to discover the capabilities of 248 the PCEs within the network at the same time as it discovers their 249 existence. Further and more detailed exchanges of PCE capabilities 250 can be made directly between the PCEs and the LSRs. 252 3. Fragmenting the P2MP Tree 254 A way to reduce the computational burden on a single PCE of computing 255 a large P2MP tree is to fragment or partition the tree. This may be 256 particularly obvious in a multi-domain network (such as multiple 257 routing areas), but is equally applicable in a single domain. 259 Consider the network topology in Figure 1. A P2MP LSP is required 260 from ingress LSR A to exgress LSRs s, t, u, v, w, x, y, and z. Using 261 a single PCE model, LSR A may request the entire path of the tree and 262 this may be supplied by the PCE. Alternatively, the PCE that is 263 consulted by LSR A may only compute the first fragment of the tree 264 (for example from A to K, L, and M) and may rely on other PCEs to 265 compute the three smaller trees from K to t, u and v, from L to w and 266 x, and from M to s, y, and z. 268 The LSR consulted by A may simply return the first subtree and leave 269 LSRs K, L, and M to invoke PCEs in their turn in order to complete 270 the signaling. Alternatively, the first PCE may cooperate with other 271 PCEs to collect the paths for the later subtrees and return them 272 in a single computaiton response to PCE A. The mechanisms for both of 273 these approaches are described in the PCE architecture [RFC4655]. 275 t 276 / 277 / 278 n--u 279 / 280 / 281 e--f--h--K--o--v 282 / 283 / 284 A--b--c--d--g--i--L--p--w 285 \ \ 286 \ \ 287 j x 288 \ 289 \ 290 M--r--y 291 \ \ 292 \ \ 293 s z 295 Figure 1 : A P2MP Tree with Intermediate Computation Points 297 A futher possibility is that LSRs at which the subtrees are stitched 298 together (K, L, and M in this example) are selected from a set of 299 potential such points using a cooperative PCE technique such as the 300 Backward Recursive Path Computation (BRPC) mechanism [BRPC]. Indeed, 301 if the LSRs K, L, and M were ASBRs or Area Border Routers (ABRs) the 302 BRPC technique would be particularly applicable. 304 Note, however, that while these mechanisms are superficially 305 beneficial, it is far from obvious how the first LSR selects the 306 transit LSRs K, L, and M, nor how the leaf nodes are assigned to be 307 downstream of particular downstream nodes. The computation to 308 determine these questions may be no less intensive than the 309 determination of the full tree unless there is some known property of 310 the leaf node identifiers such as might be provided by address 311 aggregation. 313 4. Central Replication Points 315 A deployment model for P2MP LSPs is to use centralized, well-known 316 replication points. This choice may be made for administrative or 317 security reasons, or because of particular hardware capability 318 limitations within the network. Indeed, this deployment model can be 319 achieved using P2P LSPs between ingress and replication point, and 320 between replication point and each leaf so as to achieve a P2MP 321 service without the use of P2MP MPLS-TE. 323 The motivations for this type of deployment are beyond the sope of 324 this document, but it is appropriate to examine how PCE might be used 325 to support this model. 327 In Figure 2, a P2MP service is required from ingress LSR a to egress 328 LSRs m, n, o, and p. There are four replication-capable LSRs in the 329 network: D, E, J, and K. 331 When LSR a consults a PCE it could be given the full P2MP path from 332 LSR a to the leaves, but in this model, the PCE simply returns a P2P 333 path to the first replication point (in this case LSR D). LSR D will 334 consult a PCE in its turn and determine the P2P LSPs to egress LSRs 335 m and p, and the P2P LSP to the next replication point, LSR J. 336 Finally, LSR J will use a PCE to determine P2P LSPs to egresses n and 337 o. 339 f--i--m 340 / 341 / 342 a--b--c--D--g--J--n 343 \ \ 344 \ \ 345 E h K o 346 \ 347 \ 348 l--p 350 Figure 2 : Using Centralised Replication Points 352 In this model of operation it is quite likely that the PCE function 353 is located at the replication points which will be high-capacity 354 LSRs. One of the main features of the computation activity is the 355 selection of the replicaiton points (for example, why is LSR D 356 selected in preference to LSR E, and why is LSR J chosen over LSR 357 K?). This selection may be made on solely on the basis of path 358 optimization as it would be for a P2MP computation, but may also be 359 influenced by policy issues (for example, LSR D may be able to give 360 better security to protect against rogue leaf attachment) or network 361 loading concerns (for example, LSR E may already be handling a very 362 large amount of traffic replication for other P2MP services). 364 5. Reoptimization and Modification 366 Once established, P2MP LSPs are more sensitive to modification than 367 their P2P counterparts. If an egress is removed from a P2P LSP, the 368 whole LSP is torn down. But egresses may be added to and removed from 369 active P2MP LSPs as receivers come and go. 371 The removal of an egress from a P2MP LSP does not require any new 372 path computation since the tree can be automatically pruned. 374 The addition of a new egress to a P2MP LSP can be handled as the 375 computation of an appropriate branch point and the determination of a 376 P2P path from the branch point to the new egress. This is a 377 relatively simple computation and can be achieved by reverse path 378 CSPF much as in the manner of some multicast IP routing protocols. 380 However, repeated addition to and removal from a P2MP LSP will almost 381 certainly leave it in a suboptimal state. The tree shape that was 382 optimal for the original set of destinations will be distorted by the 383 changes and will not be optimal for the new set of destinations. 385 Further, as resource availability changes in the network due to other 386 LSPs being released or network resources being brough online, the 387 path of the P2MP LSP may become sub-optimal. 389 Computing a new optimal path for the P2MP LSP is as simple as 390 computing any optimal P2MP path, but selecting a path that can be 391 applied within the network as a migration from the existing LSP may 392 be more complex. Additional constraints may be applied by the network 393 administrator so that only subsets of the egresses (or subtrees of 394 the P2MP tree) are optimized at any time. In these cases, the 395 computational load of reoptimization may be considerable, but 396 fortunately reoptimization computations may be performed as 397 background activities. Splitting the P2MP tree into subtrees as 398 described in Section 3 may further reduce the computation load and 399 may assist with administrative preferences for partial tree 400 reoptimization. 402 Network-wide reoptimization of multiple LSPs [GCO] can achieve far 403 greater improvements in optimality within congested networks than can 404 be achieved by reoptimizing LSPs sequentially. Such computation would 405 typically be performed offline and would usually require a dedicated 406 processor such as a PCE invoked by the NMS. 408 6. Repair 410 LSP repair is necessary when a network fault disrupts the ability of 411 the LSP to deliver data to an egress. For a P2MP LSP, a network fault 412 is (statistically) likely to only impact a small subset of the total 413 set of egresses. Repair activity, therefore, does not need to 414 recompute the path of the entire P2MP tree. Rather, it needs to 415 quickly find suitable new branches that can be grafted onto the 416 existing tree to reconnect the diconnected leaves. 418 In fact, immediately after a network failure there may be a very 419 large number of path computations required in order to restore 420 multiple P2P and P2MP LSPs. The PCEs will be heavily loaded, and it 421 is important that computation requests are restricted to only the 422 'essential'. 424 In this light it is useful to note that the simple repair 425 computations described in the first paragraph of this section may be 426 applied to achieve a first repair of the LSPs, while more 427 sophisticated reoptimization computations can be deferred until the 428 network is stable and the load on the PCEs has been reduced. Those 429 reoptimizations can be computed as described in Section 5. 431 7. Disjoint Paths 433 Disjoint paths are required for end-to-end protection services and 434 sometimes for load balancing. They may require to be fully disjoint 435 (except at the ingress and egress!), link disjoint (allowing common 436 nodes on the paths), or best-effort disjoint (allowing sharing of 437 links or nodes when no other path can be found). 439 It is possible to compute disjoint paths sequentially, but this can 440 lead to blocking problems where the second path cannot be placed. 441 Such issues are more readily avoided if the paths are computed in 442 parallel. 444 The computation of link disjoint P2P paths may be non-trivial and may 445 be the sort of task that an LSR offloads to a PCE because of its 446 complexity. The computation of disjoint P2MP paths is considerably 447 more difficult and is therefore a good candidate to be offloaded to a 448 PCE that has dedicated resources. In fact, it may well be the case 449 that not all P2MP-capable PCEs can handle disjoint path requests and 450 it may be necessary to select between PCEs based on their 451 capabilities. 453 8. Manageability Considerations 455 The use of PCE to compute P2MP paths has many of the same 456 manageability considerations as when it is used for P2P LSPs. There 457 may be additional manageability implications for the size of P2MP 458 computation requests and the additional loading exerted on the PCEs. 460 8.1. Control of Function and Policy 462 As already described, individual PCEs may choose to not be capable of 463 P2MP computation, and where this function is available, it may be 464 disabled by an operator, or may be automatically withdrawn when the 465 PCE becomes loaded or based on other policy considerations. 467 Further, a PCE may refuse any P2MP computation request or pass it on 468 to another PCE based on policy. 470 8.2. Information and Data Models 472 P2MP computation requests necessitate considerably more information 473 exchange between the LSR and the PCE than is required for P2P 474 computations. This will result in much larger data sets to be 475 controlled and modeled and will impact the utility of any management 476 data models, such as MIB modules. 478 8.3. Liveness Detection and Monitoring 480 PCE liveness detection and monitoring is unchanged from P2P 481 operation, but it should be noted that P2MP requests will take longer 482 to process than P2P requests meaning that the time between request 483 and response will be, on average, longer. this increases the chance 484 of a communications failure between request and response and means 485 that liveness detection is more important. 487 8.4. Verifying Correct Operation 489 Correct operation of any communication between LSRs and PCEs is 490 exactly as important as it is for P2P computations. 492 The correct operation of path computation algorithms implemented at 493 PCEs is out of scope, but nervous LSRs may make identical requests 494 to separate PCEs and compare the responses. 496 8.5. Requirements on Other Protocols and Functional Components 498 As is clear from the PCE architecture, a communications protocol is 499 necessary to allow LSRs to send computation requests to PCEs, and for 500 PCEs to cooperate. Requirements for such a protocol to handle P2P 501 path computations are described in [RFC4657] and additional 502 requirements in support of P2MP computations are described in 504 [PCE-P2MP-REQ]. The PCE Communicaiton Protocol (PCEP) is defined in 505 [PCEP], but extensions will be necessary to support P2MP computation 506 requests. 508 As described in the body of this document, LSRs need to be able to 509 recognise which PCEs can perform P2MP computations. Capability 510 advertisement is already present in the PCE Discovery protocols 511 [RFC5088] and [RFC5089], and can also be exchanged in PCEP [PCEP], 512 but extensions will be required to describe P2MP capablities. 514 As also described in this document, the PCE needs to know the branch 515 capabilities of the LSRs and store this information in the TED. This 516 information can be distributed using the routing protocols as 517 described in [RFC5073]. 519 8.6. Impact on Network Operation 521 The use of a PCE to perform P2MP computations may have a beneficial 522 impact on network operation if it can offload processing from the 523 LSRs freeing them up to handle protocol operations. 525 Furthermore, the use of a PCE may enable more dynamic behavior in 526 P2MP LSPs (such as addition of new egresses, reoptimization, and 527 failure recovery) than is possible using more traditional management- 528 based planning techniques. 530 9. Security Considerations 532 The use of PCE to compute P2MP paths does not raise any additional 533 security issues beyond those that generally apply to the PCE 534 architecture. See [RFC4655] for a full discussion. 536 Note, however, that P2MP computation requests are more CPU-intensive 537 and also use more link bandwidth. Therefore if the PCE was attacked 538 by the injection of spurious path computation requests, it would be 539 more vulnerable through a smaller number of such requests. 541 It would be possible to consider applying different authorization 542 policies for P2MP path computation requests compared to other 543 requests. 545 10. IANA Considerations 547 This document makes no requests for IANA action. 549 11. Acknowledgments 551 The authors would like to thank Jerry Ash and Jean-Louis Le Roux for 552 their thoughtful comments. 554 12. References 556 12.1. Normative Reference 558 [RFC4655] Farrel, A., Vasseur, J.P., and Ash, G., "A Path 559 Computation Element (PCE)-Based Architecture", 560 RFC 4655, August 2006. 562 12.2. Informative Reference 564 [RFC4461] S. Yasukawa, Editor, "Signaling Requirements for 565 Point-to-Multipoint Traffic Engineered MPLS LSPs", 566 RFC4461, April 2006. 568 [RFC4657] Ash, J., and Le Roux, J.L., "Path Computation Element 569 (PCE) Communication Protocol Generic Requirements", 570 RFC 4657, September 2006. 572 [RFC4834] Morin, T., "Requirements for Multicast in Layer 3 573 Provider-Provisioned Virtual Private Networks 574 (PPVPNs)", RFC 4834, April 2007. 576 [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 577 "Extensions to Resource Reservation Protocol - Traffic 578 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 579 Switched Paths (LSPs)", RFC 4875, May 2007. 581 [RFC5073] Vasseur, J.P, and Le Roux, J.L., Editors, "IGP Routing 582 Protocol Extensions for Discovery of Traffic 583 Engineering Node Capabilities", RFC 5073, December 584 2007. 586 [RFC5088] Le Roux, J.L., and Vasseur, J.P., Editors, "OSPF 587 Protocol Extensions for Path Computation Element (PCE) 588 Discovery", RFC 5088, January 2008. 590 [RFC5089] Le Roux, J.L., and Vasseur, J.P., Editors, "IS-IS 591 Protocol Extensions for Path Computation Element (PCE) 592 Discovery", RFC 5089, January 2008. 594 [BRPC] J.P. Vasseur, Editor, "A Backward Recursive PCE-based 595 Computation (BRPC) procedure to compute shortest 596 inter-domain Traffic Engineering Label Switched 597 Paths", draft-ietf-pce-brpc, work in progress. 599 [GCO] Lee, Y., Le Roux, JL., King, D., and Oki, E., "Path 600 Computation Element Communication Protocol (PCECP) 601 Requirements and Protocol Extensions In Support of 602 Global Concurrent Optimization", draft-ietf-pce- 603 global-concurrent-optimization, work in progress. 605 [PCE-P2MP-REQ] Yasukawa, S., and Farrel, A., "PCC-PCE Communication 606 Requirements for Point to Multipoint Multiprotocol 607 Label Switching Traffic Engineering (MPLS-TE)", 608 draft-yasukawa-pce-p2mp-req, work in progress. 610 [PCE-POLICY] Bryskin, I., Papadimitriou, D., and Berger, L., 611 "Policy-Enabled Path Computation Framework", 612 draft-ietf-pce-policy-enabled-path-comp, work in 613 progress. 615 [PCEP] Vasseur, J.P, and Le Roux, J.L., Editors, "Path 616 Computation Element (PCE) communication Protocol 617 (PCEP) - Version 1", draft-ietf-pce-pcep, work in 618 progress. 620 13. Authors' Addresses 622 Seisho Yasukawa 623 NTT Corporation 624 (R&D Strategy Department) 625 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 626 Phone: +81 3 5205 5341 627 Email: s.yasukawa@hco.ntt.co.jp 629 Adrian Farrel 630 Old Dog Consulting 631 Email: adrian@olddog.co.uk 633 14. Intellectual Property Statement 635 The IETF takes no position regarding the validity or scope of any 636 Intellectual Property Rights or other rights that might be claimed to 637 pertain to the implementation or use of the technology described in 638 this document or the extent to which any license under such rights 639 might or might not be available; nor does it represent that it has 640 made any independent effort to identify any such rights. Information 641 on the procedures with respect to rights in RFC documents can be 642 found in BCP 78 and BCP 79. 644 Copies of IPR disclosures made to the IETF Secretariat and any 645 assurances of licenses to be made available, or the result of an 646 attempt made to obtain a general license or permission for the use of 647 such proprietary rights by implementers or users of this 648 specification can be obtained from the IETF on-line IPR repository at 649 http://www.ietf.org/ipr. 651 The IETF invites any interested party to bring to its attention any 652 copyrights, patents or patent applications, or other proprietary 653 rights that may cover technology that may be required to implement 654 this standard. Please address the information to the IETF at ietf- 655 ipr@ietf.org. 657 15. Full Copyright Statement 659 Copyright (C) The IETF Trust (2008). 661 This document is subject to the rights, licenses and restrictions 662 contained in BCP 78, and except as set forth therein, the authors 663 retain all their rights. 665 This document and the information contained herein are provided on an 666 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 667 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 668 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 669 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 670 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 671 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.