idnits 2.17.1 draft-yasukawa-pce-p2mp-req-04.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 467. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 480. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (~~), 2 warnings (==), 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 4 Created: November 14, 2007 Old Dog Consulting 5 Expires: May 14, 2008 7 PCC-PCE Communication Requirements for Point to Multipoint 8 Multiprotocol Label Switching Traffic Engineering (MPLS-TE) 10 draft-yasukawa-pce-p2mp-req-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of 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 Multi-Protocol 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). Since P2MP TE LSP routes are 44 sometimes complex to compute, and given the use of PCE in MPLS 45 networks it is likely that PCE will be used in P2MP MPLS-TE networks. 47 Generic requirements for a communication protocol between Path 48 Computation Clients (PCCs) and PCEs are presented in "Path 49 Computation Element (PCE) Communication Protocol Generic 50 Requirements". This document complements the generic requirements and 51 presents a detailed set of PCC-PCE communication protocol 52 requirements for point-to-multipoint MPLS traffic engineering. 54 Conventions used in this document 56 Although this document is not a protocol specification, the key words 57 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 58 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be 59 interpreted as described in RFC 2119 [RFC2119] for clarity of 60 description of requirements. 62 1. Introduction 64 The Path Computation Element (PCE) defined in [RFC4655] is an entity 65 that is capable of computing a network path or route based on a 66 network graph, and applying computational constraints. The intention 67 is that the PCE is used to compute the path of Traffic Engineered 68 Label Switched Paths (TE LSPs) within Multiprotocol Label Switching 69 (MPLS) and Generalized MPLS (GMPLS) networks. 71 Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are 72 documented in [RFC4461] and signaling protocol extensions for 73 setting up P2MP MPLS TE LSPs are defined in [RFC4875]. P2MP MPLS TE 74 networks are considered in support of various features including 75 layer 3 multicast VPNs [RFC4834]. 77 Path computation for P2MP TE LSPs presents a significant challenge, 78 and network optimization of multiple P2MP TE LSPs requires 79 considerable computational resources. PCE offers a way to offload 80 such path computations from Label Swiching Routers (LSRs). 82 The applicability of the PCE-based path computation architecture to 83 P2MP MPLS TE is described in a companion document [PCE-P2MP-APP]. No 84 further attempt is made to justify the use of PCE for P2MP MPLS TE 85 within this document. 87 This document presents a set of PCC-PCE communication protocol 88 (PCECP) requirements for P2MP MPLS traffic engineering. It 89 supplements the generic requirements documented in [RFC4657]. 91 2. PCC-PCE Communication Requirements for P2MP MPLS Traffic Engineering 93 This section sets out additional requirements not covered in 94 [RFC4657] specific to P2MP MPLS TE. 96 2.1. PCC-PCE Communication 98 The PCC-PCE communication protocol MUST allow requests and replies 99 for the computation of paths for P2MP LSPs. 101 This requires no additional messages, but requires the addition of 102 the parameters described in the following sections to the existing 103 PCC-PCE communication protocol messages. 105 2.1.1. Indication of P2MP Path Computation Request 107 Although the presence of certain parameters (such as a list of more 108 than one destination) MAY be used to infer that a path computation 109 request is for a P2MP LSP, an explicit parameter SHOULD be placed in 110 a conspicuous place within a Path Computation Request message to 111 allow a receiving PCE to easily identify that the request is for a 112 P2MP path. 114 2.1.2. Indication of P2MP Objective Functions 116 [RFC4657] includes the requirement to be able to specify the 117 objective functions to be applied by a PCE during path computation 118 and for the PCE to indicate which objective functions were applied. 120 This document makes no change to that requirement, but it should be 121 noted that new and different objective functions will be used for 122 P2MP computation, and that these obvjective functions will need to be 123 defined and allocated codepoints in a separate document. 125 2.1.3. Non-Support of P2MP Path Computation 127 PCEs are not required to support P2MP path computation. Therefore, it 128 MUST be possible for a PCE to reject a P2MP Path Computation Request 129 message with a reason code that indicates no support for P2MP path 130 computation. 132 2.1.4. Non-Support by Back-Level PCE Implementations 134 It is possible that initial PCE implementations will be developed 135 without support for P2MP path computation and without the ability to 136 recognize the explicit parameter described in section 2.1.1. Such 137 legacy implementations will not be able to make use of the new 138 reason code described in Section 2.1.3. 140 Therefore, at least one parameter required for inclusion in a P2MP 141 Path Computation Request message MUST be defined in such a way as to 142 cause automatic rejection as unprocessable or unrecognized by a back- 143 level PCE implementation without requiring any changes to that PCE. 144 It is RECOMMENDED that the parameter that causes this result is the 145 parameter described in Section 2.1.1. 147 2.1.5. Specification of Destinations 149 Since P2MP LSPs have more than one destination, it MUST be possible 150 for a single Path Computation Request to list multiple destinations. 152 2.1.6. Indication of P2MP Paths 154 The Path Computation Response MUST be able to carry the path of a 155 P2MP LSP. 157 P2MP paths can be expressed as a compacted series of routes as 158 described in [RFC4875]. The Path Computation Response MUST be able to 159 carry the P2MP path as either a compacted path (but not necessarily 160 using the identical encoding as described in [RFC4875]), or as an 161 non-compacted path comprising a series of source-to-leaf point-to- 162 point paths (known as S2L sub-paths). 164 By default, the path returned by the PCE SHOULD use the compacted 165 format. 167 The request from the PCC MAY allow the PCC to express a preference 168 for receiving a compacted or non-compacted P2MP path in the response. 170 2.1.7. Multi-Message Requests and Responses 172 A single P2MP LSP may have very many destinations, and the computed 173 path (tree) may be very extensive. In these cases it is possible that 174 the entire Path Computation Request or Response cannot fit within one 175 PCE message. Therefore, it MUST be possible for a single request or 176 response to be conveyed by a sequence of PCE messages. 178 Note that there is a requirement in [RFC4657] for reliable and 179 in-order message delivery, so it is assumed that components of the 180 sequence will be delivered in order and without missing components. 182 2.1.8. Non-Specification of Per-Destination Constraints and Parameters 184 [RFC4875] requires that all branches of a single P2MP LSP have the 185 same characteristics, and achieves this by not allowing the signaling 186 parameters to be varied for different branches of the same P2MP LSP. 188 It MUST NOT be possible to set different constraints, traffic 189 parameters, or quality of service requirements for different 190 destinations of a P2MP LSP within a single computation request. 192 2.1.9. Path Modification and Path Diversity 194 No changes are made to the requirement to support path modification 195 and path diversity as described in [RFC4657]. Note, however, that a 196 consequence of this requirement is that it MUST be possible to supply 197 an existing path on a Path Computation Request. This requirement is 198 unchanged from [RFC4657], but it is a new requirement that such paths 199 MUST be able to be P2MP paths. 201 2.1.10. Reoptimization of P2MP TE LSPs 203 Reoptimization MUST be supported for P2MP TE LSPs as described for 204 P2P LSPs in [RFC4657]. To support this, the existing path MUST be 205 supplied as described in Section 2.1.9. 207 Because P2MP LSPs are more complex it is often the case that small 208 optimization improvements can be made after changes in network 209 resource availability. But re-signaling any LSP introduces risks to 210 the stability of the service provided to the customer and the 211 stability of the network even when techniques like make-before-break 212 [RFC3209] are used. Therefore, a P2MP Path Computation Request SHOULD 213 contain a parameter that allows the PCC to express a cost-benefit 214 reoptimization threshold for the whole LSP as well as per 215 destination. The setting of this parameter is subject to local policy 216 at the PCC and SHOULD be subject to policy at the PCE [PCE-POLICY]. 218 Path reoptimization responses SHOULD indicate which of the routes (as 219 supplied according to Section 2.1.6) have been modified from the 220 paths supplied on the request. 222 2.1.11. Addition and Removal of Destinations from Existing Paths 224 A variation of path modification described in Section 2.1.9 is that 225 destinations may be added to, or removed from, existing P2MP TE LSPs. 227 In the case of the addition of one or more destinations, it is 228 necessary to compute a path for a new branch of the P2MP LSP. It may 229 be desirable to recompute the whole P2MP tree, to add the new branch 230 as a simple spur from the existing tree, or to recompute part of the 231 P2MP tree. 233 To support this function for leaf additions it MUST be possible to 234 make the following indications on a path computation request: 236 - The path of an existing P2MP LSP (as described in Section 2.1.9). 238 - Which destinations are new additions to the tree. 240 - Which destinations of the existing tree must not have their paths 241 modified. 243 It MAY also be possible to indicate on a path computation request a 244 cost-benefit reoptimization threshold such that the tree and/or a new 245 path to any individual destination is not supplied unless a certain 246 improvement is made. Compare with Section 2.1.10. 248 In the case of the deletion of one or more destinations, it is not 249 necessary to compute a new path for the P2MP TE LSP, but such a 250 computation may yield optimizations over a simple pruning of the 251 tree. The recomputation function in this case is essentially the same 252 as that described in Section 2.1.10, but note that it MAY be possible 253 to supply the full previous path of the entire P2MP TE LSP (that is, 254 before the deletion of the destinations) on the Path Computation 255 Request. 257 For both addition and deletion of destinations, the Path Computation 258 Response SHOULD indicate which of the routes (as supplied according 259 to Section 2.1.6) have been modified from the paths supplied on the 260 request as described in Section 2.1.10. 262 Note that the selection of all of these options is subject to local 263 policy at the PCC, and SHOULD be subject to policy at the PCE 264 [PCE-POLICY]. 266 2.1.12. Specification of Applicable Branch Nodes 268 For administrative or security reasons, or for other policy reasons, 269 it may be desirable to limit the set of nodes within the network that 270 may be used as branch points for a given LSP. That is, to provide to 271 the path computation a limiting set of nodes that can be used as 272 branches for a P2MP path computation, or to provide a list of nodes 273 that must not be used as branch points. 275 The PCC MUST be able to specify on a Path Computation Request a list 276 of nodes that constitues a limiting superset of the branch nodes for 277 a P2MP path computation. 279 A PCC MUST be able to specify on a Path Computation Request a list of 280 nodes that must not be used as branch nodes for a P2MP path 281 computation. 283 2.1.13. Capabilities Exchange 285 PCE capabilities exchange forms part of PCE discovery [RFC4674], but 286 MAY also be included in the PCECP message exchanges [RFC4657]. 288 The ability to perform P2MP path computation and the objective 289 functions supported by a PCE SHOULD be advertised as part of PCE 290 discovery. In the event that the PCE ability to perform P2MP 291 computation is not advertised as part of PCE discovery, the PCECP 292 MUST allow a PCC to discover which PCEs with which it communicates 293 support P2MP path computation and which objective functions specific 294 to P2MP path computation are supported by each PCE. 296 The list of objective functions is assumed to be coordinated with 297 those that can be requested as described in Section 2.1.2. 299 These requirements do not represent a change to [RFC4657] except to 300 add more capabilities and objective functions. 302 3. Manageability Considerations 304 3.1. Control of Function and Policy 306 PCE implementations MAY provide a configuration switch to allow 307 support of P2MP MPLS TE computations to be enabled or disabled. When 308 the level of support is changed, this SHOULD be re-advertised as 309 described in Section 2.1.13. 311 Support for, and advertisement of support for, P2MP MPLS TE path 312 computation MAY be subject to policy and a PCE MAY hide its P2MP 313 capabilities from certain PCCs by not advertising them through the 314 discovery protocol, and not reporting them to the specific PCCs in 315 any PCECP capabilities exchange. Further, a PCE MAY be directed by 316 policy to refuse a P2MP path computation for any reason including, 317 but not limited to, the identity of the PCC that makes the request. 319 3.2. Information and Data Models 321 PCECP protocol extensions to support P2MP MPLS TE MUST be accompanied 322 by MIB objects for the control and monitoring of the protocol and the 323 PCE that performs the computations. The MIB objects MAY be provided 324 in the same MIB module as used for general PCECP control and 325 monitoring or MAY be provided in a new MIB module. 327 The MIB objects MUST provide the ability to control and monitor all 328 aspects of PCECP relevant to P2MP MPLS TE path computation. 330 3.3. Liveness Detection and Monitoring 332 No changes are necessary to the liveness detection and monitoring 333 requirements as already embodied in [RFC4657]. It should be noted, 334 however, that in general P2MP computations are likely to take longer 335 than P2P computations. The liveness detection and molnitoring 336 features of the PCECP SHOULD take this into account. 338 3.4. Verifying Correct Operation 340 There are no additional requirements beyond those expressed in 341 [RFC4657] for verifying the correct operation of the PCECP. Note that 342 verification of the correct operation of the PCE and its algorithms 343 is out of scope for the protocol requirements, but a PCC MAY send the 344 same request to more than one PCE and compare the results. 346 3.5. Requirements on Other Protocols and Functional Components 348 A PCE operates on a topology graph that may be built using 349 information distributed by TE extensions to the routing protocol 350 operating within the network. In order that the PCE can select a 351 suitable path for the signaling protocol to use to install the P2MP 352 LSP, the topology graph must include information about the P2MP 353 signaling and branching capabilities of each LSR in the network. 355 Whatever means is used to collect the information to build the 356 topology graph MUST include the requisite information. If the TE 357 extensions to the routing protocol are used, these SHOULD be as 358 described in [TE-NODE-CAP]. 360 3.6. Impact on Network Operation 362 The use of a PCE to compute P2MP paths is not expected to have 363 significant impact on network operations. But it should be noted that 364 the introduction of P2MP support to a PCE that already provides P2P 365 path computation might change the loading of the PCE significantly 366 and that might have an impact on the network behavior especially 367 during recovery periods immediately after a network failure. 369 4. Security Considerations 371 P2MP computation requests do not raise any additional security issues 372 for the PCECP as there are no new messages and no new PCC-PCE 373 relationships or transactions introduced. 375 Note, however, that P2MP computation requests are more CPU-intensive 376 and also use more link bandwidth. Therefore, if the PCECP was 377 susceptible to denial of service attacks based on the injection of 378 spurious Path Computation Requests, the support of P2MP path 379 computation would exacerbate the effect. 381 It would be possible to consider applying different authorization 382 policies for P2MP Path Computation Requests compared to other 383 requests. 385 5. IANA Considerations 387 This document makes no requests for IANA action. 389 6. Acknowledgments 391 Thanks to Dean Cheng, Young Lee, and Quintin Zhao for their comments 392 and suggestions on this document. 394 7. References 396 7.1. Normative Reference 398 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 399 requirements levels", RFC 2119, March 1997. 401 [RFC4657] Ash, J., and Le Roux, J.L., "Path Computation Element 402 (PCE) Communication Protocol Generic Requirements", 403 RFC 4657, September 2006. 405 [PCE-POLICY] Bryskin, I., Papadimitriou, D., and Berger, L., 406 "Policy-Enabled Path Computation Framework", 407 draft-ietf-pce-policy-enabled-path-comp, work in 408 progress. 410 7.2. Informative Reference 412 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 413 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 414 LSP Tunnels", RFC 3209, December 2001. 416 [RFC4461] S. Yasukawa, Editor "Signaling Requirements for 417 Point-to-Multipoint Traffic Engineered MPLS LSPs", 418 RFC4461, April 2006. 420 [RFC4655] Farrel, A., Vasseur, J.P., and Ash, G., "A Path 421 Computation Element (PCE)-Based Architecture", 422 RFC 4655, August 2006. 424 [RFC4674] J.L. Le Roux, Editor, "Requirements for Path 425 Computation Element (PCE) Discovery", RFC 4674, 426 October 2006. 428 [PCE-P2MP-APP] S. Yasukawa et al., "Applicability of the Path 429 Computation Element to Point-to-Multipoint Traffic 430 Engineering", draft-yasukawa-pce-p2mp-app, work in 431 progress. 433 [RFC4834] Morin, T., "Requirements for Multicast in Layer 3 434 Provider-Provisioned Virtual Private Networks 435 (PPVPNs)", RFC 4834, April 2007. 437 [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 438 "Extensions to Resource Reservation Protocol - Traffic 439 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 440 Switched Paths (LSPs)", RFC 4875, May 2007. 442 [TE-NODE-CAP] Vasseur, J.P, and Le Roux, J.L., Editors, "IGP Routing 443 Protocol Extensions for Discovery of Traffic 444 Engineering Node Capabilities", draft-ietf-ccamp-te- 445 node-cap, work in progress. 447 8. Authors' Addresses 449 Seisho Yasukawa 450 NTT Corporation (R&D Strategy Department) 451 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 452 Email: s.yasukawa@hco.ntt.co.jp 454 Adrian Farrel 455 Old Dog Consulting 456 Email: adrian@olddog.co.uk 458 9. Intellectual Property Statement 460 The IETF takes no position regarding the validity or scope of any 461 Intellectual Property Rights or other rights that might be claimed to 462 pertain to the implementation or use of the technology described in 463 this document or the extent to which any license under such rights 464 might or might not be available; nor does it represent that it has 465 made any independent effort to identify any such rights. Information 466 on the procedures with respect to rights in RFC documents can be 467 found in BCP 78 and BCP 79. 469 Copies of IPR disclosures made to the IETF Secretariat and any 470 assurances of licenses to be made available, or the result of an 471 attempt made to obtain a general license or permission for the use of 472 such proprietary rights by implementers or users of this 473 specification can be obtained from the IETF on-line IPR repository at 474 http://www.ietf.org/ipr. 476 The IETF invites any interested party to bring to its attention any 477 copyrights, patents or patent applications, or other proprietary 478 rights that may cover technology that may be required to implement 479 this standard. Please address the information to the IETF at ietf- 480 ipr@ietf.org. 482 10. Full Copyright Statement 484 Copyright (C) The IETF Trust (2007). 486 This document is subject to the rights, licenses and restrictions 487 contained in BCP 78, and except as set forth therein, the authors 488 retain all their rights. 490 This document and the information contained herein are provided on an 491 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 492 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 493 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 494 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 495 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 496 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.