idnits 2.17.1 draft-yasukawa-pce-p2mp-req-01.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 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 347. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 354. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 360. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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.) -- The document date (September 2006) is 6434 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Seisho Yasukawa 2 Internet Draft NTT 3 Category: Informational Adrian Farrel 4 Expires: March 2007 Old Dog Consulting 5 September 2006 7 PCC-PCE Communication Requirements for Point to Multipoint 8 Multiprotocol Label Switching Traffic Engineering (MPLS-TE) 10 draft-yasukawa-pce-p2mp-req-01.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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119 [RFC2119]. 60 1. Introduction 62 The Path Computation Element (PCE) defined in [RFC4655] is an entity 63 that is capable of computing a network path or route based on a 64 network graph, and applying computational constraints. The intention 65 is that the PCE is used to compute the path of Traffic Engineered 66 Label Switched Paths (TE LSPs) within Multiprotocol Label Switching 67 (MPLS) and Generalized MPLS (GMPLS) networks. 69 Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are 70 documented in [RFC4461] and signaling protocol extensions for 71 setting up P2MP MPLS TE LSPs are defined in [P2MP-RSVP]. P2MP MPLS TE 72 networks are considered in support of various features including 73 layer 3 multicast VPNs. 75 Path computation for P2MP TE LSPs presents a significant challenge 76 and network optimization of multiple P2MP TE LSPs requires 77 considerable computational resources. PCE offers a way to offload 78 such path computations from LSRs. 80 The applicability of the PCE-based path computation architecture to 81 P2MP MPLS TE is described in a companion document [PCE-P2MP-APP]. No 82 further attempt is made to justify the use of PCE for P2MP MPLS TE 83 within this document. 85 This document presents a set of PCC-PCE communication protocol 86 (PCECP) requirements for P2MP MPLS traffic engineering. It 87 supplements the generic requirements documented in [PCE-COM-REQ]. 89 2. PCC-PCE Communication Requirements for P2MP MPLS Traffic Engineering 91 This section sets out additional requirements not covered in 92 [PCE-COM-REQ] specific to the problems of P2MP MPLS TE. 94 2.1. PCC-PCE Communication 96 The PCC-PCE communication protocol MUST allow requests and replies for 97 the computation of paths for P2MP LSPs. 99 This requires no additional messages, but implies the following 100 additional constraints to be added to the PCC-PCE communication 101 protocol. 103 2.1.1. Indication of P2MP Path Computation Request 105 Although the presence of certain parameters (such as a list of more 106 than one destination) may be used to infer that a path computation 107 request is for a P2MP LSP, an explicit parameter SHOULD be placed in 108 a conspicuous place within a Path Computation Request message to 109 allow a receiving PCE to easily identify that the request is for a 110 P2MP path. 112 2.1.2. Non-Support of P2MP Path Computation 114 Not all PCEs are required to support P2MP path computation. Therefore 115 it MUST be possible for a PCE to reject a P2MP Path Computation 116 Request message with a reason code that indicates no support for P2MP 117 path computation. 119 2.1.3. Non-Support by Back-Level PCE Implementations 121 It is possible that initial PCE implementations will be developed 122 without support for P2MP path computation and without the ability to 123 recognize the explicit parameter described in section 2.1.1. 124 Therefore, at least one parameter required for a P2MP path 125 computation request MUST be defined in such a way as to cause 126 automatic rejection as unprocessable or unrecognized by a back-level 127 PCE implementation without requiring any changes to that PCE. It is 128 RECOMMENDED that the parameter that causes this result is the 129 parameter described in section 2.1.1. 131 2.1.4. Specification of Destinations 133 Since P2MP LSPs have more than one destination, it MUST be possible 134 for a single Path Computation Request to list multiple destinations. 136 2.1.5. Indication of P2MP Paths 138 The Path Computation Response MUST be able to carry the path of a 139 P2MP LSP. This SHOULD be expressed as a compacted series of routes as 140 described in [P2MP-RSVP] although not necessarily using an identical 141 encoding. This MAY be expressed as a non-compacted series of 142 source-to-destination routes. 144 2.1.6. Multi-Message Requests and Responses 146 A single P2MP LSP may have very many destinations, and the computed 147 path (tree) may be very extensive. In these cases it is possible that 148 the entire Path Computation Request or Response cannot fit within one 149 PCE message. Therefore it MUST be possible for a single request or 150 response to be conveyed by a sequence of messages. 152 Note that there is a requirement in [PCE-COM-REQ] for reliable and 153 in-order message delivery, so it is assumed that components of the 154 sequence will be delivered in order and without missing items. 156 2.1.7. Non-Specification of Per-Destination Constraints and Parameters 158 It MUST NOT be possible to set different constraints, traffic 159 parameters, or quality of service requirements for different 160 destination of a P2MP LSP within a single computation request. 162 2.1.8. Path Modification and Path Diversity 164 No changes are made to the requirement to support path modification 165 and path diversity as described in [PCE-COM-REQ]. Note, however, that 166 a consequence of this requirement is that it must be possible to 167 supply an existing path on a Path Computation Request. This 168 requirement is unchanged as well, but it is a new requirement that 169 such paths MUST be able to be P2MP paths. 171 2.1.9. Reoptimization of P2MP TE LSPs 173 Reoptimization MUST be supported for P2MP TE LSPs as described for 174 P2P LSPs in [PCE-COM-REQ]. To support this, the existing path MUST 175 be supplied as described in Section 2.1.8. 177 Because P2MP LSPs are more complex it is often the case that small 178 optimization improvements can be made after changes in network 179 resource availablity, but re-signaling any LSP introduces risks to 180 the stability of the service provided to the customer and the 181 stability of the network even when techniques like make-before-break 182 [RFC3209] are used. Therefore, a path computation request SHOULD 183 contain a parameter that allows the PCC to express a cost-benefit 184 reoptimization threshold for the whole LSP as well as per 185 destination. The setting of this parameter is subject to local policy 186 at the PCC and SHOULD be subject to policy at the PCE [PCE-POLICY]. 188 For path reoptimization responses SHOULD indicate which of the routes 189 (as supplied according to Section 2.1.5) have been modified from the 190 paths supplied on the request. 192 2.1.10. Addition and Removal of Destinations from Existing Paths 194 A varitation of path modification described in Section 2.1.8 is that 195 destinations may be added to or removed from existing P2MP TE LSPs. 197 In the case of the addition of one or more destinations it is 198 necessary to compute a path for a new branch of the P2MP LSP. It may 199 be desirable to recompute the whole P2MP tree, to add the new branch 200 as a simple spur from the existing tree, or to recompute part of the 201 P2MP tree. 203 To support this function for leaf additions it MUST be possible to 204 make the following indications on a path computation request: 206 - The path of an existing P2MP LSP (as described in Section 2.1.8) 208 - Which destinations are new additions to the tree 210 - Which destinations of the existing tree must not have their paths 211 modified. 213 It MAY also be possible to indicate on a path computation request a 214 cost-benefit reoptimization threshold such that the tree and/or a new 215 path to any individual destination is not supplied unless a certain 216 improvement is made. Compare with Section 2.1.9. 218 In the case of the deletion of one or more destination it is not 219 necessary to compute a new path for the P2MP TE LSP, but such a 220 computation may yield optimizations over a simple pruning of the 221 tree. The recomputation function in this case is essentially the same 222 as that described in Section 2.1.9, but note that is MAY be possible 223 to supply the full previous path of the entire P2MP TE LSP (that is, 224 before the deletion of the destinations) on the path computation 225 request. 227 For both addition and deletion of destinations, the path computation 228 response SHOULD indicate which of the routes (as supplied according 229 to Section 2.1.5) have been modified from the paths supplied on the 230 request as described in Section 2.1.9. 232 Note that the selection of all of these options is subject to local 233 policy at the PCC, and SHOULD be subject to policy at the PCE 234 [PCE-POLICY]. 236 2.1.11. Capabilities Exchange 238 PCE capabilities exchange forms part of PCE discovery [PCE-DISCO], 239 but MAY also be included in the PCECP message exchanges. 241 The ability to perform P2MP path computation SHOULD be advertised as 242 part of PCE discovery. In the event that the PCE ability to perform 243 P2MP computation is not advertised as part of PCE discovery, the 244 PCECP MUST allow a PCC to discover which PCEs with which it 245 communicates support P2MP path computation and which objective 246 functions specific to P2MP path computation are supported by each 247 PCE. 249 3. Manageability Considerations 251 Manageability of P2MP MPLS TE with PCE must address the following 252 considerations. 254 - Need for a MIB module for control and monitoring. 255 - Need for built-in diagnostic tools. 256 - Configuration implications for the protocol. 258 4. Security Considerations 260 P2MP computation requests do not raise any additional security issues 261 for the PCECP. 263 Note, however, that P2MP computation requests are more CPU-intensive 264 and also use more link bandwidth. Therefore if the PCECP was 265 susceptible to denial of service attacks based on the injection of 266 spurious Path Computation Requests, the support of P2MP path 267 computation would exacerbate the effect. 269 It would be possible to consider applying different authorization 270 policies for P2MP path computation requests compared to other 271 requests. 273 5. IANA Considerations 275 This document makes no requests for IANA action. 277 6. Acknowledgments 279 TBD 281 7. References 283 7.1. Normative Reference 285 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 286 requirements levels", RFC 2119, March 1997. 288 [PCE-COM-REQ] J. Ash, J.L Le Roux et al., "PCE Communication 289 Protocol Generic Requirements", 290 draft-ietf-pce-comm-protocol-gen-reqs, work in 291 progress. 293 [PCE-POLICY] Bryskin, I., Papadimitriou, D., and Berger, L., 294 "Policy-Enabled Path Computation Framework", 295 draft-ietf-pce-policy-enabled-path-comp, work in 296 progress. 298 7.2. Informative Reference 300 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 301 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 302 LSP Tunnels", RFC 3209, December 2001. 304 [RFC4461] S. Yasukawa, Editor "Signaling Requirements for 305 Point-to-Multipoint Traffic Engineered MPLS LSPs", 306 RFC4461, April 2006. 308 [RFC4655] Farrel, A., Vasseur, J.P., and Ash, G., "A Path 309 Computation Element (PCE)-Based Architecture", 310 RFC 4655, August 2006. 312 [PCE-DISCO] JL Le Roux et al., "Requirements for Path Computation 313 Element (PCE) Discovery", 314 draft-ietf-pce-discovery-reqs, work in progress. 316 [PCE-P2MP-APP] S. Yasukawa et al., "Applicability of the Path 317 Computation Element to Point-to-Multipoint Traffic 318 Engineering", draft-yasukawa-pce-p2mp-app, work in 319 progress. 321 [P2MP-RSVP] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 322 "Extensions to RSVP-TE for Point to Multipoint TE 323 LSPs", draft-ietf-mpls-rsvp-te-p2mp, work in progress. 325 8. Authors' Addresses 327 Seisho Yasukawa 328 NTT Corporation 329 (R&D Strategy Department) 330 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan 331 Phone: +81 3 5205 5341 332 Email: s.yasukawa@hco.ntt.co.jp 334 Adrian Farrel 335 Old Dog Consulting 336 Email: adrian@olddog.co.uk 338 9. Intellectual Property Statement 340 The IETF takes no position regarding the validity or scope of any 341 Intellectual Property Rights or other rights that might be claimed to 342 pertain to the implementation or use of the technology described in 343 this document or the extent to which any license under such rights 344 might or might not be available; nor does it represent that it has 345 made any independent effort to identify any such rights. Information 346 on the procedures with respect to rights in RFC documents can be 347 found in BCP 78 and BCP 79. 349 Copies of IPR disclosures made to the IETF Secretariat and any 350 assurances of licenses to be made available, or the result of an 351 attempt made to obtain a general license or permission for the use of 352 such proprietary rights by implementers or users of this 353 specification can be obtained from the IETF on-line IPR repository at 354 http://www.ietf.org/ipr. 356 The IETF invites any interested party to bring to its attention any 357 copyrights, patents or patent applications, or other proprietary 358 rights that may cover technology that may be required to implement 359 this standard. Please address the information to the IETF at 360 ietf-ipr@ietf.org. 362 Disclaimer of Validity 364 This document and the information contained herein are provided on an 365 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 366 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 367 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 368 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 369 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 372 Copyright Statement 374 Copyright (C) The Internet Society (2006). This document is subject 375 to the rights, licenses and restrictions contained in BCP 78, and 376 except as set forth therein, the authors retain all their rights.