idnits 2.17.1 draft-ietf-pce-pcep-p2mp-extensions-11.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, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (May 25, 2010) is 5079 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) ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: A later version (-11) exists of draft-ietf-pce-pcep-mib-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Q. Zhao, Ed. 2 Internet-Draft Huawei Technology 3 Intended Status: Standards Track Daniel King, Ed. 4 Expires: November 25, 2010 Old Dog Consulting 5 May 25, 2010 7 Extensions to the Path Computation Element Communication Protocol 8 (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths 9 draft-ietf-pce-pcep-p2mp-extensions-11.txt 11 Abstract 13 Point-to-point Multiprotocol Label Switching (MPLS) and Generalized 14 MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may 15 be established using signaling techniques, but their paths may first 16 need to be determined. The Path Computation Element (PCE) has been 17 identified as an appropriate technology for the determination of the 18 paths of P2MP TE LSPs. 20 This document describes extensions to the PCE communication Protocol 21 (PCEP) to handle requests and responses for the computation of paths 22 for P2MP TE LSPs. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on May 25, 2010. 47 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) 68 controlling the copyright in such materials, this document may not 69 be modified outside the IETF Standards Process, and derivative works 70 of it may not be created outside the IETF Standards Process, except 71 to format it for publication as an RFC or to translate it into 72 languages other than English. 74 Requirements Language 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [RFC2119]. 80 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .3 82 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . .4 83 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . .5 84 3. Protocol Procedures and Extensions . . . . . . . . . . . . . .6 85 3.1. P2MP Capability Advertisement . . . . . . . . . . . . . .6 86 3.1.1. P2MP Computation TLV in the Existing PCE Discovery 87 Protocol . . . . . . . . . . . . . . . . . . . . . . .6 88 3.1.2. Open Message Extension . . . . . . . . . . . . . . . .6 89 3.2. Efficient Presentation of P2MP TE LSPs . . . . . . . . . .7 90 3.3. P2MP Path Computation Request/Reply Message Extensions . .8 91 3.3.1. The Extension of the RP Object . . . . . . . . . . . .8 92 3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . .9 93 3.4. Request Message Format . . . . . . . . . . . . . . . . . .11 94 3.5. Reply Message Format . . . . . . . . . . . . . . . . . . .11 95 3.6. P2MP Objective Functions and Metric Types . . . . . . . .12 96 3.6.1. New Objective Functions . . . . . . . . . . . . . . .12 97 3.6.2. New Metric Object Types . . . . . . . . . . . . . . .13 98 3.7. Non-Support of P2MP Path Computation. . . . . . . . . . .13 99 3.8. Non-Support by Back-Level PCE Implementations. . . . . . .13 100 3.9. P2MP TE Path Reoptimization Request . . . . . . . . . . .14 101 3.10. Adding and Pruning Leaves to the P2MP Tree . . . . . . . .14 102 3.11. Discovering Branch Nodes . . . . . . . . . . . . . . . . .17 103 3.11.1 Branch Node Object . . . . . . . . . . . . . . . . . .17 104 3.12. Synchronization of P2MP TE Path Computation Requests . . .18 105 3.13. Request and Response Fragmentation . . . . . . . . . . . .19 106 3.13.1. Request Fragmentation Procedure . . . . . . . . . . .19 107 3.13.2. Response Fragmentation Procedure . . . . . . . . . . .19 108 3.13.3. Fragmentation Examples . . . . . . . . . . . . . . . .19 109 3.14. UNREACH-DESTINATION Object . . . . . . . . . . . . . . . .20 110 3.15. P2MP PCEP Error Object and Types . . . . . . . . . . . . .21 111 3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .22 112 4. Manageability Considerations . . . . . . . . . . . . . . . . .22 113 4.1. Control of Function and Policy . . . . . . . . . . . . . .23 114 4.2. Information and Data Models . . . . . . . . . . . . . . .23 115 4.3. Liveness Detection and Monitoring . . . . . . . . . . . .23 116 4.4. Verifying Correct Operation . . . . . . . . . . . . . . .23 117 4.5. Requirements on Other Protocols and Functional 118 Components . . . . . . . . . . . . . . . . . . . . . . . .23 119 4.6. Impact on Network Operation . . . . . . . . . . . . . . .24 120 5. Security Considerations . . . . . . . . . . . . . . . . . . .24 121 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .24 122 6.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . .25 123 6.2. Request Parameter Bit Flags . . . . . . . . . . . . . . .25 124 6.3. Objective Functions . . . . . . . . . . . . . . . . . . .25 125 6.4. Metric Object Types . . . . . . . . . . . . . . . . . . .25 126 6.5. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . .25 127 6.6. PCEP Error Objects and Types . . . . . . . . . . . . . . .26 128 6.7. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . .27 129 6.8. SVEC Object Flag . . . . . . . . . . . . . . . . . . . .27 130 6.9. OSPF PCE Capability Flag . . . . . . . . . . . . . . . .28 131 7. Acknowledgement's . . . . . . . . . . . . . . . . . . . . . .28 132 8. References . . . . . . . . . . . . . . . . . . . . . . . . . .28 133 8.1. Normative References . . . . . . . . . . . . . . . . . . .28 134 8.2. Informative References . . . . . . . . . . . . . . . . . .29 135 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .30 136 9.1. Contributors . . . . . . . . . . . . . . . . . . . . . . .31 138 1. Introduction 140 The Path Computation Element (PCE) defined in [RFC4655] is an entity 141 that is capable of computing a network path or route based on a 142 network graph, and applying computational constraints. A Path 143 Computation Client (PCC) may make requests to a PCE for paths to be 144 computed. 146 [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic 147 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 148 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. 150 The PCE has been identified as a suitable application for the 151 computation of paths for P2MP TE LSPs [RFC5671]. 153 The PCE communication protocol (PCEP) is designed as a communication 154 protocol between PCCs and PCEs for point-to-point (P2P) path 155 computations and is defined in [RFC5440]. However, that 156 specification does not provide a mechanism to request path 157 computation of P2MP TE LSPs. 159 A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. 160 These S2L sub-LSPs are set up between ingress and egress LSRs and are 161 appropriately overlaid to construct a P2MP TE LSP. During path 162 computation, the P2MP TE LSP may be determined as a set of S2L sub- 163 LSPs that are computed separately and combined to give the path of 164 the P2MP LSP, or the entire P2MP TE LSP may be determined as a P2MP 165 tree in a single computation. 167 This document relies on the mechanisms of PCEP to request path 168 computation for P2MP TE LSPs. One path computation request message 169 from a PCC may request the computation of the whole P2MP TE LSP, or 170 the request may be limited to a sub-set of the S2L sub-LSPs. In the 171 extreme case, the PCC may request the S2L sub-LSPs to be computed 172 individually with it being the PCC's responsibility to decide whether 173 to signal individual S2L sub-LSPs or combine the computation results 174 to signal the entire P2MP TE LSP. Hence the PCC may use one path 175 computation request message or may split the request across multiple 176 path computation messages. 178 1.1 Terminology 180 Terminology used in this document. 182 TE LSP: Traffic Engineered 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 paths 189 (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 2. Requirements 200 This section summarizes the PCC-PCE Communication Requirements for 201 P2MP MPLS-TE LSPs described in [PCE-P2MP-REQ]. The numbering system 202 corresponds to the requirement numbers used in [PCE-P2MP-REQ]. 204 1. The PCC MUST be able to specify that the request is a P2MP path 205 computation request. 207 2. The PCC MUST be able to specify that objective functions are to be 208 applied to the P2MP path computation request. 210 3. The PCE MUST have the capability to reject a P2MP path request 211 and indicate non-support of P2MP path computation. 213 4. The PCE MUST provide an indication of non-support of P2MP path 214 computation by back-level PCE implementations. 216 5. A P2MP path computation request MUST be able to list multiple 217 destinations. 219 6. A P2MP path computation response MUST be able to carry the path 220 of a P2MP LSP. 222 7. It MUST be possible for a single P2MP path computation request or 223 response to be conveyed by a sequence of messages. 225 8. It MUST NOT be possible for a single P2MP path computation 226 request to specify a set of different constraints, traffic 227 parameters, or quality-of-service requirements for different 228 destinations of a P2MP LSP. 230 9. P2MP path modification and P2MP path diverse MUST be supported. 232 10. It MUST be possible to reoptimize existing P2MP TE LSPs. 234 11. It MUST be possible to add and remove P2MP destinations 235 from existing paths. 237 12. It MUST be possible to specify a list of applicable branch 238 nodes to use when computing the P2MP path. 240 13. It MUST be possible for a PCC to discover P2MP path computation 241 capability. 243 14. The PCC MUST be able to request diverse paths when requesting a 244 P2MP path. 246 3. Protocol Procedures and Extensions 248 The following section describes the protocol extensions required to 249 satisfy the requirements specified in Section 2. (Requirements) 250 of this document. 252 3.1. P2MP Capability Advertisement 254 3.1.1. P2MP Computation TLV in the Existing PCE Discovery Protocol 256 [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF 257 Router Information LSA defined in [RFC4970] to facilitate PCE 258 discovery using OSPF. [RFC5088] specifies that no new sub-TLVs may be 259 added to the PCED TLV. This document defines a new flag in the OSPF 260 PCE Capability Flags to indicate the capability of P2MP computation. 262 Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE 263 Discovery using IS-IS. This document will use the same flag 264 requested for the OSPF PCE Capability Flags sub-TLV 265 to allow IS-IS to indicate the capability of P2MP computation. 267 The IANA request for a shared OSPF and IS-IS P2MP capability flag 268 is documented in Section 6.9. (OSPF PCE Capability Flag) of this 269 document. 271 PCEs wishing to advertise that they support P2MP path computation 272 would set the bit (to be assigned by IANA) accordingly. PCCs that 273 do not understand this bit will ignore it (per [RFC5088] and 274 [RFC5089]). PCEs that do not support P2MP will leave the bit clear 275 (per the default behavior defined in [RFC5088] and [RFC5089]). 277 PCEs that set the bit to indicate support of P2MP path computation 278 MUST follow the procedures in Section 3.1.2. (The New P2MP END-POINTS 279 Object)to further qualify the level of support 281 3.1.2. Open Message Extension 283 Based on the Capabilities Exchange requirement described in 284 [PCE-P2MP-REQ]. If a PCE does not advertise its P2MP capability 285 during discovery, PCEP should be used to allow a PCC to discover 286 during the Open Message Exchange, which PCEs are capable of 287 supporting P2MP path computation. 289 To satisfy this requirement, we extend the PCEP OPEN object by 290 defining a new optional TLV to indicate the PCE's capability to 291 perform P2MP path computations. 293 The allocation from the "PCEP TLV Type Indicators" sub-registry will 294 be assigned by IANA and the request is documented in Section 6.1. 295 (PCEP TLV Type Indicators). The description is "P2MP capable", the 296 length value is 2 bytes. The value field is set to default value 0. 298 The inclusion of this TLV in an OPEN object indicates that the sender 299 can perform P2MP path computations. 301 The capability TLV is meaningful only for a PCE so it will typically 302 appear only in one of the two Open messages during PCE session 303 establishment. However, in case of PCE cooperation (e.g., 304 inter-domain), when a PCE behaving as a PCC initiates a PCE session 305 it SHOULD also indicate its path computation capabilities. 307 3.2. Efficient Presentation of P2MP LSPs 309 When specifying additional leaves, or optimizing existing P2MP TE 310 LSPs as specified in [PCE-P2MP-REQ], it may be necessary to pass 311 existing P2MP LSP route information between the PCC and PCE in the 312 request and reply message. In each of these scenarios, we need new 313 path objects for efficiently passing the existing P2MP LSP between 314 the PCE and PCC. 316 We specify the use of the Reservation Protocol Traffic Engineering 317 Extensions (RSVP-TE) Explicit Route Object (ERO) to encode the 318 explicit route of a TE LSP through the network. PCEP ERO sub-object 319 types correspond to RSVP-TE ERO sub-object types. The format and 320 content of the ERO object are defined in [RFC3209] and [RFC3473]. 322 The Secondary Explicit Route Object (SERO) is used to specify the 323 explicit route of a S2L sub-LSP. The path of each subsequent S2L 324 sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object SERO. 325 The format of the SERO is the same as an ERO defined in [RFC3209] 326 and [RFC3473]. 328 The Secondary Recorded Route Object (SRRO) is used to record 329 the explicit route of the S2L sub-LSP. The class of the P2MP SRRO 330 is the same as the SRRO defined in [RFC4873]. 332 The SERO and SRRO are used to report the route of an existing TE 333 LSP for which a reoptimization is desired. The format and content 334 of the SERO and SRRO are defined in [RFC4875]. 336 A new PCEP object class and type are requested for SERO and SRRO. 338 Object-Class Value 26 339 Name SERO 340 Object-Type 1: SERO 341 2-15: Unassigned 342 Reference This.I-D 343 Object-Class Value 27 344 Name SRRO 345 Object-Type 1: SRRO 346 2-15: Unassigned 347 Reference This.I-D 349 The IANA request is referenced in Section 6.5. (PCEP Objects). 351 Since the explicit path is available for immediate signaling by the 352 MPLS or GMPLS control plane, the meanings of all of the sub-objects 353 and fields in this object are identical to those defined for the ERO. 355 3.3. P2MP Path Computation Request/Reply Message Extensions 357 This document extends the existing P2P RP (Request Parameters) object 358 so that a PCC can signal a P2MP path computation request to the PCE 359 receiving the PCEP request. The END-POINT object is also extended 360 to improve the efficiency of the message exchange between PCC and PCE 361 in the case of P2MP path computation. 363 3.3.1. The Extension of the RP Object 365 The PCE path computation request and reply message will need the 366 following additional parameters to allow a receiving PCE to 367 identify that the request and reply message has been fragmented 368 across multiple messages, has been requested for a P2MP path and to 369 specify if the route is represented in the compressed or uncompressed 370 format. 372 This document adds the following flags to the RP Object: 374 The F bit is added to the flag bits of the RP object to indicate 375 to the receiver that the request is part of a fragmented request, or 376 is not a fragmented request. 378 o F ( RP fragmentation bit - 1 bit): 380 0: This indicates that the RP is not fragmented or it is the 381 last piece of the fragmented RP. 383 1: This indicates that the RP is fragmented and this is not 384 the last piece of the fragmented RP. The receiver 385 needs to wait for additional fragments until it receives 386 an RP with the same RP-ID and with the F bit is set to 0. 388 The N bit is added in the flag bits field of the RP object to signal 389 the receiver of the message that the request/reply is for P2MP or 390 not. 392 o N ( P2MP bit - 1 bit): 394 0: This indicates that this is not PCReq/PCRep for P2MP. 396 1: This indicates that this is PCReq or PCRep message for P2MP. 398 The E bit is added in the flag bits field of the RP object to signal 399 the receiver of the message that the route is in the compressed 400 format or not. By default, the path returned by the PCE will use the 401 compressed format. 403 o E ( ERO-compression bit - 1 bit): 405 0: This indicates that the route is not in the compressed 406 format. 408 1: This indicates that the route is in the compressed format. 410 The IANA request is referenced in Section 6.2 (Request Parameter Bit 411 Flags) of this document. 413 3.3.2. The New P2MP END-POINTS Object 415 The END-POINTS object is used in a PCReq message to specify the 416 source IP address and the destination IP address of the path for 417 which a path computation is requested. To represent the end points 418 for a P2MP path efficiently, we define two new types of end-point 419 objects for the P2MP path: 421 o Old leaves whose path can be modified/reoptimized; 422 o Old leaves whose path must be left unchanged. 424 With the new END-POINTS object, the PCE path computation request 425 message is expanded in a way which allows a single request 426 message to list multiple destinations. 428 In total there are now 4 possible types of leaves in a P2MP request: 430 o New leaves to add (leaf type = 1) 431 o Old leaves to remove (leaf type = 2) 432 o Old leaves whose path can be modified/reoptimized (leaf type = 3) 433 o Old leaves whose path must be left unchanged (leaf type = 4) 435 A given END-POINTS object gathers the leaves of a given type. The 436 type of leaf in a given END-POINTS object is identified by the END- 437 POINTS object leaf type field. 439 Using the new END-POINTS object, the END-POINTS portion of a request 440 message for the multiple destinations can be reduced by up to 50% for 441 a P2MP path where a single source address has a very large number of 442 destinations. 444 Note that a P2MP path computation request can mix the different types 445 of leaves by including several END-POINTS object per RP object as 446 shown in the PCReq Routing Backus-Naur Format (RBNF) [RFC5511] format 447 in Section 3.4. (Request Message Format). 449 The format of the new END-POINTS object body for IPv4 (Object-Type 3) 450 is as follows: 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Leaf type | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Source IPv4 address | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Destination IPv4 address | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 ~ ... ~ 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Destination IPv4 address | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Figure 1: The New P2MP END-POINTS Object Body Format for IPv4 468 The format of the END-POINTS object body for IPv6 (Object-Type 4) is 469 as follows: 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Leaf type | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | | 477 | Source IPv6 address (16 bytes) | 478 | | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | | 481 | Destination IPv6 address (16 bytes) | 482 | | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 ~ ... ~ 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | | 487 | Destination IPv6 address (16 bytes) | 488 | | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Figure 2: The New P2MP END-POINTS Object Body Format for IPv6 493 The END-POINTS object body has a variable length. These are 494 multiples of 4 bytes for IPv4, and multiples of 16 bytes, plus 4 495 bytes, for IPv6. 497 3.4. Request Message Format 499 The PCReq message is encoded as follows using RBNF as defined in 500 [RFC5511]. 502 Below is the message format for the request message: 504 ::= 505 506 where: 507 ::= 508 509 [] 510 [] 511 [] 512 [] 513 [] 514 [] 516 where: 518 ::= 519 [][] 520 [] 522 ::=[][] 523 ::=[] 525 Figure 3: The Message Format for the Request Message 527 Note we preserve compatibility with the [RFC5440] definition of 528 . At least one instance of MUST be present 529 in this message. 531 We have documented the IANA request for additional END-POINTS 532 Object-Types in Section 6.5 (PCEP Objects) of this document. 534 3.5. Reply Message Format 536 The PCRep message is encoded as follows using RBNF as defined in 537 [RFC5511]. 539 Below is the message format for the reply message: 541 ::= 542 543 ::= 544 [] 545 [] 546 [] 548 where: 550 ::= 551 [][] 553 ::= (|) [] 555 ::=[] 556 [] 557 [] 558 [] 559 [] 561 Figure 4: The Message Format for the Reply Message 563 The optional END-POINTS in the reply message is used to specify which 564 paths are removed, changed, not changed, or added for the request. 565 The path is only needed for the end points which are added or 566 changed. 568 If the E bit (ERO-Compress bit) was set to 1 in the request then the 569 path will be formed by an ERO followed by a list of SEROs. 571 Note that we preserve compatibility with the [RFC5440] definition of 572 and the optional and . 574 3.6. P2MP Objective Functions and Metric Types 576 3.6.1. New Objective Functions 578 Six objective functions have been defined in [RFC5541] for P2P path 579 computation. 581 This document defines two additional objective functions, namely SPT 582 (Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to P2MP 583 path computation. Hence two new objective function codes have to be 584 defined. 585 The description of the two new objective functions is as follows. 587 Objective Function Code: 7 (suggested value, to be assigned by IANA) 589 Name: Shortest Path Tree (SPT) 590 Description: Minimize the maximum source-to-leaf cost with respect to 591 a specific metric or to the TE metric used as the default metric when 592 the metric is not specified. (e.g. TE or IGP metric) 594 Objective Function Code: 8 (suggested value, to be assigned by IANA) 596 Name: Minimum Cost Tree (MCT) 598 Description: Minimize the total cost of the tree, that is the sum of 599 the costs of tree links, with respect to a specific metric or to the 600 TE metric used as the default metric when the metric is not 601 specified. 603 Processing these two new objective functions is subject to the rules 604 defined in [RFC5541]. 606 3.6.2. New Metric Object Types 608 There are three types defined for the object in [RFC5440], 609 namely, the IGP metric, the TE metric and the Hop Count metric. This 610 document defines three additional types for the object: the 611 P2MP IGP metric, the P2MP TE metric, and the P2MP hop count metric. 612 They encode the sum of the metrics of all links of the tree. We 613 propose the following values for these new metric types: 615 o P2MP IGP metric: T=8 (suggested value, to be assigned by IANA) 617 o P2MP TE metric: T=9 (suggested value, to be assigned by IANA) 619 o P2MP hop count metric: T=10 (suggested value, to be assigned by 620 IANA) 622 3.7. Non-Support of P2MP Path Computation. 624 o If a PCE receives a P2MP path request and it understands the P2MP 625 flag in the RP object, but the PCE is not capable of P2MP 626 computation, the PCE MUST send a PCErr message with a PCEP-ERROR 627 Object and corresponding Error-Value. The request MUST then be 628 cancelled at the PCC. New Error-Types and Error-Values are 629 requested in Section 6. (IANA Considerations) of this document. 631 o If the PCE does not understand the P2MP flag in the RP object, 632 then the PCE MUST send a PCErr message with Error-value=2 633 (capability not supported). 635 3.8. Non-Support by Back-Level PCE Implementations. 637 If a PCE receives a P2MP request and the PCE does not understand the 638 P2MP flag in the RP object, and therefore the PCEP P2MP extensions, 639 then the PCE SHOULD reject the request. 641 3.9. P2MP TE Path Reoptimization Request 643 A reoptimization request for a P2MP TE path is specified by the use 644 of the R bit within the RP object as defined in [RFC5440] and is 645 similar to the reoptimization request for a P2P TE path. The only 646 difference is that the user MUST insert the list of RROs and SRROs 647 after each type of END-POINTS in the PCReq message, as described in 648 the Request Message Format section (Section 3.4) of this document. 650 An example of a reoptimization request and subsequent PCReq message 651 is described below: 653 Common Header 654 RP with P2MP flag/R bits set 655 END-POINTS for leaf type 3 656 RRO list 657 OF (optional) 659 Figure 5: PCReq Message Example 1 for Optimization 661 In this example, we request reoptimization of the path to all leaves 662 without adding or pruning leaves. The reoptimization request would 663 use an END-POINT type 3. The RRO list would represent the P2MP LSP 664 before the optimization and the modifiable path leaves would be 665 indicated in the END-POINTS object. 667 It is also possible to specify specific leaves whose path cannot 668 be modified. An example of the PCReq message in this scenario would 669 be: 671 Common Header 672 RP with P2MP flag/R bits set 673 END-POINTS for leaf type 3 674 RRO list 675 END-POINTS for leaf type 4 676 RRO list 677 OF (optional) 679 Figure 6: PCReq Message Example 2 for Optimization 681 3.10. Adding and Pruning Leaves to the P2MP Tree 683 When adding new leaves or removing old leaves to the existing P2MP 684 tree, by supplying a list of existing leaves, it SHOULD be possible 685 to optimize the existing P2MP tree. This section explains the methods 686 to add new leaves or remove old leaves to the existing P2MP tree. 688 To add new leaves the user MUST build a P2MP request using 689 END-POINTS with leaf type 1. 691 To remove old leaves the user must build a P2MP request using 692 END-POINTS with leaf type 2. If no type-2 end-points exist, then the 693 PCE MUST send an error type 17, value=1: The PCE is not capable to 694 satisfy the request due to no END-POINTS with leaf type 2. 696 The PCC must also provide the list of old leaves, if any, including 697 END-POINTS with leaf type 3, leaf type 4 or both. The error values 698 when the conditions are not satisfied (i.e., when there is no 699 END-POINTS with leaf type 3 or 4, in the presence of END-POINTS with 700 leaf type 1 or 2). A generic "Inconsistent END-POINT" error is also 701 requested if a PCC receives a request that has an inconsistent 702 END-POINT (i.e., if a leaf specified as type 1 already exists). The 703 The IANA request for all new error values is documented in Section 704 6.6. (PCEP Error Objects and Types) of this document. 706 For old leaves the user MUST provide the old path as a list of RROs 707 that immediately follows each END-POINTS object. This document 708 specifies error values when specific conditions are not satisfied. 710 The following examples demonstrate full and partial reoptimization 711 of existing P2MP LSPs: 713 Case 1: Adding leaves with full reoptimization of existing paths 715 Common Header 716 RP with P2MP flag/R bits set 717 END-POINTS for leaf type 1 718 RRO list 719 END-POINTS for leaf type 3 720 RRO list 721 OF (optional) 723 Case 2: Adding leaves with partial reoptimization of existing paths 725 Common Header 726 RP with P2MP flag/R bits set 727 END-POINTS for leaf type 1 728 END-POINTS for leaf type 3 729 RRO list 730 END-POINTS for leaf type 4 731 RRO list 732 OF (optional) 734 Case 3: Adding leaves without reoptimization of existing paths 735 Common Header 736 RP with P2MP flag/R bits set 737 END-POINTS for leaf type 1 738 RRO list 739 END-POINTS for leaf type 4 740 RRO list 741 OF (optional) 743 Case 4: Pruning Leaves with Full Reoptimization 745 Common Header 746 RP with P2MP flag/R bits set 747 END-POINTS for leaf type 2 748 RRO list 749 END-POINTS for leaf type 3 750 RRO list 751 OF (optional) 753 Case 5: Pruning leaves with partial reoptimization of existing paths 755 Common Header 756 RP with P2MP flag/R bits set 757 END-POINTS for leaf type 2 758 RRO list 759 END-POINTS for leaf type 3 760 RRO list 761 END-POINTS for leaf type 4 762 RRO list 763 OF (optional) 765 Case 6: Pruning leaves without reoptimization of existing paths 767 Common Header 768 RP with P2MP flag/R bits set 769 END-POINTS for leaf type 2 770 RRO list 771 END-POINTS for leaf type 4 772 RRO list 773 OF (optional) 775 Case 7: Adding and pruning leaves full reoptimization of existing 776 paths 777 Common Header 778 RP with P2MP flag/R bits set 779 END-POINTS for leaf type 1 780 END-POINTS for leaf type 2 781 RRO list 782 END-POINTS for leaf type 3 783 RRO list 784 OF (optional) 786 Case 8: Adding and pruning leaves with partial reoptimization of 787 existing paths 789 Common Header 790 RP with P2MP flag/R bits set 791 END-POINTS for leaf type 1 792 END-POINTS for leaf type 2 793 RRO list 794 END-POINTS for leaf type 3 795 RRO list 796 END-POINTS for leaf type 4 797 RRO list 798 OF (optional) 800 Case 9: Adding and pruning leaves without reoptimization of existing 801 paths 803 Common Header 804 RP with P2MP flag/R bits set 805 END-POINTS for leaf type 1 806 END-POINTS for leaf type 2 807 RRO list 808 END-POINTS for leaf type 4 809 RRO list 810 OF (optional) 812 3.11. Discovering Branch Nodes 814 Before computing the P2MP path, a PCE may need to be provided means 815 to know which nodes in the network are capable of acting as branch 816 LSRs. A PCE can discover such capabilities by using the mechanisms 817 defined in [RFC5073]. 819 3.11.1 Branch Node Object 821 The PCC can specify a list of nodes that can be used as branch 822 nodes or a list of nodes that cannot be used as branch nodes by 823 using the a BRANCH NODE Capability (BNC) Object. The BNC Object has 824 the same format as the IRO object defined in [RFC5440] except that 825 it only supports IPv4 and IPv6 prefix sub-objects. Two Object- 826 types are also defined: 828 o Branch node list: List of nodes that can be used as branch 829 nodes. 831 o Non-branch node list: List of nodes that cannot be used as branch 832 nodes. 834 The object can only be carried in a PCReq message. A Path Request 835 may carry at most one BRANCH NODE Object. 837 The Object-Class and Object-types will need to allocated by IANA. The 838 IANA request is documented in Section 6.5. (PCEP Objects). 840 3.12. Synchronization of P2MP TE Path Computation Requests 842 There are cases when multiple P2MP LSPs computations need to be 843 synchronized. For example, one P2MP LSP is the designated backup of 844 another P2MP LSP. In this case, path diverse for these dependent 845 LSPs may need to be considered during the path computation. 847 The synchronization can be done by using the existing SVEC 848 functionality defined in [RFC5440] 850 An example of synchronizing two P2MP LSPs, each has two leaves for 851 Path Computation Request Messages is illustrated as below: 853 Common Header 854 SVEC for sync of LSP1 and LSP2 855 OF (optional) 856 END-POINTS1 for P2MP 857 RRO1 list 858 END-POINTS2 for P2MP 859 RRO2 list 861 Figure 7: PCReq Message Example for Synchronization 863 This specification also defines two new flags to the SVEC Object Flag 864 Field for P2MP path dependent computation requests. The first new 865 flag is to allow the PCC to request that the PCE should compute a 866 secondary P2MP path tree with partial path diverse for specific 867 leaves or a specific S2L sub-path to the primary P2MP path tree. 868 The second flag, would allow the PCC to request that partial paths 869 should be link direction diverse. 871 The following flags are added to the SVEC object body in this 872 document: 874 o P ( Partial Path Diverse bit - 1 bit): 876 When set this would indicate a request for path diverse 877 for a specific leaf, a set of leaves or all leaves. 879 o D ( Link Direction Diverse bit - 1 bit): 881 When set this would indicate a request that a partial path or 882 paths should be link direction diverse. 884 The IANA request is referenced in Section 6.8. of this document. 886 3.13. Request and Response Fragmentation 888 The total PCEP message-length, including the common header, is 16 889 bytes. In certain scenarios the P2MP computation request may not fit 890 into a single request or response message. For example, if a tree has 891 many hundreds or thousands of leaves, then the request or response 892 may need to be fragmented into multiple messages. 894 The F bit has been outlined in the Extension of the RP Object section 895 (Section 3.3.1) of this document. The F bit is used in the RP object 896 header to signal that the initial request or response was too large 897 to fit into a single message and will be fragmented into multiple 898 messages. In order to identify the single request or response, each 899 message will use the same request ID. 901 3.13.1 Request Fragmentation Procedure 903 If the initial request is too large to fit into a single request 904 message the PCC will split the request over multiple messages. Each 905 message sent to the PCE, except the last one, will have the F bit set 906 in the RP object to signify that the request has been fragmented 907 into multiple messages. In order to identify that a series of 908 request messages represents a single request, each message will 909 use the same request ID. 911 The assumption is that request messages are reliably delivered 912 and in sequence since PCEP relies on TCP. 914 3.13.2 Response Fragmentation Procedure 916 Once the PCE computes a path based on the initial request, a response 917 is sent back to the PCC. If the response is too large to fit into a 918 single response message the PCE will split the response over multiple 919 messages. Each message sent to the PCE, except the last one, will 920 have the F bit set in the RP object to signify that the response 921 has been fragmented into multiple messages. In order to identify 922 that a series of response messages represents a single response, 923 each message will use the same response ID. 925 Again, the assumption is that response messages are reliably 926 delivered and in sequence since PCEP relies on TCP. 928 3.13.3 Fragmentation Examples 929 The following example illustrates the PCC sending a request message 930 with Req-ID1 to the PCE, in order to add one leaf to an existing tree 931 with 1200 leaves. The assumption used for this example is that one 932 request message can hold up to 800 leaves. In this scenario, the 933 original single message needs to be fragmented and sent using two 934 smaller messages, which have the Req-ID1 specified in the RP object, 935 and with the F bit set on the first message, and cleared on the 936 second message. 938 Common Header 939 RP1 with Req-ID1 and P2MP=1 and F-bit=1 940 OF (optional) 941 END-POINTS1 for P2MP 942 RRO1 list 944 Common Header 945 RP2 with Req-ID1 and P2MP=1 and F-bit=0 946 OF (optional) 947 END-POINTS1 for P2MP 948 RRO1 list 950 Figure 8: PCReq Message Fragmentation Example 952 To handle the scenario that the last fragmented message piece is 953 lost, the receiver side of the fragmented message may start a timer 954 once it receives the first piece of the fragmented message. When 955 the timer expires and it has not received the last piece of the 956 fragmented message, it should send an error message to the sender 957 to signal that it has received an incomplete message. The relevant 958 error message is document in Section 3.15. (P2MP PCEP Error Objects 959 and Types). 961 3.14. UNREACH-DESTINATION Object 963 The PCE path computation request may fail because all or a subset of 964 the destinations are unreachable. 966 In such a case, the UNREACH-DESTINATION object allows the PCE to 967 optionally specify the list of unreachable destinations. 969 This object can be present in PCRep messages. There can be up to one 970 such object per RP. 972 The following UNREACH-DESTINATION objects will be required: 974 UNREACH-DESTINATION Object-Class is to be assigned by IANA. 975 UNREACH-DESTINATION Object-Type for IPv4 is to be assigned by IANA 976 UNREACH-DESTINATION Object-Type for IPv6 is to be assigned by IANA. 978 The format of the UNREACH-DESTINATION object body for IPv4 (Object- 979 Type=1) is as follows: 981 0 1 2 3 982 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 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Destination IPv4 address | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 ~ ... ~ 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Destination IPv4 address | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 Figure 9: UNREACH-DESTINATION Object Body for IPv4 993 The format of the UNREACH-DESTINATION object body for IPv6 (Object- 994 Type=2) is as follows: 996 0 1 2 3 997 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 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | | 1000 | Destination IPv6 address (16 bytes) | 1001 | | 1002 | | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 ~ ... ~ 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | | 1007 | Destination IPv6 address (16 bytes) | 1008 | | 1009 | | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 Figure 10: UNREACH-DESTINATION Object Body for IPv6 1014 3.15. P2MP PCEP Error Objects and Types 1016 To indicate an error associated with policy violation, a new error 1017 value "P2MP Path computation not allowed" should be added to the 1018 existing error code for policy violation (Error-Type=5) as defined 1019 in [RFC5440]: 1021 Error-Type=5; Error-Value=7: if a PCE receives a P2MP path 1022 computation request which is not compliant with administrative 1023 privileges (i.e., "The PCE policy does not support P2MP path 1024 computation"), the PCE MUST send a PCErr message with a PCEP-ERROR 1025 Object (Error-Type=5) and an Error-Value (Error-Value=7). The 1026 corresponding P2MP path computation request MUST also be cancelled. 1028 To indicate capability errors associated with the P2MP path request, 1029 a new Error-Type (16) and subsequent error-values are defined as 1030 follows for inclusion in the PCEP-ERROR object: 1032 Error-Type=16 and Error-Value=1: if a PCE receives a P2MP path 1033 request and the PCE is not capable to satisfy the request due to 1034 insufficient memory, the PCE MUST send a PCErr message with a PCEP 1035 ERROR object (Error-Type=16) and an Error-Value(Error-Value=1). The 1036 corresponding P2MP path computation request MUST also be cancelled. 1038 Error-Type=16; Error-Value=2: if a PCE receives a P2MP path request 1039 and the PCE is not capable of P2MP computation, the PCE MUST send a 1040 PCErr message with a PCEP-ERROR Object (Error-Type=16) and an Error- 1041 Value (Error-Value=2). The corresponding P2MP path computation 1042 request MUST be also cancelled. 1044 To indicate P2MP message fragmentation errors associated with a P2MP 1045 path request, a new Error-Type (17) and subsequent error-values are 1046 defined as follows for inclusion in the PCEP-ERROR object: 1048 Error-Type=18; Error-Value=1: if a PCE has not received the last 1049 piece of the fragmented message, it should send an error message 1050 to the sender to signal that it has received an incomplete message 1051 (i.e., "Fragmented request failure"), the PCE MUST send a PCErr 1052 message with a PCEP-ERROR Object (Error-Type=18) and an Error-Value 1053 (Error-Value=1). 1055 3.16. PCEP NO-PATH Indicator 1057 To communicate the reasons for not being able to find P2MP path 1058 computation, the NO-PATH object can be used in the PCRep message. 1060 One new bit is defined in the NO-PATH-VECTOR TLV carried in 1061 the NO-PATH Object: 1063 bit 24: when set, the PCE indicates that there is a reachability 1064 problem with all or a subset of the P2MP destinations. Optionally 1065 the PCE can specify the destination or list of destinations that are 1066 not reachable using the new UNREACH-DESTINATION object defined in 1067 section 3.6. 1069 4. Manageability Considerations 1071 [PCE-P2MP-REQ] describes various manageability requirements in 1072 support of P2MP path computation when applying PCEP. This section 1073 describes how manageability requirements mentioned in [PCE-P2MP-REQ] 1074 are supported in the context of PCEP extensions specified in this 1075 document. 1077 Note that [RFC5440] describes various manageability considerations in 1078 PCEP, and most of manageability requirements mentioned in [PCE-P2MP 1079 P2MP] are already covered there. 1081 4.1. Control of Function and Policy 1083 In addition to PCE configuration parameters listed in [RFC5440], 1084 the following additional parameters might be required: 1086 o The ability to enable to disable P2MP path computations on the 1087 PCE. 1089 o The PCE may be configured to enable or disable the advertizement 1090 of its P2MP path computation capability. A PCE can advertize its 1091 P2MP capability via the IGP discovery mechanism discussed in 1092 Section 3.1.1. (P2MP Computation TLV in the Existing PCE Discovery 1093 Protocol), or during the Open Message Exchange discussed in 1094 Section 3.1.2. (Open Message Extension). 1096 4.2. Information and Data Models 1098 A number of MIB objects have been defined for general PCEP control 1099 and monitoring of P2P computations in [PCEP-MIB]. [PCE-P2MP-REQ] 1100 specifies that MIB objects will be required to support the control 1101 and monitoring of the protocol extensions defined in this document. 1102 A new document will be required to define MIB objects for PCEP 1103 control and monitoring of P2MP computations. 1105 4.3. Liveness Detection and Monitoring 1107 There are no additional considerations beyond those expressed in 1108 [RFC5440], since [PCE-P2MP-REQ] does not address any additional 1109 requirements. 1111 4.4. Verifying Correct Operation 1113 There are no additional requirements beyond those expressed in 1114 [RFC4657] for verifying the correct operation of the PCEP sessions. 1115 It is expected that future MIB objects will facilitate verification 1116 of correct operation and reporting of P2MP PCEP requests, responses 1117 and errors. 1119 4.5. Requirements on Other Protocols and Functional Components 1121 The method for the PCE to obtain information about a PCE capable of 1122 P2MP path computations via OSPF and IS-IS is discussed in Section 1123 3.1.1 (P2MP Computation TLV in the Existing PCE Discovery Protocol) 1124 of this document. 1126 The subsequent IANA requests are documented in Section 6.9 (PCE 1127 Capability Flag) of this document. 1129 4.6. Impact on Network Operation 1131 It is expected that use of PCEP extensions specified in this document 1132 will not significantly increase the level of operational traffic. 1133 However, computing a P2MP tree may require more PCE state compared to 1134 a P2P computation. In the event of a major network failure and 1135 multiple recovery P2MP tree computation requests being sent to the 1136 PCE, the load on the PCE may also be significantly increased. 1138 5. Security Considerations 1140 As described in [PCE-P2MP-REQ], P2MP path computation requests are 1141 more CPU-intensive and also utilize more link bandwidth. In the 1142 event of an unauthorized P2MP path computation request, or denial of 1143 service attack, the subsequent PCEP requests and processing may be 1144 disruptive to the network. Consequently, it is important that 1145 implementations conform to the relevant security requirements of 1146 [RFC5440] that specifically help to minimize or negate unauthorized 1147 P2MP path computation requests and denial of service attacks. These 1148 mechanisms include: 1150 o Securing the PCEP session requests and responses using TCP Security 1151 Techniques (Section 10.2. [RFC5440]). 1153 o Authenticating the PCEP requests and responses to ensure the 1154 message is intact and sent from an authorized node (Section 10.3. 1155 [RFC5440]). 1157 o Providing policy control by explicitly defining which PCCs, via IP 1158 access-lists, are allowed to send P2MP path requests to the PCE 1159 (Section 10.6. [RFC5440]). 1161 PCEP operates over TCP so it is also important to secure the PCE and 1162 PCC against TCP denial of service attacks. Section 10.7.1 of 1163 [RFC5440] outlines a number of mechanisms for minimizing the risk of 1164 TCP based denial of service attacks against PCEs and PCCs. 1166 PCEP implementations SHOULD consider the additional security provided 1167 by TCP-AO [TCP-AUTH]. 1169 6. IANA Considerations 1171 IANA maintains a registry of PCEP parameters. A number of IANA 1172 considerations have been highlighted in previous sections of this 1173 document. IANA is requested to make the following allocations. 1175 6.1 PCEP TLV Type Indicators 1177 As described in Section 3.1.2., the newly defined P2MP capability TLV 1178 allows the PCE to advertize its P2MP path computation capability. 1179 IANA is requested to make the following allocation from the "PCEP 1180 TLV Type Indicators" sub-registry. 1182 Value Description Reference 1183 6 P2MP capable This.I-D 1185 6.2 Request Parameter Bit Flags 1187 As described in Section 3.3.1., three new RP Object Flags have 1188 been defined. IANA is requested to make the following allocations 1189 from the "PCEP RP Object Flag Field" Sub-Registry: 1191 Bit Description Reference 1193 18 Fragmentation(F-bit) This.I-D 1194 19 P2MP (N-bit) This.I-D 1195 20 ERO-compression (E-bit) This.I-D 1197 6.3 Objective Functions 1199 As described in Section 3.6.1., two new Objective Functions have been 1200 defined. IANA is requested to make the following allocations from the 1201 "PCEP Objective Function" sub-registry: 1203 Code Point Name Reference 1205 7 SPT This.I-D 1206 8 MCT This.I-D 1208 6.4 Metric Object Types 1210 As described in Section 3.6.2., three new metric object T fields have 1211 been defined. IANA is requested to make the following allocations 1212 from the "PCEP METRIC Object T Field" sub-registry: 1214 Value Description Reference 1216 8 P2MP IGP metric This.I-D 1217 9 P2MP TE metric This.I-D 1218 10 P2MP hop count metric This.I-D 1220 6.5 PCEP Objects 1222 As discussed in Section 3.3.2., two new END-POINTS Object-Types are 1223 defined. IANA is requested to make the following Object-Type 1224 allocations from the "PCEP Objects" sub-registry: 1226 Object-Class Value 4 1227 Name END-POINTS 1228 Object-Type 3: IPv4 1229 4: IPv6 1230 5-15: Unassigned 1231 Reference This.I-D 1233 As described in Section 3.2., Section 3.11.1. and Section 3.14., 1234 four PCEP Object-Classes and six PCEP Object-Types have been defined. 1235 IANA is requested to make the following allocations from the "PCEP 1236 Objects" sub-registry: 1238 Object-Class Value 28 1239 Name UNREACH-DESTINATION 1240 Object-Type 1: IPv4 1241 2: IPv6 1242 3-15: Unassigned 1243 Reference This.I-D 1245 Object-Class Value 29 1246 Name SERO 1247 Object-Type 1: SERO 1248 2-15: Unassigned 1249 Reference This.I-D 1251 Object-Class Value 30 1252 Name SRRO 1253 Object-Type 1: SRRO 1254 2-15: Unassigned 1255 Reference This.I-D 1257 Object-Class Value 31 1258 Name Branch Node Capability Object 1259 Object-Type 1: Branch node list 1260 2: Non-branch node list 1261 3-15: Unassigned 1262 Reference This.I-D 1264 6.6 PCEP Error Objects and Types 1266 As described in Section 3.15., a number of new PCEP-ERROR Object 1267 Error Types and Values have been defined. IANA is requested to 1268 make the following allocations from the "PCEP PCEP-ERROR Object 1269 Error Type and Value" sub-registry: 1271 Error 1272 Type Meaning Reference 1274 5 Policy violation 1275 Error-value=7: This.I-D 1276 P2MP Path computation is not allowed 1278 16 P2MP Capability Error This.I-D 1279 Error-Value=0: Unassigned 1280 Error-Value=1: This.I-D 1281 The PCE is not capable to satisfy the request 1282 due to insufficient memory 1283 Error-Value=2: This.I-D 1284 The PCE is not capable of P2MP computation 1286 17 P2MP END-POINTS Error This.I-D 1287 Error-Value=0: Unassigned 1288 Error-Value=1: This.I-D 1289 The PCE is not capable to satisfy the request 1290 due to no END-POINTS with leaf type 2 1291 Error-Value=2: This.I-D 1292 The PCE is not capable to satisfy the request 1293 due to no END-POINTS with leaf type 3 1294 Error-Value=3: This.I-D 1295 The PCE is not capable to satisfy the request 1296 due to no END-POINTS with leaf type 4 1297 Error-Value=4: This.I-D 1298 The PCE is not capable to satisfy the request 1299 due to inconsistent END-POINTS 1301 18 P2MP Fragmentation Error This.I-D 1302 Error-Value=0: Unassigned 1303 Error-Value=1: This.I-D 1304 Fragmented request failure 1306 6.7 PCEP NO-PATH Indicator 1308 As discussed in Section 3.16, a new NO-PATH-VECTOR TLV Flag Field 1309 has been defined. IANA is requested to make the following 1310 allocation from the "PCEP NO-PATH-VECTOR TLV Flag Field" 1311 sub-registry: 1313 Bit Description Reference 1315 24 P2MP Reachability Problem This.I-D 1317 6.8 SVEC Object Flag 1319 As discussed in Section 3.12, two new SVEC Object Flags are 1320 defined. IANA is requested to make the following 1321 allocation from the "PCEP SVEC Object Flag Field" sub-registry: 1323 Bit Description Reference 1325 19 Partial Path Diverse This.I-D 1326 20 Link Direction Diverse This.I-D 1328 6.9 PCE Capability Flag 1330 As discussed in Section 3.1, a new OSPF Capability Flag is defined 1331 to indicate P2MP path computation capability. IANA is requested to 1332 make the assignment from the "OSPF Parameters Path Computation 1333 Element (PCE) Capability Flags" registry: 1335 Bit Description Reference 1337 10 P2MP path computation This.I-D 1339 7. Acknowledgements 1341 The authors would like to thank Adrian Farrel, Young Lee, Dan 1342 Tappan, Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh 1343 Babu K,Dhruv Dhody, Udayasree Palle, Gaurav Agrawal, Vishwas 1344 Manral, Dan Romascanu, Tim Polk, Stewart Bryant, David 1345 Harrington and Sean Turner for their valuable comments and input 1346 on this draft. 1348 8. References 1350 8.1. Normative References 1352 [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, 1353 A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, 1354 "Path Computation Element (PCE) Communication Protocol 1355 (PCEP)", RFC 5440, March 2009. 1357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1358 Requirement Levels", BCP 14, RFC 2119, March 1997. 1360 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1361 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1362 Tunnels", RFC 3209, December 2001. 1364 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 1365 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 1366 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 1368 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 1369 "GMPLS Segment Recovery", RFC 4873, May 2007 1371 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1372 "Extensions to Resource Reservation Protocol - Traffic 1373 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1374 Switched Paths (LSPs)", RFC 4875, May 2007. 1376 [RFC4970] Lindem A., et al. 1377 "Extensions to OSPF for Advertising Optional Router 1378 Capabilities', RFC 4970, July 2007 1380 [RFC5073] Vasseur, JP., Le Roux, JL., "IGP Routing Protocol 1381 Extensions for Discovery of Traffic Engineering Node 1382 Capabilities", RFC 5073, December 2007. 1384 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1385 "OSPF Protocol Extensions for Path Computation Element 1386 (PCE) Discovery", RFC 5088, January 2008. 1388 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1389 Zhang, "IS-IS Protocol Extensions for Path Computation 1390 Element (PCE) Discovery", RFC 5089, January 2008. 1392 [RFC5511] Farrel, F., "Routing Backus-Naur Form (RBNF): A Syntax 1393 Used to Form Encoding Rules in Various Routing Protocol 1394 Specifications", RFC 5511, April 2009. 1396 [RFC5541] 1397 Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective 1398 Functions in the Path Computation Element Communication 1399 Protocol (PCEP)", RFC5541, December 2008. 1401 8.2. Informative References 1403 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1404 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1406 [RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the Path 1407 Computation Element (PCE) to Point-to-Multipoint (P2MP) 1408 MPLS and GMPLS Traffic Engineering (TE)" RFC 5671, 1409 October 2009. 1411 [PCE-P2MP-REQ] 1412 Yasukawa, S. and A. Farrel, "PCC-PCE Communication 1413 Requirements for Point to Multipoint Multiprotocol Label 1414 Switching Traffic Engineering (MPLS-TE)", 1415 draft-ietf-pce-p2mp-req-05 (work in progress), 1416 December 2009. 1418 [PCEP-MIB] Koushik, K., Stephan, E., Zhao, Q., and King, D., 1419 "PCE communication protocol(PCEP) Management 1420 Information Base", draft-ietf-pce-pcep-mib-01 (work in 1421 progress), March 2010. 1423 [RFC4657] J. Ash, J.L Le Roux et al., " Path Computation Element 1424 (PCE) Communication Protocol Generic Requirements", RFC 1425 4657, September 2006. 1427 [TCP-AUTH] Touch, J., Mankin, A., and R. Bonica, "The TCP 1428 Authentication Option", draft-ietf-tcpm-tcp-auth-opt-11 1429 (work in progress), March 2010. 1431 9. Authors' Addresses 1433 Quintin Zhao (editor) 1434 Huawei Technology 1435 125 Nagog Technology Park 1436 Acton, MA 01719 1437 US 1438 Email: qzhao@huawei.com 1440 Daniel King (editor) 1441 Old Dog Consulting 1442 UK 1443 Email: daniel@olddog.co.uk 1445 Fabien Verhaeghe 1446 Thales Communication France 1447 160 Bd Valmy 92700 Colombes 1448 France 1449 Email: fabien.verhaeghe@gmail.com 1451 Tomonori Takeda 1452 NTT Corporation 1453 3-9-11, Midori-Cho 1454 Musashino-Shi, Tokyo 180-8585 1455 Japan 1456 Email: takeda.tomonori@lab.ntt.co.jp 1458 Zafar Ali 1459 Cisco systems, Inc. 1460 2000 Innovation Drive 1461 Kanata, Ontario K2K 3E8 1462 Canada 1463 Email: zali@cisco.com 1465 Julien Meuric 1466 France Telecom 1467 2, avenue Pierre-Marzin 1468 22307 Lannion Cedex, 1469 julien.meuric@orange-ftgroup.com 1471 9.1 Contributors 1473 Jean-Louis Le Roux 1474 France Telecom 1475 2, avenue Pierre-Marzin 1476 22307 Lannion Cedex, 1477 France 1478 Email: jeanlouis.leroux@orange-ftgroup.com 1480 Mohamad Chaitou 1481 France 1482 Email: mohamad.chaitou@gmail.com