idnits 2.17.1 draft-ietf-pce-rfc6006bis-03.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 (July 03, 2017) is 2487 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 1430, 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: January 04, 2018 D. King 7 Old Dog Consulting 8 July 03, 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-03 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 January 04, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 This document may contain material from IETF Documents or IETF 64 Contributions published or made publicly available before November 65 10, 2008. The person(s) controlling the copyright in some of this 66 material may not have granted the IETF Trust the right to allow 67 modifications of such material outside the IETF Standards Process. 68 Without obtaining an adequate license from the person(s) controlling 69 the copyright in such materials, this document may not be modified 70 outside the IETF Standards Process, and derivative works of it may 71 not be created outside the IETF Standards Process, except to format 72 it for publication as an RFC or to translate it into languages other 73 than English. 75 Table of Contents 77 1. Introduction ....................................................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 0: Reserved 352 1: SERO 353 2-15: Unassigned 354 Reference [This I-D] 356 Object-Class Value 30 357 Name SRRO 358 Object-Type 0: Reserved 359 1: SRRO 360 2-15: Unassigned 361 Reference [This I-D] 363 The IANA assignment is documented in Section 6.5 ("PCEP Objects"). 365 Since the explicit path is available for immediate signaling by the 366 MPLS or GMPLS control plane, the meanings of all of the sub-objects 367 and fields in this object are identical to those defined for the ERO. 369 3.3. P2MP Path Computation Request/Reply Message Extensions 371 This document extends the existing P2P RP (Request Parameters) object 372 so that a PCC can signal a P2MP path computation request to the PCE 373 receiving the PCEP request. The END-POINTS object is also extended 374 to improve the efficiency of the message exchange between PCC and PCE 375 in the case of P2MP path computation. 377 3.3.1. The Extension of the RP Object 379 The PCE path computation request and reply messages will need the 380 following additional parameters to indicate to the receiving PCE that 381 the request and reply messages have been fragmented across multiple 382 messages, that they have been requested for a P2MP path, and whether 383 the route is represented in the compressed or uncompressed format. 385 This document adds the following flags to the RP Object: 387 The F-bit is added to the flag bits of the RP object to indicate to 388 the receiver that the request is part of a fragmented request, or is 389 not a fragmented request. 391 o F (RP fragmentation bit - 1 bit): 393 0: This indicates that the RP is not fragmented or it is the last 394 piece of the fragmented RP. 396 1: This indicates that the RP is fragmented and this is not the 397 last piece of the fragmented RP. The receiver needs to wait 398 for additional fragments until it receives an RP with the same 399 RP-ID and with the F-bit set to 0. 401 The N-bit is added in the flag bits field of the RP object to signal 402 the receiver of the message that the request/reply is for P2MP or is 403 not for P2MP. 405 o N (P2MP bit - 1 bit): 407 0: This indicates that this is not a PCReq or PCRep message for 408 P2MP. 410 1: This indicates that this is a PCReq or PCRep message for P2MP. 412 The E-bit is added in the flag bits field of the RP object to signal 413 the receiver of the message that the route is in the compressed 414 format or is not in the compressed format. By default, the path 415 returned by the PCE SHOULD use the compressed format. 417 o E (ERO-compression bit - 1 bit): 419 0: This indicates that the route is not in the compressed format. 421 1: This indicates that the route is in the compressed format. 423 The IANA assignment is documented in Section 6.2 ("Request Parameter 424 Bit Flags") of this document. 426 3.3.2. The New P2MP END-POINTS Object 428 The END-POINTS object is used in a PCReq message to specify the 429 source IP address and the destination IP address of the path for 430 which a path computation is requested. To represent the end points 431 for a P2MP path efficiently, we define two new types of END-POINTS 432 objects for the P2MP path: 434 o Old leaves whose path can be modified/reoptimized; 436 o Old leaves whose path must be left unchanged. 438 With the new END-POINTS object, the PCE path computation request 439 message is expanded in a way that allows a single request message to 440 list multiple destinations. 442 In total, there are now 4 possible types of leaves in a P2MP request: 444 o New leaves to add (leaf type = 1) 446 o Old leaves to remove (leaf type = 2) 448 o Old leaves whose path can be modified/reoptimized (leaf type = 3) 450 o Old leaves whose path must be left unchanged (leaf type = 4) 452 A given END-POINTS object gathers the leaves of a given type. The 453 type of leaf in a given END-POINTS object is identified by the END- 454 POINTS object leaf type field. 456 Using the new END-POINTS object, the END-POINTS portion of a request 457 message for the multiple destinations can be reduced by up to 50% for 458 a P2MP path where a single source address has a very large number of 459 destinations. 461 Note that a P2MP path computation request can mix the different types 462 of leaves by including several END-POINTS objects per RP object as 463 shown in the PCReq Routing Backus-Naur Form (RBNF) [RFC5511] format 464 in Section 3.4 ("Request Message Format"). 466 The format of the new END-POINTS object body for IPv4 (Object-Type 3) 467 is as follows: 469 0 1 2 3 470 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 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Leaf type | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Source IPv4 address | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Destination IPv4 address | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 ~ ... ~ 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Destination IPv4 address | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Figure 1. The New P2MP END-POINTS Object Body Format for IPv4 485 The format of the END-POINTS object body for IPv6 (Object-Type 4) is 486 as follows: 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Leaf type | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | | 494 | Source IPv6 address (16 bytes) | 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | | 498 | Destination IPv6 address (16 bytes) | 499 | | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 ~ ... ~ 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | | 504 | Destination IPv6 address (16 bytes) | 505 | | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 2. The New P2MP END-POINTS Object Body Format for IPv6 510 The END-POINTS object body has a variable length. These are 511 multiples of 4 bytes for IPv4, and multiples of 16 bytes, plus 4 512 bytes, for IPv6. 514 3.4. Request Message Format 516 As per [RFC5440], a Path Computation Request message (also referred 517 to as a PCReq message) is a PCEP message sent by a PCC to a PCE to 518 request a path computation. A PCReq message may carry more than one 519 path computation request. 521 As per [RFC5541], the OF object MAY be carried within a PCReq 522 message. If an objective function is to be applied to a set of 523 synchronized path computation requests, the OF object MUST be carried 524 just after the corresponding SVEC (Synchronization VECtor) object and 525 MUST NOT be repeated for each elementary request. 527 The PCReq message is encoded as follows using RBNF as defined in 528 [RFC5511]. 530 Below is the message format for the request message: 532 ::= 533 [] 534 536 where: 538 ::= 539 [] 540 [] 541 [] 543 ::=[] 545 ::= 546 547 [] 548 [] 549 [] 550 [] 551 [|] 552 [] 554 where: 556 ::= 557 [[]] 558 [] 560 ::=(|)[] 561 ::=[] 563 Figure 3. The Message Format for the Request Message 565 Note that we preserve compatibility with the [RFC5440] definition of 566 . At least one instance of MUST be present in 567 this message. 569 We have documented the IANA assignment of additional END-POINTS 570 Object-Types in Section 6.5 ("PCEP Objects") of this document. 572 3.5. Reply Message Format 574 The PCEP Path Computation Reply message (also referred to as a PCRep 575 message) is a PCEP message sent by a PCE to a requesting PCC in 576 response to a previously received PCReq message. PCEP supports the 577 bundling of multiple replies to a set of path computation requests 578 within a single PCRep message. 580 The PCRep message is encoded as follows using RBNF as defined in 581 [RFC5511]. 583 Below is the message format for the reply message: 585 ::= 586 588 where: 590 ::=[] 592 ::= 593 [] 594 [] 595 [] 596 [] 598 ::= 599 [] 600 [] 602 ::= (|) [] 604 where: 606 ::=[] 607 [] 608 [] 609 [] 610 [] 612 Figure 4. The Message Format for the Reply Message 614 The optional END-POINTS object in the reply message is used to 615 specify which paths are removed, changed, not changed, or added for 616 the request. The path is only needed for the end points that are 617 added or changed. 619 If the E-bit (ERO-Compress bit) was set to 1 in the request, then the 620 path will be formed by an ERO followed by a list of SEROs. 622 Note that we preserve compatibility with the [RFC5440] definition of 623 and the optional and . 625 3.6. P2MP Objective Functions and Metric Types 627 3.6.1. New Objective Functions 629 Six objective functions have been defined in [RFC5541] for P2P path 630 computation. 632 This document defines two additional objective functions -- namely, 633 SPT (Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to 634 P2MP path computation. Hence two new objective function codes have 635 to be defined. 637 The description of the two new objective functions is as follows. 638 Objective Function Code: 7 640 Name: Shortest Path Tree (SPT) 642 Description: Minimize the maximum source-to-leaf cost with respect 643 to a specific metric or to the TE metric used as the default 644 metric when the metric is not specified (e.g., TE or IGP metric). 646 Objective Function Code: 8 648 Name: Minimum Cost Tree (MCT) 650 Description: Minimize the total cost of the tree, that is the sum 651 of the costs of tree links, with respect to a specific metric or 652 to the TE metric used as the default metric when the metric is not 653 specified. 655 Processing these two new objective functions is subject to the rules 656 defined in [RFC5541]. 658 3.6.2. New Metric Object Types 660 There are three types defined for the object in [RFC5440] -- 661 namely, the IGP metric, the TE metric, and the hop count metric. This 662 document defines three additional types for the object: the 663 P2MP IGP metric, the P2MP TE metric, and the P2MP hop count metric. 664 They encode the sum of the metrics of all links of the tree. We 665 propose the following values for these new metric types: 667 o P2MP IGP metric: T=8 669 o P2MP TE metric: T=9 671 o P2MP hop count metric: T=10 673 3.7. Non-Support of P2MP Path Computation 675 o If a PCE receives a P2MP path request and it understands the P2MP 676 flag in the RP object, but the PCE is not capable of P2MP 677 computation, the PCE MUST send a PCErr message with a PCEP-ERROR 678 object and corresponding Error-Value. The request MUST then be 679 cancelled at the PCC. New Error-Types and Error-Values are 680 requested in Section 6 ("IANA Considerations") of this document. 682 o If the PCE does not understand the P2MP flag in the RP object, 683 then the PCE MUST send a PCErr message with Error-value=2 684 (capability not supported). 686 3.8. Non-Support by Back-Level PCE Implementations 688 If a PCE receives a P2MP request and the PCE does not understand the 689 P2MP flag in the RP object, and therefore the PCEP P2MP extensions, 690 then the PCE SHOULD reject the request. 692 3.9. P2MP TE Path Reoptimization Request 694 A reoptimization request for a P2MP TE path is specified by the use 695 of the R-bit within the RP object as defined in [RFC5440] and is 696 similar to the reoptimization request for a P2P TE path. The only 697 difference is that the PCC MUST insert the list of RROs and SRROs 698 after each type of END-POINTS in the PCReq message, as described in 699 the "Request Message Format" section (Section 3.4) of this document. 701 An example of a reoptimization request and subsequent PCReq message 702 is described below: 704 Common Header 705 RP with P2MP flag/R-bit set 706 END-POINTS for leaf type 3 707 RRO list 708 OF (optional) 710 Figure 5. PCReq Message Example 1 for Optimization 712 In this example, we request reoptimization of the path to all leaves 713 without adding or pruning leaves. The reoptimization request would 714 use an END-POINT type 3. The RRO list would represent the P2MP LSP 715 before the optimization, and the modifiable path leaves would be 716 indicated in the END-POINTS object. 718 It is also possible to specify distinct leaves whose path cannot be 719 modified. An example of the PCReq message in this scenario would be: 721 Common Header 722 RP with P2MP flag/R-bit set 723 END-POINTS for leaf type 3 724 RRO list 725 END-POINTS for leaf type 4 726 RRO list 727 OF (optional) 729 Figure 6. PCReq Message Example 2 for Optimization 731 3.10. Adding and Pruning Leaves to/from the P2MP Tree 733 When adding new leaves to or removing old leaves from the existing 734 P2MP tree, by supplying a list of existing leaves, it is possible to 735 optimize the existing P2MP tree. This section explains the methods 736 for adding new leaves to or removing old leaves from the existing 737 P2MP tree. 739 To add new leaves, the PCC MUST build a P2MP request using END- 740 POINTS with leaf type 1. 742 To remove old leaves, the PCC MUST build a P2MP request using END- 743 POINTS with leaf type 2. If no type-2 END-POINTS exist, then the PCE 744 MUST send an error type 17, value=1: The PCE is not capable of 745 satisfying the request due to no END-POINTS with leaf type 2. 747 When adding new leaves to or removing old leaves from the existing 748 P2MP tree, the PCC MUST also provide the list of old leaves, if any, 749 including END-POINTS with leaf type 3, leaf type 4, or both. New 750 PCEP-ERROR objects and types are necessary for reporting when certain 751 conditions are not satisfied (i.e., when there are no END-POINTS with 752 leaf type 3 or 4, or in the presence of END-POINTS with leaf type 1 753 or 2). A generic "Inconsistent END-POINT" error will be used if a 754 PCC receives a request that has an inconsistent END-POINT (i.e., if a 755 leaf specified as type 1 already exists). These IANA assignments are 756 documented in Section 6.6 ("PCEP-ERROR Objects and Types") of this 757 document. 759 For old leaves, the PCC MUST provide the old path as a list of RROs 760 that immediately follows each END-POINTS object. This document 761 specifies error values when specific conditions are not satisfied. 763 The following examples demonstrate full and partial reoptimization of 764 existing P2MP LSPs: 766 Case 1: Adding leaves with full reoptimization of existing paths 768 Common Header 769 RP with P2MP flag/R-bit set 770 END-POINTS for leaf type 1 771 RRO list 772 END-POINTS for leaf type 3 773 RRO list 774 OF (optional) 776 Case 2: Adding leaves with partial reoptimization of existing paths 778 Common Header 779 RP with P2MP flag/R-bit set 780 END-POINTS for leaf type 1 781 END-POINTS for leaf type 3 782 RRO list 783 END-POINTS for leaf type 4 784 RRO list 785 OF (optional) 787 Case 3: Adding leaves without reoptimization of existing paths 789 Common Header 790 RP with P2MP flag/R-bit set 791 END-POINTS for leaf type 1 792 RRO list 793 END-POINTS for leaf type 4 794 RRO list 795 OF (optional) 797 Case 4: Pruning Leaves with full reoptimization of existing paths 799 Common Header 800 RP with P2MP flag/R-bit set 801 END-POINTS for leaf type 2 802 RRO list 803 END-POINTS for leaf type 3 804 RRO list 805 OF (optional) 807 Case 5: Pruning leaves with partial reoptimization of existing paths 809 Common Header 810 RP with P2MP flag/R-bit set 811 END-POINTS for leaf type 2 812 RRO list 813 END-POINTS for leaf type 3 814 RRO list 815 END-POINTS for leaf type 4 816 RRO list 817 OF (optional) 819 Case 6: Pruning leaves without reoptimization of existing paths 821 Common Header 822 RP with P2MP flag/R-bit set 823 END-POINTS for leaf type 2 824 RRO list 825 END-POINTS for leaf type 4 826 RRO list 827 OF (optional) 829 Case 7: Adding and pruning leaves with full reoptimization of 830 existing paths 832 Common Header 833 RP with P2MP flag/R-bit set 834 END-POINTS for leaf type 1 835 END-POINTS for leaf type 2 836 RRO list 837 END-POINTS for leaf type 3 838 RRO list 839 OF (optional) 841 Case 8: Adding and pruning leaves with partial reoptimization of 842 existing paths 844 Common Header 845 RP with P2MP flag/R-bit set 846 END-POINTS for leaf type 1 847 END-POINTS for leaf type 2 848 RRO list 849 END-POINTS for leaf type 3 850 RRO list 851 END-POINTS for leaf type 4 852 RRO list 853 OF (optional) 855 Case 9: Adding and pruning leaves without reoptimization of existing 856 paths 858 Common Header 859 RP with P2MP flag/R-bit set 860 END-POINTS for leaf type 1 861 END-POINTS for leaf type 2 862 RRO list 863 END-POINTS for leaf type 4 864 RRO list 865 OF (optional) 867 3.11. Discovering Branch Nodes 869 Before computing the P2MP path, a PCE may need to be provided means 870 to know which nodes in the network are capable of acting as branch 871 LSRs. A PCE can discover such capabilities by using the mechanisms 872 defined in [RFC5073]. 874 3.11.1. Branch Node Object 876 The PCC can specify a list of nodes that can be used as branch nodes 877 or a list of nodes that cannot be used as branch nodes by using the 878 Branch Node Capability (BNC) Object. The BNC Object has the same 879 format as the Include Route Object (IRO) defined in [RFC5440], except 880 that it only supports IPv4 and IPv6 prefix sub-objects. Two Object- 881 types are also defined: 883 o Branch node list: List of nodes that can be used as branch nodes. 885 o Non-branch node list: List of nodes that cannot be used as branch 886 nodes. 888 The object can only be carried in a PCReq message. A Path Request 889 may carry at most one Branch Node Object. 891 The Object-Class and Object-types have been allocated by IANA. The 892 IANA assignment is documented in Section 6.5 ("PCEP Objects"). 894 3.12. Synchronization of P2MP TE Path Computation Requests 896 There are cases when multiple P2MP LSPs' computations need to be 897 synchronized. For example, one P2MP LSP is the designated backup of 898 another P2MP LSP. In this case, path diversity for these dependent 899 LSPs may need to be considered during the path computation. 901 The synchronization can be done by using the existing Synchronization 902 VECtor (SVEC) functionality defined in [RFC5440]. 904 An example of synchronizing two P2MP LSPs, each having two leaves for 905 Path Computation Request Messages, is illustrated below: 907 Common Header 908 SVEC for sync of LSP1 and LSP2 909 OF (optional) 910 RP for LSP1 911 END-POINTS1 for LSP1 912 RRO1 list 913 RP for LSP2 914 END-POINTS2 for LSP2 915 RRO2 list 917 Figure 7. PCReq Message Example for Synchronization 919 This specification also defines two new flags to the SVEC Object Flag 920 Field for P2MP path dependent computation requests. The first new 921 flag is to allow the PCC to request that the PCE should compute a 922 secondary P2MP path tree with partial path diversity for specific 923 leaves or a specific S2L sub-path to the primary P2MP path tree. The 924 second flag, would allow the PCC to request that partial paths should 925 be link direction diverse. 927 The following flags are added to the SVEC object body in this 928 document: 930 o P (Partial Path Diverse bit - 1 bit): 932 When set, this would indicate a request for path diversity for a 933 specific leaf, a set of leaves, or all leaves. 935 o D (Link Direction Diverse bit - 1 bit): 937 When set, this would indicate a request that a partial path or 938 paths should be link direction diverse. 940 The IANA assignment is referenced in Section 6.8 of this document. 942 3.13. Request and Response Fragmentation 944 The total PCEP message length, including the common header, is 945 16 bytes. In certain scenarios the P2MP computation request may not 946 fit into a single request or response message. For example, if a 947 tree has many hundreds or thousands of leaves, then the request or 948 response may need to be fragmented into multiple messages. 950 The F-bit has been outlined in "The Extension of the RP Object" 951 (Section 3.3.1) of this document. The F-bit is used in the RP object 952 to signal that the initial request or response was too large to fit 953 into a single message and will be fragmented into multiple messages. 954 In order to identify the single request or response, each message 955 will use the same request ID. 957 3.13.1. Request Fragmentation Procedure 959 If the initial request is too large to fit into a single request 960 message, the PCC will split the request over multiple messages. Each 961 message sent to the PCE, except the last one, will have the F-bit set 962 in the RP object to signify that the request has been fragmented into 963 multiple messages. In order to identify that a series of request 964 messages represents a single request, each message will use the same 965 request ID. 967 The assumption is that request messages are reliably delivered and in 968 sequence, since PCEP relies on TCP. 970 3.13.2. Response Fragmentation Procedure 972 Once the PCE computes a path based on the initial request, a response 973 is sent back to the PCC. If the response is too large to fit into a 974 single response message, the PCE will split the response over 975 multiple messages. Each message sent by the PCE, except the last 976 one, will have the F-bit set in the RP object to signify that the 977 response has been fragmented into multiple messages. In order to 978 identify that a series of response messages represents a single 979 response, each message will use the same response ID. 981 Again, the assumption is that response messages are reliably 982 delivered and in sequence, since PCEP relies on TCP. 984 3.13.3. Fragmentation Examples 986 The following example illustrates the PCC sending a request message 987 with Req-ID1 to the PCE, in order to add one leaf to an existing tree 988 with 1200 leaves. The assumption used for this example is that one 989 request message can hold up to 800 leaves. In this scenario, the 990 original single message needs to be fragmented and sent using two 991 smaller messages, which have the Req-ID1 specified in the RP object, 992 and with the F-bit set on the first message, and cleared on the 993 second message. 995 Common Header 996 RP1 with Req-ID1 and P2MP=1 and F-bit=1 997 OF (optional) 998 END-POINTS1 for P2MP 999 RRO1 list 1001 Common Header 1002 RP2 with Req-ID1 and P2MP=1 and F-bit=0 1003 OF (optional) 1004 END-POINTS1 for P2MP 1005 RRO1 list 1007 Figure 8. PCReq Message Fragmentation Example 1009 To handle a scenario where the last fragmented message piece is lost, 1010 the receiver side of the fragmented message may start a timer once it 1011 receives the first piece of the fragmented message. When the timer 1012 expires and it has not received the last piece of the fragmented 1013 message, it should send an error message to the sender to signal that 1014 it has received an incomplete message. The relevant error message is 1015 documented in Section 3.15 ("P2MP PCEP-ERROR Objects and Types"). 1017 3.14. UNREACH-DESTINATION Object 1019 The PCE path computation request may fail because all or a subset of 1020 the destinations are unreachable. 1022 In such a case, the UNREACH-DESTINATION object allows the PCE to 1023 optionally specify the list of unreachable destinations. 1025 This object can be present in PCRep messages. There can be up to one 1026 such object per RP. 1028 The following UNREACH-DESTINATION objects will be required: 1030 UNREACH-DESTINATION Object-Class is 28. 1031 UNREACH-DESTINATION Object-Type for IPv4 is 1. 1032 UNREACH-DESTINATION Object-Type for IPv6 is 2. 1034 The format of the UNREACH-DESTINATION object body for IPv4 (Object- 1035 Type=1) is as follows: 1037 0 1 2 3 1038 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 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Destination IPv4 address | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 ~ ... ~ 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Destination IPv4 address | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 Figure 9. UNREACH-DESTINATION Object Body for IPv4 1049 The format of the UNREACH-DESTINATION object body for IPv6 (Object- 1050 Type=2) is as follows: 1052 0 1 2 3 1053 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 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | | 1056 | Destination IPv6 address (16 bytes) | 1057 | | 1058 | | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 ~ ... ~ 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | | 1063 | Destination IPv6 address (16 bytes) | 1064 | | 1065 | | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 Figure 10. UNREACH-DESTINATION Object Body for IPv6 1070 3.15. P2MP PCEP-ERROR Objects and Types 1072 To indicate an error associated with policy violation, a new error 1073 value "P2MP Path computation not allowed" should be added to the 1074 existing error code for policy violation (Error-Type=5) as defined in 1075 [RFC5440]: 1077 Error-Type=5; Error-Value=7: if a PCE receives a P2MP path 1078 computation request that is not compliant with administrative 1079 privileges (i.e., "The PCE policy does not support P2MP path 1080 computation"), the PCE MUST send a PCErr message with a PCEP-ERROR 1081 object (Error-Type=5) and an Error-Value (Error-Value=7). The 1082 corresponding P2MP path computation request MUST also be cancelled. 1084 To indicate capability errors associated with the P2MP path request, 1085 a new Error-Type (16) and subsequent error-values are defined as 1086 follows for inclusion in the PCEP-ERROR object: 1088 Error-Type=16; Error-Value=1: if a PCE receives a P2MP path request 1089 and the PCE is not capable of satisfying the request due to 1090 insufficient memory, the PCE MUST send a PCErr message with a PCEP- 1091 ERROR object (Error-Type=16) and an Error-Value (Error-Value=1). The 1092 corresponding P2MP path computation request MUST also be cancelled. 1094 Error-Type=16; Error-Value=2: if a PCE receives a P2MP path request 1095 and the PCE is not capable of P2MP computation, the PCE MUST send a 1096 PCErr message with a PCEP-ERROR object (Error-Type=16) and an Error- 1097 Value (Error-Value=2). The corresponding P2MP path computation 1098 request MUST also be cancelled. 1100 To indicate P2MP message fragmentation errors associated with a P2MP 1101 path request, a new Error-Type (18) and subsequent error-values are 1102 defined as follows for inclusion in the PCEP-ERROR object: 1104 Error-Type=18; Error-Value=1: if a PCE has not received the last 1105 piece of the fragmented message, it should send an error message to 1106 the sender to signal that it has received an incomplete message 1107 (i.e., "Fragmented request failure"). The PCE MUST send a PCErr 1108 message with a PCEP-ERROR object (Error-Type=18) and an Error-Value 1109 (Error-Value=1). 1111 3.16. PCEP NO-PATH Indicator 1113 To communicate the reasons for not being able to find P2MP path 1114 computation, the NO-PATH object can be used in the PCRep message. 1116 One new bit is defined in the NO-PATH-VECTOR TLV carried in the 1117 NO-PATH Object: 1119 bit 24: when set, the PCE indicates that there is a reachability 1120 problem with all or a subset of the P2MP destinations. Optionally, 1121 the PCE can specify the destination or list of destinations that are 1122 not reachable using the new UNREACH-DESTINATION object defined in 1123 Section 3.14. 1125 4. Manageability Considerations 1127 [RFC5862] describes various manageability requirements in support of 1128 P2MP path computation when applying PCEP. This section describes how 1129 manageability requirements mentioned in [RFC5862] are supported in 1130 the context of PCEP extensions specified in this document. 1132 Note that [RFC5440] describes various manageability considerations in 1133 PCEP, and most of the manageability requirements mentioned in 1134 [RFC5862] are already covered there. 1136 4.1. Control of Function and Policy 1138 In addition to PCE configuration parameters listed in [RFC5440], the 1139 following additional parameters might be required: 1141 o The ability to enable or disable P2MP path computations on the 1142 PCE. 1144 o The PCE may be configured to enable or disable the advertisement 1145 of its P2MP path computation capability. A PCE can advertise its 1146 P2MP capability via the IGP discovery mechanism discussed in 1147 Section 3.1.1 ("P2MP Computation TLV in the Existing PCE Discovery 1148 Protocol"), or during the Open Message Exchange discussed in 1149 Section 3.1.2 ("Open Message Extension"). 1151 4.2. Information and Data Models 1153 A number of MIB objects have been defined for general PCEP control 1154 and monitoring of P2P computations in [RFC7420]. [RFC5862] specifies 1155 that MIB objects will be required to support the control and 1156 monitoring of the protocol extensions defined in this document. A new 1157 document will be required to define MIB objects for PCEP control and 1158 monitoring of P2MP computations. 1160 The PCEP YANG module [I-D.ietf-pce-pcep-yang] can be extended to also 1161 include the P2MP related parameters. 1163 4.3. Liveness Detection and Monitoring 1165 There are no additional considerations beyond those expressed in 1166 [RFC5440], since [RFC5862] does not address any additional 1167 requirements. 1169 4.4. Verifying Correct Operation 1171 There are no additional requirements beyond those expressed in 1172 [RFC4657] for verifying the correct operation of the PCEP sessions. 1174 It is expected that future MIB objects will facilitate verification 1175 of correct operation and reporting of P2MP PCEP requests, responses, 1176 and errors. 1178 4.5. Requirements for Other Protocols and Functional Components 1180 The method for the PCE to obtain information about a PCE capable of 1181 P2MP path computations via OSPF and IS-IS is discussed in 1182 Section 3.1.1 ("P2MP Computation TLV in the Existing PCE Discovery 1183 Protocol") of this document. 1185 The subsequent IANA assignments are documented in Section 6.9 ("OSPF 1186 PCE Capability Flag") of this document. 1188 4.6. Impact on Network Operation 1190 It is expected that the use of PCEP extensions specified in this 1191 document will not significantly increase the level of operational 1192 traffic. However, computing a P2MP tree may require more PCE state 1193 compared to a P2P computation. In the event of a major network 1194 failure and multiple recovery P2MP tree computation requests being 1195 sent to the PCE, the load on the PCE may also be significantly 1196 increased. 1198 5. Security Considerations 1200 As described in [RFC5862], P2MP path computation requests are more 1201 CPU-intensive and also utilize more link bandwidth. In the event of 1202 an unauthorized P2MP path computation request, or a denial of service 1203 attack, the subsequent PCEP requests and processing may be disruptive 1204 to the network. Consequently, it is important that implementations 1205 conform to the relevant security requirements of [RFC5440] that 1206 specifically help to minimize or negate unauthorized P2MP path 1207 computation requests and denial of service attacks. These mechanisms 1208 include: 1210 o Securing the PCEP session requests and responses using TCP 1211 security techniques (Section 10.2 of [RFC5440]). 1213 o Authenticating the PCEP requests and responses to ensure the 1214 message is intact and sent from an authorized node (Section 10.3 1215 of [RFC5440]). 1217 o Providing policy control by explicitly defining which PCCs, via IP 1218 access-lists, are allowed to send P2MP path requests to the PCE 1219 (Section 10.6 of [RFC5440]). 1221 PCEP operates over TCP, so it is also important to secure the PCE and 1222 PCC against TCP denial of service attacks. Section 10.7.1 of 1223 [RFC5440] outlines a number of mechanisms for minimizing the risk of 1224 TCP based denial of service attacks against PCEs and PCCs. 1226 PCEP implementations SHOULD consider the additional security provided 1227 by Transport Layer Security (TLS) [I-D.ietf-pce-pceps]. 1229 6. IANA Considerations 1231 IANA maintains a registry of PCEP parameters. A number of IANA 1232 considerations have been highlighted in previous sections of this 1233 document. IANA made the allocations as per [RFC6006]. 1235 6.1. PCEP TLV Type Indicators 1237 As described in Section 3.1.2., the P2MP capability TLV allows the 1238 PCE to advertise its P2MP path computation capability. 1240 IANA had made an allocation from the "PCEP TLV Type Indicators" 1241 subregistry, where RFC 6006 was the reference. IANA is requested to 1242 update the reference as follows to point to this document. 1244 Value Description Reference 1246 6 P2MP capable [This I-D] 1248 6.2. Request Parameter Bit Flags 1250 As described in Section 3.3.1, three RP Object Flags have been 1251 defined. 1253 IANA has made an allocations from the PCEP "RP Object Flag Field" 1254 sub-registry, where RFC 6006 was the reference. IANA is requested to 1255 update the reference as follows to point to this document. 1257 Bit Description Reference 1259 18 Fragmentation (F-bit) [This I-D] 1260 19 P2MP (N-bit) [This I-D] 1261 20 ERO-compression (E-bit) [This I-D] 1263 6.3. Objective Functions 1265 As described in Section 3.6.1, two Objective Functions have been 1266 defined. 1268 IANA has made an allocations from the PCEP "Objective Function" sub- 1269 registry, where RFC 6006 was the reference.IANA is requested to 1270 update the reference as follows to point to this document. 1272 Code Point Name Reference 1274 7 SPT [This I-D] 1275 8 MCT [This I-D] 1277 6.4. Metric Object Types 1279 As described in Section 3.6.2, three metric object T fields have been 1280 defined. 1282 IANA has made an allocations from the PCEP "METRIC Object T Field" 1283 sub-registry, where RFC 6006 was the reference. IANA is requested to 1284 update the reference as follows to point to this document. 1286 Value Description Reference 1288 8 P2MP IGP metric [This I-D] 1289 9 P2MP TE metric [This I-D] 1290 10 P2MP hop count metric [This I-D] 1292 6.5. PCEP Objects 1294 As discussed in Section 3.3.2, two END-POINTS Object-Types are 1295 defined. 1297 IANA has made the Object-Type allocations from the "PCEP Objects" 1298 sub-registry, where RFC 6006 was the reference. IANA is requested to 1299 update the reference as follows to point to this document. 1301 Object-Class Value 4 1302 Name END-POINTS 1303 Object-Type 3: IPv4 1304 4: IPv6 1305 5-15: Unassigned 1306 Reference [This I-D] 1308 As described in Section 3.2, Section 3.11.1, and Section 3.14, four 1309 PCEP Object-Classes and six PCEP Object-Types have been defined. 1311 IANA has made an allocations from the "PCEP Objects" sub- registry, 1312 where RFC 6006 was the reference. IANA is requested to update the 1313 reference as follows to point to this document. 1315 Object-Class Value 28 1316 Name UNREACH-DESTINATION 1317 Object-Type 0: Reserved 1318 1: IPv4 1319 2: IPv6 1320 3-15: Unassigned 1321 Reference [This I-D] 1323 Object-Class Value 29 1324 Name SERO 1325 Object-Type 0: Reserved 1326 1: SERO 1327 2-15: Unassigned 1328 Reference [This I-D] 1330 Object-Class Value 30 1331 Name SRRO 1332 Object-Type 0: Reserved 1333 1: SRRO 1334 2-15: Unassigned 1335 Reference [This I-D] 1337 Object-Class Value 31 1338 Name Branch Node Capability Object 1339 Object-Type 0: Reserved 1340 1: Branch node list 1341 2: Non-branch node list 1342 3-15: Unassigned 1343 Reference [This I-D] 1345 6.6. PCEP-ERROR Objects and Types 1347 As described in Section 3.15, number of PCEP-ERROR Object Error Types 1348 and Values have been defined. 1350 IANA has made an allocations from the PCEP "PCEP-ERROR Object Error 1351 Types and Values" sub-registry, where RFC 6006 was the reference. 1352 IANA is requested to update the reference as follows to point to this 1353 document. 1355 Error 1356 Type Meaning Reference 1358 5 Policy violation 1359 Error-value=7: [This I-D] 1360 P2MP Path computation is not allowed 1362 16 P2MP Capability Error 1363 Error-Value=0: Unassigned [This I-D] 1364 Error-Value=1: [This I-D] 1365 The PCE is not capable to satisfy the request 1366 due to insufficient memory 1368 Error-Value=2: [This I-D] 1369 The PCE is not capable of P2MP computation 1371 17 P2MP END-POINTS Error 1372 Error-Value=0: Unassigned [This I-D] 1373 Error-Value=1: [This I-D] 1374 The PCE is not capable to satisfy the request 1375 due to no END-POINTS with leaf type 2 1376 Error-Value=2: [This I-D] 1377 The PCE is not capable to satisfy the request 1378 due to no END-POINTS with leaf type 3 1379 Error-Value=3: [This I-D] 1380 The PCE is not capable to satisfy the request 1381 due to no END-POINTS with leaf type 4 1382 Error-Value=4: [This I-D] 1383 The PCE is not capable to satisfy the request 1384 due to inconsistent END-POINTS 1386 18 P2MP Fragmentation Error 1387 Error-Value=0: Unassigned [This I-D] 1388 Error-Value=1: [This I-D] 1389 Fragmented request failure 1391 6.7. PCEP NO-PATH Indicator 1393 As discussed in Section 3.16, NO-PATH-VECTOR TLV Flag Field has been 1394 defined. 1396 IANA has made an allocation from the PCEP "NO-PATH-VECTOR TLV Flag 1397 Field" sub-registry, where RFC 6006 was the reference. IANA is 1398 requested to update the reference as follows to point to this 1399 document. 1401 Bit Description Reference 1403 24 P2MP Reachability Problem [This I-D] 1405 6.8. SVEC Object Flag 1407 As discussed in Section 3.12, two SVEC Object Flags are defined. 1409 IANA has made an allocation from the PCEP "SVEC Object Flag Field" 1410 sub-registry, where RFC 6006 was the reference. IANA is requested to 1411 update the reference as follows to point to this document. 1413 Bit Description Reference 1415 19 Partial Path Diverse [This I-D] 1416 20 Link Direction Diverse [This I-D] 1418 6.9. OSPF PCE Capability Flag 1420 As discussed in Section 3.1.1, OSPF Capability Flag is defined to 1421 indicate P2MP path computation capability. 1423 IANA has made an assignment from the OSPF Parameters "Path 1424 Computation Element (PCE) Capability Flags" registry, where RFC 6006 1425 was the reference. IANA is requested to update the reference as 1426 follows to point to this document. 1428 Bit Description Reference 1430 10 P2MP path computation [This I-D] 1432 7. Acknowledgements 1434 The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan, 1435 Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh Babu K, Dhruv 1436 Dhody, Udayasree Palle, Gaurav Agrawal, Vishwas Manral, Dan 1437 Romascanu, Tim Polk, Stewart Bryant, David Harrington, and Sean 1438 Turner for their valuable comments and input on the RFC 6006. 1440 Thanks to Deborah Brungard for handling of related errata on the RFC 1441 6006. 1443 Authors would like to thank Jonathan Hardwick and Adrian Farrel for 1444 providing review comments with suggested text for this document. 1446 Thanks to Jonathan Hardwick for being the document shepherd and 1447 provide comments and guidance. 1449 Thanks to Ben Niven-Jenkins for RTGDIR reviews. 1451 Thanks to Deborah Brungard for being the responsible AD and guiding 1452 the authors. 1454 8. References 1456 8.1. Normative References 1458 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1459 Requirement Levels", BCP 14, RFC 2119, March 1997. 1461 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1462 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1463 Tunnels", RFC 3209, December 2001. 1465 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1466 Switching (GMPLS) Signaling Resource ReserVation 1467 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1468 RFC 3473, January 2003. 1470 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 1471 Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. 1473 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 1474 Yasukawa, Ed., "Extensions to Resource Reservation 1475 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 1476 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 1477 2007. 1479 [RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing 1480 Protocol Extensions for Discovery of Traffic Engineering 1481 Node Capabilities", RFC 5073, December 2007. 1483 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1484 Zhang, "OSPF Protocol Extensions for Path Computation 1485 Element (PCE) Discovery", RFC 5088, January 2008. 1487 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1488 Zhang, "IS-IS Protocol Extensions for Path Computation 1489 Element (PCE) Discovery", RFC 5089, January 2008. 1491 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1492 Used to Form Encoding Rules in Various Routing Protocol 1493 Specifications", RFC 5511, April 2009. 1495 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 1496 Computation Element (PCE) Communication Protocol (PCEP)", 1497 RFC 5440, March 2009. 1499 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1500 Objective Functions in the Path Computation Element 1501 Communication Protocol (PCEP)", RFC 5541, June 2009. 1503 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1504 S. Shaffer, "Extensions to OSPF for Advertising Optional 1505 Router Capabilities", RFC 7770, February 2016. 1507 8.2. Informative References 1509 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1510 Computation Element (PCE)-Based Architecture", RFC 4655, 1511 August 2006. 1513 [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation 1514 Element (PCE) Communication Protocol Generic 1515 Requirements", RFC 4657, September 2006. 1517 [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the 1518 Path Computation Element (PCE) to Point-to-Multipoint 1519 (P2MP) MPLS and GMPLS Traffic Engineering (TE)", 1520 RFC 5671, October 2009. 1522 [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients 1523 (PCC) - Path Computation Element (PCE) Requirements for 1524 Point-to-Multipoint MPLS-TE", RFC 5862, June 2010. 1526 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 1527 Ali, Z., and J. Meuric, "Extensions to the Path 1528 Computation Element Communication Protocol (PCEP) for 1529 Point-to-Multipoint Traffic Engineering Label Switched 1530 Paths", RFC 6006, September 2010. 1532 [RFC7420] Koushik, K., Stephan, E., Zhao, Q., King D., and J. 1533 Hardwick "PCE communication protocol (PCEP) Management 1534 Information Base (MIB) Module", RFC 7420, December 2014. 1536 [I-D.ietf-pce-pcep-yang] 1537 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1538 YANG Data Model for Path Computation Element 1539 Communications Protocol (PCEP)", draft-ietf-pce-pcep-yang 1540 (work in progress), March 2017. 1542 [I-D.ietf-pce-pceps] 1543 Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure 1544 Transport for PCEP", draft-ietf-pce-pceps (work in 1545 progress), January 2017. 1547 Appendix A. Summary of the RBNF Changes from RFC 6006 1549 o Update to RBNF for Request message format: 1551 * Update to the request message to allow for the bundling of 1552 multiple path computation requests within a single Path 1553 Computation Request (PCReq) message. 1555 * Addition of in PCReq message. This object was missed 1556 in [RFC6006]. 1558 * Addition of BNC object in PCReq message. This object is required 1559 to support P2MP. It shares the same format as Include Route Object 1560 (IRO) but it is a different object. 1562 * Update to the format, to also allow Secondary Record 1563 Route object (SRRO). This object was missed in [RFC6006]. 1565 * Removed the BANDWIDTH Object followed by Record Route Object 1566 (RRO) from . As BANDWIDTH object doesn't need to follow 1567 for each RRO in the , there already exist BANDWIDTH 1568 object follow and is backward compatible with 1569 [RFC5440]. 1571 * Update to the , to allow optional 1572 BANDWIDTH object only if is included. 1574 o Update the RBNF for Reply message format: 1576 * Update to the reply message to allow for bundling of multiple 1577 path computation requests within a single Path Computation Reply 1578 (PCRep) message. 1580 * Addition of the UNREACH-DESTINATION in PCRep message. This 1581 object was missed in [RFC6006]. 1583 Contributors 1585 Fabien Verhaeghe 1586 Thales Communication France 1587 160 Bd Valmy 92700 Colombes 1588 France 1589 EMail: fabien.verhaeghe@gmail.com 1591 Tomonori Takeda 1592 NTT Corporation 1593 3-9-11, Midori-Cho 1594 Musashino-Shi, Tokyo 180-8585 1595 Japan 1596 EMail: tomonori.takeda@ntt.com 1598 Zafar Ali 1599 Cisco Systems, Inc. 1600 2000 Innovation Drive 1601 Kanata, Ontario K2K 3E8 1602 Canada 1603 EMail: zali@cisco.com 1605 Julien Meuric 1606 Orange 1607 2, Avenue Pierre-Marzin 1608 22307 Lannion Cedex 1609 France 1610 EMail: julien.meuric@orange.com 1612 Jean-Louis Le Roux 1613 Orange 1614 2, Avenue Pierre-Marzin 1615 22307 Lannion Cedex 1616 France 1617 EMail: jeanlouis.leroux@orange.com 1619 Mohamad Chaitou 1620 France 1621 EMail: mohamad.chaitou@gmail.com 1623 Udayasree Palle 1624 Huawei Technologies 1625 Divyashree Techno Park, Whitefield 1626 Bangalore, Karnataka 560066 1627 India 1628 EMail: udayasree.palle@huawei.com 1630 Authors' Addresses 1631 Quintin Zhao 1632 Huawei Technology 1633 125 Nagog Technology Park 1634 Acton, MA 01719 1635 US 1636 EMail: quintin.zhao@huawei.com 1638 Dhruv Dhody 1639 Huawei Technology 1640 Divyashree Techno Park, Whitefield 1641 Bangalore, Karnataka 560066 1642 India 1643 EMail: dhruv.ietf@gmail.com 1645 Ramanjaneya Reddy Palleti 1646 Huawei Technology 1647 Divyashree Techno Park, Whitefield 1648 Bangalore, Karnataka 560066 1649 India 1650 EMail: ramanjaneya.palleti@huawei.com 1652 Daniel King 1653 Old Dog Consulting 1654 UK 1655 EMail: daniel@olddog.co.uk