idnits 2.17.1 draft-ietf-pce-p2mp-req-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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 4 Created: January 29, 2010 Old Dog Consulting 5 Expires: July 29, 2010 7 PCC-PCE Communication Requirements for Point to Multipoint 8 Multiprotocol Label Switching Traffic Engineering (MPLS-TE) 10 draft-ietf-pce-p2mp-req-05.txt 12 Abstract 14 The Path Computation Element (PCE) provides path computation 15 functions in support of traffic engineering in Multi-Protocol Label 16 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 18 Extensions to the MPLS and GMPLS signaling and routing protocols have 19 been made in support of point-to-multipoint (P2MP) Traffic Engineered 20 (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is 21 already established, and since P2MP TE LSP routes are sometimes 22 complex to compute, it is likely that PCE will be used for P2MP LSPs. 24 Generic requirements for a communication protocol between Path 25 Computation Clients (PCCs) and PCEs are presented in "Path 26 Computation Element (PCE) Communication Protocol Generic 27 Requirements". This document complements the generic requirements and 28 presents a detailed set of PCC-PCE communication protocol 29 requirements for point-to-multipoint MPLS/GMPLS traffic engineering. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt. 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Conventions used in this document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [RFC2119]. 72 Although this document is not a protocol specification, this 73 convention is adopted for clarity of description of requirements. 75 1. Introduction 77 The Path Computation Element (PCE) defined in [RFC4655] is an entity 78 that is capable of computing a network path or route based on a 79 network graph, and applying computational constraints. The intention 80 is that the PCE is used to compute the path of Traffic Engineered 81 Label Switched Paths (TE LSPs) within Multiprotocol Label Switching 82 (MPLS) and Generalized MPLS (GMPLS) networks. 84 Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are 85 documented in [RFC4461] and signaling protocol extensions for 86 setting up P2MP MPLS TE LSPs are defined in [RFC4875]. P2MP MPLS TE 87 networks are considered in support of various features including 88 layer 3 multicast virtual private networks [RFC4834]. 90 Path computation for P2MP TE LSPs presents a significant challenge, 91 and network optimization of multiple P2MP TE LSPs requires 92 considerable computational resources. PCE offers a way to offload 93 such path computations from Label Switching Routers (LSRs). 95 The applicability of the PCE-based path computation architecture to 96 P2MP MPLS TE is described in a companion document [RFC5671]. No 97 further attempt is made to justify the use of PCE for P2MP MPLS TE 98 within this document. 100 This document presents a set of PCC-PCE communication protocol 101 (PCECP) requirements for P2MP MPLS traffic engineering. It 102 supplements the generic requirements documented in [RFC4657]. 104 2. PCC-PCE Communication Requirements for P2MP MPLS Traffic Engineering 106 This section sets out additional requirements not covered in 107 [RFC4657] specific to P2MP MPLS TE. 109 2.1. PCC-PCE Communication 111 The PCC-PCE communication protocol MUST allow requests and replies 112 for the computation of paths for P2MP LSPs. 114 This requires no additional messages, but requires the addition of 115 the parameters described in the following sections to the existing 116 PCC-PCE communication protocol messages. 118 2.1.1. Indication of P2MP Path Computation Request 120 R1: Although the presence of certain parameters (such as a list of 121 more than one destination) MAY be used by a protocol 122 specification to allow an implementation to infer that a path 123 computation request is for a P2MP LSP, an explicit parameter 124 SHOULD be placed in a conspicuous place within a Path 125 Computation Request message to allow a receiving PCE to easily 126 identify that the request is for a P2MP path. 128 2.1.2. Indication of P2MP Objective Functions 130 R2: [RFC4657] includes the requirement to be able to specify the 131 objective functions to be applied by a PCE during path 132 computation. 134 This document makes no change to that requirement, but it should 135 be noted that new and different objective functions will be used 136 for P2MP computation. Definitions for core objective functions 137 can be found in [RFC5541] together with usage procedures. New 138 objective functions for use with P2MP path computations will 139 need to be defined and allocated codepoints in a separate 140 document. 142 2.1.3. Non-Support of P2MP Path Computation 144 R3: PCEs are not required to support P2MP path computation. 145 Therefore, it MUST be possible for a PCE to reject a P2MP Path 146 Computation Request message with a reason code that indicates no 147 support for P2MP path computation. 149 2.1.4. Non-Support by Back-Level PCE Implementations 151 It is possible that initial PCE implementations will be developed 152 without support for P2MP path computation and without the ability to 153 recognize the explicit parameter described in section 2.1.1. Such 154 legacy implementations will not be able to make use of the new 155 reason code described in Section 2.1.3. 157 R4: Therefore, at least one parameter required for inclusion in a 158 P2MP Path Computation Request message MUST be defined in such a 159 way as to cause automatic rejection as unprocessable or 160 unrecognized by a back-level PCE implementation without 161 requiring any changes to that PCE. It is RECOMMENDED that the 162 parameter that causes this result is the parameter described in 163 Section 2.1.1. 165 2.1.5. Specification of Destinations 167 R5: Since P2MP LSPs have more than one destination, it MUST be 168 possible for a single Path Computation Request to list multiple 169 destinations. 171 2.1.6. Indication of P2MP Paths 173 R6: The Path Computation Response MUST be able to carry the path of 174 a P2MP LSP. 176 P2MP paths can be expressed as a compressed series of routes as 177 described in [RFC4875]. The Path Computation Response MUST be able to 178 carry the P2MP path as either a compressed path (but not necessarily 179 using the identical encoding as described in [RFC4875]), or as a non- 180 compressed path comprising a series of source-to-leaf point-to-point 181 (P2P) paths (known as S2L sub-paths). 183 R7: By default, the path returned by the PCE SHOULD use the 184 compressed format. 186 The request from the PCC MAY allow the PCC to express a 187 preference for receiving a compressed or non-compressed P2MP 188 path in the response. 190 2.1.7. Multi-Message Requests and Responses 192 R8: A single P2MP LSP may have very many destinations, and the 193 computed path (tree) may be very extensive. In these cases it is 194 possible that the entire Path Computation Request or Response 195 cannot fit within one PCE message. Therefore, it MUST be 196 possible for a single request or response to be conveyed by a 197 sequence of PCE messages. 199 Note that there is a requirement in [RFC4657] for reliable and 200 in-order message delivery, so it is assumed that components of the 201 sequence will be delivered in order and without missing components. 203 2.1.8. Non-Specification of Per-Destination Constraints and Parameters 205 [RFC4875] requires that all branches of a single P2MP LSP have the 206 same characteristics, and achieves this by not allowing the signaling 207 parameters to be varied for different branches of the same P2MP LSP. 209 R9: It MUST NOT be possible to set different constraints, traffic 210 parameters, or quality of service requirements for different 211 destinations of a P2MP LSP within a single computation request. 213 2.1.9. Path Modification and Path Diversity 215 R10: No changes are made to the requirement to support path 216 modification and path diversity as described in [RFC4657]. Note, 217 however, that a consequence of this requirement is that it MUST 218 be possible to supply an existing path on a Path Computation 219 Request. This requirement is unchanged from [RFC4657], but it is 220 a new requirement that such paths MUST be able to be P2MP paths. 221 The PCC MUST be able to supply these paths as compressed paths 222 or as a non-compressed paths (see Section 2.1.6) according to 223 the preference of the PCC. 225 2.1.10. Reoptimization of P2MP TE LSPs 227 R11: Reoptimization MUST be supported for P2MP TE LSPs as described 228 for P2P LSPs in [RFC4657]. To support this, the existing path 229 MUST be supplied as described in Section 2.1.9. 231 Because P2MP LSPs are more complex it is often the case that 232 small optimization improvements can be made after changes in 233 network resource availability. But re-signaling any LSP 234 introduces risks to the stability of the service provided to the 235 customer and the stability of the network even when techniques 236 like make-before-break [RFC3209] are used. Therefore, a P2MP 237 Path Computation Request SHOULD contain a parameter that allows 238 the PCC to express a cost-benefit reoptimization threshold for 239 the whole LSP as well as per destination. The setting of this 240 parameter is subject to local policy at the PCC and SHOULD be 241 subject to policy at the PCE [RFC5394]. 243 Path reoptimization responses SHOULD indicate which of the 244 routes (as supplied according to Section 2.1.6) have been 245 modified from the paths supplied on the request. 247 2.1.11. Addition and Removal of Destinations from Existing Paths 249 A variation of path modification described in Section 2.1.9 is that 250 destinations may be added to, or removed from, existing P2MP TE LSPs. 252 In the case of the addition of one or more destinations, it is 253 necessary to compute a path for a new branch of the P2MP LSP. It may 254 be desirable to recompute the whole P2MP tree, to add the new branch 255 as a simple spur from the existing tree, or to recompute part of the 256 P2MP tree. 258 R12: To support this function for leaf additions it MUST be possible 259 to make the following indications on a path computation request: 261 - The path of an existing P2MP LSP (as described in Section 262 2.1.9). 264 - Which destinations are new additions to the tree. 266 - Which destinations of the existing tree must not have their 267 paths modified. 269 It MAY also be possible to indicate on a path computation 270 request a cost-benefit reoptimization threshold such that the 271 addition of new leaves will not cause reoptimization of the 272 existing P2MP tree unless a certain improvement is made over 273 simply grafting the new leaves to the existing tree. (Compare 274 with Section 2.1.10.) 276 In the case of the deletion of one or more destinations, it is 277 not necessary to compute a new path for the P2MP TE LSP, but 278 such a computation may yield optimizations over a simple pruning 279 of the tree. The recomputation function in this case is 280 essentially the same as that described in Section 2.1.10, but 281 note that it MAY be possible to supply the full previous path of 282 the entire P2MP TE LSP (that is, before the deletion of the 283 destinations) on the Path Computation Request. 285 For both addition and deletion of destinations, the Path 286 Computation Response SHOULD indicate which of the routes (as 287 supplied according to Section 2.1.6) have been modified from the 288 paths supplied on the request as described in Section 2.1.10. 290 Note that the selection of all of these options is subject to 291 local policy at the PCC, and SHOULD be subject to policy at the 292 PCE [RFC5394]. 294 2.1.12. Specification of Applicable Branch Nodes 296 For administrative or security reasons, or for other policy reasons, 297 it may be desirable to limit the set of nodes within the network that 298 may be used as branch points for a given LSP. That is, to provide to 299 the path computation a limiting set of nodes that can be used as 300 branches for a P2MP path computation, or to provide a list of nodes 301 that must not be used as branch points. 303 R13: The PCC MUST be able to specify on a Path Computation Request a 304 list of nodes that constitutes a limiting superset of the branch 305 nodes for a P2MP path computation. 307 A PCC MUST be able to specify on a Path Computation Request a 308 list of nodes that must not be used as branch nodes for a P2MP 309 path computation. 311 2.1.13. Capabilities Exchange 313 PCE capabilities exchange forms part of PCE discovery [RFC4674], but 314 may also be included in the PCECP message exchanges [RFC4657]. 316 R14: The ability to perform P2MP path computation and the objective 317 functions supported by a PCE SHOULD be advertised as part of PCE 318 discovery. In the event that the PCE ability to perform P2MP 319 computation is not advertised as part of PCE discovery, the 320 PCECP MUST allow a PCC to discover which PCEs with which it 321 communicates support P2MP path computation and which objective 322 functions specific to P2MP path computation are supported by 323 each PCE. 325 The list of objective functions is assumed to be coordinated with 326 those that can be requested as described in Section 2.1.2. 328 These requirements do not represent a change to [RFC4657] except to 329 add more capabilities and objective functions. 331 2.1.14. Path-Tree Diversity 333 Section 2.1.9 sets out the requirement to be able to request multiple 334 diverse paths. Additionally, with P2MP trees it may be that only 335 parts of the tree can be, or need to be diverse. 337 R15: The PCC SHOULD be able to request a PCE to compute a secondary 338 P2MP path tree with partial path diversity for specific leaves 339 or a specific S2L sub-path. 341 3. Manageability Considerations 343 3.1. Control of Function and Policy 345 PCE implementations MAY provide a configuration switch to allow 346 support of P2MP MPLS TE computations to be enabled or disabled. When 347 the level of support is changed, this SHOULD be re-advertised as 348 described in Section 2.1.13. 350 Support for, and advertisement of support for, P2MP MPLS TE path 351 computation MAY be subject to policy and a PCE MAY hide its P2MP 352 capabilities from certain PCCs by not advertising them through the 353 discovery protocol, and not reporting them to the specific PCCs in 354 any PCECP capabilities exchange. Further, a PCE MAY be directed by 355 policy to refuse a P2MP path computation for any reason including, 356 but not limited to, the identity of the PCC that makes the request. 358 3.2. Information and Data Models 360 PCECP protocol extensions to support P2MP MPLS TE SHOULD be 361 accompanied by MIB objects for the control and monitoring of the 362 protocol and the PCE that performs the computations. The MIB objects 363 MAY be provided in the same MIB module as used for general PCECP 364 control and monitoring or MAY be provided in a new MIB module. 366 The MIB objects SHOULD provide the ability to control and monitor all 367 aspects of PCECP relevant to P2MP MPLS TE path computation. 369 3.3. Liveness Detection and Monitoring 371 No changes are necessary to the liveness detection and monitoring 372 requirements as already embodied in [RFC4657]. It should be noted, 373 however, that in general P2MP computations are likely to take longer 374 than P2P computations. The liveness detection and monitoring features 375 of the PCECP SHOULD take this into account. 377 3.4. Verifying Correct Operation 379 There are no additional requirements beyond those expressed in 380 [RFC4657] for verifying the correct operation of the PCECP. Note that 381 verification of the correct operation of the PCE and its algorithms 382 is out of scope for the protocol requirements, but a PCC MAY send the 383 same request to more than one PCE and compare the results. 385 3.5. Requirements on Other Protocols and Functional Components 387 A PCE operates on a topology graph that may be built using 388 information distributed by TE extensions to the routing protocol 389 operating within the network. In order that the PCE can select a 390 suitable path for the signaling protocol to use to install the P2MP 391 LSP, the topology graph must include information about the P2MP 392 signaling and branching capabilities of each LSR in the network. 394 Whatever means is used to collect the information to build the 395 topology graph, the graph MUST include the requisite information. If 396 the TE extensions to the routing protocol are used, these SHOULD be 397 as described in [RFC5073]. 399 3.6. Impact on Network Operation 401 The use of a PCE to compute P2MP paths is not expected to have 402 significant impact on network operations. But it should be noted that 403 the introduction of P2MP support to a PCE that already provides P2P 404 path computation might change the loading of the PCE significantly 405 and that might have an impact on the network behavior especially 406 during recovery periods immediately after a network failure. 408 4. Security Considerations 410 P2MP computation requests do not raise any additional security issues 411 for the PCECP as there are no new messages and no new PCC-PCE 412 relationships or transactions introduced. 414 Note, however, that P2MP computation requests are more CPU-intensive 415 and also use more link bandwidth. Therefore, if the PCECP was 416 susceptible to denial of service attacks based on the injection of 417 spurious Path Computation Requests, the support of P2MP path 418 computation would exacerbate the effect. 420 It would be possible to consider applying different authorization 421 policies for P2MP Path Computation Requests compared to other 422 requests. 424 5. IANA Considerations 426 This document makes no requests for IANA action. 428 6. Acknowledgments 430 Thanks to Dean Cheng, Young Lee, Quintin Zhao, Daniel King, Fabien 431 Verhaeghe, and Francis Dupont for their comments and suggestions on 432 this document. 434 7. References 436 7.1. Normative Reference 438 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 439 requirements levels", RFC 2119, March 1997. 441 [RFC4657] Ash, J., and Le Roux, J.L., "Path Computation Element 442 (PCE) Communication Protocol Generic Requirements", 443 RFC 4657, September 2006. 445 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and Ash, 446 J., "Policy-Enabled Path Computation Framework", 447 RFC 5394, December 2008. 449 [RFC5671] Yasukawa, S., and Farrel, A., "Applicability of the 450 Path Computation Element (PCE) to Point-to-Multipoint 451 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 452 5671, October 2009. 454 7.2. Informative Reference 456 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 457 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 458 LSP Tunnels", RFC 3209, December 2001. 460 [RFC4461] S. Yasukawa, Editor "Signaling Requirements for 461 Point-to-Multipoint Traffic Engineered MPLS LSPs", 462 RFC4461, April 2006. 464 [RFC4655] Farrel, A., Vasseur, J.P., and Ash, G., "A Path 465 Computation Element (PCE)-Based Architecture", 466 RFC 4655, August 2006. 468 [RFC4674] J.L. Le Roux, Editor, "Requirements for Path 469 Computation Element (PCE) Discovery", RFC 4674, 470 October 2006. 472 [RFC4834] Morin, T., "Requirements for Multicast in Layer 3 473 Provider-Provisioned Virtual Private Networks 474 (PPVPNs)", RFC 4834, April 2007. 476 [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 477 "Extensions to Resource Reservation Protocol - Traffic 478 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 479 Switched Paths (LSPs)", RFC 4875, May 2007. 481 [RFC5073] Vasseur, J.P, and Le Roux, J.L., Editors, "IGP Routing 482 Protocol Extensions for Discovery of Traffic 483 Engineering Node Capabilities", RFC 5073, December 484 2007. 486 [RFC5541] Le Roux, J.L., Vasseur, J.P., and Lee, Y., "Encoding 487 of Objective Functions in the Path Computation Element 488 Communication Protocol (PCEP)", RFC 5541, June 2009. 490 8. Authors' Addresses 492 Seisho Yasukawa 493 NTT Corporation 494 9-11, Midori-Cho 3-Chome 495 Musashino-Shi, Tokyo 180-8585, 496 Japan 497 Email: yasukawa.seisho@lab.ntt.co.jp 499 Adrian Farrel 500 Old Dog Consulting 501 Email: adrian@olddog.co.uk