idnits 2.17.1 draft-dhody-pce-pcep-ds-04.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5441], [CSO-PCE], [ABNO]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 20, 2013) is 3896 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'PCEP-MIB' is mentioned on line 739, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-05 == Outdated reference: A later version (-07) exists of draft-dhody-pce-cso-enabled-path-computation-02 == Outdated reference: A later version (-16) exists of draft-farrkingel-pce-abno-architecture-05 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft U. Palle 4 Intended status: Experimental Huawei Technologies India Pvt Ltd 5 Expires: February 21, 2014 August 20, 2013 7 Encoding of Data Structure (DS) in the Path Computation Element 8 Communication Protocol (PCEP) 9 draft-dhody-pce-pcep-ds-04 11 Abstract 13 The ability to compute shortest constrained Traffic Engineering Label 14 Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and 15 Generalized MPLS (GMPLS) networks across multiple domains has been 16 identified as a key requirement for point-to-point (P2P) and point- 17 to-multipoint (P2MP) scenarios. Backward-Recursive Path Computation 18 (BRPC) [RFC5441] defines Virtual Shortest Path Tree (VSPT) as a 19 default de-facto data structure for path reply message in inter- 20 domain scenarios. 22 As Path Computation Element (PCE) will get used in newer scenarios 23 like inter-domain, protection, P2MP etc. As well as PCE is being 24 explored to be used in Cross Stratrum Optimization (CSO) environment 25 (see [CSO-PCE]) as well as in [ABNO]. Limiting PCE communication 26 Protocol (PCEP) to just one data structure limits the usage of PCEP. 27 Its important to keep PCEP generic enough to use differnt data 28 structure and apply different algorithms. 30 This document defines extensions to the PCEP to allow multiple data 31 structures. Extensions are defined for PCE to indicate the set of 32 Data Structure (DS) it supports; also Path Computation Client (PCC) 33 or PCE can indicate in a path computation request the required DS, 34 and a PCE can report in a path computation reply the Data Structure 35 that was used in the path reply message. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on February 21, 2014. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. Need for multiple Data Structure . . . . . . . . . . . . . . 5 75 3.1. Point to Multipoint (P2MP) . . . . . . . . . . . . . . . 5 76 3.2. Synchronized Dependent Path Computations . . . . . . . . 5 77 3.3. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 5 78 3.4. Others . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 3.5. PCE in future . . . . . . . . . . . . . . . . . . . . . . 6 80 3.6. Others Techniques . . . . . . . . . . . . . . . . . . . . 7 81 4. Discovery of PCE Data Structure . . . . . . . . . . . . . . . 7 82 4.1. DS-List TLV . . . . . . . . . . . . . . . . . . . . . . . 7 83 4.2. Elements of Procedure . . . . . . . . . . . . . . . . . . 8 84 5. Data Structure in PCEP Path Computation Request and Reply 85 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 5.1. DS Object . . . . . . . . . . . . . . . . . . . . . . . . 8 87 5.1.1. Elements of Procedure . . . . . . . . . . . . . . . . 9 88 5.2. Carrying The DS Object In a PCEP Message . . . . . . . . 10 89 5.3. New RP Object Flag . . . . . . . . . . . . . . . . . . . 12 90 5.3.1. Elements of Procedure . . . . . . . . . . . . . . . . 13 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 92 6.1. PCE Data Structure Sub-Registry . . . . . . . . . . . . . 14 93 6.2. PCEP Code Points . . . . . . . . . . . . . . . . . . . . 14 94 6.2.1. DS Object . . . . . . . . . . . . . . . . . . . . . . 14 95 6.2.2. DS-List TLV . . . . . . . . . . . . . . . . . . . . . 14 96 6.2.3. PCEP Error Values . . . . . . . . . . . . . . . . . . 15 97 6.2.4. RP Object Flag . . . . . . . . . . . . . . . . . . . 15 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 99 8. Manageability Considerations . . . . . . . . . . . . . . . . 16 100 8.1. Control of Function and Policy . . . . . . . . . . . . . 16 101 8.2. Information and Data Models . . . . . . . . . . . . . . . 16 102 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 16 103 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 16 104 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 17 105 8.6. Impact On Network Operations . . . . . . . . . . . . . . 17 106 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 109 10.2. Informative References . . . . . . . . . . . . . . . . . 17 111 1. Introduction 113 The PCE architecture is defined in [RFC4655]. [RFC5441] describe a 114 PCE-based path computation procedure to compute optimal inter-domain 115 constrained (G)MPLS TE LSPs. It also defines Virtual Shortest Path 116 Tree (VSPT) which is the only data structure and is used in all 117 inter-domain scenarios. 119 This document describes the need for multiple data structure (DS). 120 It may be useful for a PCC/PCE to discover the set of Data Structure 121 (DS) supported by a PCE. Furthermore, PCC/PCE requires the ability 122 to indicate in a path computation request a required/desired Data 123 Structure, as well as optional function parameters. 125 For these purposes, this document extends the PCE communication 126 Protocol (PCEP). It defines PCEP extensions that allow a PCE to 127 advertise a list of supported Data Structure (DS), as well as 128 extensions to carry Data Structure (DS) in PCEP request and reply 129 messages. It complements the PCEP base specification [RFC5440]. 131 Note that OSPF and IS-IS-based PCE discovery mechanisms are defined 132 in [RFC5088] and [RFC5089]. These mechanisms are dedicated to the 133 discovery of a few generic parameters, while more detailed PCE 134 parameters should be discovered using the PCE communication Protocol. 136 Data Structure (DS) are in this second category; thus, the Data 137 Structure discovery procedure is handled by PCEP. 139 A new PCEP TLV, named the DS-List TLV, is defined in Section 4. The 140 DS-List TLV is carried in the PCEP OPEN object and allows a PCE to 141 list, during PCEP session-setup phase, the Data Structure (DS) that 142 it supports. 144 A new PCEP object, the DS object, is defined in Section 5. The DS 145 object is carried within a PCReq (Path Computation Request) message 146 to indicate the required/desired data structure to be applied by a 147 PCE, or in a PCRep (Path Computation Reply) message to indicate the 148 data structure that was used for path computation and the reply 149 message. 151 1.1. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 2. Terminology 159 The following terminology is used in this document. 161 BRPC: Backward Recursive Path Computation. 163 DS: Data Structure. 165 H-PCE: Hierarchical PCE. 167 IGP: Interior Gateway Protocol. Either of the two routing 168 protocols, Open Shortest Path First (OSPF) or Intermediate System 169 to Intermediate System (IS-IS). 171 IS-IS: Intermediate System to Intermediate System. 173 OF: Objective Function. 175 OSPF: Open Shortest Path First. 177 PCC: Path Computation Client: any client application requesting a 178 path computation to be performed by a Path Computation Element. 180 PCE: Path Computation Element. An entity (component, application, 181 or network node) that is capable of computing a network path or 182 route based on a network graph and applying computational 183 constraints. 185 P2MP: Point-to-Multipoint 187 P2P: Point-to-Point 189 TE LSP: Traffic Engineering Label Switched Path. 191 TLV: Type-Length-Variable data encoding. 193 VSPT: Virtual Shortest Path Tree as defined in [RFC5441]. 195 3. Need for multiple Data Structure 197 3.1. Point to Multipoint (P2MP) 199 [PCE-P2MP-PROCEDURES] describes the need for an extended VSPT for 200 computation of the best core-tree. In case of Core tree based path 201 computation, the PCE in a downstream domain does the pruning and 202 returns the single optimal sub-path to its previous PCE, BRPC insures 203 that the ingress PCE will get all the best optimal sub-paths for each 204 LN (Leaf Border Nodes), but the combination of these single optimal 205 sub-paths into a P2MP tree is not necessarily optimal even if each 206 S2L (Source-to-Leaf) sub-path is optimal. Without trimming, the 207 ingress PCE will get all the possible S2L sub-paths set for LN, and 208 eventually by looking through all the combinations, and taking one 209 sub-path from each set to built one P2MP tree it finds the optimal 210 tree. 212 3.2. Synchronized Dependent Path Computations 214 [RFC6007] describes the need for disjoint VSPT in case of 215 Synchronized Dependent Path Computations. 217 The BRPC procedure constructs a VSPT to inform the enquiring PCE of 218 potential paths to the destination node. 220 In the end-to-end diverse path computation, diversity (or 221 disjointness) information among the potential paths must be preserved 222 in the VSPT to ensure an end-to-end disjoint path. In order to 223 preserve diversity (or disjointness) information, disjoint VSPTs are 224 sent in the PCEP PCRep message. The PCReq containing a SVEC object 225 with the appropriate diverse flag set would signal that the PCE 226 should compute a disjoint VSPT. 228 A definition of the disjoint VSPT is a collection of VSPTs, in which 229 each VSPT contains a potential set of primary and secondary paths. 231 3.3. Hierarchical PCE 233 In Hierarchical PCE model ([RFC6805]), Parent PCE MAY be used to 234 return the domain-sequence which may be further applied by the 235 ingress PCE to do the BRPC path computation; or Parent PCE MAY do the 236 full end to end path computation. 238 In full end to end path computation model, Parent PCE MAY ask the 239 child PCE to do the intra domain path computation between - 240 o Ingress Domain: Ingress to Exit Boundary Nodes 242 o Transit Domain(s): Entry Boundary Nodes to Exit Boundary Nodes 244 o Egress Domain: Entry Boundary Nodes to Egress 246 Here the results are a list of best paths between the nodes listed 247 above, is is not a VSPT, which clearly defines it self as a P2MP Tree 248 from entry boundary nodes to egress. 250 There exist clear instances like this where VSPT is not the only data 251 structure in use. 253 3.4. Others 255 VSPT does not work well with boundary constraints like HOP-LIMIT in 256 inter-domain scenarios. Since there maybe a not-the-best-path in a 257 domain which would have satisfied the end to end contraint, but was 258 prunded. 260 Since PCEP allow multiple Objective Function (OF) [RFC5541]; it is 261 natural to extend PCEP to support multiple Data Structure based on 262 path computation scenarios. 264 3.5. PCE in future 266 [CSO-PCE] describes the use of PCE in Cross Stratrum Optimization 267 (CSO) environment. A request can be made to the PCE with different 268 sets of computation mode that are not currently supported by PCE. 269 For instance, NCG may request PCE a multi-destination and multi- 270 source path computation request. This scenario arises when there are 271 many possible Data Center choices for a given application request and 272 there could be multiple sources for this request. Multi-destination 273 with a single source (aka., anycast) is a default case for multi- 274 destination and multi-source path computation. 276 In addition, with this architecture, NCG may have different sets of 277 objectives and constraints than typical path computation requests. 278 For instance, multi-criteria objective functions that combine the 279 bandwidth requirement and latency may be very useful for some 280 applications. 282 [ABNO] describes Application-Based Network Operations using PCE. 284 Its important to keep PCEP generic to support new requirements in the 285 future. 287 3.6. Others Techniques 289 This is being achieved in some extent by an RP object bit. 291 For example, if P2MP bit is set and Objective function (OF) is 292 Minimum Cost Tree (MCT), the extended VSPT should be used. We 293 beleive this not a sustainable mechanism. 295 Making PCEP generic allowing use of multiple DS will make PCEP 296 protocol behave in a better way. 298 4. Discovery of PCE Data Structure 300 This section defines PCEP extensions (see [RFC5440]) so as to support 301 the advertisement of the Data Structure (DS) supported by a PCE. 303 A new PCEP DS-List (Data Structure list) TLV is defined. The PCEP 304 DS-List TLV is carried within an OPEN object. This way, during PCEP 305 session-setup phase, a PCE can advertise to a PCEP peer the list of 306 data structure it supports. 308 4.1. DS-List TLV 310 The PCEP DS-List TLV is optional. It MAY be carried within an OPEN 311 object sent by a PCE in an Open message to a PCEP peer so as to 312 indicate the list of supported data structures. 314 The DS-List TLV format is compliant with the PCEP TLV format defined 315 in [RFC5440]. That is, the TLV is composed of 2 octets for the type, 316 2 octets specifying the TLV length, and a Value field. The Length 317 field defines the length of the value portion in octets. The TLV is 318 padded to 4-octet alignment, and padding is not included in the 319 Length field (e.g., a 3-octet value would have a length of three, but 320 the total size of the TLV would be eight octets). 322 The PCEP DS-List TLV has the following format: 323 TYPE: 4 324 LENGTH: N * 2 (where N is the number of Data Structures) 325 VALUE: list of 2-byte data structure code points, identifying 326 the data structures supported by the sender of the Open 327 message. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | DS Code #1 | DS Code #2 | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 // // 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | DS Code #N | padding | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 DS Code (2 bytes): Data Structure code point identifier. IANA 340 manages the "PCE Data Structure" code point registry 341 (see Section 6). 343 4.2. Elements of Procedure 345 A PCE MAY include a DS-List TLV within an OPEN object in an Open 346 message sent to a PCEP peer in order to advertise a set of one or 347 more supported Data Structures. The DS-List TLV MUST NOT appear more 348 than once in an OPEN object. If it appears more than once, the PCEP 349 session MUST be rejected with error type 1 and error value 1 (PCEP 350 session establishment failure / Reception of an invalid Open 351 message). The absence of the DS-List TLV in an OPEN object MUST be 352 interpreted as an absence of information on the list of supported 353 data structures by the PCE, default data stricture VSPT is always 354 supported. 356 As specified in [RFC5440], a PCEP peer that does not recognize the 357 DS-List TLV will silently ignore it. 359 5. Data Structure in PCEP Path Computation Request and Reply Messages 361 This section defines PCEP extensions [RFC5440] so as to support the 362 communication of Data Structure (DS) in PCEP path computation request 363 and reply messages. A new PCEP DS (Data Structure) object is 364 defined, to be carried within a PCReq message in order for the PCC/ 365 PCE to indicate the required/desired data structure. 367 The PCEP DS object may also be carried within a PCRep message in 368 order for the PCE to indicate the data structure that was used by the 369 PCE and used in the reply message. 371 A new flag is defined in the RP (Request Parameters) object. The 372 flag is used in a PCReq message to indicate that the PCE MUST include 373 a DS object in the PCRep message to indicate the data structure that 374 was used during path computation and encoded in the reply message. 376 Also, new PCEP error types and values are defined. 378 5.1. DS Object 380 The PCEP DS (Data Structure) object is optional. It MAY be carried 381 within a PCReq message so as to indicate the desired/required data 382 structure to be applied by the PCE during path computation or within 383 a PCRep message so as to indicate the data structure that was used by 384 the PCE during path computation and in the reply message. 386 The DS object format is compliant with the PCEP object format defined 387 in [RFC5440]. 389 The DS Object-Class is . 391 The DS Object-Type is 1. 393 The format of the DS object body is: 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | DS Code | Reserved | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | | 401 // Optional TLV(s) // 402 | | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 DS Code (2 bytes): The identifier of the Data Structure. IANA 406 manages the "PCE Data Structure" code point registry 408 Reserved (2 bytes): This field MUST be set to zero on transmission 409 and MUST be ignored on receipt. 411 Optional TLVs may be defined in the future. 413 5.1.1. Elements of Procedure 415 To request the use of a specific data structure by the PCE, a PCC/PCE 416 includes a DS object in the PCReq message. 418 [RFC5440] specifies a bit flag, referred to as the P bit, carried in 419 the common PCEP object header. The P bit is set by a PCC/PCE to 420 mandate that a PCE must take the information carried in the object 421 into account during the path computation. 423 If the P bit is set in the DS object, the data structure is mandatory 424 (required data structure) and the PCE MUST use the data structure 425 during path computation. If the P bit is clear in the DS object, the 426 data structure is optional (desired data structure) and the PCE 427 SHOULD apply the data structure if it is supported but MAY choose to 428 apply a different data structure, according to local capabilities and 429 policies. 431 On receipt of a PCReq message with a DS object, a PCE MUST proceed as 432 follows: 434 o If the DS object is unknown/unsupported, the PCE MUST follow 435 procedures defined in [RFC5440]. That is, if the P bit is set, 436 the PCE sends a PCErr message with error type 3 or 4 (Unknown / 437 Not supported object) and error value 1 or 2 (unknown / 438 unsupported object class / object type), and the related path 439 computation request MUST be discarded. If the P bit is cleared, 440 the PCE is free to ignore the object. 442 o If the data structure is unknown/unsupported and the P bit is set, 443 the PCE MUST send a PCErr message with error type 3 or 4 (Unknown 444 / Not supported object) and error value 4 (Unrecognized/ 445 Unsupported parameter), and the related path computation request 446 MUST be discarded. 448 o If the data structure is unknown/unsupported and the P bit is 449 cleared, the PCE SHOULD apply another (default) data structure. 451 o If the data structure is supported but policy does not permit 452 applying it and if the P bit is set, the PCE MUST send a PCErr 453 message with the PCEP error type "policy-violation" (type 5) and a 454 new error value, "data structure not allowed", which is defined in 455 this document. 457 o If the data structure is supported but policy does not allow 458 applying it and if the P bit is cleared, the PCE SHOULD apply 459 another (default) data structure. 461 o If the data structure is supported and policy allows applying it 462 and if the P bit is set, the PCE MUST apply the requested data 463 structure. Otherwise, if the P bit is cleared, the PCE is free to 464 apply any other data structure. 466 The default data structure is VSPT or may be locally configured. 468 5.2. Carrying The DS Object In a PCEP Message 470 The DS object MAY be carried within a PCReq message. If a data 471 structure is to be applied to a set of synchronized path computation 472 requests, the DS object MUST be carried just after the corresponding 473 SVEC (Synchronization VECtor) object and MUST NOT be repeated for 474 each elementary request. 476 A DS object specifying a data structure that applies to an individual 477 path computation request (non-synchronized case) MUST follow the RP 478 object for which it applies. 480 The format of the PCReq message is updated as follows. 482 ::= 483 [] 484 485 where: 486 ::= 487 [] 488 [] 489 [] 490 [] 492 ::= [] 494 ::= 495 496 [] 497 [] 498 [] 499 [] 500 [] 501 [[]] 502 [] 503 [] 505 and where: 507 ::= [] 509 The DS object MAY be carried within a PCRep message to indicate the 510 data structure used by the PCE during path computation and in the 511 reply message. 513 When the PCE wants to indicate to the PCC/PCE the data structure that 514 was used for the synchronized computation of a set of paths, the 515 PCRep message MUST include the corresponding SVEC object directly 516 followed by the DS object, which MUST NOT be repeated for each 517 elementary request. 519 A DS object specifying a data structure used for an individual path 520 computation (non-synchronized case) MUST follow the RP object for 521 which it applies. 523 The format of the PCRep message is updated as follows. 525 ::= 526 [] 527 529 where: 531 ::= 532 [] 533 [] 534 [] 535 [] 537 ::= [] 539 ::= 540 [] 541 [] 542 [] 544 ::= [] 546 ::= 547 549 and where: 551 ::= [] 552 [] 553 [] 554 [] 555 [] 556 [] 558 ::= [] 560 Note: The DS object MAY be associated to a negative reply, i.e., a 561 reply with a NO-PATH object. 563 5.3. New RP Object Flag 565 In some cases, where no data structure is specified in the request or 566 an optional data structure is desired (P flag cleared in the DS 567 object common header) but the PCE does not follow the request, the 568 PCC/PCE may desire to know the data structure that was used by the 569 PCE during path computation. To that end, a new flag is defined in 570 the RP object, named the DS flag, allowing a PCC/PCE to request for 571 the inclusion in the path computation reply of the data structure 572 that was used by the PCE during path computation. 574 The following new bit flag of the RP object is defined: The Supply DS 575 on response flag (bit number ). When set in a PCReq message, 576 this indicates that the PCE MUST provide the applied data structure 577 in the PCRep message. When set in a PCRep message, this indicates 578 that the data structure that was used during path computation is 579 included. 581 5.3.1. Elements of Procedure 583 If the PCC/PCE wants to know the data structure used by the PCE 584 during path computation for a given request, it sets the DS flag in 585 the RP object. 587 On receipt of a PCReq message with the DS flag in the RP object set, 588 the PCE proceeds as follows: 590 o If policy permits, it MUST include in the PCRep message a DS 591 object indicating the data structure it used during path 592 computation. 594 o If policy does not permit, it MUST send a PCErr message with the 595 PCEP error code "policy-violation" (type 5) and a new error value, 596 "data structure indication not allowed", which is defined in this 597 document. 599 Note that a legacy PCE might not recognize the DS flag in the RP 600 object. According to the definition of the Flags field for the RP 601 object (Section 7.4.1 of [RFC5440]), the legacy PCE will ignore the 602 unknown flag, resulting in it sending a PCRep that does not contain a 603 DS object. In this case, the PCC/PCE's behavior is an implementation 604 choice. It might: 606 o Discard the PCRep because it really wanted the DS object returned. 608 o Accept the PCRep without the knowledge of the DS that was applied. 610 Note also that these procedures can give rise to the situation where 611 a PCC/PCE receives a PCRep that contains a DS object with a data 612 structure identifier that the PCC/PCE does not recognize. In this 613 situation, the PCC/PCE behavior is dependent on implementation and 614 configuration. The PCC/PCE could choose any of the following (or 615 some other action): 617 o Ignore the DS object and use the computed path. 619 o Add the data structure to its view of the PCE's repertoire for 620 inclusion in future computation requests. 622 o Discard the PCRep (i.e., the computed path) and send a PCReq to 623 another PCE. 625 o Discard the PCRep (i.e., the computed path) and send another PCReq 626 to the same PCE explicitly requiring the use of some other data 627 structure (i.e., by setting the P bit in the DS object). 629 6. IANA Considerations 631 6.1. PCE Data Structure Sub-Registry 633 This document defines a 16-bit PCE data structure identifier to be 634 carried within the PCEP DS object, and also defines the PCEP DS-List 635 TLV. IANA should create and manages the 16-bit "PCE Data Structure" 636 code point registry. Values are TBD. 638 6.2. PCEP Code Points 640 6.2.1. DS Object 642 IANA manages the PCEP Objects code point registry (see [RFC5440]). 643 This is maintained as the "PCEP Objects" sub-registry of the "Path 644 Computation Element Protocol (PCEP) Numbers" registry. This document 645 defines a new PCEP object, the DS object, to be carried in PCReq and 646 PCRep messages. 648 IANA should make the following allocation: 650 Object Name Object Name Reference 651 Class Type 652 ------------------------------------------------------------ 653 TBA DS 1 Data Structure This ID 655 6.2.2. DS-List TLV 657 IANA manages the PCEP TLV code point registry (see [RFC5440]). This 658 is maintained as the "PCEP TLV Type Indicators" sub-registry of the 659 "Path Computation Element Protocol (PCEP) Numbers" registry. This 660 document defines a new PCEP TLV, the DS-List TLV, to be carried in 661 the OPEN object. 663 IANA should make the following allocation: 665 Type TLV name References 666 ----------------------------------------------- 667 TBA DS-List This ID 669 6.2.3. PCEP Error Values 671 IANA maintains a registry of Error-types and Error-values for use in 672 PCEP messages. This is maintained as the "PCEP-ERROR Object Error 673 Types and Values" sub-registry of the "Path Computation Element 674 Protocol (PCEP) Numbers" registry. 676 Two new Error-values are defined for the Error-type "policy 677 violation" (type 5): 679 Error-type Meaning and error values Reference 680 ------------------------------------------------------ 681 5 Policy violation 683 Error-value=TBA: data This ID 684 structure not 685 allowed (request rejected) 687 Error-value=TBA: DS bit This ID 688 of the RP object set 689 (request rejected) 691 6.2.4. RP Object Flag 693 A new flag of the RP object (specified in [RFC5440]) is defined in 694 this document. IANA maintains a registry of RP object flags in the 695 "RP Object Flag Field" sub-registry of the "Path Computation Element 696 Protocol (PCEP) Numbers" registry. 698 IANA should make the following allocation: 700 Bit Description Reference 701 ---------------------------------------------- 702 TBA Supply DS on response This ID 704 7. Security Considerations 706 PCEP security mechanisms are described in [RFC5440] and are used to 707 secure entire PCEP messages. Nothing in this document changes the 708 message flows or introduces any new messages, so the security 709 mechanisms set out in [RFC5440] continue to be applicable. 711 This document introduces a single new object that may optionally be 712 carried on PCEP messages and will be automatically secured using the 713 mechanisms described in [RFC5440]. 715 If a PCEP message is vulnerable to attack (for example, because the 716 security mechanisms are not used), then the DS object could be used 717 as part of an attack; however, it is likely that other objects will 718 provide far more significant ways of attacking a PCE or PCC in this 719 case. 721 8. Manageability Considerations 723 8.1. Control of Function and Policy 725 It MUST be possible to configure the activation/deactivation of data 726 structure discovery in PCEP. In addition to the parameters already 727 listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD 728 allow configuring a list of authorized data structure on a PCE. This 729 may apply to any session the PCEP speaker participates in, to a 730 specific session with a given PCEP peer, or to a specific group of 731 sessions with a specific group of PCEP peers. Note that it is not 732 mandatory for an implementation to support all data structure 733 defined. It MUST be possible to configure a default data structure 734 used for path computation when a path request is received that 735 requests to use an optional data structure. 737 8.2. Information and Data Models 739 The PCEP MIB Module defined in [PCEP-MIB] could be extended to 740 include data structure. 742 8.3. Liveness Detection and Monitoring 744 Mechanisms defined in this document do not imply any new liveness 745 detection and monitoring requirements in addition to those already 746 listed in [RFC5440]. 748 8.4. Verify Correct Operations 750 Mechanisms defined in this document do not imply any new operation 751 verification requirements in addition to those already listed in 752 [RFC5440]. 754 8.5. Requirements On Other Protocols 756 Mechanisms defined in this document do not imply any requirements on 757 other protocols in addition to those already listed in [RFC5440]. 759 8.6. Impact On Network Operations 761 Mechanisms defined in this document do not have any impact on network 762 operations in addition to those already listed in [RFC5440]. 764 9. Acknowledgments 766 We would like to thank Pradeep Shastry, Suresh babu, Quintin Zhao and 767 Chen Huaimo for their useful comments and suggestions. 769 10. References 771 10.1. Normative References 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, March 1997. 776 10.2. Informative References 778 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 779 Element (PCE)-Based Architecture", RFC 4655, August 2006. 781 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 782 "OSPF Protocol Extensions for Path Computation Element 783 (PCE) Discovery", RFC 5088, January 2008. 785 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 786 "IS-IS Protocol Extensions for Path Computation Element 787 (PCE) Discovery", RFC 5089, January 2008. 789 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 790 (PCE) Communication Protocol (PCEP)", RFC 5440, March 791 2009. 793 [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A 794 Backward-Recursive PCE-Based Computation (BRPC) Procedure 795 to Compute Shortest Constrained Inter-Domain Traffic 796 Engineering Label Switched Paths", RFC 5441, April 2009. 798 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 799 Objective Functions in the Path Computation Element 800 Communication Protocol (PCEP)", RFC 5541, June 2009. 802 [RFC6007] Nishioka, I. and D. King, "Use of the Synchronization 803 VECtor (SVEC) List for Synchronized Dependent Path 804 Computations", RFC 6007, September 2010. 806 [RFC6805] King, D. and A. Farrel, "The Application of the Path 807 Computation Element Architecture to the Determination of a 808 Sequence of Domains in MPLS and GMPLS", RFC 6805, November 809 2012. 811 [PCE-P2MP-PROCEDURES] 812 Zhao, Q., Dhody, D., Ali, Z., Saad,, T., Sivabalan,, S., 813 and R. Casellas, "PCE-based Computation Procedure To 814 Compute Shortest Constrained P2MP Inter-domain Traffic 815 Engineering Label Switched Paths (draft-ietf-pce-pcep- 816 inter-domain-p2mp-procedures-05)", July 2013. 818 [CSO-PCE] Dhody, D., Lee, Y., Ciulli, N., Contreras, L., and O. 819 Gonzalez de Dios, "Cross Stratum Optimization enabled Path 820 Computation. (draft-dhody-pce-cso-enabled-path- 821 computation-02)", September 2012. 823 [ABNO] Farrel, A. and D. King, "A PCE-based Architecture for 824 Application-based Network Operations. (draft-farrkingel- 825 pce-abno-architecture-05)", July 2013. 827 Authors' Addresses 829 Dhruv Dhody 830 Huawei Technologies India Pvt Ltd 831 Leela Palace 832 Bangalore, Karnataka 560008 833 INDIA 835 EMail: dhruv.dhody@huawei.com 837 Udayasree Palle 838 Huawei Technologies India Pvt Ltd 839 Leela Palace 840 Bangalore, Karnataka 560008 841 INDIA 843 EMail: udayasree.palle@huawei.com