idnits 2.17.1 draft-ietf-pce-rfc6006bis-01.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 (March 28, 2017) is 2579 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 1432, 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: September 29, 2017 D. King 7 Old Dog Consulting 8 F. Verhaeghe 9 Thales Communication France 10 T. Takeda 11 NTT Corporation 12 Z. Ali 13 Cisco Systems, Inc. 14 J. Meuric 15 Orange 16 March 28, 2017 18 Extensions to 19 the Path Computation Element Communication Protocol (PCEP) 20 for Point-to-Multipoint Traffic Engineering Label Switched Paths 22 draft-ietf-pce-rfc6006bis-01 24 Abstract 26 Point-to-point Multiprotocol Label Switching (MPLS) and Generalized 27 MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may 28 be established using signaling techniques, but their paths may first 29 need to be determined. The Path Computation Element (PCE) has been 30 identified as an appropriate technology for the determination of the 31 paths of point-to-multipoint (P2MP) TE LSPs. 33 This document describes extensions to the PCE communication Protocol 34 (PCEP) to handle requests and responses for the computation of paths 35 for P2MP TE LSPs. 37 This document obsoletes RFC 6006. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on September 11, 2017. 56 Copyright Notice 58 Copyright (c) 2017 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 83 Table of Contents 85 1. Introduction ....................................................3 86 1.1. Terminology ................................................4 87 1.2. Requirements Language ......................................5 88 2. PCC-PCE Communication Requirements ..............................5 89 3. Protocol Procedures and Extensions ..............................6 90 3.1. P2MP Capability Advertisement ..............................6 91 3.1.1. P2MP Computation TLV in the Existing PCE 92 Discovery Protocol ..................................6 93 3.1.2. Open Message Extension ..............................7 94 3.2. Efficient Presentation of P2MP LSPs ........................7 95 3.3. P2MP Path Computation Request/Reply Message Extensions .....8 96 3.3.1. The Extension of the RP Object ......................8 97 3.3.2. The New P2MP END-POINTS Object ......................9 98 3.4. Request Message Format ....................................12 99 3.5. Reply Message Format ......................................12 100 3.6. P2MP Objective Functions and Metric Types .................13 101 3.6.1. New Objective Functions ............................13 102 3.6.2. New Metric Object Types ............................14 103 3.7. Non-Support of P2MP Path Computation ......................14 104 3.8. Non-Support by Back-Level PCE Implementations .............15 105 3.9. P2MP TE Path Reoptimization Request .......................15 106 3.10. Adding and Pruning Leaves to/from the P2MP Tree ..........16 107 3.11. Discovering Branch Nodes .................................19 108 3.11.1. Branch Node Object ................................19 109 3.12. Synchronization of P2MP TE Path Computation Requests .....19 110 3.13. Request and Response Fragmentation .......................20 111 3.13.1. Request Fragmentation Procedure ...................21 112 3.13.2. Response Fragmentation Procedure ..................21 113 3.13.3. Fragmentation Examples ............................21 114 3.14. UNREACH-DESTINATION Object ...............................22 115 3.15. P2MP PCEP-ERROR Objects and Types ........................23 116 3.16. PCEP NO-PATH Indicator ...................................24 117 4. Manageability Considerations ...................................25 118 4.1. Control of Function and Policy ............................25 119 4.2. Information and Data Models ...............................25 120 4.3. Liveness Detection and Monitoring .........................25 121 4.4. Verifying Correct Operation ...............................25 122 4.5. Requirements for Other Protocols and Functional 123 Components ................................................26 124 4.6. Impact on Network Operation ...............................26 125 5. Security Considerations ........................................26 126 6. IANA Considerations ............................................27 127 6.1. PCEP TLV Type Indicators ..................................27 128 6.2. Request Parameter Bit Flags ...............................27 129 6.3. Objective Functions .......................................27 130 6.4. Metric Object Types .......................................27 131 6.5. PCEP Objects ..............................................28 132 6.6. PCEP-ERROR Objects and Types ..............................29 133 6.7. PCEP NO-PATH Indicator ....................................30 134 6.8. SVEC Object Flag ..........................................30 135 6.9. OSPF PCE Capability Flag ..................................30 136 7. Acknowledgements ...............................................30 137 8. References .....................................................30 138 8.1. Normative References ......................................30 139 8.2. Informative References ....................................32 141 1. Introduction 143 The Path Computation Element (PCE) defined in [RFC4655] is an entity 144 that is capable of computing a network path or route based on a 145 network graph, and applying computational constraints. A Path 146 Computation Client (PCC) may make requests to a PCE for paths to be 147 computed. 149 [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic 150 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 151 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. 153 The PCE has been identified as a suitable application for the 154 computation of paths for P2MP TE LSPs [RFC5671]. 156 The PCE communication Protocol (PCEP) is designed as a communication 157 protocol between PCCs and PCEs for point-to-point (P2P) path 158 computations and is defined in [RFC5440]. However, that 159 specification does not provide a mechanism to request path 160 computation of P2MP TE LSPs. 162 A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. 163 These S2L sub-LSPs are set up between ingress and egress Label 164 Switching Routers (LSRs) and are appropriately overlaid to construct 165 a P2MP TE LSP. During path computation, the P2MP TE LSP may be 166 determined as a set of S2L sub-LSPs that are computed separately and 167 combined to give the path of the P2MP LSP, or the entire P2MP TE LSP 168 may be determined as a P2MP tree in a single computation. 170 This document relies on the mechanisms of PCEP to request path 171 computation for P2MP TE LSPs. One path computation request message 172 from a PCC may request the computation of the whole P2MP TE LSP, or 173 the request may be limited to a sub-set of the S2L sub-LSPs. In the 174 extreme case, the PCC may request the S2L sub-LSPs to be computed 175 individually with it being the PCC's responsibility to decide whether 176 to signal individual S2L sub-LSPs or combine the computation results 177 to signal the entire P2MP TE LSP. Hence the PCC may use one path 178 computation request message or may split the request across multiple 179 path computation messages. 181 This document obsoletes RFC 6006 and incorporates all outstanding 182 Errata: 184 o Erratum with IDs: 3819, 3830, 3836, 4867, and 4868. 186 1.1. Terminology 188 Terminology used in this document: 190 TE LSP: Traffic Engineering Label Switched Path. 192 LSR: Label Switching Router. 194 OF: Objective Function: A set of one or more optimization criteria 195 used for the computation of a single path (e.g., path cost 196 minimization), or for the synchronized computation of a set of 197 paths (e.g., aggregate bandwidth consumption minimization). 199 P2MP: Point-to-Multipoint. 201 P2P: Point-to-Point. 203 This document also uses the terminology defined in [RFC4655], 204 [RFC4875], and [RFC5440]. 206 1.2. Requirements Language 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 210 document are to be interpreted as described in RFC 2119 [RFC2119]. 212 2. PCC-PCE Communication Requirements 214 This section summarizes the PCC-PCE communication requirements for 215 P2MP MPLS-TE LSPs described in [RFC5862]. The numbering system 216 corresponds to the requirement numbers used in [RFC5862]. 218 1. The PCC MUST be able to specify that the request is a P2MP path 219 computation request. 221 2. The PCC MUST be able to specify that objective functions are to 222 be applied to the P2MP path computation request. 224 3. The PCE MUST have the capability to reject a P2MP path request 225 and indicate non-support of P2MP path computation. 227 4. The PCE MUST provide an indication of non-support of P2MP path 228 computation by back-level PCE implementations. 230 5. A P2MP path computation request MUST be able to list multiple 231 destinations. 233 6. A P2MP path computation response MUST be able to carry the path 234 of a P2MP LSP. 236 7. By default, the path returned by the PCE SHOULD use the 237 compressed format. 239 8. It MUST be possible for a single P2MP path computation request or 240 response to be conveyed by a sequence of messages. 242 9. It MUST NOT be possible for a single P2MP path computation 243 request to specify a set of different constraints, traffic 244 parameters, or quality-of-service requirements for different 245 destinations of a P2MP LSP. 247 10. P2MP path modification and P2MP path diversity MUST be supported. 249 11. It MUST be possible to reoptimize existing P2MP TE LSPs. 251 12. It MUST be possible to add and remove P2MP destinations from 252 existing paths. 254 13. It MUST be possible to specify a list of applicable branch nodes 255 to use when computing the P2MP path. 257 14. It MUST be possible for a PCC to discover P2MP path computation 258 capability. 260 15. The PCC MUST be able to request diverse paths when requesting a 261 P2MP path. 263 3. Protocol Procedures and Extensions 265 The following section describes the protocol extensions required to 266 satisfy the requirements specified in Section 2 ("PCC-PCE 267 Communication Requirements") of this document. 269 3.1. P2MP Capability Advertisement 271 3.1.1. P2MP Computation TLV in the Existing PCE Discovery Protocol 273 [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF 274 Router Information Link State Advertisement (LSA) defined in 275 [RFC7770] to facilitate PCE discovery using OSPF. [RFC5088] 276 specifies that no new sub-TLVs may be added to the PCED TLV. This 277 document defines a new flag in the OSPF PCE Capability Flags to 278 indicate the capability of P2MP computation. 280 Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE 281 Discovery using IS-IS. This document will use the same flag 282 requested for the OSPF PCE Capability Flags sub-TLV to allow IS-IS to 283 indicate the capability of P2MP computation. 285 The IANA assignment for a shared OSPF and IS-IS P2MP Capability Flag 286 is documented in Section 6.9 ("OSPF PCE Capability Flag") of this 287 document. 289 PCEs wishing to advertise that they support P2MP path computation 290 would set the bit (10) accordingly. PCCs that do not understand this 291 bit will ignore it (per [RFC5088] and [RFC5089]). PCEs that do not 292 support P2MP will leave the bit clear (per the default behavior 293 defined in [RFC5088] and [RFC5089]). 295 PCEs that set the bit to indicate support of P2MP path computation 296 MUST follow the procedures in Section 3.3.2 ("The New P2MP END-POINTS 297 Object") to further qualify the level of support. 299 3.1.2. Open Message Extension 301 Based on the Capabilities Exchange requirement described in 302 [RFC5862], if a PCE does not advertise its P2MP capability during 303 discovery, PCEP should be used to allow a PCC to discover, during the 304 Open Message Exchange, which PCEs are capable of supporting P2MP path 305 computation. 307 To satisfy this requirement, we extend the PCEP OPEN object by 308 defining a new optional TLV to indicate the PCE's capability to 309 perform P2MP path computations. 311 IANA has allocated value 6 from the "PCEP TLV Type Indicators" sub- 312 registry, as documented in Section 6.1 ("PCEP TLV Type Indicators"). 313 The description is "P2MP capable", and the length value is 2 bytes. 314 The value field is set to default value 0. 316 The inclusion of this TLV in an OPEN object indicates that the sender 317 can perform P2MP path computations. 319 The capability TLV is meaningful only for a PCE, so it will typically 320 appear only in one of the two Open messages during PCE session 321 establishment. However, in case of PCE cooperation (e.g., 322 inter-domain), when a PCE behaving as a PCC initiates a PCE session 323 it SHOULD also indicate its path computation capabilities. 325 3.2. Efficient Presentation of P2MP LSPs 327 When specifying additional leaves, or optimizing existing P2MP TE 328 LSPs as specified in [RFC5862], it may be necessary to pass existing 329 P2MP LSP route information between the PCC and PCE in the request and 330 reply messages. In each of these scenarios, we need new path objects 331 for efficiently passing the existing P2MP LSP between the PCE and 332 PCC. 334 We specify the use of the Resource Reservation Protocol Traffic 335 Engineering (RSVP-TE) extensions Explicit Route Object (ERO) to 336 encode the explicit route of a TE LSP through the network. PCEP ERO 337 sub-object types correspond to RSVP-TE ERO sub-object types. The 338 format and content of the ERO object are defined in [RFC3209] and 339 [RFC3473]. 341 The Secondary Explicit Route Object (SERO) is used to specify the 342 explicit route of a S2L sub-LSP. The path of each subsequent S2L 343 sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object SERO. 344 The format of the SERO is the same as an ERO defined in [RFC3209] and 345 [RFC3473]. 347 The Secondary Record Route Object (SRRO) is used to record the 348 explicit route of the S2L sub-LSP. The class of the P2MP SRRO is the 349 same as the SRRO defined in [RFC4873]. 351 The SERO and SRRO are used to report the route of an existing TE LSP 352 for which a reoptimization is desired. The format and content of the 353 SERO and SRRO are defined in [RFC4875]. 355 A new PCEP object class and type are requested for SERO and SRRO. 357 Object-Class Value 29 358 Name SERO 359 Object-Type 1: SERO 360 2-15: Unassigned 361 Reference RFC 6006 363 Object-Class Value 30 364 Name SRRO 365 Object-Type 1: SRRO 366 2-15: Unassigned 367 Reference RFC 6006 369 The IANA assignment is documented in Section 6.5 ("PCEP Objects"). 371 Since the explicit path is available for immediate signaling by the 372 MPLS or GMPLS control plane, the meanings of all of the sub-objects 373 and fields in this object are identical to those defined for the ERO. 375 3.3. P2MP Path Computation Request/Reply Message Extensions 377 This document extends the existing P2P RP (Request Parameters) object 378 so that a PCC can signal a P2MP path computation request to the PCE 379 receiving the PCEP request. The END-POINTS object is also extended 380 to improve the efficiency of the message exchange between PCC and PCE 381 in the case of P2MP path computation. 383 3.3.1. The Extension of the RP Object 385 The PCE path computation request and reply messages will need the 386 following additional parameters to indicate to the receiving PCE that 387 the request and reply messages have been fragmented across multiple 388 messages, that they have been requested for a P2MP path, and whether 389 the route is represented in the compressed or uncompressed format. 391 This document adds the following flags to the RP Object: 393 The F-bit is added to the flag bits of the RP object to indicate to 394 the receiver that the request is part of a fragmented request, or is 395 not a fragmented request. 397 o F (RP fragmentation bit - 1 bit): 399 0: This indicates that the RP is not fragmented or it is the last 400 piece of the fragmented RP. 402 1: This indicates that the RP is fragmented and this is not the 403 last piece of the fragmented RP. The receiver needs to wait 404 for additional fragments until it receives an RP with the same 405 RP-ID and with the F-bit set to 0. 407 The N-bit is added in the flag bits field of the RP object to signal 408 the receiver of the message that the request/reply is for P2MP or is 409 not for P2MP. 411 o N (P2MP bit - 1 bit): 413 0: This indicates that this is not a PCReq or PCRep message for 414 P2MP. 416 1: This indicates that this is a PCReq or PCRep message for P2MP. 418 The E-bit is added in the flag bits field of the RP object to signal 419 the receiver of the message that the route is in the compressed 420 format or is not in the compressed format. By default, the path 421 returned by the PCE SHOULD use the compressed format. 423 o E (ERO-compression bit - 1 bit): 425 0: This indicates that the route is not in the compressed format. 427 1: This indicates that the route is in the compressed format. 429 The IANA assignment is documented in Section 6.2 ("Request Parameter 430 Bit Flags") of this document. 432 3.3.2. The New P2MP END-POINTS Object 434 The END-POINTS object is used in a PCReq message to specify the 435 source IP address and the destination IP address of the path for 436 which a path computation is requested. To represent the end points 437 for a P2MP path efficiently, we define two new types of END-POINTS 438 objects for the P2MP path: 440 o Old leaves whose path can be modified/reoptimized; 442 o Old leaves whose path must be left unchanged. 444 With the new END-POINTS object, the PCE path computation request 445 message is expanded in a way that allows a single request message to 446 list multiple destinations. 448 In total, there are now 4 possible types of leaves in a P2MP request: 450 o New leaves to add (leaf type = 1) 452 o Old leaves to remove (leaf type = 2) 454 o Old leaves whose path can be modified/reoptimized (leaf type = 3) 456 o Old leaves whose path must be left unchanged (leaf type = 4) 458 A given END-POINTS object gathers the leaves of a given type. The 459 type of leaf in a given END-POINTS object is identified by the END- 460 POINTS object leaf type field. 462 Using the new END-POINTS object, the END-POINTS portion of a request 463 message for the multiple destinations can be reduced by up to 50% for 464 a P2MP path where a single source address has a very large number of 465 destinations. 467 Note that a P2MP path computation request can mix the different types 468 of leaves by including several END-POINTS objects per RP object as 469 shown in the PCReq Routing Backus-Naur Form (RBNF) [RFC5511] format 470 in Section 3.4 ("Request Message Format"). 472 The format of the new END-POINTS object body for IPv4 (Object-Type 3) 473 is as follows: 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Leaf type | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Source IPv4 address | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Destination IPv4 address | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 ~ ... ~ 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Destination IPv4 address | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 Figure 1. The New P2MP END-POINTS Object Body Format for IPv4 491 The format of the END-POINTS object body for IPv6 (Object-Type 4) is 492 as follows: 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Leaf type | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | | 500 | Source IPv6 address (16 bytes) | 501 | | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | | 504 | Destination IPv6 address (16 bytes) | 505 | | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 ~ ... ~ 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | | 510 | Destination IPv6 address (16 bytes) | 511 | | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Figure 2. The New P2MP END-POINTS Object Body Format for IPv6 516 The END-POINTS object body has a variable length. These are 517 multiples of 4 bytes for IPv4, and multiples of 16 bytes, plus 4 518 bytes, for IPv6. 520 3.4. Request Message Format 522 As per [RFC5440], a Path Computation Request message (also referred 523 to as a PCReq message) is a PCEP message sent by a PCC to a PCE to 524 request a path computation. A PCReq message may carry more than one 525 path computation request. 527 As per [RFC5541], the OF object MAY be carried within a PCReq 528 message. If an objective function is to be applied to a set of 529 synchronized path computation requests, the OF object MUST be carried 530 just after the corresponding SVEC (Synchronization VECtor) object and 531 MUST NOT be repeated for each elementary request. 533 The PCReq message is encoded as follows using RBNF as defined in 534 [RFC5511]. 536 Below is the message format for the request message: 538 ::= 539 [] 540 542 where: 544 ::= 545 [] 546 [] 547 [] 549 ::=[] 551 ::= 552 553 [] 554 [] 555 [] 556 [] 557 [|] 558 [] 560 where: 562 ::= 563 [[]] 564 [] 566 ::=(|)[] 567 ::=[] 569 Figure 3. The Message Format for the Request Message 571 Note that we preserve compatibility with the [RFC5440] definition of 572 . At least one instance of MUST be present in 573 this message. 575 We have documented the IANA assignment of additional END-POINTS 576 Object-Types in Section 6.5 ("PCEP Objects") of this document. 578 3.5. Reply Message Format 580 The PCEP Path Computation Reply message (also referred to as a PCRep 581 message) is a PCEP message sent by a PCE to a requesting PCC in 582 response to a previously received PCReq message. PCEP supports the 583 bundling of multiple replies to a set of path computation requests 584 within a single PCRep message. 586 The PCRep message is encoded as follows using RBNF as defined in 587 [RFC5511]. 589 Below is the message format for the reply message: 591 ::= 592 594 where: 596 ::=[] 598 ::= 599 [] 600 [] 601 [] 602 [] 604 ::= 605 [] 606 [] 608 ::= (|) [] 610 where: 612 ::=[] 613 [] 614 [] 615 [] 616 [] 618 Figure 4. The Message Format for the Reply Message 620 The optional END-POINTS object in the reply message is used to 621 specify which paths are removed, changed, not changed, or added for 622 the request. The path is only needed for the end points that are 623 added or changed. 625 If the E-bit (ERO-Compress bit) was set to 1 in the request, then the 626 path will be formed by an ERO followed by a list of SEROs. 628 Note that we preserve compatibility with the [RFC5440] definition of 629 and the optional and . 631 3.6. P2MP Objective Functions and Metric Types 633 3.6.1. New Objective Functions 635 Six objective functions have been defined in [RFC5541] for P2P path 636 computation. 638 This document defines two additional objective functions -- namely, 639 SPT (Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to 640 P2MP path computation. Hence two new objective function codes have 641 to be defined. 643 The description of the two new objective functions is as follows. 644 Objective Function Code: 7 646 Name: Shortest Path Tree (SPT) 648 Description: Minimize the maximum source-to-leaf cost with respect 649 to a specific metric or to the TE metric used as the default 650 metric when the metric is not specified (e.g., TE or IGP metric). 652 Objective Function Code: 8 654 Name: Minimum Cost Tree (MCT) 656 Description: Minimize the total cost of the tree, that is the sum 657 of the costs of tree links, with respect to a specific metric or 658 to the TE metric used as the default metric when the metric is not 659 specified. 661 Processing these two new objective functions is subject to the rules 662 defined in [RFC5541]. 664 3.6.2. New Metric Object Types 666 There are three types defined for the object in [RFC5440] -- 667 namely, the IGP metric, the TE metric, and the hop count metric. This 668 document defines three additional types for the object: the 669 P2MP IGP metric, the P2MP TE metric, and the P2MP hop count metric. 670 They encode the sum of the metrics of all links of the tree. We 671 propose the following values for these new metric types: 673 o P2MP IGP metric: T=8 675 o P2MP TE metric: T=9 677 o P2MP hop count metric: T=10 679 3.7. Non-Support of P2MP Path Computation 681 o If a PCE receives a P2MP path request and it understands the P2MP 682 flag in the RP object, but the PCE is not capable of P2MP 683 computation, the PCE MUST send a PCErr message with a PCEP-ERROR 684 object and corresponding Error-Value. The request MUST then be 685 cancelled at the PCC. New Error-Types and Error-Values are 686 requested in Section 6 ("IANA Considerations") of this document. 688 o If the PCE does not understand the P2MP flag in the RP object, 689 then the PCE MUST send a PCErr message with Error-value=2 690 (capability not supported). 692 3.8. Non-Support by Back-Level PCE Implementations 694 If a PCE receives a P2MP request and the PCE does not understand the 695 P2MP flag in the RP object, and therefore the PCEP P2MP extensions, 696 then the PCE SHOULD reject the request. 698 3.9. P2MP TE Path Reoptimization Request 700 A reoptimization request for a P2MP TE path is specified by the use 701 of the R-bit within the RP object as defined in [RFC5440] and is 702 similar to the reoptimization request for a P2P TE path. The only 703 difference is that the user MUST insert the list of RROs and SRROs 704 after each type of END-POINTS in the PCReq message, as described in 705 the "Request Message Format" section (Section 3.4) of this document. 707 An example of a reoptimization request and subsequent PCReq message 708 is described below: 710 Common Header 711 RP with P2MP flag/R-bit set 712 END-POINTS for leaf type 3 713 RRO list 714 OF (optional) 716 Figure 5. PCReq Message Example 1 for Optimization 718 In this example, we request reoptimization of the path to all leaves 719 without adding or pruning leaves. The reoptimization request would 720 use an END-POINT type 3. The RRO list would represent the P2MP LSP 721 before the optimization, and the modifiable path leaves would be 722 indicated in the END-POINTS object. 724 It is also possible to specify distinct leaves whose path cannot be 725 modified. An example of the PCReq message in this scenario would be: 727 Common Header 728 RP with P2MP flag/R-bit set 729 END-POINTS for leaf type 3 730 RRO list 731 END-POINTS for leaf type 4 732 RRO list 733 OF (optional) 735 Figure 6. PCReq Message Example 2 for Optimization 737 3.10. Adding and Pruning Leaves to/from the P2MP Tree 739 When adding new leaves to or removing old leaves from the existing 740 P2MP tree, by supplying a list of existing leaves, it SHOULD be 741 possible to optimize the existing P2MP tree. This section explains 742 the methods for adding new leaves to or removing old leaves from the 743 existing P2MP tree. 745 To add new leaves, the user MUST build a P2MP request using END- 746 POINTS with leaf type 1. 748 To remove old leaves, the user must build a P2MP request using END- 749 POINTS with leaf type 2. If no type-2 END-POINTS exist, then the PCE 750 MUST send an error type 17, value=1: The PCE is not capable of 751 satisfying the request due to no END-POINTS with leaf type 2. 753 When adding new leaves to or removing old leaves from the existing 754 P2MP tree, the PCC must also provide the list of old leaves, if any, 755 including END-POINTS with leaf type 3, leaf type 4, or both. New 756 PCEP-ERROR objects and types are necessary for reporting when certain 757 conditions are not satisfied (i.e., when there are no END-POINTS with 758 leaf type 3 or 4, or in the presence of END-POINTS with leaf type 1 759 or 2). A generic "Inconsistent END-POINT" error will be used if a 760 PCC receives a request that has an inconsistent END-POINT (i.e., if a 761 leaf specified as type 1 already exists). These IANA assignments are 762 documented in Section 6.6 ("PCEP-ERROR Objects and Types") of this 763 document. 765 For old leaves, the user MUST provide the old path as a list of RROs 766 that immediately follows each END-POINTS object. This document 767 specifies error values when specific conditions are not satisfied. 769 The following examples demonstrate full and partial reoptimization of 770 existing P2MP LSPs: 772 Case 1: Adding leaves with full reoptimization of existing paths 774 Common Header 775 RP with P2MP flag/R-bit set 776 END-POINTS for leaf type 1 777 RRO list 778 END-POINTS for leaf type 3 779 RRO list 780 OF (optional) 782 Case 2: Adding leaves with partial reoptimization of existing paths 784 Common Header 785 RP with P2MP flag/R-bit set 786 END-POINTS for leaf type 1 787 END-POINTS for leaf type 3 788 RRO list 789 END-POINTS for leaf type 4 790 RRO list 791 OF (optional) 793 Case 3: Adding leaves without reoptimization of existing paths 795 Common Header 796 RP with P2MP flag/R-bit set 797 END-POINTS for leaf type 1 798 RRO list 799 END-POINTS for leaf type 4 800 RRO list 801 OF (optional) 803 Case 4: Pruning Leaves with full reoptimization of existing paths 805 Common Header 806 RP with P2MP flag/R-bit set 807 END-POINTS for leaf type 2 808 RRO list 809 END-POINTS for leaf type 3 810 RRO list 811 OF (optional) 813 Case 5: Pruning leaves with partial reoptimization of existing paths 815 Common Header 816 RP with P2MP flag/R-bit set 817 END-POINTS for leaf type 2 818 RRO list 819 END-POINTS for leaf type 3 820 RRO list 821 END-POINTS for leaf type 4 822 RRO list 823 OF (optional) 825 Case 6: Pruning leaves without reoptimization of existing paths 827 Common Header 828 RP with P2MP flag/R-bit set 829 END-POINTS for leaf type 2 830 RRO list 831 END-POINTS for leaf type 4 832 RRO list 833 OF (optional) 835 Case 7: Adding and pruning leaves with full reoptimization of 836 existing paths 838 Common Header 839 RP with P2MP flag/R-bit set 840 END-POINTS for leaf type 1 841 END-POINTS for leaf type 2 842 RRO list 843 END-POINTS for leaf type 3 844 RRO list 845 OF (optional) 847 Case 8: Adding and pruning leaves with partial reoptimization of 848 existing paths 850 Common Header 851 RP with P2MP flag/R-bit set 852 END-POINTS for leaf type 1 853 END-POINTS for leaf type 2 854 RRO list 855 END-POINTS for leaf type 3 856 RRO list 857 END-POINTS for leaf type 4 858 RRO list 859 OF (optional) 861 Case 9: Adding and pruning leaves without reoptimization of existing 862 paths 864 Common Header 865 RP with P2MP flag/R-bit set 866 END-POINTS for leaf type 1 867 END-POINTS for leaf type 2 868 RRO list 869 END-POINTS for leaf type 4 870 RRO list 871 OF (optional) 873 3.11. Discovering Branch Nodes 875 Before computing the P2MP path, a PCE may need to be provided means 876 to know which nodes in the network are capable of acting as branch 877 LSRs. A PCE can discover such capabilities by using the mechanisms 878 defined in [RFC5073]. 880 3.11.1. Branch Node Object 882 The PCC can specify a list of nodes that can be used as branch nodes 883 or a list of nodes that cannot be used as branch nodes by using the 884 Branch Node Capability (BNC) Object. The BNC Object has the same 885 format as the Include Route Object (IRO) defined in [RFC5440], except 886 that it only supports IPv4 and IPv6 prefix sub-objects. Two Object- 887 types are also defined: 889 o Branch node list: List of nodes that can be used as branch nodes. 891 o Non-branch node list: List of nodes that cannot be used as branch 892 nodes. 894 The object can only be carried in a PCReq message. A Path Request 895 may carry at most one Branch Node Object. 897 The Object-Class and Object-types have been allocated by IANA. The 898 IANA assignment is documented in Section 6.5 ("PCEP Objects"). 900 3.12. Synchronization of P2MP TE Path Computation Requests 902 There are cases when multiple P2MP LSPs' computations need to be 903 synchronized. For example, one P2MP LSP is the designated backup of 904 another P2MP LSP. In this case, path diversity for these dependent 905 LSPs may need to be considered during the path computation. 907 The synchronization can be done by using the existing Synchronization 908 VECtor (SVEC) functionality defined in [RFC5440]. 910 An example of synchronizing two P2MP LSPs, each having two leaves for 911 Path Computation Request Messages, is illustrated below: 913 Common Header 914 SVEC for sync of LSP1 and LSP2 915 OF (optional) 916 RP for LSP1 917 END-POINTS1 for LSP1 918 RRO1 list 919 RP for LSP2 920 END-POINTS2 for LSP2 921 RRO2 list 923 Figure 7. PCReq Message Example for Synchronization 925 This specification also defines two new flags to the SVEC Object Flag 926 Field for P2MP path dependent computation requests. The first new 927 flag is to allow the PCC to request that the PCE should compute a 928 secondary P2MP path tree with partial path diversity for specific 929 leaves or a specific S2L sub-path to the primary P2MP path tree. The 930 second flag, would allow the PCC to request that partial paths should 931 be link direction diverse. 933 The following flags are added to the SVEC object body in this 934 document: 936 o P (Partial Path Diverse bit - 1 bit): 938 When set, this would indicate a request for path diversity for a 939 specific leaf, a set of leaves, or all leaves. 941 o D (Link Direction Diverse bit - 1 bit): 943 When set, this would indicate a request that a partial path or 944 paths should be link direction diverse. 946 The IANA assignment is referenced in Section 6.8 of this document. 948 3.13. Request and Response Fragmentation 950 The total PCEP message length, including the common header, is 951 16 bytes. In certain scenarios the P2MP computation request may not 952 fit into a single request or response message. For example, if a 953 tree has many hundreds or thousands of leaves, then the request or 954 response may need to be fragmented into multiple messages. 956 The F-bit has been outlined in "The Extension of the RP Object" 957 (Section 3.3.1) of this document. The F-bit is used in the RP object 958 to signal that the initial request or response was too large to fit 959 into a single message and will be fragmented into multiple messages. 960 In order to identify the single request or response, each message 961 will use the same request ID. 963 3.13.1. Request Fragmentation Procedure 965 If the initial request is too large to fit into a single request 966 message, the PCC will split the request over multiple messages. Each 967 message sent to the PCE, except the last one, will have the F-bit set 968 in the RP object to signify that the request has been fragmented into 969 multiple messages. In order to identify that a series of request 970 messages represents a single request, each message will use the same 971 request ID. 973 The assumption is that request messages are reliably delivered and in 974 sequence, since PCEP relies on TCP. 976 3.13.2. Response Fragmentation Procedure 978 Once the PCE computes a path based on the initial request, a response 979 is sent back to the PCC. If the response is too large to fit into a 980 single response message, the PCE will split the response over 981 multiple messages. Each message sent by the PCE, except the last 982 one, will have the F-bit set in the RP object to signify that the 983 response has been fragmented into multiple messages. In order to 984 identify that a series of response messages represents a single 985 response, each message will use the same response ID. 987 Again, the assumption is that response messages are reliably 988 delivered and in sequence, since PCEP relies on TCP. 990 3.13.3. Fragmentation Examples 992 The following example illustrates the PCC sending a request message 993 with Req-ID1 to the PCE, in order to add one leaf to an existing tree 994 with 1200 leaves. The assumption used for this example is that one 995 request message can hold up to 800 leaves. In this scenario, the 996 original single message needs to be fragmented and sent using two 997 smaller messages, which have the Req-ID1 specified in the RP object, 998 and with the F-bit set on the first message, and cleared on the 999 second message. 1001 Common Header 1002 RP1 with Req-ID1 and P2MP=1 and F-bit=1 1003 OF (optional) 1004 END-POINTS1 for P2MP 1005 RRO1 list 1007 Common Header 1008 RP2 with Req-ID1 and P2MP=1 and F-bit=0 1009 OF (optional) 1010 END-POINTS1 for P2MP 1011 RRO1 list 1013 Figure 8. PCReq Message Fragmentation Example 1015 To handle a scenario where the last fragmented message piece is lost, 1016 the receiver side of the fragmented message may start a timer once it 1017 receives the first piece of the fragmented message. When the timer 1018 expires and it has not received the last piece of the fragmented 1019 message, it should send an error message to the sender to signal that 1020 it has received an incomplete message. The relevant error message is 1021 documented in Section 3.15 ("P2MP PCEP-ERROR Objects and Types"). 1023 3.14. UNREACH-DESTINATION Object 1025 The PCE path computation request may fail because all or a subset of 1026 the destinations are unreachable. 1028 In such a case, the UNREACH-DESTINATION object allows the PCE to 1029 optionally specify the list of unreachable destinations. 1031 This object can be present in PCRep messages. There can be up to one 1032 such object per RP. 1034 The following UNREACH-DESTINATION objects will be required: 1036 UNREACH-DESTINATION Object-Class is 28. 1037 UNREACH-DESTINATION Object-Type for IPv4 is 1. 1038 UNREACH-DESTINATION Object-Type for IPv6 is 2. 1040 The format of the UNREACH-DESTINATION object body for IPv4 (Object- 1041 Type=1) is as follows: 1043 0 1 2 3 1044 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 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Destination IPv4 address | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 ~ ... ~ 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Destination IPv4 address | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 Figure 9. UNREACH-DESTINATION Object Body for IPv4 1055 The format of the UNREACH-DESTINATION object body for IPv6 (Object- 1056 Type=2) is as follows: 1058 0 1 2 3 1059 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 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | | 1062 | Destination IPv6 address (16 bytes) | 1063 | | 1064 | | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 ~ ... ~ 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | | 1069 | Destination IPv6 address (16 bytes) | 1070 | | 1071 | | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 Figure 10. UNREACH-DESTINATION Object Body for IPv6 1076 3.15. P2MP PCEP-ERROR Objects and Types 1078 To indicate an error associated with policy violation, a new error 1079 value "P2MP Path computation not allowed" should be added to the 1080 existing error code for policy violation (Error-Type=5) as defined in 1081 [RFC5440]: 1083 Error-Type=5; Error-Value=7: if a PCE receives a P2MP path 1084 computation request that is not compliant with administrative 1085 privileges (i.e., "The PCE policy does not support P2MP path 1086 computation"), the PCE MUST send a PCErr message with a PCEP-ERROR 1087 object (Error-Type=5) and an Error-Value (Error-Value=7). The 1088 corresponding P2MP path computation request MUST also be cancelled. 1090 To indicate capability errors associated with the P2MP path request, 1091 a new Error-Type (16) and subsequent error-values are defined as 1092 follows for inclusion in the PCEP-ERROR object: 1094 Error-Type=16; Error-Value=1: if a PCE receives a P2MP path request 1095 and the PCE is not capable of satisfying the request due to 1096 insufficient memory, the PCE MUST send a PCErr message with a PCEP- 1097 ERROR object (Error-Type=16) and an Error-Value (Error-Value=1). The 1098 corresponding P2MP path computation request MUST also be cancelled. 1100 Error-Type=16; Error-Value=2: if a PCE receives a P2MP path request 1101 and the PCE is not capable of P2MP computation, the PCE MUST send a 1102 PCErr message with a PCEP-ERROR object (Error-Type=16) and an Error- 1103 Value (Error-Value=2). The corresponding P2MP path computation 1104 request MUST also be cancelled. 1106 To indicate P2MP message fragmentation errors associated with a P2MP 1107 path request, a new Error-Type (18) and subsequent error-values are 1108 defined as follows for inclusion in the PCEP-ERROR object: 1110 Error-Type=18; Error-Value=1: if a PCE has not received the last 1111 piece of the fragmented message, it should send an error message to 1112 the sender to signal that it has received an incomplete message 1113 (i.e., "Fragmented request failure"). The PCE MUST send a PCErr 1114 message with a PCEP-ERROR object (Error-Type=18) and an Error-Value 1115 (Error-Value=1). 1117 3.16. PCEP NO-PATH Indicator 1119 To communicate the reasons for not being able to find P2MP path 1120 computation, the NO-PATH object can be used in the PCRep message. 1122 One new bit is defined in the NO-PATH-VECTOR TLV carried in the 1123 NO-PATH Object: 1125 bit 24: when set, the PCE indicates that there is a reachability 1126 problem with all or a subset of the P2MP destinations. Optionally, 1127 the PCE can specify the destination or list of destinations that are 1128 not reachable using the new UNREACH-DESTINATION object defined in 1129 Section 3.14. 1131 4. Manageability Considerations 1133 [RFC5862] describes various manageability requirements in support of 1134 P2MP path computation when applying PCEP. This section describes how 1135 manageability requirements mentioned in [RFC5862] are supported in 1136 the context of PCEP extensions specified in this document. 1138 Note that [RFC5440] describes various manageability considerations in 1139 PCEP, and most of the manageability requirements mentioned in 1140 [RFC5862] are already covered there. 1142 4.1. Control of Function and Policy 1144 In addition to PCE configuration parameters listed in [RFC5440], the 1145 following additional parameters might be required: 1147 o The ability to enable or disable P2MP path computations on the 1148 PCE. 1150 o The PCE may be configured to enable or disable the advertisement 1151 of its P2MP path computation capability. A PCE can advertise its 1152 P2MP capability via the IGP discovery mechanism discussed in 1153 Section 3.1.1 ("P2MP Computation TLV in the Existing PCE Discovery 1154 Protocol"), or during the Open Message Exchange discussed in 1155 Section 3.1.2 ("Open Message Extension"). 1157 4.2. Information and Data Models 1159 A number of MIB objects have been defined for general PCEP control 1160 and monitoring of P2P computations in [RFC7420]. [RFC5862] specifies 1161 that MIB objects will be required to support the control and 1162 monitoring of the protocol extensions defined in this document. A new 1163 document will be required to define MIB objects for PCEP control and 1164 monitoring of P2MP computations. 1166 4.3. Liveness Detection and Monitoring 1168 There are no additional considerations beyond those expressed in 1169 [RFC5440], since [RFC5862] does not address any additional 1170 requirements. 1172 4.4. Verifying Correct Operation 1174 There are no additional requirements beyond those expressed in 1175 [RFC4657] for verifying the correct operation of the PCEP sessions. 1176 It is expected that future MIB objects will facilitate verification 1177 of correct operation and reporting of P2MP PCEP requests, responses, 1178 and errors. 1180 4.5. Requirements for Other Protocols and Functional Components 1182 The method for the PCE to obtain information about a PCE capable of 1183 P2MP path computations via OSPF and IS-IS is discussed in 1184 Section 3.1.1 ("P2MP Computation TLV in the Existing PCE Discovery 1185 Protocol") of this document. 1187 The subsequent IANA assignments are documented in Section 6.9 ("OSPF 1188 PCE Capability Flag") of this document. 1190 4.6. Impact on Network Operation 1192 It is expected that the use of PCEP extensions specified in this 1193 document will not significantly increase the level of operational 1194 traffic. However, computing a P2MP tree may require more PCE state 1195 compared to a P2P computation. In the event of a major network 1196 failure and multiple recovery P2MP tree computation requests being 1197 sent to the PCE, the load on the PCE may also be significantly 1198 increased. 1200 5. Security Considerations 1202 As described in [RFC5862], P2MP path computation requests are more 1203 CPU-intensive and also utilize more link bandwidth. In the event of 1204 an unauthorized P2MP path computation request, or a denial of service 1205 attack, the subsequent PCEP requests and processing may be disruptive 1206 to the network. Consequently, it is important that implementations 1207 conform to the relevant security requirements of [RFC5440] that 1208 specifically help to minimize or negate unauthorized P2MP path 1209 computation requests and denial of service attacks. These mechanisms 1210 include: 1212 o Securing the PCEP session requests and responses using TCP 1213 security techniques (Section 10.2 of [RFC5440]). 1215 o Authenticating the PCEP requests and responses to ensure the 1216 message is intact and sent from an authorized node (Section 10.3 1217 of [RFC5440]). 1219 o Providing policy control by explicitly defining which PCCs, via IP 1220 access-lists, are allowed to send P2MP path requests to the PCE 1221 (Section 10.6 of [RFC5440]). 1223 PCEP operates over TCP, so it is also important to secure the PCE and 1224 PCC against TCP denial of service attacks. Section 10.7.1 of 1225 [RFC5440] outlines a number of mechanisms for minimizing the risk of 1226 TCP based denial of service attacks against PCEs and PCCs. 1228 PCEP implementations SHOULD consider the additional security provided 1229 by the TCP Authentication Option (TCP-AO) [RFC5925]. 1231 6. IANA Considerations 1233 IANA maintains a registry of PCEP parameters. A number of IANA 1234 considerations have been highlighted in previous sections of this 1235 document. IANA made the allocations as per [RFC6006]. 1237 6.1. PCEP TLV Type Indicators 1239 As described in Section 3.1.2., the P2MP capability TLV allows the 1240 PCE to advertise its P2MP path computation capability. 1242 IANA had made an allocation from the "PCEP TLV Type Indicators" 1243 subregistry, where RFC 6006 was the reference. IANA is requested to 1244 update the reference as follows to point to this document. 1246 Value Description Reference 1248 6 P2MP capable [This I-D] 1250 6.2. Request Parameter Bit Flags 1252 As described in Section 3.3.1, three RP Object Flags have been 1253 defined. 1255 IANA has made an allocations from the PCEP "RP Object Flag Field" 1256 sub-registry, where RFC 6006 was the reference. IANA is requested to 1257 update the reference as follows to point to this document. 1259 Bit Description Reference 1261 18 Fragmentation (F-bit) [This I-D] 1262 19 P2MP (N-bit) [This I-D] 1263 20 ERO-compression (E-bit) [This I-D] 1265 6.3. Objective Functions 1267 As described in Section 3.6.1, two Objective Functions have been 1268 defined. 1270 IANA has made an allocations from the PCEP "Objective Function" sub- 1271 registry, where RFC 6006 was the reference.IANA is requested to 1272 update the reference as follows to point to this document. 1274 Code Point Name Reference 1276 7 SPT [This I-D] 1277 8 MCT [This I-D] 1279 6.4. Metric Object Types 1281 As described in Section 3.6.2, three metric object T fields have been 1282 defined. 1284 IANA has made an allocations from the PCEP "METRIC Object T Field" 1285 sub-registry, where RFC 6006 was the reference. IANA is requested to 1286 update the reference as follows to point to this document. 1288 Value Description Reference 1290 8 P2MP IGP metric [This I-D] 1291 9 P2MP TE metric [This I-D] 1292 10 P2MP hop count metric [This I-D] 1294 6.5. PCEP Objects 1296 As discussed in Section 3.3.2, two END-POINTS Object-Types are 1297 defined. 1299 IANA has made the Object-Type allocations from the "PCEP Objects" 1300 sub-registry, where RFC 6006 was the reference. IANA is requested to 1301 update the reference as follows to point to this document. 1303 Object-Class Value 4 1304 Name END-POINTS 1305 Object-Type 3: IPv4 1306 4: IPv6 1307 5-15: Unassigned 1308 Reference [This I-D] 1310 As described in Section 3.2, Section 3.11.1, and Section 3.14, four 1311 PCEP Object-Classes and six PCEP Object-Types have been defined. 1313 IANA has made an allocations from the "PCEP Objects" sub- registry, 1314 where RFC 6006 was the reference. IANA is requested to update the 1315 reference as follows to point to this document. 1317 Object-Class Value 28 1318 Name UNREACH-DESTINATION 1319 Object-Type 0: Reserved 1320 1: IPv4 1321 2: IPv6 1322 3-15: Unassigned 1323 Reference [This I-D] 1325 Object-Class Value 29 1326 Name SERO 1327 Object-Type 0: Reserved 1328 1: SERO 1329 2-15: Unassigned 1330 Reference [This I-D] 1332 Object-Class Value 30 1333 Name SRRO 1334 Object-Type 0: Reserved 1335 1: SRRO 1336 2-15: Unassigned 1337 Reference [This I-D] 1339 Object-Class Value 31 1340 Name Branch Node Capability Object 1341 Object-Type 0: Reserved 1342 1: Branch node list 1343 2: Non-branch node list 1344 3-15: Unassigned 1345 Reference [This I-D] 1347 6.6. PCEP-ERROR Objects and Types 1349 As described in Section 3.15, number of PCEP-ERROR Object Error Types 1350 and Values have been defined. 1352 IANA has made an allocations from the PCEP "PCEP-ERROR Object Error 1353 Types and Values" sub-registry, where RFC 6006 was the reference. 1354 IANA is requested to update the reference as follows to point to this 1355 document. 1357 Error 1358 Type Meaning Reference 1360 5 Policy violation 1361 Error-value=7: [This I-D] 1362 P2MP Path computation is not allowed 1364 16 P2MP Capability Error 1365 Error-Value=0: Unassigned [This I-D] 1366 Error-Value=1: [This I-D] 1367 The PCE is not capable to satisfy the request 1368 due to insufficient memory 1370 Error-Value=2: [This I-D] 1371 The PCE is not capable of P2MP computation 1373 17 P2MP END-POINTS Error 1374 Error-Value=0: Unassigned [This I-D] 1375 Error-Value=1: [This I-D] 1376 The PCE is not capable to satisfy the request 1377 due to no END-POINTS with leaf type 2 1378 Error-Value=2: [This I-D] 1379 The PCE is not capable to satisfy the request 1380 due to no END-POINTS with leaf type 3 1381 Error-Value=3: [This I-D] 1382 The PCE is not capable to satisfy the request 1383 due to no END-POINTS with leaf type 4 1384 Error-Value=4: [This I-D] 1385 The PCE is not capable to satisfy the request 1386 due to inconsistent END-POINTS 1388 18 P2MP Fragmentation Error 1389 Error-Value=0: Unassigned [This I-D] 1390 Error-Value=1: [This I-D] 1391 Fragmented request failure 1393 6.7. PCEP NO-PATH Indicator 1395 As discussed in Section 3.16, NO-PATH-VECTOR TLV Flag Field has been 1396 defined. 1398 IANA has made an allocation from the PCEP "NO-PATH-VECTOR TLV Flag 1399 Field" sub-registry, where RFC 6006 was the reference. IANA is 1400 requested to update the reference as follows to point to this 1401 document. 1403 Bit Description Reference 1405 24 P2MP Reachability Problem [This I-D] 1407 6.8. SVEC Object Flag 1409 As discussed in Section 3.12, two SVEC Object Flags are defined. 1411 IANA has made an allocation from the PCEP "SVEC Object Flag Field" 1412 sub-registry, where RFC 6006 was the reference. IANA is requested to 1413 update the reference as follows to point to this document. 1415 Bit Description Reference 1417 19 Partial Path Diverse [This I-D] 1418 20 Link Direction Diverse [This I-D] 1420 6.9. OSPF PCE Capability Flag 1422 As discussed in Section 3.1.1, OSPF Capability Flag is defined to 1423 indicate P2MP path computation capability. 1425 IANA has made an assignment from the OSPF Parameters "Path 1426 Computation Element (PCE) Capability Flags" registry, where RFC 6006 1427 was the reference. IANA is requested to update the reference as 1428 follows to point to this document. 1430 Bit Description Reference 1432 10 P2MP path computation [This I-D] 1434 7. Acknowledgements 1436 The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan, 1437 Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh Babu K, Dhruv 1438 Dhody, Udayasree Palle, Gaurav Agrawal, Vishwas Manral, Dan 1439 Romascanu, Tim Polk, Stewart Bryant, David Harrington, and Sean 1440 Turner for their valuable comments and input on the RFC 6006. 1442 Thanks to Deborah Brungard for handling of related errata on the RFC 1443 6006. 1445 Authors would like to thank Jonathan Hardwick and Adrian Farrel for 1446 providing review comments with suggested text for this document. 1448 8. References 1450 8.1. Normative References 1452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1453 Requirement Levels", BCP 14, RFC 2119, March 1997. 1455 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1456 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1457 Tunnels", RFC 3209, December 2001. 1459 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1460 Switching (GMPLS) Signaling Resource ReserVation 1461 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1462 RFC 3473, January 2003. 1464 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 1465 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 1467 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1468 Yasukawa, Ed., "Extensions to Resource Reservation 1469 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1470 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 1471 2007. 1473 [RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing 1474 Protocol Extensions for Discovery of Traffic Engineering 1475 Node Capabilities", RFC 5073, December 2007. 1477 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1478 Zhang, "OSPF Protocol Extensions for Path Computation 1479 Element (PCE) Discovery", RFC 5088, January 2008. 1481 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1482 Zhang, "IS-IS Protocol Extensions for Path Computation 1483 Element (PCE) Discovery", RFC 5089, January 2008. 1485 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1486 Used to Form Encoding Rules in Various Routing Protocol 1487 Specifications", RFC 5511, April 2009. 1489 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 1490 Computation Element (PCE) Communication Protocol (PCEP)", 1491 RFC 5440, March 2009. 1493 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1494 Objective Functions in the Path Computation Element 1495 Communication Protocol (PCEP)", RFC 5541, June 2009. 1497 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1498 S. Shaffer, "Extensions to OSPF for Advertising Optional 1499 Router Capabilities", RFC 7770, February 2016. 1501 8.2. Informative References 1503 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1504 Computation Element (PCE)-Based Architecture", RFC 4655, 1505 August 2006. 1507 [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation 1508 Element (PCE) Communication Protocol Generic 1509 Requirements", RFC 4657, September 2006. 1511 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 1512 Path Computation Element (PCE) to Point-to-Multipoint 1513 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", 1514 RFC 5671, October 2009. 1516 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 1517 (PCC) - Path Computation Element (PCE) Requirements for 1518 Point-to-Multipoint MPLS-TE", RFC 5862, June 2010. 1520 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1521 Authentication Option", RFC 5925, June 2010. 1523 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 1524 Ali, Z., and J. Meuric, "Extensions to the Path 1525 Computation Element Communication Protocol (PCEP) for 1526 Point-to-Multipoint Traffic Engineering Label Switched 1527 Paths", RFC 6006, September 2010. 1529 [RFC7420] Koushik, K., Stephan, E., Zhao, Q., King D., and J. 1530 Hardwick "PCE communication protocol (PCEP) Management 1531 Information Base (MIB) Module", RFC 7420, December 2014. 1533 Appendix A. Summary of the RBNF Changes from RFC 6006 1535 o Update to RBNF for Request message format: 1537 * Update to the request message to allow for the bundling of 1538 multiple path computation requests within a single Path 1539 Computation Request (PCReq) message. 1541 * Addition of in PCReq message. This object was missed 1542 in [RFC6006]. 1544 * Addition of BNC object in PCReq message. This object is required 1545 to support P2MP. It shares the same format as Include Route Object 1546 (IRO) but it is a different object. 1548 * Update to the format, to also allow Secondary Record 1549 Route object (SRRO). This object was missed in [RFC6006]. 1551 * Removed the BANDWIDTH Object followed by Record Route Object 1552 (RRO) from . As BANDWIDTH object doesn't need to follow 1553 for each RRO in the , there already exist BANDWIDTH 1554 object follow and is backward compatible with 1555 [RFC5440]. 1557 * Update to the , to allow optional 1558 BANDWIDTH object only if is included. 1560 o Update the RBNF for Reply message format: 1562 * Update to the reply message to allow for bundling of multiple 1563 path computation requests within a single Path Computation Reply 1564 (PCRep) message. 1566 * Addition of the UNREACH-DESTINATION in PCRep message. This 1567 object was missed in [RFC6006]. 1569 Contributors 1571 Jean-Louis Le Roux 1572 Orange 1573 2, Avenue Pierre-Marzin 1574 22307 Lannion Cedex 1575 France 1576 EMail: jeanlouis.leroux@orange.com 1578 Mohamad Chaitou 1579 France 1580 EMail: mohamad.chaitou@gmail.com 1582 Udayasree Palle 1583 Huawei Technologies 1584 Divyashree Techno Park, Whitefield 1585 Bangalore, Karnataka 560066 1586 India 1587 EMail: udayasree.palle@huawei.com 1589 Authors' Addresses 1590 Quintin Zhao 1591 Huawei Technology 1592 125 Nagog Technology Park 1593 Acton, MA 01719 1594 US 1595 EMail: quintin.zhao@huawei.com 1597 Dhruv Dhody 1598 Huawei Technology 1599 Divyashree Techno Park, Whitefield 1600 Bangalore, Karnataka 560066 1601 India 1602 EMail: dhruv.ietf@gmail.com 1604 Ramanjaneya Reddy Palleti 1605 Huawei Technology 1606 Divyashree Techno Park, Whitefield 1607 Bangalore, Karnataka 560066 1608 India 1609 EMail: ramanjaneya.palleti@huawei.com 1611 Daniel King 1612 Old Dog Consulting 1613 UK 1614 EMail: daniel@olddog.co.uk 1616 Fabien Verhaeghe 1617 Thales Communication France 1618 160 Bd Valmy 92700 Colombes 1619 France 1620 EMail: fabien.verhaeghe@gmail.com 1622 Tomonori Takeda 1623 NTT Corporation 1624 3-9-11, Midori-Cho 1625 Musashino-Shi, Tokyo 180-8585 1626 Japan 1627 EMail: takeda.tomonori@lab.ntt.co.jp 1629 Zafar Ali 1630 Cisco Systems, Inc. 1631 2000 Innovation Drive 1632 Kanata, Ontario K2K 3E8 1633 Canada 1634 EMail: zali@cisco.com 1636 Julien Meuric 1637 Orange 1638 2, Avenue Pierre-Marzin 1639 22307 Lannion Cedex 1640 France 1641 EMail: julien.meuric@orange.com