idnits 2.17.1 draft-zhao-pcep-p2mp-extension-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1001. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 871. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 878. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 884. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2, 2008) is 5776 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) == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-12 -- Possible downref: Normative reference to a draft: ref. 'ID.pcep-p2mp-req' == Outdated reference: A later version (-06) exists of draft-ietf-pce-of-02 ** Downref: Normative reference to an Informational draft: draft-nishioka-pce-svec-list (ref. 'ID.pce-svec-list') Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Q. Zhao(Editor) 2 Internet-Draft Huawei Technology 3 Intended status: Standards Track M. Chaitou(Editor) 4 Expires: December, 2008 France Telecom 5 July 2, 2008 7 Extensions to the Path Computation Element Communication Protocol 8 (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths 9 draft-zhao-pcep-p2mp-extension-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 29, 2008. 36 Abstract 38 Point-to-point Multiprotocol Label Switching (MPLS) and Generalized 39 MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may 40 be established using signaling techniques, but their paths may first 41 be determined. The Path Computation Element (PCE) has been 42 identified as an appropriate technology for the determination of the 43 paths of P2MP TE LSPs. 45 This document describes extensions to the PCE Communication Protocol 46 PCEP) to handle requests and responses for the computation of paths 47 for P2MP TE LSPs. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 Table of Contents 57 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Protocol Procedures and Extensions . . . . . . . . . . . . . . 6 61 4.1. P2MP LSPs Efficient Presentation . . . . . . . . . . . . . 6 62 4.2. Indication of P2MP Path Computation Request/Reply . . . . 6 63 4.2.1. The Extension of RP Object . . . . . . . . . . . . . . 6 64 4.2.2. The New P2MP END-POINTS Object . . . . . . . . . . . . 7 65 4.3. Request Message Formats . . . . . . . . . . . . . . . . . 10 66 4.4. Reply Message Formats . . . . . . . . . . . . . . . . . . 11 67 5. P2MP Objective Functions and Metric Types . . . . . . . . . . 12 68 5.1. New Object Functions . . . . . . . . . . . . . . . . . . . 12 69 5.2. New Metric Object Types . . . . . . . . . . . . . . . . . 13 70 6. Non-Support of P2MP Path Computation. . . . . . . . . . . . . 13 71 7. Non-Support by Back-Level PCE Implementations. . . . . . . . . 14 72 8. P2MP TE Path Re-optimization Request . . . . . . . . . . . . . 14 73 9. Adding/pruning Leaves . . . . . . . . . . . . . . . . . . . . 15 74 10. Branch Nodes . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 11. Synchronization of P2MP TE Path Computation Requests . . . . . 15 76 12. P2MP Capability Advertisement . . . . . . . . . . . . . . . . 16 77 12.1. Extend the TLV in the Existing PCE Discovery Protocol . . 16 78 12.2. Open Message Extension . . . . . . . . . . . . . . . . . . 16 79 13. Multi-Message Support . . . . . . . . . . . . . . . . . . . . 17 80 14. UNREACH_DESTINATION object . . . . . . . . . . . . . . . . . . 18 81 15. P2MP PCEP Error Object . . . . . . . . . . . . . . . . . . . . 19 82 16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 20 83 17. Manageability Considerations . . . . . . . . . . . . . . . . . 20 84 17.1. Control of Function and Policy . . . . . . . . . . . . . . 21 85 17.2. Information and Data Models . . . . . . . . . . . . . . . 21 86 17.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21 87 17.4. Verifying Correct Operation . . . . . . . . . . . . . . . 21 88 17.5. Requirements on Other Protocols and Functional 89 Components . . . . . . . . . . . . . . . . . . . . . . . . 21 90 17.6. Impact on Network Operation . . . . . . . . . . . . . . . 21 91 18. Security Considerations . . . . . . . . . . . . . . . . . . . 21 92 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 93 20. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22 94 21. Intellectual Property Considerations . . . . . . . . . . . . . 22 95 22. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 96 22.1. Normative References . . . . . . . . . . . . . . . . . . . 23 97 22.2. Informative References . . . . . . . . . . . . . . . . . . 23 98 23. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 99 24. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25 101 1. Terminology 103 Terminology used in this document 105 TE LSP: Traffic Engineered Label Switched Path. 107 LSR: Label Switch Router. 109 OF: Objective Function: A set of one or more optimization criterion 110 (criteria) used for the computation of a single path (e.g. path cost 111 minimization), or the synchronized computation of a set of paths 112 (e.g. aggregate bandwidth consumption minimization, etc.). 114 PCC: Path Computation Client: Any client application requesting a 115 path computation to be performed by a Path Computation Element. 117 PCE: Path Computation Element: An entity (component, application, or 118 network node) that is capable of computing a network path or route 119 based on a network graph, and applying computational constraints. 121 PCEP: Path Computation Element communication Protocol. 123 P2MP: Point-to-MultiPoint. 125 P2P: Point-to-Point. 127 This document also uses the terminology defined in [RFC4655], 128 [RFC4875], and [ID.pcep]. 130 2. Introduction 132 The Path Computation Element (PCE) defined in [RFC4655] is an entity 133 that is capable of computing a network path or route based on a 134 network graph, and applying computational constraints. A Path 135 Computation Client (PCC) may make requests to a PCE for paths to be 136 computed. 138 [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic 139 Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol 140 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. 142 The PCE is identified as a suitable application for the computation 143 of paths for P2MP TE LSPs [ID.pcep-p2mp-req]. 145 The PCE communication protocol (PCEP) is designed as a communication 146 protocol between PCCs and PCEs for point-to-point (P2P) path 147 computations and is defined in [ID.pcep]. However, that 148 specification does not provide a mechanism to request path 149 computation of P2MP TE LSPs. 151 This document presents extensions to PCEP to support P2MP path 152 computation satisfying the set of requirements described in 153 [ID.pcep-p2mp-req]. 155 This document relies on the semantics of PCEP for requesting path 156 computation for P2MP TE LSPs. A P2MP LSP is comprised of multiple 157 source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between 158 ingress and egress LSRs and are appropriately combined by the branch 159 LSRs using computation result from PCE to result in a P2MP TE LSP. 160 One request message from a PCC may signal one or more S2L sub-LSP 161 path computation requests to the PCE for a single P2MP LSP with 162 certain constraints. Hence the S2L sub-LSPs belonging to a P2MP LSP 163 can use one path computation request message or be split across 164 multiple path computation messages. 166 3. Requirements 168 This section summarizes the PCEP requirements specific to Point to 169 Multi point as described in [ID.pcep-p2mp-req]. 171 R1: Indication of P2MP Path Computation Request. 173 R2: Indication of P2MP Objective Functions. 175 R3: Non-Support of P2MP Path Computation. 177 R4: Non-Support by Back-Level PCE Implementations. 179 R5: Specification of Destinations. 181 R6: Indication of P2MP Paths. 183 R7: Multi-Message Requests and Responses. 185 R8: Non-Specification of Per-Destination Constraints and Parameters. 187 R9: Path Modification and Path Diversity. 189 R10: Reoptimization of P2MP TE LSPs. 191 R11: Addition and Removal of Destinations from Existing Paths. 193 R12: Specification of Applicable Branch Nodes. 195 R13: Capabilities Exchange. 197 Also there are additional requirments which might be need to be added 198 into the requirement draft. Here we list the ones which may need to 199 be highlighted in the requirement draft (to be discussed with the 200 authors of the requirements draft). 202 R14: Sender of the request message can specify if the return result 203 from the PCE need to be represented in the compressed format or not. 205 4. Protocol Procedures and Extensions 207 The following sections describe the protocol extensions to satisfy 208 the requirements specified in the previous section. 210 4.1. P2MP LSPs Efficient Presentation 212 In the request message of the adding of leaves, optimization of P2MP 213 TE LSPs as specified in [ID.pcep-p2mp-req], and in the reply message, 214 we need to pass an existing P2MP LSP between the PCC and PCE. In 215 these cases, we need new path objects for efficiently passing the 216 existing P2MP LSP between PCE to PCC. 218 We suggest to using the ERO/SERO and RRO/SRRO to represent each 219 individual S2L sub-LSP. The ERO/RRO are same as defined in the 220 [ID.pcep] and SERO and SRRO are same as defined in RFC4875 for the 221 RSVP extension of P2MP. 223 4.2. Indication of P2MP Path Computation Request/Reply 225 The existing P2P RP object is extended so that it can signal to the 226 receiver of the request or reply message that it is for P2P or P2MP 227 path computation. Also the END- POINT object is extended to improve 228 the efficiency of the message exchange between PCC and PCE in the 229 case of P2MP path computation. 231 4.2.1. The Extension of RP Object 233 The PCE path computation request/reply message adds an explicit 234 parameter to allow a receiving PCE to identify that the request/reply 235 is for a P2MP path and also specify if the route is represented in 236 the compress format or not. 238 The M bit is added in the flag bits field of the RP object to signal 239 the receiver of the message that the request/reply is for P2P or it 240 is for P2MP. 242 The E bit is added in the flag bits field of the RP object to signal 243 the receiver of the message that the route is in the compress format 244 or not. 246 The extended format of the RP object body to include the M bit and 247 the E bit is as follows: 249 0 1 2 3 250 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 2 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Reserved | Flags |E|M| O|B|R| Pri | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Request-ID-number | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 // Optional TLV(s) // 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 1: RP Object Body Format 263 The following flags are added in this draft: 265 o M ( P2MP bit - 1 bit): 267 0: This indicates that this is not PCReq/PCRrep for P2MP. 269 1: This indicates that this is PCReq or PCRep message for P2MP. 271 o E ( ERO-compression bit - 1 bit): 273 0: This indicates that the route is not in the compressed 274 format. 276 1: This indicates that the route is in the compressed format. 278 4.2.2. The New P2MP END-POINTS Object 280 To represent the end points for a P2MP path efficiently, we define a 281 new type of end-points object for P2MP path. 283 With this new END-POINTS object, the PCE path computation request 284 message is expanded in a way such that it allows a single request 285 message to list multiple destinations. 287 There are 4 types of leaves in a P2MP request: 289 o New leaves to add; 291 o Old leaves to remove; 293 o Old leaves whose path can be modified/reoptimized; 295 o Old leaves whose path must be left unchanged. 297 A given END-POINTS object gathers the leaves of a given type. The 298 type of leaf in a given END-POINTS object is identified by the END- 299 POINTS object leaf type field. 301 So four values are possible for the leaf type field: 303 1. New leaves to add; 305 2. Old leaves to remove; 307 3. Old leaves whose path can be modified/reoptimized; 309 4. Old leaves whose path must be left unchanged. 311 With this new END-POINTS object, the request message size for the 312 multiple destinations can be reduced up to 50% for a P2MP path where 313 a single source address has many destinations. 315 The format of the new END-POINTS object body for IPv4 (Object-Type 3) 316 is as follows: 318 0 1 2 3 319 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 2 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Leaf type | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Source IPv4 address | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Destination IPv4 address | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | ... | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | ... | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | ... | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Destination IPv4 address | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 2: The New P2MP END-POINTS Object Body Format for IPv4 338 The format of the END-POINTS object body for IPv6 (Object-Type 4) is 339 as follows: 341 0 1 2 3 342 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 2 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Leaf type | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | | 347 | Source IPv6 address (16 bytes) | 348 | | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 | Destination IPv6 address (16 bytes) | 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | | 355 | ... | 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | | 359 | ... | 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 | ... | 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | | 367 | Destination IPv6 address (16 bytes) | 368 | | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 3: The New P2MP END-POINTS Object Body Format for IPv6 373 The END-POINTS object body has a variable length of multiple of 4 374 bytes for IPv4 and multiple of 16 bytes for IPv6. 376 4.3. Request Message Formats 377 Below is the message format for the request message: 379 ::= 380 381 where: 382 ::= 383 384 [] 385 [] 386 [] 387 [] 388 [] 389 [] 391 where: 393 ::= 394 [] 395 [] 397 RRO-List::=[BANDWIDTH][] 398 ::=[] 400 Figure 4: The Message Format for the Request Message 402 4.4. Reply Message Formats 403 Below is the message format for the reply message: 405 ::= 406 407 ::= 408 [] 409 [] 410 [] 412 where: 414 ::= 415 [][] 417 ::= |[] 419 ::=[] 420 [] 421 [] 422 [] 423 [] 425 Figure 5: The Message Format for the Reply Message 427 The optional END-POINTS in the reply message is used to specify which 428 paths are removed, changed, not changed, or added for the request. 429 The path is only needed for the end points which are added or 430 changed. 432 If the ERO-Compress bit was set to 1 in request then the path will be 433 formed by an ERO followed by a list of SERO. Otherwise it is a list 434 of ERO. 436 5. P2MP Objective Functions and Metric Types 438 5.1. New Object Functions 440 Six objective functions have been defined in [ID.pce-of] for P2P path 441 computation. 443 This document defines two additional objective functions, namely SPT 444 (Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to P2MP 445 path computation. Hence two new objective function codes have to be 446 defined. 448 The description of the two new objective functions is as follows. 450 Objective Function Code: 7 (suggested value, to be assigned by IANA) 452 Name: Shortest Path Tree (SPT) 454 Description: Minimize the maximum source-to-leaf cost with respect to 455 a specific metric (e.g. TE or IGP metric) 457 Objective Function Code: 8 (suggested value, to be assigned by IANA) 459 Name: Minimum Cost Tree (MCT) 461 Description: Minimize the total cost of the tree, that is the sum of 462 the costs of tree links, with respect to a specific metric. 464 Processing these two new objective functions is subject to the rules 465 defined in [ID.pce-of]. 467 5.2. New Metric Object Types 469 There are three types defined for the object in [ID.pcep], 470 namely, the IGP metric, the TE metric and the hop count metric. This 471 document defines three other types for the object: the P2MP 472 IGP metric, the P2MP TE metric, and the P2MP Hop Count metric. They 473 encode the sum of the metrics of all links of the tree. We propose 474 the following values for these new metric types (to be assigned by 475 IANA): 477 o P2MP IGP metric: T=4 479 o P2MP TE metric: T=5 481 o P2MP hop count metric: T=6 483 6. Non-Support of P2MP Path Computation. 485 o if a PCE receives a P2MP path request and it understands the P2MP 486 flag in RP object, but the PCE is not capable of P2MP computation, 487 the PCE MUST send a PCErr message with a PCEP-ERROR Object and an 488 Error-Value. The corresponding P2MP path computation request MUST 489 be cancelled. (Error-Type and Error-Value are defined in this 490 document). 492 o If the PCE does not understand the P2MP flag in the RP object, 493 then the PCE MUST send a PCErr message with a new error type 494 "Unknown RP flag". 496 7. Non-Support by Back-Level PCE Implementations. 498 If we accidentally send the P2MP request to the PCE which does not 499 support the P2MP yet, we have the following solution: 501 Using the same RP type with P2MP flag and the new END-POINTS type, 502 the receiver will reject the request when it can not understand the 503 new END-POINTS object. 505 8. P2MP TE Path Re-optimization Request 507 The reoptimization request for a P2MP TE path is specified by R bit 508 in the RP object similarly to the re-optimization request for a P2P 509 TE path. The only difference is that the user must insert the list 510 of RRO after each type of END-POINTS as described in the PCReq 511 message format section. 513 So the PCReq message would look like this: 515 ::= 516 517 where: 518 ::= 519 520 522 Figure 6: PCReq Message Example 1 for Optimization 524 In this example, the RRO list is representing the P2MP LSP before the 525 optimization and the modifiable paths are indicated in the END-POINTS 526 object. 528 Optionally it is possible to specify some leaves whose path cannot be 529 modified. The PCReq message would then look like this: 531 ::= 532 533 where: 534 ::= 535 536 537 539 Figure 7: PCReq Message Example 2 for Optimization 541 9. Adding/pruning Leaves 543 When adding new leaves or removing old leaves to the existing P2MP 544 tree, by supplying a list of existing leaves, one may be able to 545 optimize the new P2MP tree. This section explains ways to add new 546 leaves or remove old leaves to the existing P2MP tree. 548 To add new leaves the user must build a P2MP request with 549 END-POINTs of leaf type 1. 551 To remove old leaves the user must build a P2MP request with 552 END-POINTS of leaf type 2. 554 In any case it must also provides the list of old leaves and indicate 555 if they must be reoptimized or not by including END-POINTS with leaf 556 type 3 or 4 or both. In the future version, we may want to consider 557 to define error values when the condition is not satisfied (i.e., 558 when there is no END-POINTS with leaf type 3 or 4, in the presence of 559 END-POINTS with leaf type 1 or 2). 561 For old leaves the user must provide the old path as list of RROs 562 that immediately follows each END-POINTS object. In the future 563 version, we may want to consider to define error values when the 564 condition is not satisfied. 566 10. Branch Nodes 568 Before computing the P2MP path, a PCE must be provided means to know 569 which nodes in the network are capable of acting as branch LSRs. A 570 PCE can discover such capability by using the mechanisms defined in 571 [ID.node-cap]. 573 11. Synchronization of P2MP TE Path Computation Requests 575 There are cases when multiple P2MP LSPs' computation need to be 576 synchronized. For example, one P2MP LSP is the backup of another 577 P2MP LSP. In this case, the path diversity for these two LSPs needs 578 to be considered during the path computation. 580 Synchronized computation and SynchronizedVector (SVEC) association 581 for point-to-multipoint path requests are detailed in 582 [ID.pce-svec-list]. 584 Example of synchronizing two P2MP LSPs, each has two leaves for Path 585 Computation Request Messages is illustrated as below: 587 ::= 588 [OF?] 589 590 where: 591 ::= 592 ::= 593 594 595 [] 597 ::= 598 599 600 [] 602 Figure 8: PCReq Message Example for Synchronization 604 12. P2MP Capability Advertisement 606 12.1. Extend the TLV in the Existing PCE Discovery Protocol 608 Since the RFC 5088 has specified that we can not add additional sub- 609 TLV to the PCED TLV, we will define new bits to go in the existing 32 610 bits PCE Caps Flags to indicate the capability of P2MP for the PCC 611 and PCE. 613 12.2. Open Message Extension 615 Based on the Capabilities Exchange requirement described in [ID-pcep- 616 p2mp-req], if a PCE does not advertise its P2MP capability through 617 discovery and the capability is not configured to the PCC, we need to 618 use PCEP to allow a PCC to discover which PCEs with which it 619 communicates support P2MP path computation. To satisfy this 620 requirement, we extend the OPEN object format by including a new 621 defined TLV for the capability of P2MP in the optional field. The 622 new defined capability TLV allows the PCE to advertise its path 623 computation capabilities. 625 The TLV type number will be assigned by IANA, the LENGTH value is 2 626 bytes. The value field is set to default value 0. 628 Note that the capability TLV is meaningful only for a PCE so it will 629 typically appear only in one of the two Open messages during PCE 630 session establishment. However, in case of PCE cooperation (e.g., 631 inter-domain), when a PCE behaving as a PCC initiates a PCE session 632 it SHOULD also indicate its Path Computation capability. 634 13. Multi-Message Support 636 The solution follows synchronization procedures defined in [ID.pcep]. 638 If the P2MP request (i.e. ) is too large to fit into 639 a single message it is permitted to divide it into multiple requests 640 that would be carried in different messages. That means that a P2MP 641 request would then contain multiple requests with RP objects that 642 have the same request IDs. 644 Here is an example of such P2MP request that is divided in 2 request 645 messages: 647 ::= 648 649 651 where: 653 ::=< RP with Req-ID1 > 654 655 657 ::= 658 660 where: 662 ::=< RP with Req-ID1> 663 664 666 Figure 9: PCReq Message Example for Message Fragmentation 668 Note that the SVEC object contains the same request Id repeated N 669 times where N is the total number of RP objects included in all 670 messages. This is to be able to detect that the whole P2MP request 671 has been received. Note that this assumes that the transmission of 672 the messages is performed reliably and in consistent order, which is 673 not a problem since PCEP relies on TCP. 675 14. UNREACH_DESTINATION object 677 The PCE path computation request may fail because all or a subset of 678 the destinations are unreachable. 680 In such a case, the UNREACH-DESTINATION object allows the PCE to 681 optionally specify the list of unreachable destinations. 683 This object can be present in PCRep messages. There can be up to one 684 such object per RP. 686 UNREACH_DESTINATION Object-Class is to be assigned by IANA. 688 UNREACH_DESTINATION Object-Type for IPv4 is to be assigned by IANA 690 UNREACH_DESTINATION Object-Type for IPv6 is to be assigned by IANA. 692 The format of the UNREACH_DESTINATION object body for IPv4 (Object- 693 Type=1) is as follows: 695 0 1 2 3 696 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Destination IPv4 address | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 ~ ... ~ 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Destination IPv4 address | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Figure 10: UNREACH_DESTINATION Object Body for IPv4 707 The format of the UNREACH_DESTINATION object body for IPv6 (Object- 708 Type=2) is as follows: 710 0 1 2 3 711 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | | 714 | Destination IPv6 address (16 bytes) | 715 | | 716 | | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 ~ ... ~ 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | | 722 | Destination IPv6 address (16 bytes) | 723 | | 724 | | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 Figure 11: UNREACH_DESTINATION Object Body for IPv6 729 15. P2MP PCEP Error Object 731 To indicate errors associated with the P2MP path request, a new 732 Error-Type (16) and subsequent error-values are defined as follows 733 for inclusion in the PCEP-ERROR object: 735 A new Error-Type (16) and subsequent error-values are defined as 736 follows: 738 Error-Type=16 and Error-Value=1: if a PCE receives a P2MP path 739 request and the PCE is not capable to satisfy the request due to 740 insufficient memory, the PCE MUST send a PCErr message with a PCEP 741 ERROR object (Error-Type=16) and an Error-Value(Error-Value=1). The 742 corresponding P2MP path computation request MUST be cancelled. 744 Error-Type=16; Error-Value=2: if a PCE receives a P2MP path request 745 and the PCE is not capable of P2MP computation, the PCE MUST send a 746 PCErr message with a PCEP-ERROR Object (Error-Type=16) and an Error- 747 Value (Error-Value=2). The corresponding P2MP path computation 748 request MUST be cancelled. 750 To indicate an error associated with policy violation, a new error 751 value "P2MP Path computation not allowed" should be added to an 752 existing error code for policy violation (Error-Type=5) as defined in 753 [ID.pcep]. 755 Error-Type=5; Error-Value=4: if a PCE receives a P2MP path 756 computation request which is not compliant with administrative 757 privileges (i.e., the PCE policy does not support P2MP path 758 computation), the PCE sends a PCErr message with a PCEP-ERROR Object 759 (Error-Type=5) and an Error-Value (Error-Value=4). The corresponding 760 P2MP path computation request MUST be cancelled. 762 16. PCEP NO-PATH Indicator 764 To communicate the reason(s) for not being able to find P2MP path 765 computation, the NO-PATH object can be used in the PCRep message. 766 The format of the NO-PATH object body is as follows: 768 0 1 2 3 769 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 |C| Flags | Reserved | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | | 774 // Optional TLV(s) // 775 | | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 Figure 12: The Format of the NO-PATH Object Body 780 One new bit flags are defined in the NO-PATH-VECTOR TLV carried in 781 the NO-PATH Object: 783 0x20: when set, the PCE indicates that there is a reachability 784 problem with all or a subset of the P2MP destinations. Optionally 785 the PCE can specify the list of destination(s) that are not reachable 786 using the new UNREACH_DESTINATION object defined in section 3.6. 788 17. Manageability Considerations 790 [ID.pcep-p2mp-req] describes various manageability requirements in 791 support of P2MP path computation when applying PCEP. This section 792 describes how manageability requirements mentioned in 793 [ID.pcep-p2mp-req] are supported in the context of PCEP extensions 794 specified in this document. 796 Note that [ID.pcep] describes various manageability considerations in 797 PCEP, and most of manageability requirements mentioned in [PCEP-P2MP 798 P2MP] are already covered there. 800 17.1. Control of Function and Policy 802 In addition to configuration parameters listed in [ID.pcep], the 803 following parameters MAY be required. 805 o P2MP path computations enabled or disabled. 807 o Advertisement of P2MP path computation capability enabled or 808 disabled (discovery protocol, capability exchange). 810 17.2. Information and Data Models 812 As described in [ID.pcep-p2mp-req], MIB objects MUST be supported for 813 PCEP extensions specified in this document. 815 17.3. Liveness Detection and Monitoring 817 There are no additional considerations beyond those expressed in 818 [ID.pcep], since [ID.pcep-p2mp-req] does not address any additional 819 requirements. 821 17.4. Verifying Correct Operation 823 There are no additional considerations beyond those expressed in 824 [ID.pcep], since [ID.pcep-p2mp-req] does not address any additional 825 requirements. 827 17.5. Requirements on Other Protocols and Functional Components 829 As described in [ID.pcep-p2mp-req], the PCE MUST obtain information 830 about the P2MP signaling and branching capabilities of each LSR in 831 the network. 833 Protocol extensions specified in this document does not provide such 834 capability. Other mechanisms MUST be present. 836 17.6. Impact on Network Operation 838 It is expected that use of PCEP extensions specified in this document 839 does not have significant impact on network operations. 841 18. Security Considerations 843 As described in [ID.pcep], P2MP path computation requests 844 are more CPU-intensive and also use more link bandwidth. Therefore, 845 it may be more vulnerable to denial of service attacks. 847 [ID.pcep] describes various mechanisms for denial of service attacks, 848 and these tools MAY be advantageously used. 850 19. IANA Considerations 852 A number of IANA considerations have been highlighted in the relevent 853 sections of this document. Further clarifications of these requests 854 will be made in a future version of this document. 856 20. Acknowledgement 858 The authors would like to thank Adrian Farrel, Young Lee, Dan 859 Tappan,Autumn Liu and Huaimo Chen, and Eiji Oki for their valuable 860 comments on this draft. 862 21. Intellectual Property Considerations 864 The IETF takes no position regarding the validity or scope of any 865 Intellectual Property Rights or other rights that might be claimed to 866 pertain to the implementation or use of the technology described in 867 this document or the extent to which any license under such rights 868 might or might not be available; nor does it represent that it has 869 made any independent effort to identify any such rights. Information 870 on the procedures with respect to rights in RFC documents can be 871 found in BCP 78 and BCP 79. 873 Copies of IPR disclosures made to the IETF Secretariat and any 874 assurances of licenses to be made available, or the result of an 875 attempt made to obtain a general license or permission for the use of 876 such proprietary rights by implementers or users of this 877 specification can be obtained from the IETF on-line IPR repository at 878 http://www.ietf.org/ipr. 880 The IETF invites any interested party to bring to its attention any 881 copyrights, patents or patent applications, or other proprietary 882 rights that may cover technology that may be required to implement 883 this standard. Please address the information to the IETF at 884 ietf-ipr@ietf.org. 886 22. References 888 22.1. Normative References 890 [ID.pcep] 891 Ayyangar, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri, 892 Y., Kumaki, K., Vasseur, J., and J. Roux, "Path 893 Computation Element (PCE) Communication Protocol (PCEP)", 894 draft-ietf-pce-pcep-12 (work in progress), March 2008. 896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels", BCP 14, RFC 2119, March 1997. 899 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 900 "Extensions to Resource Reservation Protocol - Traffic 901 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 902 Switched Paths (LSPs)", RFC 4875, May 2007. 904 [ID.node-cap] Vasseur, J.-P., Le Roux, J.L., "IGP Routing Protocol 905 Extensions for Discovery of Traffic Engineering Node 906 Capabilities", RFC 5073, December 2007 908 [ID.pcep-p2mp-req] 909 Yasukawa, S. and A. Farrel, "PCC-PCE Communication 910 Requirements for Point to Multipoint Multiprotocol Label 911 Switching Traffic Engineering (MPLS-TE)", 912 draft-yasukawa-pce-p2mp-req-05 (work in progress), 913 May 2008. 915 [ID.pce-of] 916 Roux, J., "Encoding of Objective Functions in Path 917 Computation Element communication Protocol (PCEP)", 918 draft-ietf-pce-of-02 (work in progress), February 2008. 920 [ID.pce-svec-list] 921 Nishioka, I. and D. King, "The use of SVEC 922 (Synchronization VECtor) list for Synchronized dependent 923 path computations", draft-nishioka-pce-svec-list-02 (work 924 in progress), July 2008. 926 22.2. Informative References 928 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 929 Element (PCE)-Based Architecture", RFC 4655, August 2006. 931 23. Authors' Addresses 933 Quintin Zhao 934 Huawei Technology 935 125 Nagog Technology Park 936 Acton, MA 01719 937 US 939 Email: qzhao@huawei.com 941 Daniel King 942 Old Dog Consulting 943 UK 945 Email: daniel@olddog.co.uk 947 Fabien Verhaeghe 948 Marben Products 949 176 avenue Jean Jaures 950 92800 Puteaux, 951 France 953 Email: fabien.verhaeghe@marben-products.com 955 Tomonori Takeda 956 NTT Corporation 957 3-9-11, Midori-Cho 958 Musashino-Shi, Tokyo 180-8585 959 Japan 961 Phone: 962 Email: takeda.tomonori@lab.ntt.co.jp 964 Mohamad Chaitou 965 France Telecom 966 2, avenue Pierre-Marzin 967 22307 Lannion Cedex, 968 France 970 Email: Mohamad.Chaitou@orange-ftgroup.com 971 Jean-Louis Le Roux 972 France Telecom 973 2, avenue Pierre-Marzin 974 22307 Lannion Cedex, 975 France 977 Email: Jeanlouis.Leroux@orange-ftgroup.com 979 Zafar Ali 980 Cisco systems, Inc. 981 2000 Innovation Drive 982 Kanata, Ontario K2K 3E8 983 Canada 985 Email: zali@cisco.com 987 24. Full Copyright Statement 989 Copyright (C) The IETF Trust (2008). 991 This document is subject to the rights, licenses and restrictions 992 contained in BCP 78, and except as set forth therein, the authors 993 retain all their rights. 995 This document and the information contained herein are provided on an 996 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 997 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 998 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 999 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1000 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1001 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.