idnits 2.17.1 draft-ietf-pce-pcep-svec-list-05.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 (June 6, 2010) is 5072 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Itaru Nishioka 2 Internet Draft NEC Corp. 3 Intended Status: Informational Daniel King 4 Expires: December 6, 2010 Old Dog Consulting 5 June 6, 2010 7 The use of SVEC (Synchronization VECtor) list for Synchronized 8 dependent path computations 10 draft-ietf-pce-pcep-svec-list-05.txt 12 Abstract 14 A Path Computation Element (PCE) may be required to perform 15 dependent path computations. Dependent path computations are 16 requests that need to be synchronized in order to meet specific 17 objectives. An example of a dependent request would be a PCE 18 computing a set of services which are required to be diverse 19 (disjointed) from each other. When a PCE computes sets of dependent 20 path computation requests concurrently, it is required to use the 21 Synchronization VECtor (SVEC) list for association among the sets of 22 dependent path computation requests. The SVEC object is optional and 23 carried within the Path Computation Element Protocol (PCEP) 24 PCRequest (PCReq) message. 26 This document does not specify the PCEP SVEC object or procedure. 27 This informational document clarifies the use of the SVEC list for 28 synchronized path computations when computing dependent requests. 29 The document also describes a number of usage scenarios for SVEC 30 lists within single domain and multi-domain environments. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on December 6, 2010. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with 65 respect to this document. Code Components extracted from this 66 document must include Simplified BSD License text as described in 67 Section 4.e of the Trust Legal Provisions and are provided without 68 warranty as described in the Simplified BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) 76 controlling the copyright in such materials, this document may not 77 be modified outside the IETF Standards Process, and derivative works 78 of it may not be created outside the IETF Standards Process, except 79 to format it for publication as an RFC or to translate it into 80 languages other than English. 82 Table of Contents 84 1. Introduction ..................................................3 85 1.1. SVEC Object ...............................................4 86 1.2. Application of SVEC Lists .................................4 87 2. Terminology ...................................................6 88 3. SVEC association scenarios ....................................6 89 3.1. Synchronized computation for diverse path requests ........6 90 3.2. Synchronized computation for point-to-multipoint path 91 requests ..................................................8 92 4. SVEC association ..............................................8 93 4.1. SVEC list .................................................8 94 4.2. Associated SVECs ..........................................8 95 4.3. Non-associated SVECs ......................................9 96 5. Processing of SVEC list .......................................10 97 5.1. Single PCE, single domain environments ....................10 98 5.2. Multi-PCE, single domain environments .....................11 99 5.3. Multi-PCE, multi-domain environments ......................11 100 6. End-to-end diverse path computation ...........................12 101 6.1. Disjoint VSPT .............................................12 102 6.2. Disjoint VSPT encoding ....................................13 103 6.3. Path computation procedure ................................14 104 7. Manageability considerations ..................................14 105 7.1. Control of Function and Policy ............................14 106 7.2. Information and Data Models, e.g. MIB modules .............15 107 7.3. Liveness Detection and Monitoring .........................15 108 7.4. Verifying Correct Operation ...............................15 109 7.5. Requirements on Other Protocols and Functional Components..15 110 7.6. Impact on Network Operation ...............................15 111 8. Security Considerations .......................................15 112 9. IANA Considerations ...........................................16 113 10. References ...................................................16 114 10.1. Normative References .....................................16 115 10.2. Informative References ...................................17 116 11. Acknowledgements .............................................17 117 12. Authors' Addresses ...........................................17 119 1. Introduction 121 [RFC5440] describes the specifications for PCEP (Path Computation 122 Element communication Protocol). PCEP specifies the communication 123 between a Path Computation Client (PCC) and a Path Computation 124 Element (PCE), or between two PCEs based on the PCE architecture 125 [RFC4655]. PCEP interactions include path computation requests and 126 path computation replies. 128 The PCE may be required to compute independent and dependent path 129 requests. Path computation requests are said to be independent if 130 they are not related to each other, and therefore not required to be 131 synchronized. Equally a set of dependent path computation requests, 132 that are required to be synchronized, cannot be performed 133 independently of each other. The Synchronization VECtor (SVEC) with 134 a list of the path computation request identifiers carried within 135 the request message allows the PCC or PCE to specify a list of 136 multiple path computation requests that must be synchronized. 137 Section 1.1 (SVEC Object) describes the SVEC object. Section 1.2 138 (Application of SVEC Lists) describes the application of SVEC lists 139 in certain scenarios. 141 This informational document clarifies the handling of dependent and 142 synchronized path computation requests, using the SVEC list, based 143 on the PCE architecture [RFC4655] and PCEP [RFC5440]. The document 144 also describes a number of usage scenarios for SVEC lists within 145 single domain and multi-domain environments. This document is not 146 intended to specify the procedure when using SVEC lists for 147 dependent and synchronized path computation requests. 149 1.1. SVEC Object 151 When a PCC or PCE sends path computation requests to a PCE, a PCEP 152 Path Computation Request (PCReq) message may carry multiple requests 153 each of which has a unique path computation request identifier. The 154 SVEC with a list of the path computation request identifiers carried 155 within the request message allows the PCC or PCE to specify a list 156 of multiple path computation requests that must be synchronized, and 157 also allows the specification of any dependency relationships 158 between the paths. The path computation requests listed in the SVEC 159 must be handled in a relation to each other (i.e. synchronized). 161 [RFC5440] defines two synchronous path computation modes for 162 dependent or independent path computation requests specified by the 163 dependency flags (i.e. Node, Link or SRLG diverse flags) in the SVEC. 164 (See [RFC5440] for more details of dependent, independent and 165 synchronous path computation.) 167 o A set of independent and synchronized path computation requests, 169 o A set of dependent and synchronized path computation requests. 171 These computation modes are exclusive each other in a single SVEC. 172 If one of the dependency flags in a SVEC is set, it indicates a set 173 of synchronous path computation requests has a dependency and does 174 not allow any other path computation requests. In order to be 175 synchronized with other path computation requests with a dependency, 176 it is necessary to associate them. 178 The aim of the SVEC object carried within a PCReq message is to 179 request the synchronization of M path computation requests. Each 180 path computation request is uniquely identified by the Request-ID- 181 number carried within the respective RP object. The SVEC object 182 also contains a set of flags that specify the synchronization type. 183 The SVEC Object is defined in Section 7.13 (SVEC Object) of 184 [RFC5440]. 186 1.2. Application of SVEC Lists 188 It is important for the PCE, when performing path computations, to 189 synchronize any path computation requests with a dependency. For 190 example, consider two protected end-to-end services: 192 o It would be beneficial for each back-up path to be disjointed so 193 they do not share the same links and nodes as the working path. 195 o Two diverse path computation requests would be needed to compute 196 the working and disjointed protected paths. 198 If the diverse path requests are computed sequentially, fulfillment 199 of the initial diverse path computation without consideration of the 200 second diverse path computation and disjoint constraint may result in 201 the PCE providing sub-optimal path disjoint results for the protected 202 path, or may fail to meet the end-to-end disjoint requirement 203 altogether. 205 Additionally, SVEC can be applied to end-to-end diverse path 206 computations that traverse multiple domains. [RFC5441] describes two 207 approaches, synchronous (i.e. simultaneous) and 2-step approaches, 208 for the end-to-end diverse path computation across a chain of 209 domains. The path computation procedure is specified for the 2-step 210 approaches in [RFC5521], but no guidelines are provided for a 211 synchronous approach which is described in this document. 213 The following scenarios are specifically described within this 214 document: 216 o Single domain, single PCE, dependent and synchronized path 217 computation request. 219 o Single domain, multi-PCE, dependent and synchronized path 220 request. 222 o Multi-domain, dependent and synchronized path computation request, 223 including end-to-end diverse path computation. 225 The association among multiple SVECs for multiple sets of 226 synchronized dependent path computation is also described in this 227 document, as well as disjoint Virtual Shortest Path Tree (VSPT) 228 encoding rule for end-to-end diverse path computation across domains. 229 Path computation algorithms for these path computation scenarios are 230 out of the scope of this document. 232 The clarifications and use cases in this document are applicable to 233 the Global Concurrent Optimization (GCO) path computation mechanism 234 specified in [RFC5557]. The GCO application provides the capability 235 to optimize a set of services within the network, in order to 236 maximize efficient use of network resources. A single or set of 237 objective functions (OFs) can be applied to a GCO. To compute a set 238 of such traffic-engineered paths for the GCO application, PCEP 239 supports the synchronous and dependent path computation requests 240 required in [RFC4657]. 242 The SVEC association and the disjoint VSPT described in this 243 document do not require any extension to PCEP messages and object 244 formats, when computing a GCO for multiple or end-to-end diverse 245 paths. In addition, the use of multiple SVECs is not restricted to 246 only SRLG, Node and Link diversity currently defined in the SVEC 247 object [RFC5440], but is also available for other dependent path 248 computation requests. 250 The SVEC association and disjoint VSPT are available to both single 251 PCE path computation and multi-PCE path computation. 253 2. Terminology 255 This document uses PCE terminology defined in [RFC4655], [RFC4875], 256 and [RFC5440]. 258 Associated SVECs: A group of multiple SVECs (Synchronization 259 VECtors), defined in this document, to indicate a set of 260 synchronized or concurrent path computations. 262 Disjoint VSPT: A set of VSPTs, defined in this document, to indicate 263 a set of virtual diverse path tree. 265 GCO (Global Concurrent Optimization): A concurrent path computation 266 application, defined in [RFC5557], where a set of TE paths is 267 computed concurrently in order to efficiently utilize network 268 resources. 270 Synchronized: A set of path computation requests is said to be 271 synchronized if the PCE associates the requests, and does not 272 compute each request independently of each other. 274 VSPT: Virtual Shortest Path Tree defined in [RFC5441]. 276 3. SVEC association scenarios 278 This section clarifies several path computation scenarios, in which 279 SVEC association can be applied. Also, any combination of scenarios 280 described in this section could be applicable. 282 3.1. Synchronized computation for diverse path requests 284 A PCE may compute two or more point-to-point diverse paths, 285 concurrently, in order to increase the probability of meeting 286 primary and secondary path diversity (or disjointness) objective and 287 network resource optimization objective. 289 Two scenarios can be considered for the SVEC association of point- 290 to-point diverse paths. 292 o Two or more end-to-end diverse paths 294 When concurrent path computation of two or more end-to-end diverse 295 paths is requested, SVEC association is needed among diverse path 296 requests. Note here that each diverse path request consists of 297 primary, secondary, and tertiary and beyond path requests, in which 298 all path requests are grouped with one SVEC association. 300 Consider two end-to-end services that are to be kept separate by 301 using diverse paths. The path computation requests would need to be 302 associated so that diversity could be assured. Consider further that 303 each of these services requires a backup path that can protect 304 against any failure in the primary path. These backup paths must be 305 computed using requests that are associated with the primary paths 306 giving rise to a set of four associated requests. 308 o End-to-end primary path and its segmented secondary paths 310 When concurrent path computation for segment recovery paths, as 311 shown in figure 1, is requested, SVEC association is needed between 312 a primary path and several segmented secondary paths. 314 <------------ primary -----------> 316 A------B------C---D------E------F 318 \ / \ / 320 P---Q---R X---Y---Z 322 <--secondary1--> <--secondary2--> 324 Figure 1: Segment Recovery Paths 326 In this scenario, we assume that the primary path may be pre- 327 computed, which is used for specifying the segment for secondary 328 paths. Otherwise, the segment for secondary path requests are 329 specified in advance, by using Exclude Route Object (XRO) and/or 330 Include Route Object (IRO) constraints in the primary request. 332 3.2. Synchronized computation for point-to-multipoint path requests 334 For point-to-multipoint path requests, SVEC association can be 335 applied. 337 o Two or more point-to-multipoint paths 339 If a point-to-multipoint paths request is represented as a set of 340 point-to-point paths [ID.pce-p2mp-ext], two or more point-to- 341 multipoint path computation requests can be associated for 342 concurrent path computation, in order to optimize network resources. 344 o Point-to-multipoint paths and their secondary paths 346 When concurrent path computation of a point-to-multipoint path and 347 its point-to-point secondary paths [RFC4875], or a point-to- 348 multipoint path and its point-to-multipoint secondary paths is 349 requested, SVEC association is needed among these requests. In this 350 scenario, we use the same assumption as "end-to-end primary path and 351 its segmented secondary paths scenario" in section 3.1. 353 4. SVEC association 355 This section describes the associations among SVECs in a SVEC list. 357 4.1. SVEC list 359 PCEP provides the capability to carry one or more SVEC objects in a 360 PCReq message, and this set of SVEC objects within the PCReq message 361 is termed a SVEC list. Each SVEC object in the SVEC list contains a 362 distinct group of path computation requests. When requesting 363 association among such distinct groups, associated SVECs described 364 in this document are used. 366 4.2. Associated SVECs 368 "Associated SVECs" defines that there are relationships among 369 multiple SVECs in SVEC list. Note that there is no automatic 370 association in [RFC5440] between the members of one SVEC and the 371 members of another SVEC in the same SVEC list. The associated SVEC 372 is introduced to associate these SVECs, especially for correlating 373 among SVECs with dependency flags. 375 Request identifiers in the SVEC objects are used to indicate the 376 association among SVEC objects. If the same request-IDs exist in 377 SVEC objects, this indicates these SVEC objects are associated. When 378 associating among SVEC objects, at least one request identifier must 379 be shared between associated SVECs. The SVEC objects can be 380 associated regardless of the dependency flags in each SVEC object, 381 but it is recommended to use a single SVEC if the dependency flags 382 are not set in all SVEC objects. Similarly, when associating among 383 SVEC objects with dependency flags, it is recommended to construct 384 them using a minimum set of associated SVECs, thus avoiding complex 385 relational associations. 387 Below is an example of associated SVECs. In this example, the first 388 SVEC is associated with the other SVECs, and all of path computation 389 requests contained in the associated SVECs (i.e. Request-ID#1,#2,#3, 390 #4,#X,#Y,#Z) must be synchronized. 392 394 without dependency flags 396 Request-ID #1, Request-ID #3, Request-ID #X 398 with one or more dependency flags 400 Request-ID #1, Request-ID #2 402 with one or more dependency flags 404 Request-ID #3, Request-ID #4 406 without dependency flag 408 Request-ID #X, Request-ID #Y, Request-ID #Z 410 4.3. Non-associated SVECs 412 Non-associated SVECs mean that there are no relationships among 413 SVECs. If none of the SVEC objects in the SVEC list on a PCReq 414 message contains a common request-ID, there is no association 415 between the SVECs and so no association between the requests in one 416 SVEC and the requests in another SVEC. 418 Below is an example of non-associated SVECs that does not contain 419 any common request-IDs. 421 423 with one or more dependency flags 425 Request-ID #1, Request-ID #2 427 with one or more dependency flags 429 Request-ID #3, Request-ID #4 431 without dependency flags 433 Request-ID #X, Request-ID #Y, Request-ID #Z 435 5. Processing of SVEC list 437 5.1. Single PCE, single domain environments 439 In this environment, there is a single PCE within the domain. 441 When a PCE receives PCReq messages with more than one SVEC objects 442 in the SVEC list, PCEP has to first check the request-IDs in all 443 SVEC objects in order to identify any associations among them. 445 If there are no matching request-IDs in the different SVEC objects, 446 these SVEC objects are not associated, and then each set of path 447 computation requests in the non-associated SVEC objects has to be 448 computed separately. 450 If there are matching request-IDs in the different SVEC objects, 451 these SVEC objects are associated, and then all path computation 452 requests in the associated SVEC objects are treated in a synchronous 453 manner for GCO application. 455 If the PCE does not have capability to handle the associated SVEC 456 objects, it may send a PCErr message with Error-Type="Capability not 457 supported". 459 In the case that M path computation requests are sent across 460 multiple PCReq messages, the PCE may start a SyncTimer as 461 recommended in Section 7.13.3 (Handling of the SVEC Object) 462 [RFC5440]. In this case, the associated SVECs should also be handled 463 as described in [RFC5440]. I.E. after receiving the entire set of M 464 path computation requests associated by SVECs, the computation 465 should start at one. If the SyncTimer has expired or the following 466 PCReq messages have been malformed; the PCE should cancel the path 467 computation request and respond to the PCC with the relevant PCErr 468 message. 470 5.2. Multi-PCE, single domain environments 472 There are multiple PCEs in a domain, to which PCCs can communicate 473 directly, and PCCs can choose an appropriate PCE for load balanced 474 path computation requests. In this environment it is possible 475 dependent path computation requests are sent to different PCEs. 477 If a PCC sends path computation requests to a PCE and then sends 478 another path computation requests, which are dependent on the first 479 requests and has been associated by using a SVEC list. There is no 480 method for the PCE to correlate the dependent requests sent to 481 different PCEs. No SVEC object correlation function between the PCEs 482 is specified in [RFC5440]. As indentified, no mechanism exists to 483 resolve this problem and the issue is open for future study. 484 Therefore, a PCC must not send dependent path computation requests 485 associated by SVECs to different PCEs. 487 5.3. Multi-PCE, multi-domain environments 489 In this environment, there are multiple domains in which PCEs are 490 located in each domain, and end-to-end dependent paths (i.e. diverse 491 path) is computed using multiple PCEs. Note that we assume a chain 492 of PCEs are pre-determined and the BRPC procedure [RFC5441] is in 493 use. 495 The SVECs can be applied to end-to-end diverse path computations 496 that traverse multiple domains. [RFC5441] describes two approaches, 497 synchronous (i.e. simultaneous) and 2-step approaches, for the end- 498 to-end diverse path computation across a chain of domains. In the 2- 499 step approaches described in [RFC5521], it is not necessary to use 500 the associated SVECs because any of dependency flags in a SVEC 501 object are not set. On one hand, the simultaneous approach may 502 require the associated SVEC because at least one of dependency flags 503 is required in a SVEC object. Thus, a use case of the simultaneous 504 approach is described in this environment. 506 When a chain of PCEs located in separate domains are used for 507 simultaneous path computations, additional path computation 508 processing is required. It is described in this document (Section 6). 510 If the PCReq message contains multiple associated SVEC objects and 511 these SVEC objects contain path computation requests that will be 512 sent to the next PCE along the path computation chain, the following 513 procedures are applied. 515 When a chain of PCEs is a unique sequence for all of path 516 computation requests in a PCReq message, it is not necessary to re- 517 construct associations among SVEC objects. Thus, the PCReq message 518 is passed to the tail end PCE. When a PCReq message contains more 519 than one SVEC objects with the dependency flag set, the contained 520 SVECs may then be associated. PCEs receiving the associated SVECs 521 must maintain their association, and consider their relationship in 522 path computing after receiving a corresponding PCRep message. 524 When a chain of PCEs is different, it is required that intermediate 525 PCEs receiving such PCReq messages may re-construct associations 526 among SVEC objects, and then send PCReq messages to corresponding 527 PCEs located in neighboring domains. If the associated SVECs are re- 528 constructed at the intermediate PCE, the PCE must not start its path 529 computation until all PCRep messages have been received from all 530 neighbor PCEs. However, a complex PCE implementation is required for 531 SVEC reconstruction, and waiting mechanisms must be implemented. 532 Therefore, it is not recommended to associate path computation 533 requests with different PCE chains. This is open issue and is 534 currently being discussed in [ID.h-pce] which proposes a 535 hierarchical PCE architecture. 537 6. End-to-end diverse path computation 539 In this section, the synchronous approach is provided to compute 540 primary and secondary paths simultaneously. 542 6.1. Disjoint VSPT 544 The BRPC procedure constructs a VSPT to inform the enquiring PCE of 545 potential paths to the destination node. 547 In the end-to-end diverse path computation, diversity (or 548 disjointness) information among the potential paths must be 549 preserved in the VSPT to ensure end-to-end disjoint path. In order 550 to preserve diversity (or disjointness) information, disjoint VSPTs 551 are sent in the PCEP PCRep message. The PCReq containing a SVEC 552 object with the appropriate diverse flag set would signal that the 553 PCE should compute a disjoint VSPT. 555 A definition of the disjoint VSPT is a collection of VSPTs, in which 556 each VSPT contains a potential set of primary and secondary paths. 558 Figure 2 shows an example network. Here, transit nodes in domains 559 are not depicted, and PCE1 and PCE2 may be located in border nodes. 560 In this network, there are three VSPTs for the potential set of 561 diverse paths shown in Figure 3, when the primary path and secondary 562 path are requested from S1 to D1. These VSPTs consist of a disjoint 563 VSPT, which is replied to PCE1. When receiving the disjoint VSPT, 564 PCE1 recognizes the disjoint request and disjoint VSPT information. 565 PCE1 will then continue to process the request and compute the 566 diverse path using the BRPC procedure [RFC5441]. The detail encoding 567 for the disjoint VSPT is described in Section 6.2. 569 Domain1 Domain2 571 +----------+ +----------+ 573 | PCE1 | | PCE2 | S1: Source node 575 | BN1---BN4 | D1: Destination node 577 | S1 BN2---BN5 D1 | BN1-BN6: Border nodes 579 | BN3---BN6 | 581 +----------+ +----------+ 583 Figure 2: Example network for diverse path computation 585 VSPT1: VSPT2: VSPT3: 587 D1 D1 D1 589 / \ / \ / \ 591 BN4 BN5 BN4 BN6 BN5 BN6 593 Figure 2: Disjoint VSPT from PCE2 to PCE1 595 6.2. Disjoint VSPT encoding 597 Encoding for disjoint VSPT follows the definition of PCEP message 598 encoding in [RFC5440]. 600 PCEP PCRep message returns a disjoint VSPT as for each 601 RP object (Request Parameter object). The order of in among implies a set of primary EROs (Explicit 603 Route Objects) and secondary EROs. 605 A PCE sending PCRep with a disjoint VSPT can reply with a partial 606 disjoint VSPT based on its network operation policy, but the order 607 of in must be aligned correctly. 609 If confidentiality is required between domains, path key mechanism 610 defined in [RFC5520] is used for a disjoint VSPT. 612 Detailed disjoint VSPT encoding in Figure 2 is shown below, when a 613 primary path and a secondary path are requested from S1 to D1. 615 o Request ID #1 (Primary) 617 - ERO1 BN4(TE route ID)- ...-D1(TE-Router ID) [for VSPT1] 619 - ERO2 BN4(TE route ID)- ...-D1(TE-Router ID) [for VSPT2] 621 - ERO3 BN5(TE route ID)- ...-D1(TE-Router ID) [for VSPT3] 623 O Request ID #2 (Secondary) 625 - ERO4 BN5(TE route ID)- ...-D1(TE-Router ID) [for VSPT1] 627 - ERO5 BN6(TE route ID)- ...-D1(TE-Router ID) [for VSPT2] 629 - ERO6 BN6(TE route ID)- ...-D1(TE-Router ID) [for VSPT3] 631 6.3. Path computation procedure 633 For end-to-end diverse path computation, the same mode of operation 634 as BRPC procedure can be applied (i.e. Step 1 to Step n in Section 635 4.2 [RFC5441]). During this procedure, a question is how to 636 recognize disjoint VSPTs. 638 The recognition of disjoint VSPT is achieved by the PCE sending 639 PCReq to its neighbor PCE which maintains the path computation 640 request (PCReq) information. If PCReq has one or more SVEC object(s) 641 with the appropriate dependency flags, the received PCRep will 642 contain the disjoint VSPT. If not, the received VSPT is a normal 643 VSPT based on the shortest path computation. 645 Note that the PCE will apply a suitable algorithm for computing 646 requests with disjoint VSPT. The selection and application of the 647 appropriate algorithm is out of scope in this draft. 649 7. Manageability considerations 651 This section describes manageability considerations specified in 652 [ID.pce-mngabl-reqs]. 654 7.1. Control of Function and Policy 655 In addition to [RFC5440], PCEP implementations should allow the PCC 656 to be responsible for mapping the requested paths to computation 657 requests. The PCC should construct the SVECs to indentify and 658 associate SVEC relationships. 660 7.2. Information and Data Models, e.g. MIB modules 662 There are currently no additional parameters for MIB modules. There 663 is value in a MIB module that details the SVEC association. This 664 work is currently out of scope of this document. 666 7.3. Liveness Detection and Monitoring 668 The associated SVEC in this document allows PCEs to compute optimal 669 sets of diverse paths. This type of path computation may require 670 more time to obtain its results. Therefore, it is recommended for 671 PCEP to support PCE monitoring mechanism specified in [ID.pce- 672 monitor]. 674 7.4. Verifying Correct Operation 676 [RFC5440] provides the sufficient descriptions for this document. So, 677 there are no additional considerations. 679 7.5. Requirements on Other Protocols and Functional Components 681 This document does not require any other protocol and functional 682 components. 684 7.6. Impact on Network Operation 686 [RFC5440] provides descriptions for the mechanisms discussed in this 687 document. There is value in considering that large associated SVECs 688 will require greater PCE resources, compared to non-associated SVECs. 689 Additionally, the sending of large associated SVECs within multiple 690 PCReq messages will require more network resources. Solving these 691 specific issues is out of scope of this document. 693 8. Security Considerations 695 This document describes the usage of SVEC list, and does not have 696 any extensions for PCEP protocol. The security of the procedures 697 described in this document depends on PCEP protocol [RFC5440]. 698 However, a PCE that supports associated SVECs may be open to DoS 699 attack from a rogue PCC. A PCE may be made to queue large numbers of 700 requests waiting for other requests that will never arrive. 701 Additionally a PCE might be made to compute exceedingly complex 702 associated SVEC computations. These DoS attacks may be mitigated 703 with the use of practical SVEC list limits, as well as: 705 o Using the same number of simultaneous service provisioning 706 would be recommended. 708 o Priority-based multi-queuing mechanism in which path 709 computation requests with a smaller SVEC list are prioritized 710 for path computation processing 712 o Specifying which PCCs may request large SVEC associations 713 through PCE access policy control. 715 9. IANA Considerations 717 This document has no specific extension for PCEP messages, objects 718 and its parameters and does not require any registry assignment. 720 10. References 722 10.1. Normative References 724 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 725 Element (PCE)-Based Architecture," RFC 4655, September 726 2006. 728 [RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE) 729 Communication Protocol Generic Requirements," RFC 4757, 730 September 2006. 732 [RFC4875] R. Aggarwal, D. Papadimitriou, and S. Yasukawa, 733 "Extensions to Resource Reservation Protocol - Traffic 734 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 735 Switched Paths (LSPs)," RFC4875, May 2007. 737 [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow A. 738 Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Path 739 Computation Element (PCE) communication Protocol (PCEP)," 740 RFC5440, March. 2009. 742 [RFC5441] JP. Vasseur, R. Zhang, N. Bitar and JL. Le Roux, "A 743 Backward Recursive PCE-based Computation (BRPC) Procedure 744 to Compute Shortest Constrained Inter-domain Traffic 745 Engineering Label Switched Paths," RFC5441, April 2009. 747 [RFC5520] R. Bradford, JP. Vasseur, and A. Farrel, "Preserving 748 Topology Confidentiality in Inter-Domain Path Computations 749 Using a Path-Key-Based mechanism," RFC5520, April 2009. 751 [RFC5521] E. Oki, T. Takeda and A. Farrel, "Extensions to the Path 752 Computation Element Communication Protocol (PCEP) for 753 Route Exclusions," RFC5521, April 2009. 755 [RFC5557] Y. Lee, JL. Le Roux, D. King and E. Oki, "Path Computation 756 Element Communication Protocol (PCECP) Requirements and 757 Protocol Extensions In Support of Global Concurrent 758 Optimization," RFC5557, July 2009. 760 10.2. Informative References 762 [ID.pce-p2mp-ext] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z.,Zhao, 763 Q., King, D., "Extensions to the Path Computation Element 764 Communication Protocol (PCEP) for Point-to-Multipoint 765 Traffic Engineering Label Switched Paths," draft-ietf-pce- 766 pcep-p2mp-extensions, work in progress, February, 2010. 768 [ID.pce-mngabl-reqs] A. Farrel, "Inclusion of Manageability Sections 769 in PCE Working Group Drafts," draft-ietf-pce- 770 manageability-requirements, work in progress, July 2009. 772 [ID.h-pce] King, D., Farrel, A. "The Application of the Path 773 Computation Element Architecture to the Determination of a 774 Sequence of Domains in MPLS & GMPLS", draft-king-pce- 775 hierarchy-fwk, work in progress, December 2009. 777 11. Acknowledgements 779 The authors would like to thank Adrian Farrel, Julien Meuric and 780 Filippo Cugini for their valuable comments. 782 12. Authors' Addresses 784 Itaru Nishioka 785 NEC Corp. 786 1753 Shimonumabe, 787 Kawasaki, 211-8666, 788 Japan 790 Phone: +81 44 396 3287 791 Email: i-nishioka@cb.jp.nec.com 793 Daniel King 794 Old Dog Consulting 795 United Kingdom 797 Phone: +44 7790 775187 798 Email: daniel@olddog.co.uk