idnits 2.17.1 draft-ietf-pce-rfc6006bis-04.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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 26, 2017) is 2403 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'This I-D' is mentioned on line 1446, but not defined == Unused Reference: 'I-D.ietf-pce-pcep-yang' is defined on line 1577, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6006 (Obsoleted by RFC 8306) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group Q. Zhao 3 Internet-Draft D. Dhody, Ed. 4 Intended status: Standards Track R. Palleti 5 Obsoletes: 6006 (if approved) Huawei Technology 6 Expires: March 30, 2018 D. King 7 Old Dog Consulting 8 September 26, 2017 10 Extensions to 11 the Path Computation Element Communication Protocol (PCEP) 12 for Point-to-Multipoint Traffic Engineering Label Switched Paths 14 draft-ietf-pce-rfc6006bis-04 16 Abstract 18 Point-to-point Multiprotocol Label Switching (MPLS) and Generalized 19 MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may 20 be established using signaling techniques, but their paths may first 21 need to be determined. The Path Computation Element (PCE) has been 22 identified as an appropriate technology for the determination of the 23 paths of point-to-multipoint (P2MP) TE LSPs. 25 This document describes extensions to the PCE communication Protocol 26 (PCEP) to handle requests and responses for the computation of paths 27 for P2MP TE LSPs. 29 This document obsoletes RFC 6006. 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). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on March 30, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 This document may contain material from IETF Documents or IETF 64 Contributions published or made publicly available before November 65 10, 2008. The person(s) controlling the copyright in some of this 66 material may not have granted the IETF Trust the right to allow 67 modifications of such material outside the IETF Standards Process. 68 Without obtaining an adequate license from the person(s) controlling 69 the copyright in such materials, this document may not be modified 70 outside the IETF Standards Process, and derivative works of it may 71 not be created outside the IETF Standards Process, except to format 72 it for publication as an RFC or to translate it into languages other 73 than English. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 80 2. PCC-PCE Communication Requirements . . . . . . . . . . . . . . 5 81 3. Protocol Procedures and Extensions . . . . . . . . . . . . . . 6 82 3.1. P2MP Capability Advertisement . . . . . . . . . . . . . . 6 83 3.1.1. P2MP Computation TLV in the Existing PCE Discovery 84 Protocol . . . . . . . . . . . . . . . . . . . . . . . 6 85 3.1.2. Open Message Extension . . . . . . . . . . . . . . . . 8 86 3.2. Efficient Presentation of P2MP LSPs . . . . . . . . . . . 8 87 3.3. P2MP Path Computation Request/Reply Message Extensions . . 9 88 3.3.1. The Extension of the RP Object . . . . . . . . . . . . 9 89 3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . . 10 90 3.4. Request Message Format . . . . . . . . . . . . . . . . . . 13 91 3.5. Reply Message Format . . . . . . . . . . . . . . . . . . . 14 92 3.6. P2MP Objective Functions and Metric Types . . . . . . . . 15 93 3.6.1. New Objective Functions . . . . . . . . . . . . . . . 15 94 3.6.2. New Metric Object Types . . . . . . . . . . . . . . . 16 95 3.7. Non-Support of P2MP Path Computation . . . . . . . . . . . 16 96 3.8. Non-Support by Back-Level PCE Implementations . . . . . . 18 97 3.9. P2MP TE Path Reoptimization Request . . . . . . . . . . . 18 98 3.10. Adding and Pruning Leaves to/from the P2MP Tree . . . . . 19 99 3.11. Discovering Branch Nodes . . . . . . . . . . . . . . . . 22 100 3.11.1. Branch Node Object . . . . . . . . . . . . . . . . . 22 101 3.12. Synchronization of P2MP TE Path Computation Requests . . 22 102 3.13. Request and Response Fragmentation . . . . . . . . . . . 23 103 3.13.1. Request Fragmentation Procedure . . . . . . . . . . . 24 104 3.13.2. Response Fragmentation Procedure . . . . . . . . . . 24 105 3.13.3. Fragmentation Examples . . . . . . . . . . . . . . . 24 106 3.14. UNREACH-DESTINATION Object . . . . . . . . . . . . . . . 25 107 3.15. P2MP PCEP-ERROR Objects and Types . . . . . . . . . . . . 26 108 3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . 27 109 4. Manageability Considerations . . . . . . . . . . . . . . . . . 28 110 4.1. Control of Function and Policy . . . . . . . . . . . . . . 28 111 4.2. Information and Data Models . . . . . . . . . . . . . . . 28 112 4.3. Liveness Detection and Monitoring . . . . . . . . . . . . 28 113 4.4. Verifying Correct Operation . . . . . . . . . . . . . . . 29 114 4.5. Requirements for Other Protocols and Functional 115 Components . . . . . . . . . . . . . . . . . . . . . . . . 30 116 4.6. Impact on Network Operation . . . . . . . . . . . . . . . 30 117 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 118 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 119 6.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 31 120 6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . . 31 121 6.3. Objective Functions . . . . . . . . . . . . . . . . . . . 31 122 6.4. Metric Object Types . . . . . . . . . . . . . . . . . . . 32 123 6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 32 124 6.6. PCEP-ERROR Objects and Types . . . . . . . . . . . . . . . 33 125 6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . 34 126 6.8. SVEC Object Flag . . . . . . . . . . . . . . . . . . . . . 34 127 6.9. OSPF PCE Capability Flag . . . . . . . . . . . . . . . . . 35 128 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 129 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 130 8.1. Normative References . . . . . . . . . . . . . . . . . . . 37 131 8.2. Informative References . . . . . . . . . . . . . . . . . . 38 132 Appendix A. Summary of the all Changes from RFC 6006 . . . . . . . 40 133 Appendix A.1 RBNF Changes from RFC 6006 . . . . . . . . . . . . . 40 134 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 137 1. Introduction 139 The Path Computation Element (PCE) defined in [RFC4655] is an entity 140 that is capable of computing a network path or route based on a 141 network graph, and applying computational constraints. A Path 142 Computation Client (PCC) may make requests to a PCE for paths to be 143 computed. 145 [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic 146 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 147 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. 149 The PCE has been identified as a suitable application for the 150 computation of paths for P2MP TE LSPs [RFC5671]. 152 The PCE communication Protocol (PCEP) is designed as a communication 153 protocol between PCCs and PCEs for point-to-point (P2P) path 154 computations and is defined in [RFC5440]. However, that 155 specification does not provide a mechanism to request path 156 computation of P2MP TE LSPs. 158 A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. 159 These S2L sub-LSPs are set up between ingress and egress Label 160 Switching Routers (LSRs) and are appropriately overlaid to construct 161 a P2MP TE LSP. During path computation, the P2MP TE LSP may be 162 determined as a set of S2L sub-LSPs that are computed separately and 163 combined to give the path of the P2MP LSP, or the entire P2MP TE LSP 164 may be determined as a P2MP tree in a single computation. 166 This document relies on the mechanisms of PCEP to request path 167 computation for P2MP TE LSPs. One path computation request message 168 from a PCC may request the computation of the whole P2MP TE LSP, or 169 the request may be limited to a sub-set of the S2L sub-LSPs. In the 170 extreme case, the PCC may request the S2L sub-LSPs to be computed 171 individually with it being the PCC's responsibility to decide whether 172 to signal individual S2L sub-LSPs or combine the computation results 173 to signal the entire P2MP TE LSP. Hence the PCC may use one path 174 computation request message or may split the request across multiple 175 path computation messages. 177 This document obsoletes [RFC6006] and incorporates all outstanding 178 Errata: 180 o Erratum with IDs: 3819, 3830, 3836, 4867, 4868 and 4956. 182 All changes from [RFC6006] are listed in Appendix A. 184 1.1. Terminology 185 Terminology used in this document: 187 TE LSP: Traffic Engineering Label Switched Path. 189 LSR: Label Switching Router. 191 OF: Objective Function: A set of one or more optimization criteria 192 used for the computation of a single path (e.g., path cost 193 minimization), or for the synchronized computation of a set of 194 paths (e.g., aggregate bandwidth consumption minimization). 196 P2MP: Point-to-Multipoint. 198 P2P: Point-to-Point. 200 This document also uses the terminology defined in [RFC4655], 201 [RFC4875], and [RFC5440]. 203 1.2. Requirements Language 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 207 "OPTIONAL" in this document are to be interpreted as described in BCP 208 14 [RFC2119] [RFC8174] when, and only when, they appear in all 209 capitals, as shown here. 211 2. PCC-PCE Communication Requirements 213 This section summarizes the PCC-PCE communication requirements for 214 P2MP MPLS-TE LSPs described in [RFC5862]. The numbering system 215 corresponds to the requirement numbers used in [RFC5862]. 217 1. The PCC MUST be able to specify that the request is a P2MP path 218 computation request. 220 2. The PCC MUST be able to specify that objective functions are to 221 be applied to the P2MP path computation request. 223 3. The PCE MUST have the capability to reject a P2MP path request 224 and indicate non-support of P2MP path computation. 226 4. The PCE MUST provide an indication of non-support of P2MP path 227 computation by back-level PCE implementations. 229 5. A P2MP path computation request MUST be able to list multiple 230 destinations. 232 6. A P2MP path computation response MUST be able to carry the path 233 of a P2MP LSP. 235 7. By default, the path returned by the PCE SHOULD use the 236 compressed format. 238 8. It MUST be possible for a single P2MP path computation request or 239 response to be conveyed by a sequence of messages. 241 9. It MUST NOT be possible for a single P2MP path computation 242 request to specify a set of different constraints, traffic 243 parameters, or quality-of-service requirements for different 244 destinations of a P2MP LSP. 246 10. P2MP path modification and P2MP path diversity MUST be supported. 248 11. It MUST be possible to reoptimize existing P2MP TE LSPs. 250 12. It MUST be possible to add and remove P2MP destinations from 251 existing paths. 253 13. It MUST be possible to specify a list of applicable branch nodes 254 to use when computing the P2MP path. 256 14. It MUST be possible for a PCC to discover P2MP path computation 257 capability. 259 15. The PCC MUST be able to request diverse paths when requesting a 260 P2MP path. 262 3. Protocol Procedures and Extensions 264 The following section describes the protocol extensions required to 265 satisfy the requirements specified in Section 2 ("PCC-PCE 266 Communication Requirements") of this document. 268 3.1. P2MP Capability Advertisement 270 3.1.1. P2MP Computation TLV in the Existing PCE Discovery Protocol 272 [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF 273 Router Information Link State Advertisement (LSA) defined in 274 [RFC7770] to facilitate PCE discovery using OSPF. [RFC5088] 275 specifies that no new sub-TLVs may be added to the PCED TLV. This 276 document defines a new flag in the OSPF PCE Capability Flags to 277 indicate the capability of P2MP computation. 279 Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE 280 Discovery using IS-IS. This document will use the same flag 281 requested for the OSPF PCE Capability Flags sub-TLV to allow IS-IS to 282 indicate the capability of P2MP computation. 284 The IANA assignment for a shared OSPF and IS-IS P2MP Capability Flag 285 is documented in Section 6.9 ("OSPF PCE Capability Flag") of this 286 document. 288 PCEs wishing to advertise that they support P2MP path computation 289 would set the bit (10) accordingly. PCCs that do not understand this 290 bit will ignore it (per [RFC5088] and [RFC5089]). PCEs that do not 291 support P2MP will leave the bit clear (per the default behavior 292 defined in [RFC5088] and [RFC5089]). 294 PCEs that set the bit to indicate support of P2MP path computation 295 MUST follow the procedures in Section 3.3.2 ("The New P2MP END-POINTS 296 Object") to further qualify the level of support. 298 3.1.2. Open Message Extension 300 Based on the Capabilities Exchange requirement described in 301 [RFC5862], if a PCE does not advertise its P2MP capability during 302 discovery, PCEP should be used to allow a PCC to discover, during the 303 Open Message Exchange, which PCEs are capable of supporting P2MP path 304 computation. 306 To satisfy this requirement, we extend the PCEP OPEN object by 307 defining a new optional TLV to indicate the PCE's capability to 308 perform P2MP path computations. 310 IANA has allocated value 6 from the "PCEP TLV Type Indicators" sub- 311 registry, as documented in Section 6.1 ("PCEP TLV Type Indicators"). 312 The description is "P2MP capable", and the length value is 2 bytes. 313 The value field is set to default value 0. 315 The inclusion of this TLV in an OPEN object indicates that the sender 316 can perform P2MP path computations. 318 The capability TLV is meaningful only for a PCE, so it will typically 319 appear only in one of the two Open messages during PCE session 320 establishment. However, in case of PCE cooperation (e.g., 321 inter-domain), when a PCE behaving as a PCC initiates a PCE session 322 it SHOULD also indicate its path computation capabilities. 324 3.2. Efficient Presentation of P2MP LSPs 326 When specifying additional leaves, or optimizing existing P2MP TE 327 LSPs as specified in [RFC5862], it may be necessary to pass existing 328 P2MP LSP route information between the PCC and PCE in the request and 329 reply messages. In each of these scenarios, we need new path objects 330 for efficiently passing the existing P2MP LSP between the PCE and 331 PCC. 333 We specify the use of the Resource Reservation Protocol Traffic 334 Engineering (RSVP-TE) extensions Explicit Route Object (ERO) to 335 encode the explicit route of a TE LSP through the network. PCEP ERO 336 sub-object types correspond to RSVP-TE ERO sub-object types. The 337 format and content of the ERO object are defined in [RFC3209] and 338 [RFC3473]. 340 The Secondary Explicit Route Object (SERO) is used to specify the 341 explicit route of a S2L sub-LSP. The path of each subsequent S2L 342 sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object SERO. 343 The format of the SERO is the same as an ERO defined in [RFC3209] and 344 [RFC3473]. 346 The Secondary Record Route Object (SRRO) is used to record the 347 explicit route of the S2L sub-LSP. The class of the P2MP SRRO is the 348 same as the SRRO defined in [RFC4873]. 350 The SERO and SRRO are used to report the route of an existing TE LSP 351 for which a reoptimization is desired. The format and content of the 352 SERO and SRRO are defined in [RFC4875]. 354 A new PCEP object class and type are requested for SERO and SRRO. 356 Object-Class Value 29 357 Name SERO 358 Object-Type 0: Reserved 359 1: SERO 360 2-15: Unassigned 361 Reference [This I-D] 363 Object-Class Value 30 364 Name SRRO 365 Object-Type 0: Reserved 366 1: SRRO 367 2-15: Unassigned 368 Reference [This I-D] 370 The IANA assignment is documented in Section 6.5 ("PCEP Objects"). 372 Since the explicit path is available for immediate signaling by the 373 MPLS or GMPLS control plane, the meanings of all of the sub-objects 374 and fields in this object are identical to those defined for the ERO. 376 3.3. P2MP Path Computation Request/Reply Message Extensions 378 This document extends the existing P2P RP (Request Parameters) object 379 so that a PCC can signal a P2MP path computation request to the PCE 380 receiving the PCEP request. The END-POINTS object is also extended 381 to improve the efficiency of the message exchange between PCC and PCE 382 in the case of P2MP path computation. 384 3.3.1. The Extension of the RP Object 386 The PCE path computation request and reply messages will need the 387 following additional parameters to indicate to the receiving PCE that 388 the request and reply messages have been fragmented across multiple 389 messages, that they have been requested for a P2MP path, and whether 390 the route is represented in the compressed or uncompressed format. 392 This document adds the following flags to the RP Object: 394 The F-bit is added to the flag bits of the RP object to indicate to 395 the receiver that the request is part of a fragmented request, or is 396 not a fragmented request. 398 o F (RP fragmentation bit - 1 bit): 400 0: This indicates that the RP is not fragmented or it is the last 401 piece of the fragmented RP. 403 1: This indicates that the RP is fragmented and this is not the 404 last piece of the fragmented RP. The receiver needs to wait 405 for additional fragments until it receives an RP with the same 406 RP-ID and with the F-bit set to 0. 408 The N-bit is added in the flag bits field of the RP object to signal 409 the receiver of the message that the request/reply is for P2MP or is 410 not for P2MP. 412 o N (P2MP bit - 1 bit): 414 0: This indicates that this is not a PCReq or PCRep message for 415 P2MP. 417 1: This indicates that this is a PCReq or PCRep message for P2MP. 419 The E-bit is added in the flag bits field of the RP object to signal 420 the receiver of the message that the route is in the compressed 421 format or is not in the compressed format. By default, the path 422 returned by the PCE SHOULD use the compressed format. 424 o E (ERO-compression bit - 1 bit): 426 0: This indicates that the route is not in the compressed format. 428 1: This indicates that the route is in the compressed format. 430 The IANA assignment is documented in Section 6.2 ("Request Parameter 431 Bit Flags") of this document. 433 3.3.2. The New P2MP END-POINTS Object 435 The END-POINTS object is used in a PCReq message to specify the 436 source IP address and the destination IP address of the path for 437 which a path computation is requested. To represent the end points 438 for a P2MP path efficiently, we define two new types of END-POINTS 439 objects for the P2MP path: 441 o Old leaves whose path can be modified/reoptimized; 443 o Old leaves whose path must be left unchanged. 445 With the new END-POINTS object, the PCE path computation request 446 message is expanded in a way that allows a single request message to 447 list multiple destinations. 449 In total, there are now 4 possible types of leaves in a P2MP request: 451 o New leaves to add (leaf type = 1) 453 o Old leaves to remove (leaf type = 2) 455 o Old leaves whose path can be modified/reoptimized (leaf type = 3) 457 o Old leaves whose path must be left unchanged (leaf type = 4) 459 A given END-POINTS object gathers the leaves of a given type. The 460 type of leaf in a given END-POINTS object is identified by the END- 461 POINTS object leaf type field. 463 Using the new END-POINTS object, the END-POINTS portion of a request 464 message for the multiple destinations can be reduced by up to 50% for 465 a P2MP path where a single source address has a very large number of 466 destinations. 468 Note that a P2MP path computation request can mix the different types 469 of leaves by including several END-POINTS objects per RP object as 470 shown in the PCReq Routing Backus-Naur Form (RBNF) [RFC5511] format 471 in Section 3.4 ("Request Message Format"). 473 The format of the new END-POINTS object body for IPv4 (Object-Type 3) 474 is as follows: 476 0 1 2 3 477 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Leaf type | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Source IPv4 address | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Destination IPv4 address | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 ~ ... ~ 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Destination IPv4 address | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 1. The New P2MP END-POINTS Object Body Format for IPv4 492 The format of the END-POINTS object body for IPv6 (Object-Type 4) is 493 as follows: 495 0 1 2 3 496 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Leaf type | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | | 501 | Source IPv6 address (16 bytes) | 502 | | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | | 505 | Destination IPv6 address (16 bytes) | 506 | | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 ~ ... ~ 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | | 511 | Destination IPv6 address (16 bytes) | 512 | | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Figure 2. The New P2MP END-POINTS Object Body Format for IPv6 517 The END-POINTS object body has a variable length. These are 518 multiples of 4 bytes for IPv4, and multiples of 16 bytes, plus 4 519 bytes, for IPv6. 521 3.4. Request Message Format 523 As per [RFC5440], a Path Computation Request message (also referred 524 to as a PCReq message) is a PCEP message sent by a PCC to a PCE to 525 request a path computation. A PCReq message may carry more than one 526 path computation request. 528 As per [RFC5541], the OF object MAY be carried within a PCReq 529 message. If an objective function is to be applied to a set of 530 synchronized path computation requests, the OF object MUST be carried 531 just after the corresponding SVEC (Synchronization VECtor) object and 532 MUST NOT be repeated for each elementary request. 534 The PCReq message is encoded as follows using RBNF as defined in 535 [RFC5511]. 537 Below is the message format for the request message: 539 ::= 540 [] 541 543 where: 545 ::= 546 [] 547 [] 548 [] 550 ::=[] 552 ::= 553 554 [] 555 [] 556 [] 557 [] 558 [|] 559 [] 561 where: 563 ::= 564 [[]] 565 [] 567 ::=(|)[] 568 ::=[] 570 Figure 3. The Message Format for the Request Message 572 Note that we preserve compatibility with the [RFC5440] definition of 573 . At least one instance of MUST be present in 574 this message. 576 We have documented the IANA assignment of additional END-POINTS 577 Object-Types in Section 6.5 ("PCEP Objects") of this document. 579 3.5. Reply Message Format 581 The PCEP Path Computation Reply message (also referred to as a PCRep 582 message) is a PCEP message sent by a PCE to a requesting PCC in 583 response to a previously received PCReq message. PCEP supports the 584 bundling of multiple replies to a set of path computation requests 585 within a single PCRep message. 587 The PCRep message is encoded as follows using RBNF as defined in 588 [RFC5511]. 590 Below is the message format for the reply message: 592 ::= 593 595 where: 597 ::=[] 599 ::= 600 [] 601 [] 602 [] 603 [] 605 ::= 606 [] 607 [] 609 ::= (|) [] 611 where: 613 ::=[] 614 [] 615 [] 616 [] 617 [] 619 Figure 4. The Message Format for the Reply Message 621 The optional END-POINTS object in the reply message is used to 622 specify which paths are removed, changed, not changed, or added for 623 the request. The path is only needed for the end points that are 624 added or changed. 626 If the E-bit (ERO-Compress bit) was set to 1 in the request, then the 627 path will be formed by an ERO followed by a list of SEROs. 629 Note that we preserve compatibility with the [RFC5440] definition of 630 and the optional and . 632 3.6. P2MP Objective Functions and Metric Types 634 3.6.1. New Objective Functions 636 Six objective functions have been defined in [RFC5541] for P2P path 637 computation. 639 This document defines two additional objective functions -- namely, 640 SPT (Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to 641 P2MP path computation. Hence two new objective function codes have 642 to be defined. 644 The description of the two new objective functions is as follows. 645 Objective Function Code: 7 647 Name: Shortest Path Tree (SPT) 649 Description: Minimize the maximum source-to-leaf cost with respect 650 to a specific metric or to the TE metric used as the default 651 metric when the metric is not specified (e.g., TE or IGP metric). 653 Objective Function Code: 8 655 Name: Minimum Cost Tree (MCT) 657 Description: Minimize the total cost of the tree, that is the sum 658 of the costs of tree links, with respect to a specific metric or 659 to the TE metric used as the default metric when the metric is not 660 specified. 662 Processing these two new objective functions is subject to the rules 663 defined in [RFC5541]. 665 3.6.2. New Metric Object Types 667 There are three types defined for the object in [RFC5440] -- 668 namely, the IGP metric, the TE metric, and the hop count metric. This 669 document defines three additional types for the object: the 670 P2MP IGP metric, the P2MP TE metric, and the P2MP hop count metric. 671 They encode the sum of the metrics of all links of the tree. We 672 propose the following values for these new metric types: 674 o P2MP IGP metric: T=8 676 o P2MP TE metric: T=9 678 o P2MP hop count metric: T=10 680 3.7. Non-Support of P2MP Path Computation 682 o If a PCE receives a P2MP path request and it understands the P2MP 683 flag in the RP object, but the PCE is not capable of P2MP 684 computation, the PCE MUST send a PCErr message with a PCEP-ERROR 685 object and corresponding Error-Value. The request MUST then be 686 cancelled at the PCC. New Error-Types and Error-Values are 687 requested in Section 6 ("IANA Considerations") of this document. 689 o If the PCE does not understand the P2MP flag in the RP object, 690 then the PCE MUST send a PCErr message with Error-value=2 691 (capability not supported). 693 3.8. Non-Support by Back-Level PCE Implementations 695 If a PCE receives a P2MP request and the PCE does not understand the 696 P2MP flag in the RP object, and therefore the PCEP P2MP extensions, 697 then the PCE SHOULD reject the request. 699 3.9. P2MP TE Path Reoptimization Request 701 A reoptimization request for a P2MP TE path is specified by the use 702 of the R-bit within the RP object as defined in [RFC5440] and is 703 similar to the reoptimization request for a P2P TE path. The only 704 difference is that the PCC MUST insert the list of RROs and SRROs 705 after each type of END-POINTS in the PCReq message, as described in 706 the "Request Message Format" section (Section 3.4) of this document. 708 An example of a reoptimization request and subsequent PCReq message 709 is described below: 711 Common Header 712 RP with P2MP flag/R-bit set 713 END-POINTS for leaf type 3 714 RRO list 715 OF (optional) 717 Figure 5. PCReq Message Example 1 for Optimization 719 In this example, we request reoptimization of the path to all leaves 720 without adding or pruning leaves. The reoptimization request would 721 use an END-POINT type 3. The RRO list would represent the P2MP LSP 722 before the optimization, and the modifiable path leaves would be 723 indicated in the END-POINTS object. 725 It is also possible to specify distinct leaves whose path cannot be 726 modified. An example of the PCReq message in this scenario would be: 728 Common Header 729 RP with P2MP flag/R-bit set 730 END-POINTS for leaf type 3 731 RRO list 732 END-POINTS for leaf type 4 733 RRO list 734 OF (optional) 736 Figure 6. PCReq Message Example 2 for Optimization 738 3.10. Adding and Pruning Leaves to/from the P2MP Tree 740 When adding new leaves to or removing old leaves from the existing 741 P2MP tree, by supplying a list of existing leaves, it is possible to 742 optimize the existing P2MP tree. This section explains the methods 743 for adding new leaves to or removing old leaves from the existing 744 P2MP tree. 746 To add new leaves, the PCC MUST build a P2MP request using END- 747 POINTS with leaf type 1. 749 To remove old leaves, the PCC MUST build a P2MP request using END- 750 POINTS with leaf type 2. If no type-2 END-POINTS exist, then the PCE 751 MUST send an error type 17, value=1: The PCE is not capable of 752 satisfying the request due to no END-POINTS with leaf type 2. 754 When adding new leaves to or removing old leaves from the existing 755 P2MP tree, the PCC MUST also provide the list of old leaves, if any, 756 including END-POINTS with leaf type 3, leaf type 4, or both. New 757 PCEP-ERROR objects and types are necessary for reporting when certain 758 conditions are not satisfied (i.e., when there are no END-POINTS with 759 leaf type 3 or 4, or in the presence of END-POINTS with leaf type 1 760 or 2). A generic "Inconsistent END-POINT" error will be used if a 761 PCC receives a request that has an inconsistent END-POINT (i.e., if a 762 leaf specified as type 1 already exists). These IANA assignments are 763 documented in Section 6.6 ("PCEP-ERROR Objects and Types") of this 764 document. 766 For old leaves, the PCC MUST provide the old path as a list of RROs 767 that immediately follows each END-POINTS object. This document 768 specifies error values when specific conditions are not satisfied. 770 The following examples demonstrate full and partial reoptimization of 771 existing P2MP LSPs: 773 Case 1: Adding leaves with full reoptimization of existing paths 775 Common Header 776 RP with P2MP flag/R-bit set 777 END-POINTS for leaf type 1 778 RRO list 779 END-POINTS for leaf type 3 780 RRO list 781 OF (optional) 783 Case 2: Adding leaves with partial reoptimization of existing paths 785 Common Header 786 RP with P2MP flag/R-bit set 787 END-POINTS for leaf type 1 788 END-POINTS for leaf type 3 789 RRO list 790 END-POINTS for leaf type 4 791 RRO list 792 OF (optional) 794 Case 3: Adding leaves without reoptimization of existing paths 796 Common Header 797 RP with P2MP flag/R-bit set 798 END-POINTS for leaf type 1 799 RRO list 800 END-POINTS for leaf type 4 801 RRO list 802 OF (optional) 804 Case 4: Pruning Leaves with full reoptimization of existing paths 806 Common Header 807 RP with P2MP flag/R-bit set 808 END-POINTS for leaf type 2 809 RRO list 810 END-POINTS for leaf type 3 811 RRO list 812 OF (optional) 814 Case 5: Pruning leaves with partial reoptimization of existing paths 816 Common Header 817 RP with P2MP flag/R-bit set 818 END-POINTS for leaf type 2 819 RRO list 820 END-POINTS for leaf type 3 821 RRO list 822 END-POINTS for leaf type 4 823 RRO list 824 OF (optional) 826 Case 6: Pruning leaves without reoptimization of existing paths 828 Common Header 829 RP with P2MP flag/R-bit set 830 END-POINTS for leaf type 2 831 RRO list 832 END-POINTS for leaf type 4 833 RRO list 834 OF (optional) 836 Case 7: Adding and pruning leaves with full reoptimization of 837 existing paths 839 Common Header 840 RP with P2MP flag/R-bit set 841 END-POINTS for leaf type 1 842 END-POINTS for leaf type 2 843 RRO list 844 END-POINTS for leaf type 3 845 RRO list 846 OF (optional) 848 Case 8: Adding and pruning leaves with partial reoptimization of 849 existing paths 851 Common Header 852 RP with P2MP flag/R-bit set 853 END-POINTS for leaf type 1 854 END-POINTS for leaf type 2 855 RRO list 856 END-POINTS for leaf type 3 857 RRO list 858 END-POINTS for leaf type 4 859 RRO list 860 OF (optional) 862 Case 9: Adding and pruning leaves without reoptimization of existing 863 paths 865 Common Header 866 RP with P2MP flag/R-bit set 867 END-POINTS for leaf type 1 868 END-POINTS for leaf type 2 869 RRO list 870 END-POINTS for leaf type 4 871 RRO list 872 OF (optional) 874 3.11. Discovering Branch Nodes 876 Before computing the P2MP path, a PCE may need to be provided means 877 to know which nodes in the network are capable of acting as branch 878 LSRs. A PCE can discover such capabilities by using the mechanisms 879 defined in [RFC5073]. 881 3.11.1. Branch Node Object 883 The PCC can specify a list of nodes that can be used as branch nodes 884 or a list of nodes that cannot be used as branch nodes by using the 885 Branch Node Capability (BNC) Object. The BNC Object has the same 886 format as the Include Route Object (IRO) defined in [RFC5440], except 887 that it only supports IPv4 and IPv6 prefix sub-objects. Two Object- 888 types are also defined: 890 o Branch node list: List of nodes that can be used as branch nodes. 892 o Non-branch node list: List of nodes that cannot be used as branch 893 nodes. 895 The object can only be carried in a PCReq message. A Path Request 896 may carry at most one Branch Node Object. 898 The Object-Class and Object-types have been allocated by IANA. The 899 IANA assignment is documented in Section 6.5 ("PCEP Objects"). 901 3.12. Synchronization of P2MP TE Path Computation Requests 903 There are cases when multiple P2MP LSPs' computations need to be 904 synchronized. For example, one P2MP LSP is the designated backup of 905 another P2MP LSP. In this case, path diversity for these dependent 906 LSPs may need to be considered during the path computation. 908 The synchronization can be done by using the existing Synchronization 909 VECtor (SVEC) functionality defined in [RFC5440]. 911 An example of synchronizing two P2MP LSPs, each having two leaves for 912 Path Computation Request Messages, is illustrated below: 914 Common Header 915 SVEC for sync of LSP1 and LSP2 916 OF (optional) 917 RP for LSP1 918 END-POINTS1 for LSP1 919 RRO1 list 920 RP for LSP2 921 END-POINTS2 for LSP2 922 RRO2 list 924 Figure 7. PCReq Message Example for Synchronization 926 This specification also defines two new flags to the SVEC Object Flag 927 Field for P2MP path dependent computation requests. The first new 928 flag is to allow the PCC to request that the PCE should compute a 929 secondary P2MP path tree with partial path diversity for specific 930 leaves or a specific S2L sub-path to the primary P2MP path tree. The 931 second flag, would allow the PCC to request that partial paths should 932 be link direction diverse. 934 The following flags are added to the SVEC object body in this 935 document: 937 o P (Partial Path Diverse bit - 1 bit): 939 When set, this would indicate a request for path diversity for a 940 specific leaf, a set of leaves, or all leaves. 942 o D (Link Direction Diverse bit - 1 bit): 944 When set, this would indicate a request that a partial path or 945 paths should be link direction diverse. 947 The IANA assignment is referenced in Section 6.8 of this document. 949 3.13. Request and Response Fragmentation 951 The total PCEP message length, including the common header, is 952 16 bytes. In certain scenarios the P2MP computation request may not 953 fit into a single request or response message. For example, if a 954 tree has many hundreds or thousands of leaves, then the request or 955 response may need to be fragmented into multiple messages. 957 The F-bit has been outlined in "The Extension of the RP Object" 958 (Section 3.3.1) of this document. The F-bit is used in the RP object 959 to signal that the initial request or response was too large to fit 960 into a single message and will be fragmented into multiple messages. 961 In order to identify the single request or response, each message 962 will use the same request ID. 964 3.13.1. Request Fragmentation Procedure 966 If the initial request is too large to fit into a single request 967 message, the PCC will split the request over multiple messages. Each 968 message sent to the PCE, except the last one, will have the F-bit set 969 in the RP object to signify that the request has been fragmented into 970 multiple messages. In order to identify that a series of request 971 messages represents a single request, each message will use the same 972 request ID. 974 The assumption is that request messages are reliably delivered and in 975 sequence, since PCEP relies on TCP. 977 3.13.2. Response Fragmentation Procedure 979 Once the PCE computes a path based on the initial request, a response 980 is sent back to the PCC. If the response is too large to fit into a 981 single response message, the PCE will split the response over 982 multiple messages. Each message sent by the PCE, except the last 983 one, will have the F-bit set in the RP object to signify that the 984 response has been fragmented into multiple messages. In order to 985 identify that a series of response messages represents a single 986 response, each message will use the same response ID. 988 Again, the assumption is that response messages are reliably 989 delivered and in sequence, since PCEP relies on TCP. 991 3.13.3. Fragmentation Examples 993 The following example illustrates the PCC sending a request message 994 with Req-ID1 to the PCE, in order to add one leaf to an existing tree 995 with 1200 leaves. The assumption used for this example is that one 996 request message can hold up to 800 leaves. In this scenario, the 997 original single message needs to be fragmented and sent using two 998 smaller messages, which have the Req-ID1 specified in the RP object, 999 and with the F-bit set on the first message, and cleared on the 1000 second message. 1002 Common Header 1003 RP1 with Req-ID1 and P2MP=1 and F-bit=1 1004 OF (optional) 1005 END-POINTS1 for P2MP 1006 RRO1 list 1008 Common Header 1009 RP2 with Req-ID1 and P2MP=1 and F-bit=0 1010 OF (optional) 1011 END-POINTS1 for P2MP 1012 RRO1 list 1014 Figure 8. PCReq Message Fragmentation Example 1016 To handle a scenario where the last fragmented message piece is lost, 1017 the receiver side of the fragmented message may start a timer once it 1018 receives the first piece of the fragmented message. When the timer 1019 expires and it has not received the last piece of the fragmented 1020 message, it should send an error message to the sender to signal that 1021 it has received an incomplete message. The relevant error message is 1022 documented in Section 3.15 ("P2MP PCEP-ERROR Objects and Types"). 1024 3.14. UNREACH-DESTINATION Object 1026 The PCE path computation request may fail because all or a subset of 1027 the destinations are unreachable. 1029 In such a case, the UNREACH-DESTINATION object allows the PCE to 1030 optionally specify the list of unreachable destinations. 1032 This object can be present in PCRep messages. There can be up to one 1033 such object per RP. 1035 The following UNREACH-DESTINATION objects will be required: 1037 UNREACH-DESTINATION Object-Class is 28. 1038 UNREACH-DESTINATION Object-Type for IPv4 is 1. 1039 UNREACH-DESTINATION Object-Type for IPv6 is 2. 1041 The format of the UNREACH-DESTINATION object body for IPv4 (Object- 1042 Type=1) is as follows: 1044 0 1 2 3 1045 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Destination IPv4 address | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 ~ ... ~ 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Destination IPv4 address | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 Figure 9. UNREACH-DESTINATION Object Body for IPv4 1056 The format of the UNREACH-DESTINATION object body for IPv6 (Object- 1057 Type=2) is as follows: 1059 0 1 2 3 1060 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | | 1063 | Destination IPv6 address (16 bytes) | 1064 | | 1065 | | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 ~ ... ~ 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | | 1070 | Destination IPv6 address (16 bytes) | 1071 | | 1072 | | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 Figure 10. UNREACH-DESTINATION Object Body for IPv6 1077 3.15. P2MP PCEP-ERROR Objects and Types 1079 To indicate an error associated with policy violation, a new error 1080 value "P2MP Path computation not allowed" should be added to the 1081 existing error code for policy violation (Error-Type=5) as defined in 1082 [RFC5440]: 1084 Error-Type=5; Error-Value=7: if a PCE receives a P2MP path 1085 computation request that is not compliant with administrative 1086 privileges (i.e., "The PCE policy does not support P2MP path 1087 computation"), the PCE MUST send a PCErr message with a PCEP-ERROR 1088 object (Error-Type=5) and an Error-Value (Error-Value=7). The 1089 corresponding P2MP path computation request MUST also be cancelled. 1091 To indicate capability errors associated with the P2MP path request, 1092 a new Error-Type (16) and subsequent error-values are defined as 1093 follows for inclusion in the PCEP-ERROR object: 1095 Error-Type=16; Error-Value=1: if a PCE receives a P2MP path request 1096 and the PCE is not capable of satisfying the request due to 1097 insufficient memory, the PCE MUST send a PCErr message with a PCEP- 1098 ERROR object (Error-Type=16) and an Error-Value (Error-Value=1). The 1099 corresponding P2MP path computation request MUST also be cancelled. 1101 Error-Type=16; Error-Value=2: if a PCE receives a P2MP path request 1102 and the PCE is not capable of P2MP computation, the PCE MUST send a 1103 PCErr message with a PCEP-ERROR object (Error-Type=16) and an Error- 1104 Value (Error-Value=2). The corresponding P2MP path computation 1105 request MUST also be cancelled. 1107 To indicate P2MP message fragmentation errors associated with a P2MP 1108 path request, a new Error-Type (18) and subsequent error-values are 1109 defined as follows for inclusion in the PCEP-ERROR object: 1111 Error-Type=18; Error-Value=1: if a PCE has not received the last 1112 piece of the fragmented message, it should send an error message to 1113 the sender to signal that it has received an incomplete message 1114 (i.e., "Fragmented request failure"). The PCE MUST send a PCErr 1115 message with a PCEP-ERROR object (Error-Type=18) and an Error-Value 1116 (Error-Value=1). 1118 3.16. PCEP NO-PATH Indicator 1120 To communicate the reasons for not being able to find P2MP path 1121 computation, the NO-PATH object can be used in the PCRep message. 1123 One new bit is defined in the NO-PATH-VECTOR TLV carried in the 1124 NO-PATH Object: 1126 bit 24: when set, the PCE indicates that there is a reachability 1127 problem with all or a subset of the P2MP destinations. Optionally, 1128 the PCE can specify the destination or list of destinations that are 1129 not reachable using the new UNREACH-DESTINATION object defined in 1130 Section 3.14. 1132 4. Manageability Considerations 1134 [RFC5862] describes various manageability requirements in support of 1135 P2MP path computation when applying PCEP. This section describes how 1136 manageability requirements mentioned in [RFC5862] are supported in 1137 the context of PCEP extensions specified in this document. 1139 Note that [RFC5440] describes various manageability considerations in 1140 PCEP, and most of the manageability requirements mentioned in 1141 [RFC5862] are already covered there. 1143 4.1. Control of Function and Policy 1145 In addition to PCE configuration parameters listed in [RFC5440], the 1146 following additional parameters might be required: 1148 o The ability to enable or disable P2MP path computations on the 1149 PCE. 1151 o The PCE may be configured to enable or disable the advertisement 1152 of its P2MP path computation capability. A PCE can advertise its 1153 P2MP capability via the IGP discovery mechanism discussed in 1154 Section 3.1.1 ("P2MP Computation TLV in the Existing PCE Discovery 1155 Protocol"), or during the Open Message Exchange discussed in 1156 Section 3.1.2 ("Open Message Extension"). 1158 4.2. Information and Data Models 1160 A number of MIB objects have been defined for general PCEP control 1161 and monitoring of P2P computations in [RFC7420]. [RFC5862] specifies 1162 that MIB objects will be required to support the control and 1163 monitoring of the protocol extensions defined in this document. A new 1164 document will be required to define MIB objects for PCEP control and 1165 monitoring of P2MP computations. 1167 The PCEP YANG model "ietf-pcep" is specified in [I-D.ietf-pce-pcep- 1168 yang]. The P2MP capability of a PCEP entity or a configured peer, can 1169 be set using this YANG model. Also the support for P2MP path 1170 computation can be learned using this model. The statistics are 1171 maintained in the model "ietf-pcep-stats" as specified in [I-D.ietf- 1172 pce-pcep-yang]. This YANG model will be required to be augmented to 1173 also include the P2MP related statistics. 1175 4.3. Liveness Detection and Monitoring 1177 There are no additional considerations beyond those expressed in 1178 [RFC5440], since [RFC5862] does not address any additional 1179 requirements. 1181 4.4. Verifying Correct Operation 1183 There are no additional requirements beyond those expressed in 1184 [RFC4657] for verifying the correct operation of the PCEP sessions. 1185 It is expected that future MIB objects will facilitate verification 1186 of correct operation and reporting of P2MP PCEP requests, responses, 1187 and errors. 1189 4.5. Requirements for Other Protocols and Functional Components 1191 The method for the PCE to obtain information about a PCE capable of 1192 P2MP path computations via OSPF and IS-IS is discussed in 1193 Section 3.1.1 ("P2MP Computation TLV in the Existing PCE Discovery 1194 Protocol") of this document. 1196 The subsequent IANA assignments are documented in Section 6.9 ("OSPF 1197 PCE Capability Flag") of this document. 1199 4.6. Impact on Network Operation 1201 It is expected that the use of PCEP extensions specified in this 1202 document will not significantly increase the level of operational 1203 traffic. However, computing a P2MP tree may require more PCE state 1204 compared to a P2P computation. In the event of a major network 1205 failure and multiple recovery P2MP tree computation requests being 1206 sent to the PCE, the load on the PCE may also be significantly 1207 increased. 1209 5. Security Considerations 1211 As described in [RFC5862], P2MP path computation requests are more 1212 CPU-intensive and also utilize more link bandwidth. In the event of 1213 an unauthorized P2MP path computation request, or a denial of service 1214 attack, the subsequent PCEP requests and processing may be disruptive 1215 to the network. Consequently, it is important that implementations 1216 conform to the relevant security requirements that specifically help 1217 to minimize or negate unauthorized P2MP path computation requests and 1218 denial of service attacks. These mechanisms include: 1220 o Securing the PCEP session requests and responses is RECOMMENDED 1221 using TCP security techniques such as TCP Authentication Option 1222 (TCP-AO) [RFC5925] or using Transport Layer Security (TLS) [I- 1223 D.ietf-pce-pceps], as per the recommendations and best current 1224 practices in [RFC7525]. 1226 o Authenticating the PCEP requests and responses to ensure the 1227 message is intact and sent from an authorized node using TCP-AO or 1228 TLS is RECOMMENDED. 1230 o Providing policy control by explicitly defining which PCCs, via IP 1231 access-lists, are allowed to send P2MP path requests to the PCE. 1233 PCEP operates over TCP, so it is also important to secure the PCE and 1234 PCC against TCP denial of service attacks. 1236 As stated in [RFC6952], PCEP implementations SHOULD support TCP-AO 1238 [RFC5925] and not use TCP-MD5 because of the known vulnerabilities 1239 and weakness. 1241 6. IANA Considerations 1243 IANA maintains a registry of PCEP parameters. A number of IANA 1244 considerations have been highlighted in previous sections of this 1245 document. IANA made the allocations as per [RFC6006]. 1247 6.1. PCEP TLV Type Indicators 1249 As described in Section 3.1.2., the P2MP capability TLV allows the 1250 PCE to advertise its P2MP path computation capability. 1252 IANA had made an allocation from the "PCEP TLV Type Indicators" 1253 subregistry, where RFC 6006 was the reference. IANA is requested to 1254 update the reference as follows to point to this document. 1256 Value Description Reference 1258 6 P2MP capable [This I-D] 1260 6.2. Request Parameter Bit Flags 1262 As described in Section 3.3.1, three RP Object Flags have been 1263 defined. 1265 IANA has made an allocations from the PCEP "RP Object Flag Field" 1266 sub-registry, where RFC 6006 was the reference. IANA is requested to 1267 update the reference as follows to point to this document. 1269 Bit Description Reference 1271 18 Fragmentation (F-bit) [This I-D] 1272 19 P2MP (N-bit) [This I-D] 1273 20 ERO-compression (E-bit) [This I-D] 1275 6.3. Objective Functions 1277 As described in Section 3.6.1, two Objective Functions have been 1278 defined. 1280 IANA has made an allocations from the PCEP "Objective Function" sub- 1281 registry, where RFC 6006 was the reference.IANA is requested to 1282 update the reference as follows to point to this document. 1284 Code Point Name Reference 1286 7 SPT [This I-D] 1287 8 MCT [This I-D] 1289 6.4. Metric Object Types 1291 As described in Section 3.6.2, three metric object T fields have been 1292 defined. 1294 IANA has made an allocations from the PCEP "METRIC Object T Field" 1295 sub-registry, where RFC 6006 was the reference. IANA is requested to 1296 update the reference as follows to point to this document. 1298 Value Description Reference 1300 8 P2MP IGP metric [This I-D] 1301 9 P2MP TE metric [This I-D] 1302 10 P2MP hop count metric [This I-D] 1304 6.5. PCEP Objects 1306 As discussed in Section 3.3.2, two END-POINTS Object-Types are 1307 defined. 1309 IANA has made the Object-Type allocations from the "PCEP Objects" 1310 sub-registry, where RFC 6006 was the reference. IANA is requested to 1311 update the reference as follows to point to this document. 1313 Object-Class Value 4 1314 Name END-POINTS 1315 Object-Type 3: IPv4 1316 4: IPv6 1317 5-15: Unassigned 1318 Reference [This I-D] 1320 As described in Section 3.2, Section 3.11.1, and Section 3.14, four 1321 PCEP Object-Classes and six PCEP Object-Types have been defined. 1323 IANA has made an allocations from the "PCEP Objects" sub-registry, 1324 where RFC 6006 was the reference. IANA is requested to update the 1325 reference as follows to point to this document. 1327 Also, for the following four PCEP objects, the code-point 0 for the 1328 Object-Type field are marked "Reserved" with reference to Errata ID 1329 4956. IANA is requested to update the reference to point to this 1330 document. 1332 Object-Class Value 28 1333 Name UNREACH-DESTINATION 1334 Object-Type 0: Reserved 1335 1: IPv4 1336 2: IPv6 1337 3-15: Unassigned 1338 Reference [This I-D] 1340 Object-Class Value 29 1341 Name SERO 1342 Object-Type 0: Reserved 1343 1: SERO 1344 2-15: Unassigned 1345 Reference [This I-D] 1347 Object-Class Value 30 1348 Name SRRO 1349 Object-Type 0: Reserved 1350 1: SRRO 1351 2-15: Unassigned 1352 Reference [This I-D] 1354 Object-Class Value 31 1355 Name Branch Node Capability Object 1356 Object-Type 0: Reserved 1357 1: Branch node list 1358 2: Non-branch node list 1359 3-15: Unassigned 1360 Reference [This I-D] 1362 6.6. PCEP-ERROR Objects and Types 1364 As described in Section 3.15, number of PCEP-ERROR Object Error Types 1365 and Values have been defined. 1367 IANA has made an allocations from the PCEP "PCEP-ERROR Object Error 1368 Types and Values" sub-registry, where RFC 6006 was the reference. 1369 IANA is requested to update the reference as follows to point to this 1370 document. 1372 Error 1373 Type Meaning Reference 1375 5 Policy violation 1376 Error-value=7: [This I-D] 1377 P2MP Path computation is not allowed 1379 16 P2MP Capability Error 1380 Error-Value=0: Unassigned [This I-D] 1381 Error-Value=1: [This I-D] 1382 The PCE is not capable to satisfy the request 1383 due to insufficient memory 1384 Error-Value=2: [This I-D] 1385 The PCE is not capable of P2MP computation 1387 17 P2MP END-POINTS Error 1388 Error-Value=0: Unassigned [This I-D] 1389 Error-Value=1: [This I-D] 1390 The PCE is not capable to satisfy the request 1391 due to no END-POINTS with leaf type 2 1392 Error-Value=2: [This I-D] 1393 The PCE is not capable to satisfy the request 1394 due to no END-POINTS with leaf type 3 1395 Error-Value=3: [This I-D] 1396 The PCE is not capable to satisfy the request 1397 due to no END-POINTS with leaf type 4 1398 Error-Value=4: [This I-D] 1399 The PCE is not capable to satisfy the request 1400 due to inconsistent END-POINTS 1402 18 P2MP Fragmentation Error 1403 Error-Value=0: Unassigned [This I-D] 1404 Error-Value=1: [This I-D] 1405 Fragmented request failure 1407 6.7. PCEP NO-PATH Indicator 1409 As discussed in Section 3.16, NO-PATH-VECTOR TLV Flag Field has been 1410 defined. 1412 IANA has made an allocation from the PCEP "NO-PATH-VECTOR TLV Flag 1413 Field" sub-registry, where RFC 6006 was the reference. IANA is 1414 requested to update the reference as follows to point to this 1415 document. 1417 Bit Description Reference 1419 24 P2MP Reachability Problem [This I-D] 1421 6.8. SVEC Object Flag 1423 As discussed in Section 3.12, two SVEC Object Flags are defined. 1425 IANA has made an allocation from the PCEP "SVEC Object Flag Field" 1426 sub-registry, where RFC 6006 was the reference. IANA is requested to 1427 update the reference as follows to point to this document. 1429 Bit Description Reference 1431 19 Partial Path Diverse [This I-D] 1432 20 Link Direction Diverse [This I-D] 1434 6.9. OSPF PCE Capability Flag 1436 As discussed in Section 3.1.1, OSPF Capability Flag is defined to 1437 indicate P2MP path computation capability. 1439 IANA has made an assignment from the OSPF Parameters "Path 1440 Computation Element (PCE) Capability Flags" registry, where RFC 6006 1441 was the reference. IANA is requested to update the reference as 1442 follows to point to this document. 1444 Bit Description Reference 1446 10 P2MP path computation [This I-D] 1448 7. Acknowledgements 1450 The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan, 1451 Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh Babu K, Dhruv 1452 Dhody, Udayasree Palle, Gaurav Agrawal, Vishwas Manral, Dan 1453 Romascanu, Tim Polk, Stewart Bryant, David Harrington, and Sean 1454 Turner for their valuable comments and input on the RFC 6006. 1456 Thanks to Deborah Brungard for handling of related errata on the RFC 1457 6006. 1459 Authors would like to thank Jonathan Hardwick and Adrian Farrel for 1460 providing review comments with suggested text for this document. 1462 Thanks to Jonathan Hardwick for being the document shepherd and 1463 provide comments and guidance. 1465 Thanks to Ben Niven-Jenkins for RTGDIR reviews. 1467 Thanks to Roni Even for GENART reviews. 1469 Thanks to Fred Baker for OPSDIR review. 1471 Thanks to Deborah Brungard for being the responsible AD and guiding 1472 the authors. 1474 Thanks to Mirja Kuhlewind, Alvaro Retana, Ben Campbell, Adam Roach, 1475 Benoit Claise, Suresh Krishnan and Eric Rescorla for the IESG review 1476 and comments. 1478 8. References 1480 8.1. Normative References 1482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1483 Requirement Levels", BCP 14, RFC 2119, March 1997. 1485 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1486 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1487 Tunnels", RFC 3209, December 2001. 1489 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1490 Switching (GMPLS) Signaling Resource ReserVation 1491 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1492 RFC 3473, January 2003. 1494 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 1495 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 1497 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1498 Yasukawa, Ed., "Extensions to Resource Reservation 1499 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1500 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 1501 2007. 1503 [RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing 1504 Protocol Extensions for Discovery of Traffic Engineering 1505 Node Capabilities", RFC 5073, December 2007. 1507 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1508 Zhang, "OSPF Protocol Extensions for Path Computation 1509 Element (PCE) Discovery", RFC 5088, January 2008. 1511 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1512 Zhang, "IS-IS Protocol Extensions for Path Computation 1513 Element (PCE) Discovery", RFC 5089, January 2008. 1515 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1516 Used to Form Encoding Rules in Various Routing Protocol 1517 Specifications", RFC 5511, April 2009. 1519 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 1520 Computation Element (PCE) Communication Protocol (PCEP)", 1521 RFC 5440, March 2009. 1523 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1524 Objective Functions in the Path Computation Element 1525 Communication Protocol (PCEP)", RFC 5541, June 2009. 1527 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1528 S. Shaffer, "Extensions to OSPF for Advertising Optional 1529 Router Capabilities", RFC 7770, February 2016. 1531 8.2. Informative References 1533 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1534 Computation Element (PCE)-Based Architecture", RFC 4655, 1535 August 2006. 1537 [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation 1538 Element (PCE) Communication Protocol Generic 1539 Requirements", RFC 4657, September 2006. 1541 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 1542 Path Computation Element (PCE) to Point-to-Multipoint 1543 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", 1544 RFC 5671, October 2009. 1546 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 1547 (PCC) - Path Computation Element (PCE) Requirements for 1548 Point-to-Multipoint MPLS-TE", RFC 5862, June 2010. 1550 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1551 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1552 June 2010. 1554 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 1555 Ali, Z., and J. Meuric, "Extensions to the Path 1556 Computation Element Communication Protocol (PCEP) for 1557 Point-to-Multipoint Traffic Engineering Label Switched 1558 Paths", RFC 6006, September 2010. 1560 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 1561 BGP, LDP, PCEP, and MSDP Issues According to the Keying 1562 and Authentication for Routing Protocols (KARP) Design 1563 Guide", RFC 6952, May 2013. 1565 [RFC7420] Koushik, K., Stephan, E., Zhao, Q., King D., and J. 1566 Hardwick "PCE communication protocol (PCEP) Management 1567 Information Base (MIB) Module", RFC 7420, December 2014. 1569 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1570 "Recommendations for Secure Use of Transport Layer 1571 Security (TLS) and Datagram Transport Layer Security 1572 (DTLS)", BCP 195, RFC 7525 May 2015. 1574 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1575 2119 Key Words", BCP 14, RFC 8174, May 2017. 1577 [I-D.ietf-pce-pcep-yang] 1578 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1579 YANG Data Model for Path Computation Element 1580 Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang 1581 (work in progress), June 2017. 1583 [I-D.ietf-pce-pceps] 1584 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1585 Transport for PCEP", draft-ietf-pce-pceps (work in 1586 progress), August 2017. 1588 Appendix A. Summary of the all Changes from RFC 6006 1590 o Updated the text to use the term "PCC" instead of "user" while 1591 describing the encoding rules in section 3.10. 1593 o Updated the example in figure 7 to explicitly include the RP 1594 object. 1596 o Corrected the description of F-bit in the RP object in section 1597 3.13, as per the errata ID 3836. 1599 o Corrected the description of fragmentation procedure for the 1600 response in section 3.13.2, as per the errata ID 3819. 1602 o Corrected the Error-Type in section 3.15 for fragmentation, as per 1603 the errata ID 3830. 1605 o Updated the references for OSPF Router Information Link State 1606 Advertisement (LSA) [RFC7770] and PCEP-MIB [RFC7420]. 1608 o Add updated information and references for PCEP YANG [I-D.ietf-pce- 1609 pcep-yang] and PCEPS [I-D.ietf-pce-pceps]. 1611 o Updated security considerations to include TCP-AO and TLS. 1613 o Updated IANA considerations to mark code-point 0 as reserved for 1614 the object type defined in this document, as per the errata ID 4956. 1615 IANA references are also updated to point to this document. 1617 Appendix A.1 RBNF Changes from RFC 6006 1619 o Update to RBNF for Request message format: 1621 * Update to the request message to allow for the bundling of 1622 multiple path computation requests within a single Path 1623 Computation Request (PCReq) message. 1625 * Addition of in PCReq message. This object was missed 1626 in [RFC6006]. 1628 * Addition of BNC object in PCReq message. This object is required 1629 to support P2MP. It shares the same format as Include Route Object 1630 (IRO) but it is a different object. 1632 * Update to the format, to also allow Secondary Record 1633 Route object (SRRO). This object was missed in [RFC6006]. 1635 * Removed the BANDWIDTH Object followed by Record Route Object 1636 (RRO) from . As BANDWIDTH object doesn't need to follow 1637 for each RRO in the , there already exist BANDWIDTH 1638 object follow and is backward compatible with 1639 [RFC5440]. 1641 * Update to the , to allow optional 1642 BANDWIDTH object only if is included. 1644 * Errata ID: 4867 1646 o Update the RBNF for Reply message format: 1648 * Update to the reply message to allow for bundling of multiple 1649 path computation replies within a single Path Computation Reply 1650 (PCRep) message. 1652 * Addition of the UNREACH-DESTINATION in PCRep message. This 1653 object was missed in [RFC6006]. 1655 * Errata ID: 4868 1657 Contributors 1659 Fabien Verhaeghe 1660 Thales Communication France 1661 160 Bd Valmy 92700 Colombes 1662 France 1663 EMail: fabien.verhaeghe@gmail.com 1665 Tomonori Takeda 1666 NTT Corporation 1667 3-9-11, Midori-Cho 1668 Musashino-Shi, Tokyo 180-8585 1669 Japan 1670 EMail: tomonori.takeda@ntt.com 1672 Zafar Ali 1673 Cisco Systems, Inc. 1674 2000 Innovation Drive 1675 Kanata, Ontario K2K 3E8 1676 Canada 1677 EMail: zali@cisco.com 1679 Julien Meuric 1680 Orange 1681 2, Avenue Pierre-Marzin 1682 22307 Lannion Cedex 1683 France 1684 EMail: julien.meuric@orange.com 1686 Jean-Louis Le Roux 1687 Orange 1688 2, Avenue Pierre-Marzin 1689 22307 Lannion Cedex 1690 France 1691 EMail: jeanlouis.leroux@orange.com 1693 Mohamad Chaitou 1694 France 1695 EMail: mohamad.chaitou@gmail.com 1697 Udayasree Palle 1698 Huawei Technologies 1699 Divyashree Techno Park, Whitefield 1700 Bangalore, Karnataka 560066 1701 India 1702 EMail: udayasreereddy@gmail.com 1704 Authors' Addresses 1705 Quintin Zhao 1706 Huawei Technology 1707 125 Nagog Technology Park 1708 Acton, MA 01719 1709 US 1710 EMail: quintin.zhao@huawei.com 1712 Dhruv Dhody 1713 Huawei Technology 1714 Divyashree Techno Park, Whitefield 1715 Bangalore, Karnataka 560066 1716 India 1717 EMail: dhruv.ietf@gmail.com 1719 Ramanjaneya Reddy Palleti 1720 Huawei Technology 1721 Divyashree Techno Park, Whitefield 1722 Bangalore, Karnataka 560066 1723 India 1724 EMail: ramanjaneya.palleti@huawei.com 1726 Daniel King 1727 Old Dog Consulting 1728 UK 1729 EMail: daniel@olddog.co.uk