idnits 2.17.1 draft-ietf-pce-rfc6006bis-02.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 (April 10, 2017) is 2572 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 1428, but not defined -- Obsolete informational reference (is this intentional?): RFC 6006 (Obsoleted by RFC 8306) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 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: October 12, 2017 D. King 7 Old Dog Consulting 8 April 10, 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-02 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 September 11, 2017. 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 ....................................................3 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 84 Discovery Protocol ..................................6 85 3.1.2. Open Message Extension ..............................7 86 3.2. Efficient Presentation of P2MP LSPs ........................7 87 3.3. P2MP Path Computation Request/Reply Message Extensions .....8 88 3.3.1. The Extension of the RP Object ......................8 89 3.3.2. The New P2MP END-POINTS Object ......................9 90 3.4. Request Message Format ....................................12 91 3.5. Reply Message Format ......................................12 92 3.6. P2MP Objective Functions and Metric Types .................13 93 3.6.1. New Objective Functions ............................13 94 3.6.2. New Metric Object Types ............................14 95 3.7. Non-Support of P2MP Path Computation ......................14 96 3.8. Non-Support by Back-Level PCE Implementations .............15 97 3.9. P2MP TE Path Reoptimization Request .......................15 98 3.10. Adding and Pruning Leaves to/from the P2MP Tree ..........16 99 3.11. Discovering Branch Nodes .................................19 100 3.11.1. Branch Node Object ................................19 101 3.12. Synchronization of P2MP TE Path Computation Requests .....19 102 3.13. Request and Response Fragmentation .......................20 103 3.13.1. Request Fragmentation Procedure ...................21 104 3.13.2. Response Fragmentation Procedure ..................21 105 3.13.3. Fragmentation Examples ............................21 106 3.14. UNREACH-DESTINATION Object ...............................22 107 3.15. P2MP PCEP-ERROR Objects and Types ........................23 108 3.16. PCEP NO-PATH Indicator ...................................24 109 4. Manageability Considerations ...................................25 110 4.1. Control of Function and Policy ............................25 111 4.2. Information and Data Models ...............................25 112 4.3. Liveness Detection and Monitoring .........................25 113 4.4. Verifying Correct Operation ...............................25 114 4.5. Requirements for Other Protocols and Functional 115 Components ................................................26 116 4.6. Impact on Network Operation ...............................26 117 5. Security Considerations ........................................26 118 6. IANA Considerations ............................................27 119 6.1. PCEP TLV Type Indicators ..................................27 120 6.2. Request Parameter Bit Flags ...............................27 121 6.3. Objective Functions .......................................27 122 6.4. Metric Object Types .......................................27 123 6.5. PCEP Objects ..............................................28 124 6.6. PCEP-ERROR Objects and Types ..............................29 125 6.7. PCEP NO-PATH Indicator ....................................30 126 6.8. SVEC Object Flag ..........................................30 127 6.9. OSPF PCE Capability Flag ..................................30 128 7. Acknowledgements ...............................................30 129 8. References .....................................................30 130 8.1. Normative References ......................................30 131 8.2. Informative References ....................................32 133 1. Introduction 135 The Path Computation Element (PCE) defined in [RFC4655] is an entity 136 that is capable of computing a network path or route based on a 137 network graph, and applying computational constraints. A Path 138 Computation Client (PCC) may make requests to a PCE for paths to be 139 computed. 141 [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic 142 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 143 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. 145 The PCE has been identified as a suitable application for the 146 computation of paths for P2MP TE LSPs [RFC5671]. 148 The PCE communication Protocol (PCEP) is designed as a communication 149 protocol between PCCs and PCEs for point-to-point (P2P) path 150 computations and is defined in [RFC5440]. However, that 151 specification does not provide a mechanism to request path 152 computation of P2MP TE LSPs. 154 A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. 155 These S2L sub-LSPs are set up between ingress and egress Label 156 Switching Routers (LSRs) and are appropriately overlaid to construct 157 a P2MP TE LSP. During path computation, the P2MP TE LSP may be 158 determined as a set of S2L sub-LSPs that are computed separately and 159 combined to give the path of the P2MP LSP, or the entire P2MP TE LSP 160 may be determined as a P2MP tree in a single computation. 162 This document relies on the mechanisms of PCEP to request path 163 computation for P2MP TE LSPs. One path computation request message 164 from a PCC may request the computation of the whole P2MP TE LSP, or 165 the request may be limited to a sub-set of the S2L sub-LSPs. In the 166 extreme case, the PCC may request the S2L sub-LSPs to be computed 167 individually with it being the PCC's responsibility to decide whether 168 to signal individual S2L sub-LSPs or combine the computation results 169 to signal the entire P2MP TE LSP. Hence the PCC may use one path 170 computation request message or may split the request across multiple 171 path computation messages. 173 This document obsoletes RFC 6006 and incorporates all outstanding 174 Errata: 176 o Erratum with IDs: 3819, 3830, 3836, 4867, and 4868. 178 1.1. Terminology 180 Terminology used in this document: 182 TE LSP: Traffic Engineering Label Switched Path. 184 LSR: Label Switching Router. 186 OF: Objective Function: A set of one or more optimization criteria 187 used for the computation of a single path (e.g., path cost 188 minimization), or for the synchronized computation of a set of 189 paths (e.g., aggregate bandwidth consumption minimization). 191 P2MP: Point-to-Multipoint. 193 P2P: Point-to-Point. 195 This document also uses the terminology defined in [RFC4655], 196 [RFC4875], and [RFC5440]. 198 1.2. Requirements Language 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 202 document are to be interpreted as described in RFC 2119 [RFC2119]. 204 2. PCC-PCE Communication Requirements 206 This section summarizes the PCC-PCE communication requirements for 207 P2MP MPLS-TE LSPs described in [RFC5862]. The numbering system 208 corresponds to the requirement numbers used in [RFC5862]. 210 1. The PCC MUST be able to specify that the request is a P2MP path 211 computation request. 213 2. The PCC MUST be able to specify that objective functions are to 214 be applied to the P2MP path computation request. 216 3. The PCE MUST have the capability to reject a P2MP path request 217 and indicate non-support of P2MP path computation. 219 4. The PCE MUST provide an indication of non-support of P2MP path 220 computation by back-level PCE implementations. 222 5. A P2MP path computation request MUST be able to list multiple 223 destinations. 225 6. A P2MP path computation response MUST be able to carry the path 226 of a P2MP LSP. 228 7. By default, the path returned by the PCE SHOULD use the 229 compressed format. 231 8. It MUST be possible for a single P2MP path computation request or 232 response to be conveyed by a sequence of messages. 234 9. It MUST NOT be possible for a single P2MP path computation 235 request to specify a set of different constraints, traffic 236 parameters, or quality-of-service requirements for different 237 destinations of a P2MP LSP. 239 10. P2MP path modification and P2MP path diversity MUST be supported. 241 11. It MUST be possible to reoptimize existing P2MP TE LSPs. 243 12. It MUST be possible to add and remove P2MP destinations from 244 existing paths. 246 13. It MUST be possible to specify a list of applicable branch nodes 247 to use when computing the P2MP path. 249 14. It MUST be possible for a PCC to discover P2MP path computation 250 capability. 252 15. The PCC MUST be able to request diverse paths when requesting a 253 P2MP path. 255 3. Protocol Procedures and Extensions 257 The following section describes the protocol extensions required to 258 satisfy the requirements specified in Section 2 ("PCC-PCE 259 Communication Requirements") of this document. 261 3.1. P2MP Capability Advertisement 263 3.1.1. P2MP Computation TLV in the Existing PCE Discovery Protocol 265 [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF 266 Router Information Link State Advertisement (LSA) defined in 267 [RFC7770] to facilitate PCE discovery using OSPF. [RFC5088] 268 specifies that no new sub-TLVs may be added to the PCED TLV. This 269 document defines a new flag in the OSPF PCE Capability Flags to 270 indicate the capability of P2MP computation. 272 Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE 273 Discovery using IS-IS. This document will use the same flag 274 requested for the OSPF PCE Capability Flags sub-TLV to allow IS-IS to 275 indicate the capability of P2MP computation. 277 The IANA assignment for a shared OSPF and IS-IS P2MP Capability Flag 278 is documented in Section 6.9 ("OSPF PCE Capability Flag") of this 279 document. 281 PCEs wishing to advertise that they support P2MP path computation 282 would set the bit (10) accordingly. PCCs that do not understand this 283 bit will ignore it (per [RFC5088] and [RFC5089]). PCEs that do not 284 support P2MP will leave the bit clear (per the default behavior 285 defined in [RFC5088] and [RFC5089]). 287 PCEs that set the bit to indicate support of P2MP path computation 288 MUST follow the procedures in Section 3.3.2 ("The New P2MP END-POINTS 289 Object") to further qualify the level of support. 291 3.1.2. Open Message Extension 293 Based on the Capabilities Exchange requirement described in 294 [RFC5862], if a PCE does not advertise its P2MP capability during 295 discovery, PCEP should be used to allow a PCC to discover, during the 296 Open Message Exchange, which PCEs are capable of supporting P2MP path 297 computation. 299 To satisfy this requirement, we extend the PCEP OPEN object by 300 defining a new optional TLV to indicate the PCE's capability to 301 perform P2MP path computations. 303 IANA has allocated value 6 from the "PCEP TLV Type Indicators" sub- 304 registry, as documented in Section 6.1 ("PCEP TLV Type Indicators"). 305 The description is "P2MP capable", and the length value is 2 bytes. 306 The value field is set to default value 0. 308 The inclusion of this TLV in an OPEN object indicates that the sender 309 can perform P2MP path computations. 311 The capability TLV is meaningful only for a PCE, so it will typically 312 appear only in one of the two Open messages during PCE session 313 establishment. However, in case of PCE cooperation (e.g., 314 inter-domain), when a PCE behaving as a PCC initiates a PCE session 315 it SHOULD also indicate its path computation capabilities. 317 3.2. Efficient Presentation of P2MP LSPs 319 When specifying additional leaves, or optimizing existing P2MP TE 320 LSPs as specified in [RFC5862], it may be necessary to pass existing 321 P2MP LSP route information between the PCC and PCE in the request and 322 reply messages. In each of these scenarios, we need new path objects 323 for efficiently passing the existing P2MP LSP between the PCE and 324 PCC. 326 We specify the use of the Resource Reservation Protocol Traffic 327 Engineering (RSVP-TE) extensions Explicit Route Object (ERO) to 328 encode the explicit route of a TE LSP through the network. PCEP ERO 329 sub-object types correspond to RSVP-TE ERO sub-object types. The 330 format and content of the ERO object are defined in [RFC3209] and 331 [RFC3473]. 333 The Secondary Explicit Route Object (SERO) is used to specify the 334 explicit route of a S2L sub-LSP. The path of each subsequent S2L 335 sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object SERO. 336 The format of the SERO is the same as an ERO defined in [RFC3209] and 337 [RFC3473]. 339 The Secondary Record Route Object (SRRO) is used to record the 340 explicit route of the S2L sub-LSP. The class of the P2MP SRRO is the 341 same as the SRRO defined in [RFC4873]. 343 The SERO and SRRO are used to report the route of an existing TE LSP 344 for which a reoptimization is desired. The format and content of the 345 SERO and SRRO are defined in [RFC4875]. 347 A new PCEP object class and type are requested for SERO and SRRO. 349 Object-Class Value 29 350 Name SERO 351 Object-Type 1: SERO 352 2-15: Unassigned 353 Reference RFC 6006 355 Object-Class Value 30 356 Name SRRO 357 Object-Type 1: SRRO 358 2-15: Unassigned 359 Reference RFC 6006 361 The IANA assignment is documented in Section 6.5 ("PCEP Objects"). 363 Since the explicit path is available for immediate signaling by the 364 MPLS or GMPLS control plane, the meanings of all of the sub-objects 365 and fields in this object are identical to those defined for the ERO. 367 3.3. P2MP Path Computation Request/Reply Message Extensions 369 This document extends the existing P2P RP (Request Parameters) object 370 so that a PCC can signal a P2MP path computation request to the PCE 371 receiving the PCEP request. The END-POINTS object is also extended 372 to improve the efficiency of the message exchange between PCC and PCE 373 in the case of P2MP path computation. 375 3.3.1. The Extension of the RP Object 377 The PCE path computation request and reply messages will need the 378 following additional parameters to indicate to the receiving PCE that 379 the request and reply messages have been fragmented across multiple 380 messages, that they have been requested for a P2MP path, and whether 381 the route is represented in the compressed or uncompressed format. 383 This document adds the following flags to the RP Object: 385 The F-bit is added to the flag bits of the RP object to indicate to 386 the receiver that the request is part of a fragmented request, or is 387 not a fragmented request. 389 o F (RP fragmentation bit - 1 bit): 391 0: This indicates that the RP is not fragmented or it is the last 392 piece of the fragmented RP. 394 1: This indicates that the RP is fragmented and this is not the 395 last piece of the fragmented RP. The receiver needs to wait 396 for additional fragments until it receives an RP with the same 397 RP-ID and with the F-bit set to 0. 399 The N-bit is added in the flag bits field of the RP object to signal 400 the receiver of the message that the request/reply is for P2MP or is 401 not for P2MP. 403 o N (P2MP bit - 1 bit): 405 0: This indicates that this is not a PCReq or PCRep message for 406 P2MP. 408 1: This indicates that this is a PCReq or PCRep message for P2MP. 410 The E-bit is added in the flag bits field of the RP object to signal 411 the receiver of the message that the route is in the compressed 412 format or is not in the compressed format. By default, the path 413 returned by the PCE SHOULD use the compressed format. 415 o E (ERO-compression bit - 1 bit): 417 0: This indicates that the route is not in the compressed format. 419 1: This indicates that the route is in the compressed format. 421 The IANA assignment is documented in Section 6.2 ("Request Parameter 422 Bit Flags") of this document. 424 3.3.2. The New P2MP END-POINTS Object 426 The END-POINTS object is used in a PCReq message to specify the 427 source IP address and the destination IP address of the path for 428 which a path computation is requested. To represent the end points 429 for a P2MP path efficiently, we define two new types of END-POINTS 430 objects for the P2MP path: 432 o Old leaves whose path can be modified/reoptimized; 434 o Old leaves whose path must be left unchanged. 436 With the new END-POINTS object, the PCE path computation request 437 message is expanded in a way that allows a single request message to 438 list multiple destinations. 440 In total, there are now 4 possible types of leaves in a P2MP request: 442 o New leaves to add (leaf type = 1) 444 o Old leaves to remove (leaf type = 2) 446 o Old leaves whose path can be modified/reoptimized (leaf type = 3) 448 o Old leaves whose path must be left unchanged (leaf type = 4) 450 A given END-POINTS object gathers the leaves of a given type. The 451 type of leaf in a given END-POINTS object is identified by the END- 452 POINTS object leaf type field. 454 Using the new END-POINTS object, the END-POINTS portion of a request 455 message for the multiple destinations can be reduced by up to 50% for 456 a P2MP path where a single source address has a very large number of 457 destinations. 459 Note that a P2MP path computation request can mix the different types 460 of leaves by including several END-POINTS objects per RP object as 461 shown in the PCReq Routing Backus-Naur Form (RBNF) [RFC5511] format 462 in Section 3.4 ("Request Message Format"). 464 The format of the new END-POINTS object body for IPv4 (Object-Type 3) 465 is as follows: 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Leaf type | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Source IPv4 address | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Destination IPv4 address | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 ~ ... ~ 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Destination IPv4 address | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 Figure 1. The New P2MP END-POINTS Object Body Format for IPv4 483 The format of the END-POINTS object body for IPv6 (Object-Type 4) is 484 as follows: 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Leaf type | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | 492 | Source IPv6 address (16 bytes) | 493 | | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | | 496 | Destination IPv6 address (16 bytes) | 497 | | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 ~ ... ~ 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | | 502 | Destination IPv6 address (16 bytes) | 503 | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 2. The New P2MP END-POINTS Object Body Format for IPv6 508 The END-POINTS object body has a variable length. These are 509 multiples of 4 bytes for IPv4, and multiples of 16 bytes, plus 4 510 bytes, for IPv6. 512 3.4. Request Message Format 514 As per [RFC5440], a Path Computation Request message (also referred 515 to as a PCReq message) is a PCEP message sent by a PCC to a PCE to 516 request a path computation. A PCReq message may carry more than one 517 path computation request. 519 As per [RFC5541], the OF object MAY be carried within a PCReq 520 message. If an objective function is to be applied to a set of 521 synchronized path computation requests, the OF object MUST be carried 522 just after the corresponding SVEC (Synchronization VECtor) object and 523 MUST NOT be repeated for each elementary request. 525 The PCReq message is encoded as follows using RBNF as defined in 526 [RFC5511]. 528 Below is the message format for the request message: 530 ::= 531 [] 532 534 where: 536 ::= 537 [] 538 [] 539 [] 541 ::=[] 543 ::= 544 545 [] 546 [] 547 [] 548 [] 549 [|] 550 [] 552 where: 554 ::= 555 [[]] 556 [] 558 ::=(|)[] 559 ::=[] 561 Figure 3. The Message Format for the Request Message 563 Note that we preserve compatibility with the [RFC5440] definition of 564 . At least one instance of MUST be present in 565 this message. 567 We have documented the IANA assignment of additional END-POINTS 568 Object-Types in Section 6.5 ("PCEP Objects") of this document. 570 3.5. Reply Message Format 572 The PCEP Path Computation Reply message (also referred to as a PCRep 573 message) is a PCEP message sent by a PCE to a requesting PCC in 574 response to a previously received PCReq message. PCEP supports the 575 bundling of multiple replies to a set of path computation requests 576 within a single PCRep message. 578 The PCRep message is encoded as follows using RBNF as defined in 579 [RFC5511]. 581 Below is the message format for the reply message: 583 ::= 584 586 where: 588 ::=[] 590 ::= 591 [] 592 [] 593 [] 594 [] 596 ::= 597 [] 598 [] 600 ::= (|) [] 602 where: 604 ::=[] 605 [] 606 [] 607 [] 608 [] 610 Figure 4. The Message Format for the Reply Message 612 The optional END-POINTS object in the reply message is used to 613 specify which paths are removed, changed, not changed, or added for 614 the request. The path is only needed for the end points that are 615 added or changed. 617 If the E-bit (ERO-Compress bit) was set to 1 in the request, then the 618 path will be formed by an ERO followed by a list of SEROs. 620 Note that we preserve compatibility with the [RFC5440] definition of 621 and the optional and . 623 3.6. P2MP Objective Functions and Metric Types 625 3.6.1. New Objective Functions 627 Six objective functions have been defined in [RFC5541] for P2P path 628 computation. 630 This document defines two additional objective functions -- namely, 631 SPT (Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to 632 P2MP path computation. Hence two new objective function codes have 633 to be defined. 635 The description of the two new objective functions is as follows. 636 Objective Function Code: 7 638 Name: Shortest Path Tree (SPT) 640 Description: Minimize the maximum source-to-leaf cost with respect 641 to a specific metric or to the TE metric used as the default 642 metric when the metric is not specified (e.g., TE or IGP metric). 644 Objective Function Code: 8 646 Name: Minimum Cost Tree (MCT) 648 Description: Minimize the total cost of the tree, that is the sum 649 of the costs of tree links, with respect to a specific metric or 650 to the TE metric used as the default metric when the metric is not 651 specified. 653 Processing these two new objective functions is subject to the rules 654 defined in [RFC5541]. 656 3.6.2. New Metric Object Types 658 There are three types defined for the object in [RFC5440] -- 659 namely, the IGP metric, the TE metric, and the hop count metric. This 660 document defines three additional types for the object: the 661 P2MP IGP metric, the P2MP TE metric, and the P2MP hop count metric. 662 They encode the sum of the metrics of all links of the tree. We 663 propose the following values for these new metric types: 665 o P2MP IGP metric: T=8 667 o P2MP TE metric: T=9 669 o P2MP hop count metric: T=10 671 3.7. Non-Support of P2MP Path Computation 673 o If a PCE receives a P2MP path request and it understands the P2MP 674 flag in the RP object, but the PCE is not capable of P2MP 675 computation, the PCE MUST send a PCErr message with a PCEP-ERROR 676 object and corresponding Error-Value. The request MUST then be 677 cancelled at the PCC. New Error-Types and Error-Values are 678 requested in Section 6 ("IANA Considerations") of this document. 680 o If the PCE does not understand the P2MP flag in the RP object, 681 then the PCE MUST send a PCErr message with Error-value=2 682 (capability not supported). 684 3.8. Non-Support by Back-Level PCE Implementations 686 If a PCE receives a P2MP request and the PCE does not understand the 687 P2MP flag in the RP object, and therefore the PCEP P2MP extensions, 688 then the PCE SHOULD reject the request. 690 3.9. P2MP TE Path Reoptimization Request 692 A reoptimization request for a P2MP TE path is specified by the use 693 of the R-bit within the RP object as defined in [RFC5440] and is 694 similar to the reoptimization request for a P2P TE path. The only 695 difference is that the user MUST insert the list of RROs and SRROs 696 after each type of END-POINTS in the PCReq message, as described in 697 the "Request Message Format" section (Section 3.4) of this document. 699 An example of a reoptimization request and subsequent PCReq message 700 is described below: 702 Common Header 703 RP with P2MP flag/R-bit set 704 END-POINTS for leaf type 3 705 RRO list 706 OF (optional) 708 Figure 5. PCReq Message Example 1 for Optimization 710 In this example, we request reoptimization of the path to all leaves 711 without adding or pruning leaves. The reoptimization request would 712 use an END-POINT type 3. The RRO list would represent the P2MP LSP 713 before the optimization, and the modifiable path leaves would be 714 indicated in the END-POINTS object. 716 It is also possible to specify distinct leaves whose path cannot be 717 modified. An example of the PCReq message in this scenario would be: 719 Common Header 720 RP with P2MP flag/R-bit set 721 END-POINTS for leaf type 3 722 RRO list 723 END-POINTS for leaf type 4 724 RRO list 725 OF (optional) 727 Figure 6. PCReq Message Example 2 for Optimization 729 3.10. Adding and Pruning Leaves to/from the P2MP Tree 731 When adding new leaves to or removing old leaves from the existing 732 P2MP tree, by supplying a list of existing leaves, it SHOULD be 733 possible to optimize the existing P2MP tree. This section explains 734 the methods for adding new leaves to or removing old leaves from the 735 existing P2MP tree. 737 To add new leaves, the user MUST build a P2MP request using END- 738 POINTS with leaf type 1. 740 To remove old leaves, the user must build a P2MP request using END- 741 POINTS with leaf type 2. If no type-2 END-POINTS exist, then the PCE 742 MUST send an error type 17, value=1: The PCE is not capable of 743 satisfying the request due to no END-POINTS with leaf type 2. 745 When adding new leaves to or removing old leaves from the existing 746 P2MP tree, the PCC must also provide the list of old leaves, if any, 747 including END-POINTS with leaf type 3, leaf type 4, or both. New 748 PCEP-ERROR objects and types are necessary for reporting when certain 749 conditions are not satisfied (i.e., when there are no END-POINTS with 750 leaf type 3 or 4, or in the presence of END-POINTS with leaf type 1 751 or 2). A generic "Inconsistent END-POINT" error will be used if a 752 PCC receives a request that has an inconsistent END-POINT (i.e., if a 753 leaf specified as type 1 already exists). These IANA assignments are 754 documented in Section 6.6 ("PCEP-ERROR Objects and Types") of this 755 document. 757 For old leaves, the user MUST provide the old path as a list of RROs 758 that immediately follows each END-POINTS object. This document 759 specifies error values when specific conditions are not satisfied. 761 The following examples demonstrate full and partial reoptimization of 762 existing P2MP LSPs: 764 Case 1: Adding leaves with full reoptimization of existing paths 766 Common Header 767 RP with P2MP flag/R-bit set 768 END-POINTS for leaf type 1 769 RRO list 770 END-POINTS for leaf type 3 771 RRO list 772 OF (optional) 774 Case 2: Adding leaves with partial reoptimization of existing paths 776 Common Header 777 RP with P2MP flag/R-bit set 778 END-POINTS for leaf type 1 779 END-POINTS for leaf type 3 780 RRO list 781 END-POINTS for leaf type 4 782 RRO list 783 OF (optional) 785 Case 3: Adding leaves without reoptimization of existing paths 787 Common Header 788 RP with P2MP flag/R-bit set 789 END-POINTS for leaf type 1 790 RRO list 791 END-POINTS for leaf type 4 792 RRO list 793 OF (optional) 795 Case 4: Pruning Leaves with full reoptimization of existing paths 797 Common Header 798 RP with P2MP flag/R-bit set 799 END-POINTS for leaf type 2 800 RRO list 801 END-POINTS for leaf type 3 802 RRO list 803 OF (optional) 805 Case 5: Pruning leaves with partial reoptimization of existing paths 807 Common Header 808 RP with P2MP flag/R-bit set 809 END-POINTS for leaf type 2 810 RRO list 811 END-POINTS for leaf type 3 812 RRO list 813 END-POINTS for leaf type 4 814 RRO list 815 OF (optional) 817 Case 6: Pruning leaves without reoptimization of existing paths 819 Common Header 820 RP with P2MP flag/R-bit set 821 END-POINTS for leaf type 2 822 RRO list 823 END-POINTS for leaf type 4 824 RRO list 825 OF (optional) 827 Case 7: Adding and pruning leaves with full reoptimization of 828 existing paths 830 Common Header 831 RP with P2MP flag/R-bit set 832 END-POINTS for leaf type 1 833 END-POINTS for leaf type 2 834 RRO list 835 END-POINTS for leaf type 3 836 RRO list 837 OF (optional) 839 Case 8: Adding and pruning leaves with partial reoptimization of 840 existing paths 842 Common Header 843 RP with P2MP flag/R-bit set 844 END-POINTS for leaf type 1 845 END-POINTS for leaf type 2 846 RRO list 847 END-POINTS for leaf type 3 848 RRO list 849 END-POINTS for leaf type 4 850 RRO list 851 OF (optional) 853 Case 9: Adding and pruning leaves without reoptimization of existing 854 paths 856 Common Header 857 RP with P2MP flag/R-bit set 858 END-POINTS for leaf type 1 859 END-POINTS for leaf type 2 860 RRO list 861 END-POINTS for leaf type 4 862 RRO list 863 OF (optional) 865 3.11. Discovering Branch Nodes 867 Before computing the P2MP path, a PCE may need to be provided means 868 to know which nodes in the network are capable of acting as branch 869 LSRs. A PCE can discover such capabilities by using the mechanisms 870 defined in [RFC5073]. 872 3.11.1. Branch Node Object 874 The PCC can specify a list of nodes that can be used as branch nodes 875 or a list of nodes that cannot be used as branch nodes by using the 876 Branch Node Capability (BNC) Object. The BNC Object has the same 877 format as the Include Route Object (IRO) defined in [RFC5440], except 878 that it only supports IPv4 and IPv6 prefix sub-objects. Two Object- 879 types are also defined: 881 o Branch node list: List of nodes that can be used as branch nodes. 883 o Non-branch node list: List of nodes that cannot be used as branch 884 nodes. 886 The object can only be carried in a PCReq message. A Path Request 887 may carry at most one Branch Node Object. 889 The Object-Class and Object-types have been allocated by IANA. The 890 IANA assignment is documented in Section 6.5 ("PCEP Objects"). 892 3.12. Synchronization of P2MP TE Path Computation Requests 894 There are cases when multiple P2MP LSPs' computations need to be 895 synchronized. For example, one P2MP LSP is the designated backup of 896 another P2MP LSP. In this case, path diversity for these dependent 897 LSPs may need to be considered during the path computation. 899 The synchronization can be done by using the existing Synchronization 900 VECtor (SVEC) functionality defined in [RFC5440]. 902 An example of synchronizing two P2MP LSPs, each having two leaves for 903 Path Computation Request Messages, is illustrated below: 905 Common Header 906 SVEC for sync of LSP1 and LSP2 907 OF (optional) 908 RP for LSP1 909 END-POINTS1 for LSP1 910 RRO1 list 911 RP for LSP2 912 END-POINTS2 for LSP2 913 RRO2 list 915 Figure 7. PCReq Message Example for Synchronization 917 This specification also defines two new flags to the SVEC Object Flag 918 Field for P2MP path dependent computation requests. The first new 919 flag is to allow the PCC to request that the PCE should compute a 920 secondary P2MP path tree with partial path diversity for specific 921 leaves or a specific S2L sub-path to the primary P2MP path tree. The 922 second flag, would allow the PCC to request that partial paths should 923 be link direction diverse. 925 The following flags are added to the SVEC object body in this 926 document: 928 o P (Partial Path Diverse bit - 1 bit): 930 When set, this would indicate a request for path diversity for a 931 specific leaf, a set of leaves, or all leaves. 933 o D (Link Direction Diverse bit - 1 bit): 935 When set, this would indicate a request that a partial path or 936 paths should be link direction diverse. 938 The IANA assignment is referenced in Section 6.8 of this document. 940 3.13. Request and Response Fragmentation 942 The total PCEP message length, including the common header, is 943 16 bytes. In certain scenarios the P2MP computation request may not 944 fit into a single request or response message. For example, if a 945 tree has many hundreds or thousands of leaves, then the request or 946 response may need to be fragmented into multiple messages. 948 The F-bit has been outlined in "The Extension of the RP Object" 949 (Section 3.3.1) of this document. The F-bit is used in the RP object 950 to signal that the initial request or response was too large to fit 951 into a single message and will be fragmented into multiple messages. 952 In order to identify the single request or response, each message 953 will use the same request ID. 955 3.13.1. Request Fragmentation Procedure 957 If the initial request is too large to fit into a single request 958 message, the PCC will split the request over multiple messages. Each 959 message sent to the PCE, except the last one, will have the F-bit set 960 in the RP object to signify that the request has been fragmented into 961 multiple messages. In order to identify that a series of request 962 messages represents a single request, each message will use the same 963 request ID. 965 The assumption is that request messages are reliably delivered and in 966 sequence, since PCEP relies on TCP. 968 3.13.2. Response Fragmentation Procedure 970 Once the PCE computes a path based on the initial request, a response 971 is sent back to the PCC. If the response is too large to fit into a 972 single response message, the PCE will split the response over 973 multiple messages. Each message sent by the PCE, except the last 974 one, will have the F-bit set in the RP object to signify that the 975 response has been fragmented into multiple messages. In order to 976 identify that a series of response messages represents a single 977 response, each message will use the same response ID. 979 Again, the assumption is that response messages are reliably 980 delivered and in sequence, since PCEP relies on TCP. 982 3.13.3. Fragmentation Examples 984 The following example illustrates the PCC sending a request message 985 with Req-ID1 to the PCE, in order to add one leaf to an existing tree 986 with 1200 leaves. The assumption used for this example is that one 987 request message can hold up to 800 leaves. In this scenario, the 988 original single message needs to be fragmented and sent using two 989 smaller messages, which have the Req-ID1 specified in the RP object, 990 and with the F-bit set on the first message, and cleared on the 991 second message. 993 Common Header 994 RP1 with Req-ID1 and P2MP=1 and F-bit=1 995 OF (optional) 996 END-POINTS1 for P2MP 997 RRO1 list 999 Common Header 1000 RP2 with Req-ID1 and P2MP=1 and F-bit=0 1001 OF (optional) 1002 END-POINTS1 for P2MP 1003 RRO1 list 1005 Figure 8. PCReq Message Fragmentation Example 1007 To handle a scenario where the last fragmented message piece is lost, 1008 the receiver side of the fragmented message may start a timer once it 1009 receives the first piece of the fragmented message. When the timer 1010 expires and it has not received the last piece of the fragmented 1011 message, it should send an error message to the sender to signal that 1012 it has received an incomplete message. The relevant error message is 1013 documented in Section 3.15 ("P2MP PCEP-ERROR Objects and Types"). 1015 3.14. UNREACH-DESTINATION Object 1017 The PCE path computation request may fail because all or a subset of 1018 the destinations are unreachable. 1020 In such a case, the UNREACH-DESTINATION object allows the PCE to 1021 optionally specify the list of unreachable destinations. 1023 This object can be present in PCRep messages. There can be up to one 1024 such object per RP. 1026 The following UNREACH-DESTINATION objects will be required: 1028 UNREACH-DESTINATION Object-Class is 28. 1029 UNREACH-DESTINATION Object-Type for IPv4 is 1. 1030 UNREACH-DESTINATION Object-Type for IPv6 is 2. 1032 The format of the UNREACH-DESTINATION object body for IPv4 (Object- 1033 Type=1) is as follows: 1035 0 1 2 3 1036 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 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Destination IPv4 address | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 ~ ... ~ 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Destination IPv4 address | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 Figure 9. UNREACH-DESTINATION Object Body for IPv4 1047 The format of the UNREACH-DESTINATION object body for IPv6 (Object- 1048 Type=2) is as follows: 1050 0 1 2 3 1051 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 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | | 1054 | Destination IPv6 address (16 bytes) | 1055 | | 1056 | | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 ~ ... ~ 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | | 1061 | Destination IPv6 address (16 bytes) | 1062 | | 1063 | | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 Figure 10. UNREACH-DESTINATION Object Body for IPv6 1068 3.15. P2MP PCEP-ERROR Objects and Types 1070 To indicate an error associated with policy violation, a new error 1071 value "P2MP Path computation not allowed" should be added to the 1072 existing error code for policy violation (Error-Type=5) as defined in 1073 [RFC5440]: 1075 Error-Type=5; Error-Value=7: if a PCE receives a P2MP path 1076 computation request that is not compliant with administrative 1077 privileges (i.e., "The PCE policy does not support P2MP path 1078 computation"), the PCE MUST send a PCErr message with a PCEP-ERROR 1079 object (Error-Type=5) and an Error-Value (Error-Value=7). The 1080 corresponding P2MP path computation request MUST also be cancelled. 1082 To indicate capability errors associated with the P2MP path request, 1083 a new Error-Type (16) and subsequent error-values are defined as 1084 follows for inclusion in the PCEP-ERROR object: 1086 Error-Type=16; Error-Value=1: if a PCE receives a P2MP path request 1087 and the PCE is not capable of satisfying the request due to 1088 insufficient memory, the PCE MUST send a PCErr message with a PCEP- 1089 ERROR object (Error-Type=16) and an Error-Value (Error-Value=1). The 1090 corresponding P2MP path computation request MUST also be cancelled. 1092 Error-Type=16; Error-Value=2: if a PCE receives a P2MP path request 1093 and the PCE is not capable of P2MP computation, the PCE MUST send a 1094 PCErr message with a PCEP-ERROR object (Error-Type=16) and an Error- 1095 Value (Error-Value=2). The corresponding P2MP path computation 1096 request MUST also be cancelled. 1098 To indicate P2MP message fragmentation errors associated with a P2MP 1099 path request, a new Error-Type (18) and subsequent error-values are 1100 defined as follows for inclusion in the PCEP-ERROR object: 1102 Error-Type=18; Error-Value=1: if a PCE has not received the last 1103 piece of the fragmented message, it should send an error message to 1104 the sender to signal that it has received an incomplete message 1105 (i.e., "Fragmented request failure"). The PCE MUST send a PCErr 1106 message with a PCEP-ERROR object (Error-Type=18) and an Error-Value 1107 (Error-Value=1). 1109 3.16. PCEP NO-PATH Indicator 1111 To communicate the reasons for not being able to find P2MP path 1112 computation, the NO-PATH object can be used in the PCRep message. 1114 One new bit is defined in the NO-PATH-VECTOR TLV carried in the 1115 NO-PATH Object: 1117 bit 24: when set, the PCE indicates that there is a reachability 1118 problem with all or a subset of the P2MP destinations. Optionally, 1119 the PCE can specify the destination or list of destinations that are 1120 not reachable using the new UNREACH-DESTINATION object defined in 1121 Section 3.14. 1123 4. Manageability Considerations 1125 [RFC5862] describes various manageability requirements in support of 1126 P2MP path computation when applying PCEP. This section describes how 1127 manageability requirements mentioned in [RFC5862] are supported in 1128 the context of PCEP extensions specified in this document. 1130 Note that [RFC5440] describes various manageability considerations in 1131 PCEP, and most of the manageability requirements mentioned in 1132 [RFC5862] are already covered there. 1134 4.1. Control of Function and Policy 1136 In addition to PCE configuration parameters listed in [RFC5440], the 1137 following additional parameters might be required: 1139 o The ability to enable or disable P2MP path computations on the 1140 PCE. 1142 o The PCE may be configured to enable or disable the advertisement 1143 of its P2MP path computation capability. A PCE can advertise its 1144 P2MP capability via the IGP discovery mechanism discussed in 1145 Section 3.1.1 ("P2MP Computation TLV in the Existing PCE Discovery 1146 Protocol"), or during the Open Message Exchange discussed in 1147 Section 3.1.2 ("Open Message Extension"). 1149 4.2. Information and Data Models 1151 A number of MIB objects have been defined for general PCEP control 1152 and monitoring of P2P computations in [RFC7420]. [RFC5862] specifies 1153 that MIB objects will be required to support the control and 1154 monitoring of the protocol extensions defined in this document. A new 1155 document will be required to define MIB objects for PCEP control and 1156 monitoring of P2MP computations. 1158 The PCEP YANG module [I-D.ietf-pce-pcep-yang] can be extended to also 1159 include the P2MP related parameters. 1161 4.3. Liveness Detection and Monitoring 1163 There are no additional considerations beyond those expressed in 1164 [RFC5440], since [RFC5862] does not address any additional 1165 requirements. 1167 4.4. Verifying Correct Operation 1169 There are no additional requirements beyond those expressed in 1170 [RFC4657] for verifying the correct operation of the PCEP sessions. 1172 It is expected that future MIB objects will facilitate verification 1173 of correct operation and reporting of P2MP PCEP requests, responses, 1174 and errors. 1176 4.5. Requirements for Other Protocols and Functional Components 1178 The method for the PCE to obtain information about a PCE capable of 1179 P2MP path computations via OSPF and IS-IS is discussed in 1180 Section 3.1.1 ("P2MP Computation TLV in the Existing PCE Discovery 1181 Protocol") of this document. 1183 The subsequent IANA assignments are documented in Section 6.9 ("OSPF 1184 PCE Capability Flag") of this document. 1186 4.6. Impact on Network Operation 1188 It is expected that the use of PCEP extensions specified in this 1189 document will not significantly increase the level of operational 1190 traffic. However, computing a P2MP tree may require more PCE state 1191 compared to a P2P computation. In the event of a major network 1192 failure and multiple recovery P2MP tree computation requests being 1193 sent to the PCE, the load on the PCE may also be significantly 1194 increased. 1196 5. Security Considerations 1198 As described in [RFC5862], P2MP path computation requests are more 1199 CPU-intensive and also utilize more link bandwidth. In the event of 1200 an unauthorized P2MP path computation request, or a denial of service 1201 attack, the subsequent PCEP requests and processing may be disruptive 1202 to the network. Consequently, it is important that implementations 1203 conform to the relevant security requirements of [RFC5440] that 1204 specifically help to minimize or negate unauthorized P2MP path 1205 computation requests and denial of service attacks. These mechanisms 1206 include: 1208 o Securing the PCEP session requests and responses using TCP 1209 security techniques (Section 10.2 of [RFC5440]). 1211 o Authenticating the PCEP requests and responses to ensure the 1212 message is intact and sent from an authorized node (Section 10.3 1213 of [RFC5440]). 1215 o Providing policy control by explicitly defining which PCCs, via IP 1216 access-lists, are allowed to send P2MP path requests to the PCE 1217 (Section 10.6 of [RFC5440]). 1219 PCEP operates over TCP, so it is also important to secure the PCE and 1220 PCC against TCP denial of service attacks. Section 10.7.1 of 1221 [RFC5440] outlines a number of mechanisms for minimizing the risk of 1222 TCP based denial of service attacks against PCEs and PCCs. 1224 PCEP implementations SHOULD consider the additional security provided 1225 by Transport Layer Security (TLS) [I-D.ietf-pce-pceps]. 1227 6. IANA Considerations 1229 IANA maintains a registry of PCEP parameters. A number of IANA 1230 considerations have been highlighted in previous sections of this 1231 document. IANA made the allocations as per [RFC6006]. 1233 6.1. PCEP TLV Type Indicators 1235 As described in Section 3.1.2., the P2MP capability TLV allows the 1236 PCE to advertise its P2MP path computation capability. 1238 IANA had made an allocation from the "PCEP TLV Type Indicators" 1239 subregistry, where RFC 6006 was the reference. IANA is requested to 1240 update the reference as follows to point to this document. 1242 Value Description Reference 1244 6 P2MP capable [This I-D] 1246 6.2. Request Parameter Bit Flags 1248 As described in Section 3.3.1, three RP Object Flags have been 1249 defined. 1251 IANA has made an allocations from the PCEP "RP Object Flag Field" 1252 sub-registry, where RFC 6006 was the reference. IANA is requested to 1253 update the reference as follows to point to this document. 1255 Bit Description Reference 1257 18 Fragmentation (F-bit) [This I-D] 1258 19 P2MP (N-bit) [This I-D] 1259 20 ERO-compression (E-bit) [This I-D] 1261 6.3. Objective Functions 1263 As described in Section 3.6.1, two Objective Functions have been 1264 defined. 1266 IANA has made an allocations from the PCEP "Objective Function" sub- 1267 registry, where RFC 6006 was the reference.IANA is requested to 1268 update the reference as follows to point to this document. 1270 Code Point Name Reference 1272 7 SPT [This I-D] 1273 8 MCT [This I-D] 1275 6.4. Metric Object Types 1277 As described in Section 3.6.2, three metric object T fields have been 1278 defined. 1280 IANA has made an allocations from the PCEP "METRIC Object T Field" 1281 sub-registry, where RFC 6006 was the reference. IANA is requested to 1282 update the reference as follows to point to this document. 1284 Value Description Reference 1286 8 P2MP IGP metric [This I-D] 1287 9 P2MP TE metric [This I-D] 1288 10 P2MP hop count metric [This I-D] 1290 6.5. PCEP Objects 1292 As discussed in Section 3.3.2, two END-POINTS Object-Types are 1293 defined. 1295 IANA has made the Object-Type allocations from the "PCEP Objects" 1296 sub-registry, where RFC 6006 was the reference. IANA is requested to 1297 update the reference as follows to point to this document. 1299 Object-Class Value 4 1300 Name END-POINTS 1301 Object-Type 3: IPv4 1302 4: IPv6 1303 5-15: Unassigned 1304 Reference [This I-D] 1306 As described in Section 3.2, Section 3.11.1, and Section 3.14, four 1307 PCEP Object-Classes and six PCEP Object-Types have been defined. 1309 IANA has made an allocations from the "PCEP Objects" sub- registry, 1310 where RFC 6006 was the reference. IANA is requested to update the 1311 reference as follows to point to this document. 1313 Object-Class Value 28 1314 Name UNREACH-DESTINATION 1315 Object-Type 0: Reserved 1316 1: IPv4 1317 2: IPv6 1318 3-15: Unassigned 1319 Reference [This I-D] 1321 Object-Class Value 29 1322 Name SERO 1323 Object-Type 0: Reserved 1324 1: SERO 1325 2-15: Unassigned 1326 Reference [This I-D] 1328 Object-Class Value 30 1329 Name SRRO 1330 Object-Type 0: Reserved 1331 1: SRRO 1332 2-15: Unassigned 1333 Reference [This I-D] 1335 Object-Class Value 31 1336 Name Branch Node Capability Object 1337 Object-Type 0: Reserved 1338 1: Branch node list 1339 2: Non-branch node list 1340 3-15: Unassigned 1341 Reference [This I-D] 1343 6.6. PCEP-ERROR Objects and Types 1345 As described in Section 3.15, number of PCEP-ERROR Object Error Types 1346 and Values have been defined. 1348 IANA has made an allocations from the PCEP "PCEP-ERROR Object Error 1349 Types and Values" sub-registry, where RFC 6006 was the reference. 1350 IANA is requested to update the reference as follows to point to this 1351 document. 1353 Error 1354 Type Meaning Reference 1356 5 Policy violation 1357 Error-value=7: [This I-D] 1358 P2MP Path computation is not allowed 1360 16 P2MP Capability Error 1361 Error-Value=0: Unassigned [This I-D] 1362 Error-Value=1: [This I-D] 1363 The PCE is not capable to satisfy the request 1364 due to insufficient memory 1366 Error-Value=2: [This I-D] 1367 The PCE is not capable of P2MP computation 1369 17 P2MP END-POINTS Error 1370 Error-Value=0: Unassigned [This I-D] 1371 Error-Value=1: [This I-D] 1372 The PCE is not capable to satisfy the request 1373 due to no END-POINTS with leaf type 2 1374 Error-Value=2: [This I-D] 1375 The PCE is not capable to satisfy the request 1376 due to no END-POINTS with leaf type 3 1377 Error-Value=3: [This I-D] 1378 The PCE is not capable to satisfy the request 1379 due to no END-POINTS with leaf type 4 1380 Error-Value=4: [This I-D] 1381 The PCE is not capable to satisfy the request 1382 due to inconsistent END-POINTS 1384 18 P2MP Fragmentation Error 1385 Error-Value=0: Unassigned [This I-D] 1386 Error-Value=1: [This I-D] 1387 Fragmented request failure 1389 6.7. PCEP NO-PATH Indicator 1391 As discussed in Section 3.16, NO-PATH-VECTOR TLV Flag Field has been 1392 defined. 1394 IANA has made an allocation from the PCEP "NO-PATH-VECTOR TLV Flag 1395 Field" sub-registry, where RFC 6006 was the reference. IANA is 1396 requested to update the reference as follows to point to this 1397 document. 1399 Bit Description Reference 1401 24 P2MP Reachability Problem [This I-D] 1403 6.8. SVEC Object Flag 1405 As discussed in Section 3.12, two SVEC Object Flags are defined. 1407 IANA has made an allocation from the PCEP "SVEC Object Flag Field" 1408 sub-registry, where RFC 6006 was the reference. IANA is requested to 1409 update the reference as follows to point to this document. 1411 Bit Description Reference 1413 19 Partial Path Diverse [This I-D] 1414 20 Link Direction Diverse [This I-D] 1416 6.9. OSPF PCE Capability Flag 1418 As discussed in Section 3.1.1, OSPF Capability Flag is defined to 1419 indicate P2MP path computation capability. 1421 IANA has made an assignment from the OSPF Parameters "Path 1422 Computation Element (PCE) Capability Flags" registry, where RFC 6006 1423 was the reference. IANA is requested to update the reference as 1424 follows to point to this document. 1426 Bit Description Reference 1428 10 P2MP path computation [This I-D] 1430 7. Acknowledgements 1432 The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan, 1433 Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh Babu K, Dhruv 1434 Dhody, Udayasree Palle, Gaurav Agrawal, Vishwas Manral, Dan 1435 Romascanu, Tim Polk, Stewart Bryant, David Harrington, and Sean 1436 Turner for their valuable comments and input on the RFC 6006. 1438 Thanks to Deborah Brungard for handling of related errata on the RFC 1439 6006. 1441 Authors would like to thank Jonathan Hardwick and Adrian Farrel for 1442 providing review comments with suggested text for this document. 1444 8. References 1446 8.1. Normative References 1448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1449 Requirement Levels", BCP 14, RFC 2119, March 1997. 1451 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1452 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1453 Tunnels", RFC 3209, December 2001. 1455 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1456 Switching (GMPLS) Signaling Resource ReserVation 1457 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1458 RFC 3473, January 2003. 1460 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 1461 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 1463 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1464 Yasukawa, Ed., "Extensions to Resource Reservation 1465 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1466 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 1467 2007. 1469 [RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing 1470 Protocol Extensions for Discovery of Traffic Engineering 1471 Node Capabilities", RFC 5073, December 2007. 1473 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1474 Zhang, "OSPF Protocol Extensions for Path Computation 1475 Element (PCE) Discovery", RFC 5088, January 2008. 1477 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1478 Zhang, "IS-IS Protocol Extensions for Path Computation 1479 Element (PCE) Discovery", RFC 5089, January 2008. 1481 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1482 Used to Form Encoding Rules in Various Routing Protocol 1483 Specifications", RFC 5511, April 2009. 1485 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 1486 Computation Element (PCE) Communication Protocol (PCEP)", 1487 RFC 5440, March 2009. 1489 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1490 Objective Functions in the Path Computation Element 1491 Communication Protocol (PCEP)", RFC 5541, June 2009. 1493 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1494 S. Shaffer, "Extensions to OSPF for Advertising Optional 1495 Router Capabilities", RFC 7770, February 2016. 1497 8.2. Informative References 1499 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1500 Computation Element (PCE)-Based Architecture", RFC 4655, 1501 August 2006. 1503 [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation 1504 Element (PCE) Communication Protocol Generic 1505 Requirements", RFC 4657, September 2006. 1507 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 1508 Path Computation Element (PCE) to Point-to-Multipoint 1509 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", 1510 RFC 5671, October 2009. 1512 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 1513 (PCC) - Path Computation Element (PCE) Requirements for 1514 Point-to-Multipoint MPLS-TE", RFC 5862, June 2010. 1516 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 1517 Ali, Z., and J. Meuric, "Extensions to the Path 1518 Computation Element Communication Protocol (PCEP) for 1519 Point-to-Multipoint Traffic Engineering Label Switched 1520 Paths", RFC 6006, September 2010. 1522 [RFC7420] Koushik, K., Stephan, E., Zhao, Q., King D., and J. 1523 Hardwick "PCE communication protocol (PCEP) Management 1524 Information Base (MIB) Module", RFC 7420, December 2014. 1526 [I-D.ietf-pce-pcep-yang] 1527 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1528 YANG Data Model for Path Computation Element 1529 Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang 1530 (work in progress), March 2017. 1532 [I-D.ietf-pce-pceps] 1533 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1534 Transport for PCEP", draft-ietf-pce-pceps (work in 1535 progress), January 2017. 1537 Appendix A. Summary of the RBNF Changes from RFC 6006 1539 o Update to RBNF for Request message format: 1541 * Update to the request message to allow for the bundling of 1542 multiple path computation requests within a single Path 1543 Computation Request (PCReq) message. 1545 * Addition of in PCReq message. This object was missed 1546 in [RFC6006]. 1548 * Addition of BNC object in PCReq message. This object is required 1549 to support P2MP. It shares the same format as Include Route Object 1550 (IRO) but it is a different object. 1552 * Update to the format, to also allow Secondary Record 1553 Route object (SRRO). This object was missed in [RFC6006]. 1555 * Removed the BANDWIDTH Object followed by Record Route Object 1556 (RRO) from . As BANDWIDTH object doesn't need to follow 1557 for each RRO in the , there already exist BANDWIDTH 1558 object follow and is backward compatible with 1559 [RFC5440]. 1561 * Update to the , to allow optional 1562 BANDWIDTH object only if is included. 1564 o Update the RBNF for Reply message format: 1566 * Update to the reply message to allow for bundling of multiple 1567 path computation requests within a single Path Computation Reply 1568 (PCRep) message. 1570 * Addition of the UNREACH-DESTINATION in PCRep message. This 1571 object was missed in [RFC6006]. 1573 Contributors 1575 Fabien Verhaeghe 1576 Thales Communication France 1577 160 Bd Valmy 92700 Colombes 1578 France 1579 EMail: fabien.verhaeghe@gmail.com 1581 Tomonori Takeda 1582 NTT Corporation 1583 3-9-11, Midori-Cho 1584 Musashino-Shi, Tokyo 180-8585 1585 Japan 1586 EMail: tomonori.takeda@ntt.com 1588 Zafar Ali 1589 Cisco Systems, Inc. 1590 2000 Innovation Drive 1591 Kanata, Ontario K2K 3E8 1592 Canada 1593 EMail: zali@cisco.com 1595 Julien Meuric 1596 Orange 1597 2, Avenue Pierre-Marzin 1598 22307 Lannion Cedex 1599 France 1600 EMail: julien.meuric@orange.com 1602 Jean-Louis Le Roux 1603 Orange 1604 2, Avenue Pierre-Marzin 1605 22307 Lannion Cedex 1606 France 1607 EMail: jeanlouis.leroux@orange.com 1609 Mohamad Chaitou 1610 France 1611 EMail: mohamad.chaitou@gmail.com 1613 Udayasree Palle 1614 Huawei Technologies 1615 Divyashree Techno Park, Whitefield 1616 Bangalore, Karnataka 560066 1617 India 1618 EMail: udayasree.palle@huawei.com 1620 Authors' Addresses 1621 Quintin Zhao 1622 Huawei Technology 1623 125 Nagog Technology Park 1624 Acton, MA 01719 1625 US 1626 EMail: quintin.zhao@huawei.com 1628 Dhruv Dhody 1629 Huawei Technology 1630 Divyashree Techno Park, Whitefield 1631 Bangalore, Karnataka 560066 1632 India 1633 EMail: dhruv.ietf@gmail.com 1635 Ramanjaneya Reddy Palleti 1636 Huawei Technology 1637 Divyashree Techno Park, Whitefield 1638 Bangalore, Karnataka 560066 1639 India 1640 EMail: ramanjaneya.palleti@huawei.com 1642 Daniel King 1643 Old Dog Consulting 1644 UK 1645 EMail: daniel@olddog.co.uk