idnits 2.17.1 draft-avantika-pce-multi-src-dest-01.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 date (February 14, 2014) is 3717 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6006 (Obsoleted by RFC 8306) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group U. Palle 3 Internet-Draft Avantika. S 4 Intended status: Experimental D. Dhody 5 Expires: August 18, 2014 Huawei Technologies 6 February 14, 2014 8 PCEP Extensions for Supporting Multiple Sources and Destinations 9 draft-avantika-pce-multi-src-dest-01 11 Abstract 13 The Path Computation Element (PCE) provides functions of path 14 computation in support of traffic engineering in networks controlled 15 by Multi-Protocol Label Switching (MPLS) and Generalized MPLS 16 (GMPLS). 18 This document provides extensions for the Path Computation Element 19 Protocol (PCEP) to support multiple sources and destinations in a 20 single path request. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 18, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Extension to PCEP . . . . . . . . . . . . . . . . . . . . . . 6 63 5.1. The New MP2MP END-POINTS Object . . . . . . . . . . . . . 6 64 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 8 65 6.1. Identification of Source-Destination Pair in PCRep 66 Message . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6.2. Request-ID . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.3. Backward Compatibility . . . . . . . . . . . . . . . . . 9 69 6.4. Overloading the PCE . . . . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 8. Manageability Considerations . . . . . . . . . . . . . . . . 9 72 8.1. Control of Function and Policy . . . . . . . . . . . . . 9 73 8.2. Information and Data Models . . . . . . . . . . . . . . . 10 74 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 10 75 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 10 76 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 10 77 8.6. Impact On Network Operations . . . . . . . . . . . . . . 10 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 9.1. New END-POINTS Object Types . . . . . . . . . . . . . . . 10 80 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 11.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Appendix A. Evaluation of Message Size Reduction . . . . . . . . 12 86 1. Introduction 88 [RFC5440] specifies the Path Computation Element Communication 89 Protocol (PCEP) for communications between a Path Computation Client 90 (PCC) and a Path Computation Element (PCE), or between two PCEs, in 91 compliance with [RFC4657]. 93 As per [RFC5440], a single Path Computation Request (PCReq) message 94 may carry more than one path computation request. Each request is 95 uniquely identified by a request-id number. In some scenarios (refer 96 Section 3), there is a need to send multiple requests with the same 97 constraints and attributes to the PCE. Currently these requests are 98 either sent in a separate PCReq messages or clubbed together in one 99 (or more) PCReq messages. In either case, the constraints and 100 attributes need to be encoded separately for each request even though 101 they are exactly identical. 103 Also note that, the PCE may choose to respond to each of the request 104 independently in a separate Path Computation Reply (PCRep) messages 105 or choose to bundle them in one (or more) PCRep messages. In some 106 scenarios (refer Section 3) one should wait for responses for all 107 request before proceeding further. 109 A mechanism to request path computation between multiple sources and 110 destinations in a single path computation request would be helpful. 112 Note that the scope of this work is point-to-point (P2P) path 113 computation and is unrelated to MP2MP LSP ([RFC6388]). 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2. Terminology 123 The following terminology is used in this document. 125 LSR: Label Switch Router. 127 MPLS: Multiprotocol Label Switching. 129 NMS: Network Management System. 131 P2P: Point-to-Point. 133 PCC: Path Computation Client. Any client application requesting a 134 path computation to be performed by a Path Computation Element. 136 PCE: Path Computation Element. An entity (component, application, 137 or network node) that is capable of computing a network path or 138 route based on a network graph and applying computational 139 constraints. 141 PCEP: Path Computation Element Communication Protocol. 143 3. Motivation 145 Following key scenarios are identified where a mechanism to request 146 path computation between multiple sources and destinations in a 147 single path computation request would be helpful. 149 Hierarchical PCE: [RFC6805] describes the procedure for inter-domain 150 path computation using Hierarchical PCE. In case of end to end 151 path computation by Parent PCE, it needs to issue multiple path 152 computation requests to child PCEs. In case of transit domain(s), 153 the Parent PCE issues requests from each entry boundary node to 154 each exit boundary node to the child PCE(s). Similarly for 155 ingress domain, the Parent PCE issues requests from source to each 156 exit boundary node, where as for egress domain, the Parent PCE 157 issues requests from each entry boundary node to the destination. 158 All requests to a particular child PCE, need to be encoded 159 separately even though they are exactly identical (they have the 160 same constraints and attributes). Also the Parent PCE needs to 161 wait for responses for all requests before proceeding further. 163 Inter-Layer PCE: [RFC5623] describes inter-layer path computation 164 framework. In case of cooperating PCEs per layer, where each PCE 165 has topology visibility restricted to its own layer and 166 collaborate to compute an end-to-end path across layers. The 167 higher layer PCE may need to issue multiple requests to lower 168 layer PCE requesting paths from each entry boundary node to each 169 exit boundary node. All these requests need to be encoded 170 separately even though they are exactly identical (they have the 171 same constraints and attributes). Also the higher layer PCE needs 172 to wait for responses for all requests before proceeding further. 174 Management-Based PCE: [RFC4655] describes a case where PCC is not 175 necessarily an LSR, but for example, maybe a NMS or a planning 176 tool etc. Such a PCC may issue multiple requests to PCE with 177 identical constraints and attributes to select among the several 178 source-destination pairs. 180 Using Multiple P2P Path Computations for MP2MP TE LSP: In case 181 where, for establishing a MP2MP TE LSP tunnel, multiple P2P path 182 computation requests are sent to the PCE, one for each source- 183 destination pair with identical constraints and attributes. 185 In these scenarios, a mechanism to request path computation between 186 multiple sources and destinations in a single path computation 187 request would be helpful. 189 3.1. Example 191 Consider the topology example mentioned in Section 4.6 of [RFC6805] - 193 ----------------------------------------------------------------- 194 | Domain 5 | 195 | ----- | 196 | |PCE 5| | 197 | ----- | 198 | | 199 | ---------------- ---------------- ---------------- | 200 | | Domain 1 | | Domain 2 | | Domain 3 | | 201 | | | | | | | | 202 | | ----- | | ----- | | ----- | | 203 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 204 | | ----- | | ----- | | ----- | | 205 | | | | | | | | 206 | | ----| |---- ----| |---- | | 207 | | |BN11+---+BN21| |BN23+---+BN31| | | 208 | | - ----| |---- ----| |---- - | | 209 | | |S| | | | | |D| | | 210 | | - ----| |---- ----| |---- - | | 211 | | |BN12+---+BN22| |BN24+---+BN32| | | 212 | | ----| |---- ----| |---- | | 213 | | | | | | | | 214 | | ---- | | | | ---- | | 215 | | |BN13| | | | | |BN33| | | 216 | -----------+---- ---------------- ----+----------- | 217 | \ / | 218 | \ ---------------- / | 219 | \ | | / | 220 | \ |---- ----| / | 221 | ----+BN41| |BN42+---- | 222 | |---- ----| | 223 | | | | 224 | | ----- | | 225 | | |PCE 4| | | 226 | | ----- | | 227 | | | | 228 | | Domain 4 | | 229 | ---------------- | 230 | | 231 ----------------------------------------------------------------- 233 Figure 1: An example topology 235 The following 11 individual requests are generated by parent PCE (PCE 236 5) - 237 Domain 1: S-BN11; S-BN12; S-BN13; 239 Domain 2: BN21-BN23; BN21-BN24; BN22-BN23; BN22-BN24; 241 Domain 3: BN31-D; BN32-D; BN33-D; 243 Domain 4: BN41-BN42; 245 The above requests for each domain, need to be encoded separately 246 even though they are exactly identical. A mechanism to request them 247 together in a single path computation request would be helpful, in 248 which case total 4 requests would be generated by parent PCE. 250 4. PCEP Requirements 252 Following key requirements are identified for PCEP to enable multiple 253 sources and destinations in a single path computation request: 255 1. It MUST be possible for a single Path Computation Request to list 256 multiple sources and destinations. 258 2. It MUST be possible for a single Path Computation Reply to be 259 sent for multiple sources and destinations. 261 3. It MUST NOT be possible to set different constraints, traffic 262 parameters, or quality-of-service requirements for different 263 source and destination pair within a single computation request. 265 5. Extension to PCEP 267 This document extends the existing END-POINTS object [RFC5440] and 268 [RFC6006] by defining two new END-POINTS object types. 270 5.1. The New MP2MP END-POINTS Object 272 The END-POINTS object is used in a PCReq message to specify the 273 source IP address and the destination IP address of the path for 274 which a path computation is requested. This document extends the 275 existing END-POINT object to support multiple sources and 276 destinations in a single path request. 278 Two new MP2MP END-POINTS objects for IPv4 and IPv6 are defined. 280 The format of the MP2MP END-POINTS object body for IPv4 (Object- 281 Type=5 (TBD)) is as follows: 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | No of Sources (2 bytes) | No of Destinations (2 bytes)| 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Source IPv4 address 1 (4 bytes) | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 ~ ...... ~ 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Source IPv4 address m (4 bytes) | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Destination IPv4 address 1 (4 bytes) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 ~ ...... ~ 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Destination IPv4 address n (4 bytes) | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Figure 2: The new MP2MP END-POINTS Object Body Format for IPv4 303 The format of the MP2MP END-POINTS object body for IPv6 (Object- 304 Type=6 (TBD)) is as follows: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | No of Sources (2 bytes) | No of Destinations (2 bytes)| 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | | 312 | Source IPv6 address 1 (16 bytes) | 313 | | 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 ~ ...... ~ 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | | 319 | Source IPv6 address m (16 bytes) | 320 | | 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | | 324 | Destination IPv6 address 1 (16 bytes) | 325 | | 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 ~ ...... ~ 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | | 331 | Destination IPv6 address n (16 bytes) | 332 | | 333 | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 3: The new MP2MP END-POINTS Object Body Format for IPv6 338 The MP2MP END-POINTS object body has a variable length. These are 339 multiples of 4 bytes for IPv4, and multiples of 16 bytes for IPv6, 340 plus 4 bytes. 342 On receiving MP2MP END-POINTS object, PCE computes m*n P2P paths, 343 i.e, point to point path is computed between each combination of 344 source and destination received in MP2MP END-POINTS object. 346 6. Other Considerations 348 6.1. Identification of Source-Destination Pair in PCRep Message 350 Since the END-POINTS object is not carried in the PCRep message 351 ([RFC5440]), the implementation supporting this extension SHOULD 352 encode the source and the destination as the first and the last hop 353 in the ERO. This is done to easily identify that which ERO 354 corresponds to which source-destination pair. 356 6.2. Request-ID 358 As per [RFC5440], each request is uniquely identified by a request-id 359 number. 361 Since a single request is used for multiple sources and destinations 362 sharing the same request-id number, along with request and response, 363 the request-id number in RP object used in other PCEP messages 364 (PCNtf, PCErr ...) applies to all sources and destinations (in the 365 single request). 367 6.3. Backward Compatibility 369 If PCE receives new END-POINTS type in path request and it 370 understands the END-POINTS type, but the PCE is not capable of/ 371 support multiple sources and destinations in a single path request, 372 the PCE MUST send a PCErr message with a PCEP-ERROR Object Error-Type 373 = 4 (Not supported object) [RFC5440]. The path computation request 374 MUST then be cancelled. 376 If the PCE does not understand the new END-POINTS type, then the PCE 377 MUST send a PCErr message with a PCEP-ERROR Object Error-Type = 3 378 (Unknown object) [RFC5440]. 380 6.4. Overloading the PCE 382 The new END-POINTS type could be used to issue multiple computations 383 together hence overloading the PCE. The PCE MUST allow for the use 384 of policies to accept/reject such a request. 386 7. Security Considerations 388 This document defines new END-POINTS types which does not add any new 389 security concerns beyond those discussed in [RFC5440]. 391 8. Manageability Considerations 393 8.1. Control of Function and Policy 395 TBD. 397 8.2. Information and Data Models 399 TBD. 401 8.3. Liveness Detection and Monitoring 403 TBD. 405 8.4. Verify Correct Operations 407 TBD. 409 8.5. Requirements On Other Protocols 411 TBD. 413 8.6. Impact On Network Operations 415 TBD. 417 9. IANA Considerations 419 IANA assigns values to PCEP parameters in registries defined in 420 [RFC5440]. IANA is requested to make the following additional 421 assignments. 423 9.1. New END-POINTS Object Types 425 Two new END-POINTS Object-Types are defined in this document. IANA 426 is requested to make the following Object-Type allocations from the 427 "PCEP Objects" sub-registry: 429 Object-Class Value 4 430 Name END-POINTS 431 Object-Type 5: MP2MP IPv4 432 6: MP2MP IPv6 433 7-15: Unassigned 434 Reference This.I-D 436 10. Acknowledgments 438 Thanks to Quintin Zhao for his suggestions. 440 11. References 441 11.1. Normative References 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, March 1997. 446 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 447 Communication Protocol Generic Requirements", RFC 4657, 448 September 2006. 450 11.2. Informative References 452 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 453 Element (PCE)-Based Architecture", RFC 4655, August 2006. 455 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 456 (PCE) Communication Protocol (PCEP)", RFC 5440, March 457 2009. 459 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 460 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 461 Traffic Engineering", RFC 5623, September 2009. 463 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, Z., 464 and J. Meuric, "Extensions to the Path Computation Element 465 Communication Protocol (PCEP) for Point-to-Multipoint 466 Traffic Engineering Label Switched Paths", RFC 6006, 467 September 2010. 469 [RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, 470 "Label Distribution Protocol Extensions for Point-to- 471 Multipoint and Multipoint-to-Multipoint Label Switched 472 Paths", RFC 6388, November 2011. 474 [RFC6805] King, D. and A. Farrel, "The Application of the Path 475 Computation Element Architecture to the Determination of a 476 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 477 2012. 479 Appendix A. Evaluation of Message Size Reduction 481 Consider the domain 2 in Figure 1, where 4 path requests need to be 482 encoded (from 2 entry boundary nodes to 2 exit boundary nodes with 483 the exact same constraints). 485 Following figure illustrates the existing mechanism of carrying 486 multiple requests in single PCReq message (as per [RFC5440]): 488 +--------------+ +--------------+ +--------------+ 489 |RP | |RP | |RP | 490 +-------+ |END-POINTS(8) | |END-POINTS | |END-POINTS | 491 |COMMON |+|BANDWIDTH |+|BANDWIDTH |+|BANDWIDTH | 492 |HEADER | |METRIC | |METRIC | |METRIC | 493 +-------+ |METRIC | |METRIC | |METRIC | 494 +--------------+ +--------------+ +--------------+ 495 4 Bytes 36 Bytes 36 Bytes 36 Bytes 497 +--------------+ 498 |RP | 499 |END-POINTS(20)| 500 + |BANDWIDTH | = 148 Bytes 501 |METRIC | 502 |METRIC | 503 +--------------+ 504 36 Bytes 506 Combining multiple requests into a single request by using MP2MP END- 507 POINTS object is illustrated below: 509 +--------------+ 510 |RP | 511 +-------+ |END-POINTS(20)| 512 |COMMON |+|BANDWIDTH | = 54 Bytes 513 |HEADER | |METRIC | 514 +-------+ |METRIC | 515 +--------------+ 516 4 Bytes 48 Bytes 518 There is message size reduction of 64% in this example for just one 519 domain. 521 Authors' Addresses 522 Udayasree Palle 523 Huawei Technologies 524 Leela Palace 525 Bangalore, Karnataka 560008 526 INDIA 528 EMail: udayasree.palle@huawei.com 530 Avantika 531 Huawei Technologies 532 Leela Palace 533 Bangalore, Karnataka 560008 534 INDIA 536 EMail: avantika.sushilkumar@huawei.com 538 Dhruv Dhody 539 Huawei Technologies 540 Leela Palace 541 Bangalore, Karnataka 560008 542 INDIA 544 EMail: dhruv.ietf@gmail.com