idnits 2.17.1 draft-nishioka-pce-svec-list-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 548. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 537. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 4, 2008) is 5774 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 ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 440, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Nishioka 3 Internet Draft NEC 4 Intended Status: Informational Daniel King 5 Expires: January 2009 Old Dog Consulting 6 July 4, 2008 8 The use of SVEC (Synchronization VECtor) list for Synchronized 9 dependent path computations 10 draft-nishioka-pce-svec-list-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on January 4, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 A Path Computation Element (PCE) performing dependent path 45 computations, for instance calculating a diverse working and 46 protected path do not share common network points, would need to 47 synchronize the computations in order to increase the probability 48 of meeting the working and protected path disjoint objective and 49 network resource optimization objective. When a PCE computes 50 multiple sets of dependent path computation requests concurrently, 51 it is required to use Synchronization VECtor (SVEC) list for 52 association among the sets of dependent path computation requests. 53 This document describes the usage of multiple SVECs in the SVEC 54 list and its processing guideline, for the synchronized computation 55 of dependent paths. 57 Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 61 this document are to be interpreted as described in RFC-2119. 63 Table of Contents 65 1. Terminology...............................................3 66 2. Introduction..............................................3 67 3. SVEC Association scenarios................................5 68 3.1. Synchronized computation for diverse path requests...5 69 3.2. Synchronized computation for point-to-multipoint path 70 requests..................................................6 71 4. Association among SVEC....................................6 72 4.1. Association among SVEC...............................6 73 4.2. Non-associated SVECs.................................7 74 5. Processing of SVEC list...................................8 75 5.1. Single PCE, single domain environments...............8 76 5.2. Multi-PCE, single domain environments................8 77 5.3. Multi-PCE, multi-domain environments.................9 78 6. Manageability considerations..............................9 79 6.1. Control of Function and Policy.......................9 80 6.2. Information and Data Models, e.g. MIB modules........9 81 6.3. Liveness Detection and Monitoring....................9 82 6.4. Verifying Correct Operation.........................10 83 6.5. Requirements on Other Protocols and Functional Components 84 .........................................................10 85 6.6. Impact on Network Operation.........................10 86 7. Security Considerations..................................10 87 8. IANA Considerations......................................10 88 9. References...............................................10 89 9.1. Normative References................................10 90 9.2. Informative References..............................11 91 Author's Addresses..........................................12 92 Intellectual Property Statement.............................12 93 Disclaimer of Validity......................................13 95 1. Terminology 97 Terminology used in this document: 99 PCC (Path Computation Client): Any client application requesting a 100 path computation to be performed by a Path Computation 101 Element. 103 PCE (Path Computation Element): An entity (component, application, 104 or network node) that is capable of computing a network path 105 or route based on a network graph, and applying computational 106 constraints. 108 PCEP (PCE Communication Protocol) : The PCE communication Protocol. 110 PCEP Peer : A neighbor element involved in a PCEP session (i.e. a 111 PCC or a PCE). 113 GCO (Global Concurrent Optimization): A concurrent path 114 computation application where a set of TE paths is computed 115 concurrently in order to efficiently utilize network 116 resources. 118 Associated SVECs : A group of multiple SVECs (Synchronization 119 VECtors) to indicate a set of synchronized or concurrent path 120 computations. 122 2. Introduction 124 [ID.pce-pcep] describes the specifications for PCEP (Path 125 Computation Element communication Protocol). PCEP facilitates the 126 communication between a Path Computation Client(PCC) and a Path 127 Computation Element (PCE), or between two PCEs based on PCE 128 architecture [RFC4655]. PCEP interactions include path computation 129 requests and path computation replies. 131 [ID.pce-gco] specifies a global concurrent path computation 132 application for the efficient use of network resources, called GCO, 133 based on required objective functions (OFs). To compute a set of 134 traffic-engineered paths for the GCO application, PCEP supports 135 the synchronous and dependent path computation requests required 136 in [RFC4657]. When a PCC or PCE sends such path computation 137 requests to a PCE, Synchronization VECtor (SVEC) allows the PCC or 138 PCE to specify a list of multiple path computation requests that 139 must be synchronized along with a potential dependency.[ID.pce- 140 pcep] defines two synchronous path computation modes using SVEC. 142 o Bundle of a set of independent and synchronized path 143 computation requests, 145 o Bundle of a set of dependent and synchronized path computation 146 requests. 148 These are exclusive modes. If one of the dependency flags (i.e. 149 Node, Link or Shared Risk Link Groups (SRLG) diverse flags) in a 150 SVEC is set, the SVEC indicates a set of synchronous path 151 computation requests with a dependency. In order to be 152 synchronized among multiple sets of path computation requests 153 with a dependency, it is necessary to use other SVECs. 155 It is important for the PCE, when performing path computations, 156 to synchronize any path computation requests with a dependency. 157 For example, consider a protected end-to-end service. Two diverse 158 path computation requests are needed to compute the disjointed 159 working and protected paths. If the diverse path requests are 160 computed sequentially, fulfillment of the initial diverse path 161 computation without consideration of the second diverse path 162 computation and disjoint constraint, may result in the PCE 163 providing sub-optimal results for the second one, or fail to meet 164 the disjoint requirement altogether. 166 This document defines the handling of synchronous path 167 computation for PCE and multiple set of path computation request 168 with a dependency. The following scenarios are specifically 169 described: 171 o Single domain, single PCE, dependent and synchronized path 172 computation request. 174 o Multi-domain, multiple-PCE, dependent and synchronized path 175 computation request. 177 The association among multiple SVECs and the processing rules to 178 support multiple sets of synchronized dependent path computation 179 requests is also described in this document. Path computation 180 algorithms for the associated path computation requests are out 181 of scope in this document. 183 The SVEC association and its processing rule do not require any 184 extension to PCEP message and object formats, when computing a 185 GCO for multiple diverse paths. In addition, the use of multiple 186 SVECs is not restricted to only SRLG, Node and Link diversity 187 currently defined in the SVEC object, [ID.pce-pcep], but is also 188 available for other dependent path computation requests. 190 The SVEC association is available to both multiple PCE path 191 computations as well as a single PCE path computation. 193 3. SVEC association scenarios 195 This section clarifies several path computation scenarios, in 196 which SVEC association can be applied. Also, any combination of 197 scenarios described in this section could be applicable. 199 3.1. Synchronized computation for diverse path requests 201 When computing two or more point-to-point diverse paths, a PCE may 202 compute these diverse paths concurrently, in order to increase the 203 probability of meeting primary and secondary path disjoint 204 objective and network resource optimization objective. 206 Two scenarios can be considered for the SVEC association of point- 207 to-point diverse paths. 209 o Two or more end-to-end diverse paths 211 When concurrent path computation of two or more end-to-end 212 diverse paths is requested, SVEC association is needed among 213 diverse path requests. Note here that each diverse path request 214 consists of primary, secondary, and etc., in which are grouped 215 with one SVEC. 217 Example of this scenario: When there are two associated end-to- 218 end diverse path requests with primary and secondary, all 219 requests must be computed in a synchronized manner. 221 o End-to-end primary path and its segmented secondary paths 223 When concurrent path computation of an end-to-end primary path 224 and several segmented secondary paths is requested, SVEC 225 association is needed among primary/segmented secondary-1 226 request, primary/segmented secondary-2 request, and etc. 228 In this scenario, we assume that the primary path may be pre- 229 computed, which is used for specifying the segment for secondary 230 paths. Otherwise, segment for secondary path requests are 231 specified in advance, by using XRO and/or IOR constraints in the 232 primary request. 234 3.2. Synchronized computation for point-to-multipoint path requests 236 For point-to-multipoint path requests, SVEC association can be 237 applied. 239 o Two or more point-to-multipoint paths 241 If a point-to-multipoint paths request is represented as a set 242 of point-to-point paths [ID.pce-p2mp-ext], two or more point-to- 243 multipoint path computation requests can be associated for 244 concurrent path computation, in order to optimize network 245 resources. 247 [Editor`s note] This scenario will be modified after PCEP 248 protocol for point-to-multipoint request is specified. 250 o point-to-multipoint paths and its secondary paths 252 When concurrent path computation of a point-to-multipoint path 253 and its point-to-point secondary paths [RFC4875], or a point-to- 254 multipoint path and its point-to-multipoint secondary paths 255 [ID.p2mp-te-bypass] is requested, SVEC association is needed 256 among these requests. 258 In this scenario, we use the same assumption as "end-to-end 259 primary path and its segmented secondary paths scenario" in 260 section 3.1 262 4. Association among SVEC 264 This section describes the associations among SVECs in a SVEC list. 266 4.1. Association among SVEC 268 Associated SVECs mean that there are relationships among multiple 269 SVECs. Request-IDs in the SVEC objects are used to indicate the 270 association among SVEC objects. If the same request-IDs exist in 271 more than two SVECs, this indicates associated SVECs. When 272 associating among SVECs, only one request-ID may in the SVEC 273 object may be contained in the other SVEC object. This contributes 274 to reducing the message size of PCEP request. Even in this case, 275 all of the path computation requests are synchronized. 277 Below is an example of associated SVECs. In this example the first 278 SVEC and the other SVECs are associated, and path computation 279 requests from Request-ID#1 to Request-ID#Z must be synchronized. 281 283 without dependency flags 285 Request-ID #1, Request-ID #3, Request-ID #4..., Request-ID 286 #X 288 with one or more dependency flags 290 Request-ID #1, Request-ID #2 292 with one or more dependency flags 294 Request-ID #4, Request-ID #5 296 ........ 298 without dependency flag 300 Request-ID #X, Request-ID #Y, Request-ID #Z 302 Note that path computation requests that do not have other SVECs, 303 like Request-ID #3, may be contained in the associated SVEC. This 304 request is also synchronized. 306 4.2. Non-associated SVECs 308 Non-associated SVECs mean that there are no relationships among 309 SVECs. If SVEC objects in PECP request messages do not have the 310 same request-ID, the relationship among these SVECs is not 311 associated. Below is an example of non-associated SVECs that does 312 not contain any same request-IDs. 314 316 with one or more dependency flags 318 Request-ID #1, Request-ID #2 320 with one or more dependency flags 322 Request-ID #4, Request-ID #5 324 ........ 326 without dependency flags 328 Request-ID #X, Request-ID #Y, Request-ID #Z 330 5. Processing of SVEC list 332 5.1. Single PCE, single domain environments 334 When PCEP receives PCReq messages with more than two SVEC objects 335 in the SVEC list, PCEP has to first check the request-IDs in all 336 SVEC objects in order to identify any associations among them. The 337 SVEC objects may be received in a single or multiple PCReq 338 message(s). In the later case, the PCE may start a SyncTimer as 339 recommended in [ID.pce-pcep]. After receiving the whole path 340 computation requests, the analysis for associated SVECs has to be 341 started. 343 If there are no matching request-IDs in the different SVEC objects, 344 these SVEC objects are not associated, and then each set of path 345 computation requests in the non-associated SVEC objects has to be 346 computed separately. 348 If there are matching request-IDs in the different SVEC objects, 349 these SVEC objects are associated, and then all path computation 350 requests in the associated SVEC objects are treated in a 351 synchronous manner for GCO application. 353 If the PCE does not have capability to handle the associated SVEC 354 objects, it may send a PCErr message with Error-Type="Capability 355 not supported". 357 5.2. Multi-PCE, single domain environments 359 Currently no mechanisms exist to manage co-ordination of dependent 360 SVEC requests between multiple PCE`s in the same domain. If a PCC 361 sends a path computation request to a PCE and then sends a second 362 service path computation request, which is required to be disjoint 363 from the first service, and this request is sent to a different 364 PCE in the domain, no SVEC object correlation function between the 365 PCEs is currently available. Equally, associated SVECs are not 366 sent to the different PCEs in the domain. 368 5.3. Multi-PCE, multi-domain environments 370 When more than two PCEs are used to concurrently compute a 371 protected end-to-end path across multiple domains, additional 372 processing may be required. If the PCReq message contains multiple 373 associated SVEC objects and these SVEC objects contain path 374 computation requests that will be sent to the next PCE along the 375 path computation chain. Intermediate PCEs receiving such PCReq 376 messages may re-construct associations among SVEC objects, and 377 then send PCReq messages to corresponding next PCEs. If the 378 associated SVECs are re-constructed at the intermediate PCE, the 379 PCE must not start path computation until all PCRep messages are 380 received from neighbor PCEs. In addition, it is not recommended 381 that SVEC objects coming from different PCReq messages are re- 382 constructed. This may contribute to resource optimization from 383 network operator`s point of view, but it is unrealistic in the 384 case of multiple PCE path computation. 386 6. Manageability considerations 388 This section describes manageability considerations specified in 389 [ID.pce-mngabl-reqs]. 391 6.1. Control of Function and Policy 393 In addition to section 8.1 to [ID.pce-pcep], PCEP implementation 394 should allow the configuration of association among SVECs on PCCs. 396 o the capability to configure SVEC association. 398 6.2. Information and Data Models, e.g. MIB modules 400 There are no additional parameters for MIB modules. 402 6.3. Liveness Detection and Monitoring 404 The associated SVEC in this document allows PCEs to compute 405 optimal sets of diverse path. This type of path computation may 406 require more time to obtain its results. Therefore, it is 407 recommended for PCEP to support PCE monitoring mechanism specified 408 in [ID.pce-monitor]. 410 6.4. Verifying Correct Operation 412 Section 8.4 in [ID.pce-pcep] provides the sufficient descriptions 413 for this document. So, there are no additional considerations. 415 6.5. Requirements on Other Protocols and Functional Components 417 This document does not require anything on other protocol and 418 functional components. 420 6.6. Impact on Network Operation 422 Section 8.6 in [ID.pce-pcep] provides the sufficient descriptions 423 for this document. So, there are no additional considerations. 425 7. Security Considerations 427 This document defines the usage of SVEC list, and does not have 428 any extensions for PCEP protocol. Therefore the security of this 429 document depends on that of PCEP protocol. 431 8. IANA Considerations 433 This document has no specific extension for PCEP messages, objects 434 and its parameters and does not require any registry assignment. 436 9. References 438 9.1. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels," BCP 14, RFC 2119, March 1997. 443 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 444 Element (PCE)-Based Architecture," RFC 4655, September 445 2006. 447 [RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE) 448 Communication Protocol Generic Requirements," RFC 4757, 449 September 2006. 451 [RFC4875] R. Aggarwal, D. Papadimitriou, and S. Yasukawa, " 452 Extensions to Resource Reservation Protocol - Traffic 453 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 454 Switched Paths (LSPs)," RFCCC4875, May 2007. 456 9.2. Informative References 458 [ID.pce-pcep] 460 JP. Vasseur and JL. Le Roux, "Path Computation Element 461 (PCE) communication Protocol (PCEP) - Version 1," draft- 462 ietf-pce-pcep-12 Work in progress, Mar. 2008. 464 [ID.pce-gco] 466 Y. Lee, JL. Le Roux, D. King and E. Oki, "Path 467 Computation Element Communication Protocol (PCECP) 468 Requirements and Protocol Extensions In Support of 469 Global Concurrent Optimization," draft-ietf-pce-global- 470 concurrent-optimization-02 Work in progress, Feb. 2008. 472 [ID.pce-p2mp-ext] 474 M. Chaitou, JL. Le Roux, and Z. Ali, "Path Computation 475 Element communication Protocol (PCEP) Extensions for 476 Point to Multipoint Label Switched Paths (LSPs)," draft- 477 chaitou-pce-pcep-p2mp-ext-00, Work in progress, Feb. 478 2008. 480 [ID.p2mp-te-bypass] 482 JL. Le Roux, R. Aggarwal, J.P. Vasseur, and M. Vigoureux, 483 "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels," 484 draft-ietf-mpls-p2mp-te-bypass-02," Work in progress, 485 Mar. 2008. 487 [ID.pce-mngabl-reqs] 489 A. Farrel, "Inclusion of Manageability Sections in PCE 490 Working Group Drafts," draft-ietf-pce-manageability- 491 requirements-04 Work in progress, June. 2008. 493 [ID.pce-monitor] 495 JP. Vasseur, JL. Le Roux and Y. Ikejiri, "A set of 496 monitoring tools for Path Computation Element based 497 Architecture," draft-ietf-pce-monitoring-01 Work in 498 progress, Feb. 2008. 500 Author's Addresses 502 Itaru Nishioka 503 NEC Corp. 504 1753 Shimonumabe, Kawasaki, Kanagawa 211-8555, Japan 506 Phone: +81 44 396 3287 507 Email: i-nishioka@cb.jp.nec.com 509 Daniel King 510 Old Dog Consulting 512 Phone: +44 7790 775187 513 Email: daniel@olddog.co.uk 515 Intellectual Property Statement 517 The IETF takes no position regarding the validity or scope of any 518 Intellectual Property Rights or other rights that might be claimed 519 to pertain to the implementation or use of the technology 520 described in this document or the extent to which any license 521 under such rights might or might not be available; nor does it 522 represent that it has made any independent effort to identify any 523 such rights. Information on the procedures with respect to rights 524 in RFC documents can be found in BCP 78 and BCP 79. 526 Copies of IPR disclosures made to the IETF Secretariat and any 527 assurances of licenses to be made available, or the result of an 528 attempt made to obtain a general license or permission for the use 529 of such proprietary rights by implementers or users of this 530 specification can be obtained from the IETF on-line IPR repository 531 at http://www.ietf.org/ipr. 533 The IETF invites any interested party to bring to its attention 534 any copyrights, patents or patent applications, or other 535 proprietary rights that may cover technology that may be required 536 to implement this standard. Please address the information to the 537 IETF at ietf-ipr@ietf.org. 539 Disclaimer of Validity 541 This document and the information contained herein are provided on 542 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 543 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 544 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 545 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 546 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 547 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 548 FOR A PARTICULAR PURPOSE. 550 Copyright Statement 552 Copyright (C) The IETF Trust (2008). 554 This document is subject to the rights, licenses and restrictions 555 contained in BCP 78, and except as set forth therein, the authors 556 retain all their rights. 558 Acknowledgment 560 Funding for the RFC Editor function is currently provided by the 561 Internet Society.