idnits 2.17.1 draft-ietf-pce-hierarchy-extensions-10.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 (March 4, 2019) is 1879 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-09 == Outdated reference: A later version (-15) exists of draft-ietf-pce-stateful-hpce-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group F. Zhang 3 Internet-Draft Q. Zhao 4 Intended status: Standards Track Huawei 5 Expires: September 5, 2019 O. Gonzalez de Dios 6 Telefonica I+D 7 R. Casellas 8 CTTC 9 D. King 10 Old Dog Consulting 11 March 4, 2019 13 Extensions to Path Computation Element Communication Protocol (PCEP) for 14 Hierarchical Path Computation Elements (PCE) 15 draft-ietf-pce-hierarchy-extensions-10 17 Abstract 19 The Hierarchical Path Computation Element (H-PCE) architecture is 20 defined in RFC 6805. It provides a mechanism to derive an optimum 21 end-to-end path in a multi-domain environment by using a hierarchical 22 relationship between domains to select the optimum sequence of 23 domains and optimum paths across those domains. 25 This document defines extensions to the Path Computation Element 26 Protocol (PCEP) to support Hierarchical PCE procedures. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 5, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .1 63 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . .4 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . .5 65 1.3. Requirements Language . . . . . . . . . . . . . . . . . .5 66 2. Requirements for H-PCE . . . . . . . . . . . . . . . . . . .5 67 2.1. Path Computation Request . . . . . . . . . . . . . . . .6 68 2.1.1. Qualification of PCEP Requests . . . . . . . . . . .6 69 2.1.2. Multi-domain Objective Functions . . . . . . . . . .6 70 2.1.3. Multi-domain Metrics . . . . . . . . . . . . . . . .6 71 2.2. Parent PCE Capability Advertisement . . . . . . . . . . .7 72 2.3. PCE Domain Identification . . . . . . . . . . . . . . . .7 73 2.4. Domain Diversity . . . . . . . . . . . . . . . . . . . .7 74 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . .8 75 3.1 Applicability to PCC-PCE Communications . . . . . . . . .8 76 3.2. OPEN Object . . . . . . . . . . . . . . . . . . . . . . .8 77 3.2.1. H-PCE Capability TLV . . . . . . . . . . . . . . . .8 78 3.2.1.1 Backwards Compatibility . . . . . . . . . . . . . . .9 79 3.2.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .10 80 3.3. RP Object . . . . . . . . . . . . . . . . . . . . . . . .11 81 3.3.1. H-PCE-FLAG TLV . . . . . . . . . . . . . . . . . . .11 82 3.3.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .11 83 3.4. Objective Functions . . . . . . . . . . . . . . . . . . .12 84 3.4.1. OF Codes . . . . . . . . . . . . . . . . . . . . . .12 85 3.4.2. OF Object . . . . . . . . . . . . . . . . . . . . . .13 86 3.5. Metric Object . . . . . . . . . . . . . . . . . . . . . .14 87 3.6. SVEC Object . . . . . . . . . . . . . . . . . . . . . . .14 88 3.7. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . .15 89 3.7.1. Hierarchy PCE Error-Type . . . . . . . . . . . . . .15 90 3.8. NO-PATH Object . . . . . . . . . . . . . . . . . . . . .15 91 4. H-PCE Procedures . . . . . . . . . . . . . . . . . . . . . .16 92 4.1. OPEN Procedure between Child PCE and Parent PCE . . . . .16 93 4.2. Procedure to Obtain Domain Sequence . . . . . . . . . . .17 94 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . .17 95 6. Manageability Considerations . . . . . . . . . . . . . . . .17 96 6.1. Control of Function and Policy . . . . . . . . . . . . .18 97 6.1.1. Child PCE . . . . . . . . . . . . . . . . . . . . . .18 98 6.1.2. Parent PCE . . . . . . . . . . . . . . . . . . . . .18 99 6.1.3. Policy Control . . . . . . . . . . . . . . . . . . .19 100 6.2. Information and Data Models . . . . . . . . . . . . . . .19 101 6.3. Liveness Detection and Monitoring . . . . . . . . . . . .19 102 6.4. Verify Correct Operations . . . . . . . . . . . . . . . .19 103 6.5. Requirements On Other Protocols . . . . . . . . . . . . .20 104 6.6. Impact On Network Operations . . . . . . . . . . . . . .20 105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .20 106 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . .20 107 7.2. H-PCE-CAPABILITY TLV Flags . . . . . . . . . . . . . . .20 108 7.3. Domain-ID TLV Domain type . . . . . . . . . . . . . . . .21 109 7.4. H-PCE-FLAG TLV Flags . . . . . . . . . . . . . . . . . .21 110 7.5. OF Codes . . . . . . . . . . . . . . . . . . . . . . . .22 111 7.6. METRIC Types . . . . . . . . . . . . . . . . . . . . . .22 112 7.7. New PCEP Error-Types and Values . . . . . . . . . . . . .22 113 7.8. New NO-PATH-VECTOR TLV Bit Flag . . . . . . . . . . . . .23 114 7.9. SVEC Flag . . . . . . . . . . . . . . . . . . . . . . . .23 115 7.10. NO-PATH VECTOR TLV Bit Flag. . . . . . . . . . . . . . .23 116 8. Security Considerations . . . . . . . . . . . . . . . . . . .23 117 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . .24 118 10.Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .24 119 11. References . . . . . . . . . . . . . . . . . . . . . . . . .24 120 11.1. Normative References . . . . . . . . . . . . . . . . . .24 121 11.2. Informative References . . . . . . . . . . . . . . . . .25 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .27 123 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 124 A1. Implementation Status . . . . . . . . . . . . . . . . . . .28 125 A1.1. Inter-layer traffic engineering with H-PCE . . . . . . .28 126 A1.2. Telefonica Netphony (Open Source PCE) . . . . . . . . .30 127 A1.3. H-PCE Proof of Concept developed by Huawei . . . . . . .31 129 1. Introduction 131 The Path Computation Element communication Protocol (PCEP) provides 132 a mechanism for Path Computation Elements (PCEs) and Path Computation 133 Clients (PCCs) to exchange requests for path computation and 134 responses that provide computed paths. 136 The capability to compute the routes of end-to-end inter-domain MPLS 137 Traffic Engineering (MPLS-TE) and GMPLS Label Switched Paths (LSPs) 138 is expressed as requirements in [RFC4105] and [RFC4216]. This 139 capability may be realized by a PCE [RFC4655]. The methods for 140 establishing and controlling inter-domain MPLS-TE and GMPLS LSPs are 141 documented in [RFC4726]. 143 [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can 144 be used for computing end-to-end paths for inter-domain MPLS Traffic 145 Engineering (TE) and GMPLS Label Switched Paths (LSPs). 147 Within the hierarchical PCE architecture, the parent PCE is used to 148 compute a multi-domain path based on the domain connectivity 149 information. A child PCE may be responsible for single or multiple 150 domains and is used to compute the intra-domain path based on its 151 own domain topology information. 153 The H-PCE end-to-end domain path computation procedure is described 154 below: 156 o A path computation client (PCC) sends the inter-domain path 157 computation requests to the child PCE responsible for its domain; 159 o The child PCE forwards the request to the parent PCE; 161 o The parent PCE computes the likely domain paths from the ingress 162 domain to the egress domain; 164 o The parent PCE sends the intra-domain path computation requests 165 (between the domain border nodes) to the child PCEs which are 166 responsible for the domains along the domain path; 168 o The child PCEs return the intra-domain paths to the parent PCE; 170 o The parent PCE constructs the end-to-end inter-domain path based 171 on the intra-domain paths; 173 o The parent PCE returns the inter-domain path to the child PCE; 175 o The child PCE forwards the inter-domain path to the PCC. 177 The parent PCE may be requested to provide only the sequence of 178 domains to achild PCE so that alternative inter-domain path 179 computation procedures, including Per Domain (PD) [RFC5152] and 180 Backwards Recursive Path Computation (BRPC) [RFC5441], may be used. 182 This document defines the PCEP extensions for the purpose of 183 implementing Hierarchical PCE procedures, which are described in 184 [RFC6805]. 186 1.1. Scope 188 The following functions are out of scope of this document: 190 o Determination of Destination Domain (section 4.5 of [RFC6805]): 192 * via a collection of reachability information from child domain; 194 * via requests to the child PCEs to discover if they contain the 195 destination node; 197 * or any other methods. 199 o Parent Traffic Engineering Database (TED) methods (section 4.4 of 200 [RFC6805]), suitible mechanisms include: 202 * YANG-based management interfaces; 204 * BGP-LS [RFC7752]; 206 * Future extension to PCEP (such as PCEP-LS). 208 o Learning of Domain connectivity and boundary nodes (BN) addresses. 209 This could be done achieved: 211 * YANG-based management interfaces; 213 * BGP-LS [RFC7752]; 215 * Future extension to PCEP (such as PCEP-LS). 217 o Stateful PCE Operations. (Refer [I-D.ietf-pce-stateful-hpce]) 219 o The hierarchical relationship model is described in [RFC6805]. It 220 is applicable to environments with small groups of domains where 221 visibility from the ingress LSRs is limited. As highlighted in 222 [RFC7399] applying the hierarchical PCE model to large groups of 223 domains such as the Internet is not considered feasible or 224 desirable. 226 1.2. Terminology 228 This document uses the terminology defined in [RFC4655], [RFC5440] 229 and the additional terms defined in Section 1.4 of [RFC6805]. 231 1.3. Requirements Language 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 235 "OPTIONAL" in this document are to be interpreted as described in BCP 236 14 [RFC2119] [RFC8174] when, and only when, they appear in all 237 capitals, as shown here. 239 2. Requirements for H-PCE 241 This section compiles the set of requirements to the PCEP extensions 242 to support the H-PCE architecture and procedures. 243 [RFC6805] identifies high-level requirements of PCEP extensions 244 required to support the hierarchical PCE model. 246 2.1. Path Computation Request 248 The Path Computation Request (PCReq) [RFC5440] messages are used by 249 a PCC or a PCE to make a path computation request to a PCE. In order 250 to achieve the full functionality of the H-PCE procedures, the PCReq 251 message needs to include: 253 o Qualification of PCE Requests (Section 4.8.1. of [RFC6805]); 255 o Multi-domain Objective Functions (OF); 257 o Multi-domain Metrics. 259 2.1.1. Qualification of PCEP Requests 261 As described in Section 4.8.1 of [RFC6805], the H-PCE architecture 262 introduces new request qualifications, which are: 264 o The ability for a child PCE to indicate that a path computation 265 request sent to a parent PCE should be satisfied by a domain 266 sequence only, that is, not by a full end-to-end path. This allows 267 the child PCE to initiate a per-domain (PD) [RFC5152] or a 268 backward recursive path computation (BRPC) [RFC5441]. 270 o As stated in [RFC6805], Section 4.5, if a PCC knows the egress 271 domain, it can supply this information as the path computation 272 request. The PCC may also want to specify the destination domain 273 information in a PCEP request, if it is known. 275 o An inter domain path computed by parent PCE should be capable of 276 disallowing specific domain re-entry. 278 2.1.2. Multi-domain Objective Functions 280 For H-PCE inter-domain path computation, there are three new 281 Objective Functions defined in this document: 283 o Minimize the number of Transit Domains (MTD) 284 o Minimize the number of border nodes (MBN) 285 o Minimize the number of Common Transit Domains (MCTD) 287 The PCC may specify the multi-domain Objective Function code to 288 use when requesting inter-domain path computation, it may also 289 include intra-domain OFs, such as Minimum Cost Path (MCP) [RFC5441], 290 which must be considered by participating child PCEs. 292 2.1.3. Multi-domain Metrics 293 For inter-domain path computation, there are several path metrics of 294 interest. 296 o Domain count (number of domains crossed); 298 o Border Node count. 300 A PCC may be able to limit the number of domains crossed by applying 301 a limit on these metrics. Details in Section 3.4. 303 2.2. Parent PCE Capability Advertisement 305 A PCEP Speaker (Parent PCE or Child PCE) that supports and wishes 306 to use the procedures described in this document must advertise 307 the fact and negotiate its role with its PCEP peers. It does this 308 using the "H-PCE Capability" TLV, described in Section 3.2.1, in the 309 OPEN Object to advertise its support for PCEP extensions for H-PCE 310 Capability. 312 During the PCEP session establishment procedure, the child PCE needs 313 to be capable of indicating to the parent PCE whether it requests the 314 parent PCE capability or not. 316 2.3. PCE Domain Identification 318 A PCE domain is a single domain with an associated PCE. Although it 319 is possible for a PCE to manage multiple domains simultaneously. The 320 PCE domain could be an IGP area or AS. 322 The PCE domain identifiers MAY be provided during the PCEP session 323 establishment procedure. 325 2.4. Domain Diversity 327 In a multi-domain environment, Domain Diversity is defined in 328 [RFC6805]. A pair of paths is domain-diverse if they do not 329 traverse any of the same transit domains. Domain diversity may be 330 maximized for a pair of paths by selecting paths that have the 331 smallest number of shared domains. Path computation should 332 facilitate the selection of domain diverse paths as a way to reduce 333 the risk of shared failure and automatically helps to ensure path 334 diversity for a pair of LSPs. 336 The main motivation behind domain diversity is to avoid fate sharing, 337 but it can also be because of some geo-political reasons and 338 commercial relationships that would require domain diversity. For 339 example, a pair of paths should choose different transit Autonomous 340 System (AS) because of some policy considerations. 342 In the case when full domain diversity could not be achieved, it is 343 helpful to minimize the commonly shared domains. Also, it is 344 interesting to note that other scope of diversity (node, link, SRLG 345 etc.) can still be applied inside the commonly shared domains. 347 3. PCEP Extensions 349 This section defines extensions to PCEP [RFC5440] to support the 350 H-PCE procedures. 352 3.1 Applicability to PCC-PCE Communications 354 Although the extensions defined in this document are intended 355 primarily for use between a child PCE and a parent PCE, they are 356 also applicable for communications between a PCC and its PCE. 358 Thus, the information that may be encoded in a PCReq can be sent 359 from a PCC towards the child PCE. This includes the RP object 360 (Section 3.3) and the Objective Function (OF) codes and objects 361 (Section 3.4). A PCC and a child PCE could also exchange the 362 capability (Section 3.2.1) during its session. 364 This allows a PCC to request paths that transit multiple 365 domains utilizing the capabilities defined in this document. 367 3.2. OPEN Object 369 Two new TLVs are defined in this document to be carried within an 370 OPEN object. This way, during the PCEP session establishment, the 371 H-PCE capability and Domain information can be advertised. 373 3.2.1. H-PCE Capability TLV 375 The H-PCE-CAPABILITY TLV is an optional TLV associated with the OPEN 376 Object [RFC5440] to exchange H-PCE capability of PCEP speakers. 378 Its format is shown in the following figure: 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type= TBD1 | Length=4 | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Flags |P| 386 +---------------------------------------------------------------+ 387 Figure 1: H-PCE-CAPABILITY TLV format 389 The type of the TLV is TBD1 (to be assigned by IANA), and it has a 390 fixed length of 4 octets. 392 The value comprises a single field - Flags (32 bits): 394 P (Parent PCE Request bit): if set, will signal that the child PCE 395 wishes to use the peer PCE as a parent PCE. 397 Unassigned bits MUST be set to 0 on transmission and MUST be ignored 398 on receipt. 400 The inclusion of this TLV in an OPEN object indicates that the H-PCE 401 extensions are supported by the PCEP speaker. The child PCE MUST 402 include this TLV and set the P flag. The parent PCE MUST include 403 this TLV and unset the P flag. 405 The setting of the P flag (parent PCE request bit) would mean that 406 the PCEP speaker wants the peer to be a parent PCE, so in the case 407 of a PCC to Child-PCE relationship, neither entity would set the P 408 flag. 410 If both peers attempt to set the P flag then the session 411 establishment MUST fail, and the PCEP speaker MUST respond with PCErr 412 message using Error-Type 1: "PCEP Session Establishment Failure" as 413 per [RFC5440]. 415 If the PCE understands the H-PCE path computation request but did not 416 advertise its H-PCE capability, it MUST send a PCErr message with 417 Error-Type=TBD8 ("H-PCE error") and Error-Value=1 ("Parent PCE 418 Capability not advertised"). 420 3.2.1.1 Backwards Compatibility 422 Section 7.1 of [RFC5440] requires that "Unrecognized TLVs MUST be 423 ignored. 425 That means that a PCE that does not support this document but that 426 receives an Open Message containing an Open Object that includes 427 an H-PCE-CAPABILITIES TLV will ignore that TLV and will continue to 428 attempt to establish a PCEP session. It will, however, not include 429 the TLV in the Open message that it sends, so the H-PCE relationship 430 will not be created. 432 If a PCE does not support the extensions defined in this document but 433 receives them in a PCEP message (notwithstanding the fact that the 434 session was not established as supporting a H-PCE relationship), the 435 receiving PCE will ignore the H-PCE related parameters because they 436 are all encoded in TLVs within standard PCEP objects. 438 3.2.2. Domain-ID TLV 440 The Domain-ID TLV, when used in the OPEN object, identifies the 441 domains served by the PCE. The child PCE uses this mechanism to 442 inform the domain information to the parent PCE. 444 The Domain-ID TLV is defined below: 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Type= TBD2 | Length | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Domain Type | Reserved | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | 454 // Domain ID // 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 2: Domain-ID TLV format 460 The type of the TLV is TBD2 (to be assigned by IANA), and it has a 461 variable Length of the value portion. The value part comprises of - 463 Domain Type (8 bits): Indicates the domain type. Four types of 464 domain are currently defined: 466 * Type=1: the Domain ID field carries a 2-byte AS number. Padded 467 with trailing zeros to a 4-byte boundary. 469 * Type=2: the Domain ID field carries a 4-byte AS number. 471 * Type=3: the Domain ID field carries a 4-byte OSPF area ID. 473 * Type=4: the Domain ID field carries (2-byte Area-Len, variable 474 length IS-IS area ID). Padded with trailing zeros to a 4-byte 475 boundary. 477 Reserved: Zero at transmission; ignored at the receipt. 479 Domain ID (variable): Indicates an IGP Area ID or AS number as 480 per the Domain Type field. It can be 2 bytes, 4 bytes or variable 481 length depending on the domain identifier used. It is padded with 482 trailing zeros to a 4-byte boundary. In case of IS-IS it includes 483 the Area-Len as well. 485 In the case a PCE serves more than one domain, multiple Domain-ID 486 TLVs are included for each domain it serves. 488 3.3. RP Object 490 3.3.1. H-PCE-FLAG TLV 492 The H-PCE-FLAG TLV is an optional TLV associated with the RP Object 493 [RFC5440] to indicate the H-PCE path computation request and options. 495 Its format is shown in the following figure: 497 0 1 2 3 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Type= TBD3 | Length=4 | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Flags |D|S| 503 +---------------------------------------------------------------+ 505 Figure 3: H-PCE-FLAG TLV format 507 The type of the TLV is TBD3 (to be assigned by IANA), and it has a 508 fixed length of 4 octets. 510 The value comprises a single field - Flags (32 bits): 512 S (Domain Sequence bit): if set, will signal that the child PCE 513 wishes to get only the domain sequence in the path computation 514 reply. Refer to Section 3.7 of [RFC7897] for details. 516 D (Disallow Domain Re-entry bit): if set, will signal that the 517 computed path does not enter a domain more than once. 519 Unassigned bits MUST be set to 0 on transmission and MUST be ignored 520 on receipt. 522 The presence of the TLV indicates that the H-PCE based path 523 computation is requested as per this document. 525 3.3.2. Domain-ID TLV 527 The usage of Domain-ID TLV, carried in an OPEN object, is used to 528 indicate a (list of) managed domains and is described in 529 Section 3.3.1. This TLV, when carried in an RP object, indicates the 530 destination domain ID. If a PCC knows the egress domain, it can 531 supply this information in the PCReq message. The format and 532 procedure of this TLV are defined in Section 3.2.2. 534 If a Domain-id TLV is used in the RP object, and the destination is 535 not actually in the indicated domain, then the parent 536 PCE should respond with a NO-PATH object and NO-PATH VECTOR TLV 537 should be used. A new bit number is assigned to indicate 538 "Destination not found in the indicated domain" (see Section 3.7). 540 3.4. Objective Functions 542 3.4.1. OF Codes 544 [RFC5541] defines a mechanism to specify an Objective Function that 545 is used by a PCE when it computes a path. Three new Objective 546 Functions are defined for H-PCE, these are: 548 o MTD 550 * Name: Minimize the number of Transit Domains (MTD) 552 * Objective Function Code - TBD4 (to be assigned by IANA) 554 * Description: Find a path P such that it passes through the 555 least number of transit domains. 557 * Objective functions are formulated using the following 558 terminology: 560 + A network comprises a set of N domains {Di, (i=1...N)}. 562 + A path P passes through K unique domains {Dpi,(i=1...K)}. 564 + Find a path P such that the value of K is minimized. 566 o MBN 568 * Name: Minimize the number of border nodes. 570 * Objective Function Code - TBD5 (to be assigned by IANA) 572 * Description: Find a path P such that it passes through the 573 least number of border nodes. 575 * Objective functions are formulated using the following 576 terminology: 578 + A network comprises a set of N links {Li, (i=1...N)}. 580 + A path P is a list of K links {Lpi,(i=1...K)}. 582 + D(Lpi) if a function that determines if the links Lpi 583 and Lpi+1 belong to different domains, D(Li) = 1 if link 584 Li and Li+1 belong to different domains, D(Lk) = 0 if 585 link Lk and Lk+1 belong to the same domain. 587 + The number of border node in a path P is denoted by B(P), 588 where B(P) = sum{D(Lpi),(i=1...K-1)}. 590 + Find a path P such that B(P) is minimized. 592 There is one objective function that applies to a set of 593 synchronized path computation requests to increase the domain 594 diversity: 596 o MCTD 598 * Name: Minimize the number of Common Transit Domains 600 * Objective Function Code - TBD13 (to be assigned by IANA) 602 * Description: Find a set of paths such that it passes through 603 the least number of common transit domains. 605 + A network comprises a set of N domains {Di, (i=1...N)}. 607 + A path P passes through K unique domains {Dpi,(i=1...K)}. 609 + A set of paths {P1...Pm} have L transit domains that are 610 common to more than one path {Dpi,(i=1...L)}. 612 + Find a set of paths such that the value of L is minimized. 614 3.4.2. OF Object 616 The OF (Objective Function) object [RFC5541] is carried within a 617 PCReq message so as to indicate the desired/required objective 618 function to be applied by the PCE during path computation. As per 619 Section 3.2 of [RFC5541] a single OF object may be included in a path 620 computation request. 622 The new OF codes described in Section 3.4.1 are applicable at the 623 inter-domain path computation performed by the parent PCE, it is 624 also necessary to specify the OF code that may be applied for the 625 intra-domain path computation performed by the child PCE. To 626 accommodate this, the OF-List TLV (described in Section 2.1. of 627 [RFC5541]) is included in the OF object as an optional TLV. 629 The OF-List TLV allows encoding of multiple OF codes. When this TLV 630 is included inside the OF object, only the first OF-code in the 631 OF-LIST TLV is considered. The parent PCE MUST use this OF code in 632 the OF object when sending the intra domain path computation request 633 to the child PCE. If the OF list TLV is included in the OF Object, 634 the OF Code inside the OF Object MUST include one of the H-PCE 635 Objective Functions defined in this document, the OF Code inside the 636 OF List TLV MUST NOT include an H-PCE Objective Function. If this 637 condition is not met, the PCEP speaker MUST respond with a PCErr 638 message with Error-Type=10 (Reception of an invalid object) and 639 Error-Value=TBD15 (Incompatible OF codes in H-PCE). 641 If the Objective Functions defined in this document are unknown or 642 unsupported by a PCE, then the procedure as defined in [RFC5541] 643 is followed. 645 3.5. Metric Object 647 The METRIC object is defined in Section 7.8 of [RFC5440], comprising 648 of metric-value, metric-type (T field) and flags. This document 649 defines the following types for the METRIC object for H-PCE: 651 o T=TBD6: Domain count metric (number of domains crossed); 653 o T=TBD7: Border Node count metric (number of border nodes crossed). 655 The domain count metric type of the METRIC object encodes the number 656 of domains crossed in the path. The border node count metric type of 657 the METRIC object encodes the number of border nodes in the path. If 658 a domain is re-entered, then domain should be double counted. 660 A PCC or child PCE MAY use the metric in a PCReq message for an 661 inter-domain path computation, meeting the number of domain or border 662 nodes crossing requirement. As per [RFC5440], in this case, the B bit 663 is set to suggest a bound (a maximum) for the metric that must not be 664 exceeded for the PCC to consider the computed path as acceptable. 666 A PCC or child PCE MAY also use this metric to ask the PCE to 667 optimize the metric during inter-domain path computation. In this 668 case, the B flag is cleared, and the C flag is set. 670 The Parent PCE MAY use the metric in a PCRep message along with a 671 NO-PATH object in the case where the PCE cannot compute a path 672 meeting this constraint. A PCE MAY also use this metric to send the 673 computed end to end metric value in a reply message. 675 3.6. SVEC Object 677 [RFC5440] defines SVEC object which includes flags for the potential 678 dependency between the set of path computation requests (Link, Node 679 and SRLG diverse). This document defines a new flag O for domain 680 diversity. 682 The following new bit is added to the Flags field: 684 o O (Domain diverse) bit - TBD14 : when set, this indicates that the 685 computed paths corresponding to the requests specified by the 686 following RP objects MUST NOT have any transit domains in 687 common. 689 The Domain Diverse O-bit can be used in Hierarchical PCE path 690 computation to compute synchronized domain diverse end to end path or 691 diverse domain sequences. 693 When domain diverse O bit is set, it is applied to the transit 694 domains. The other bit in SVEC object (N, L, S etc.) MAY be set and 695 MUST still be applied in the ingress and egress shared domain. 697 3.7. PCEP-ERROR Object 699 3.7.1. Hierarchy PCE Error-Type 701 A new PCEP Error-Type [RFC5440] is used for the H-PCE extension as 702 defined below: 704 +------------+-----------------------------------------+ 705 | Error-Type | Meaning | 706 +------------+-----------------------------------------+ 707 | TBD8 | H-PCE error | 708 | | Error-value=1: H-PCE capability | 709 | | was not advertised | 710 | | Error-value=2: parent PCE capability | 711 | | cannot be provided | 712 +------------+-----------------------------------------+ 714 Figure 4: H-PCE error 716 3.8. NO-PATH Object 718 To communicate the reason(s) for not being able to find a multi- 719 domain path or domain sequence, the NO-PATH object can be used in the 720 PCRep message. [RFC5440] defines the format of the NO-PATH object. 721 The object may contain a NO-PATH-VECTOR TLV to provide additional 722 information about why a path computation has failed. 724 Three new bit flags are defined to be carried in the Flags field in 725 the NO-PATH-VECTOR TLV carried in the NO-PATH Object. 727 o Bit number TBD9: When set, the parent PCE indicates that 728 destination domain unknown; 730 o Bit number TBD10: When set, the parent PCE indicates unresponsive 731 child PCE(s); 733 o Bit number TBD11: When set, the parent PCE indicates no available 734 resource available in one or more domains. 736 o Bit number TBD12: When set, the parent PCE indicates that 737 the destination is not found in the indicated domain. 739 4. H-PCE Procedures 741 The H-PCE path computation procedure is described in [RFC6805]. 743 4.1. OPEN Procedure between Child PCE and Parent PCE 745 If a child PCE wants to use the peer PCE as a parent, it MUST set the 746 P (parent PCE request flag) in the H-PCE-CAPABILITY TLV inside the 747 OPEN object carried in the Open message during the PCEP session 748 initialization procedure. 750 The child PCE MAY also report its list of domain IDs, to the parent 751 PCE, by specifying them in the Domain-ID TLVs in the OPEN object. 752 This object is carried in the OPEN message during the PCEP session 753 initialization procedure 755 The OF codes defined in this document can be carried in the OF-list 756 TLV of the OPEN object. If the OF-list TLV carries the OF codes, it 757 means that the PCE is capable of implementing the corresponding 758 objective functions. This information can be used for selecting a 759 proper parent PCE when a child PCE wants to get a path that satisfies 760 a certain Objective Function. 762 When a child PCE sends a PCReq to a peer PCE, which requires parental 763 activity and H-PCE capability flags TLV but which were not included 764 in the session establishment procedure described above, the peer PCE 765 should send a PCErr message to the child PCE and should specify the 766 error-type=TBD8 (H-PCE error) and error-value=1 (H-PCE capability was 767 not advertised) in the PCEP-ERROR object. 769 When a specific child PCE sends a PCReq to a peer PCE, that requires 770 parental activity and the peer PCE does not want to act as the parent 771 for it, the peer PCE should send a PCErr message to the child PCE and 772 specify the error-type=TBD8 (H-PCE error) and error-value=2 (Parent 773 PCE capability cannot be provided) in the PCEP-ERROR object. 775 4.2. Procedure to Obtain Domain Sequence 777 If a child PCE only wants to get the domain sequence for a multi- 778 domain path computation from a parent PCE, it can set the Domain Path 779 Request bit in the H-PCE-FLAG TLV in the RP object carried in a PCReq 780 message. The parent PCE which receives the PCReq message tries to 781 compute a domain sequence for it (instead of the E2E path). If the 782 domain path computation succeeds the parent PCE sends a PCRep message 783 which carries the domain sequence in the Explicit Route Object (ERO) 784 to the child PCE. Refer to [RFC7897] for more details about domain 785 sub-objects in the ERO. Otherwise, it sends a PCReq message which 786 carries the NO-PATH object to the child PCE. 788 5. Error Handling 790 A PCE that is capable of acting as a parent PCE might not be 791 configured or willing to act as the parent for a specific child PCE. 792 This fact could be determined when the child sends a PCReq that 793 requires parental activity, and could result in a negative response 794 in a PCEP Error (PCErr) message and indicate the hierarchy PCE error- 795 type=TBD8 (H-PCE error) and suitable error-value. (Section 3.7) 797 Additionally, the parent PCE may fail to find the multi-domain path 798 or domain sequence due to one or more of the following reasons: 800 o A child PCE cannot find a suitable path to the egress; 802 o The parent PCE does not hear from a child PCE for a specified 803 time; 805 o The Objective Functions specified in the path request cannot be 806 met. 808 In this case, the parent PCE MAY need to send a negative path 809 computation reply specifying the reason. This can be achieved by 810 including NO-PATH object in the PCRep message. Extension to NO-PATH 811 object is needed to include the aforementioned reasons described in 812 Section 3.7. 814 6. Manageability Considerations 816 General PCE and PCEP management considerations are discussed in 817 [RFC4655] and [RFC5440]. There are additional management 818 considerations for H-PCE which are described in [RFC6805], and 819 repeated in this section. 821 The administrative entity responsible for the management of the 822 parent PCEs must be determined for the following cases: 824 o multi-domains (e.g., IGP areas or multiple ASes) within a single 825 service provider network, the management responsibility for the 826 parent PCE would most likely be handled by the service provider, 828 o multiple ASes within different service provider networks, it may 829 be necessary for a third party to manage the parent PCEs according 830 to commercial and policy agreements from each of the participating 831 service providers. 833 6.1. Control of Function and Policy 835 Control and function will need to be carefully managed in an H-PCE 836 network. A child PCE will need to be configured with the address of 837 its parent PCE. It is expected that there will only be one or two 838 parents of any child. 840 The parent PCE also needs to be aware of the child PCEs for all child 841 domains that it can see. This information is most likely to be 842 configured (as part of the administrative definition of each domain). 844 Discovery of the relationships between parent PCEs and child PCEs 845 do not form part of the hierarchical PCE architecture. Mechanisms 846 that rely on advertising or querying PCE locations across domain or 847 provider boundaries are undesirable for security, scaling, 848 commercial, and confidentiality reasons. The specific behaviour of 849 the child and parent PCE are described in the following sub-sections. 851 6.1.1. Child PCE 853 Support of the hierarchical procedure will be controlled by the 854 management organization responsible for each child PCE. A child PCE 855 must be configured with the address of its parent PCE in order for it 856 to interact with its parent PCE. The child PCE must also be 857 authorized to peer with the parent PCE. 859 6.1.2. Parent PCE 861 The parent PCE must only accept path computation requests from 862 authorized child PCEs. If a parent PCE receives requests from an 863 unauthorized child PCE, the request should be dropped. This means 864 that a parent PCE must be configured with the identities and security 865 credentials of all of its child PCEs, or there must be some form of 866 shared secret that allows an unknown child PCE to be authorized by 867 the parent PCE. 869 6.1.3. Policy Control 871 It may be necessary to maintain a policy module on the parent PCE 872 [RFC5394]. This would allow the parent PCE to apply commercially 873 relevant constraints such as SLAs, security, peering preferences, and 874 monetary costs. 876 It may also be necessary for the parent PCE to limit the 877 end-to-end path selection by including or excluding specific domains 878 based on commercial relationships, security implications, and 879 reliability. 881 6.2. Information and Data Models 883 A MIB module for PCEP was published as RFC 7420 [RFC7420] that 884 describes managed objects for modelling of PCEP communication. A 885 YANG module for PCEP has also been proposed [I-D.ietf-pce-pcep-yang]. 887 Aditionally, H-PCE MIB module, or additional data model, will be 888 required to report parent PCE and child PCE information, including: 890 o parent PCE configuration and status, 892 o child PCE configuration and information, 894 o notifications to indicate session changes between parent PCEs and 895 child PCEs, and 897 o notification of parent PCE TED updates and changes. 899 6.3. Liveness Detection and Monitoring 901 The hierarchical procedure requires interaction with multiple PCEs. 902 Once a child PCE requests an end-to-end path, a sequence of events 903 occurs that requires interaction between the parent PCE and each 904 child PCE. If a child PCE is not operational, and an alternate 905 transit domain is not available, then the failure must be reported. 907 6.4. Verify Correct Operations 909 Verifying the correct operation of a parent PCE can be performed by 910 monitoring a set of parameters. The parent PCE implementation should 911 provide the following parameters monitored at the parent PCE: 913 o number of child PCE requests, 914 o number of successful hierarchical PCE procedures completions on a 915 per-PCE-peer basis, 917 o number of hierarchical PCE procedure completion failures on a per- 918 PCE-peer basis, and 920 o number of hierarchical PCE procedure requests from unauthorized 921 child PCEs. 923 6.5. Requirements On Other Protocols 925 Mechanisms defined in this document do not imply any new requirements 926 on other protocols. 928 6.6. Impact On Network Operations 930 The hierarchical PCE procedure is a multiple-PCE path computation 931 scheme. Subsequent requests to and from the child and parent PCEs do 932 not differ from other path computation requests and should not have 933 any significant impact on network operations. 935 7. IANA Considerations 937 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 938 registry. This document requests IANA actions to allocate code 939 points for the protocol elements defined in this document. 941 7.1. PCEP TLV Type Indicators 943 IANA Manages the PCEP TLV code point registry (see [RFC5440]). This 944 is maintained as the "PCEP TLV Type Indicators" sub-registry of the 945 "Path Computation Element Protocol (PCEP) Numbers" registry. 947 This document defines three new PCEP TLVs. IANA is requested to make 948 the following allocation: 950 Type TLV name References 951 ----------------------------------------------- 952 TBD1 H-PCE-CAPABILITY TLV This I-D 953 TBD2 Domain-ID TLV This I-D 954 TBD3 H-PCE-FLAG TLV This I-D 956 7.2. H-PCE-CAPABILITY TLV Flags 958 This document requests that a new sub-registry, named "H-PCE- 959 CAPABILITY TLV Flag Field", is created within the "Path Computation 960 Element Protocol (PCEP) Numbers" registry to manage the Flag field in 961 the H-PCE-CAPABILITY TLV of the PCEP OPEN object. 963 New values are to be assigned by Standards Action [RFC8126]. Each 964 bit should be tracked with the following qualities: 966 o Bit number (counting from bit 0 as the most significant bit) 968 o Capability description 970 o Defining RFC 972 The following values are defined in this document: 974 Bit Description Reference 975 -------------------------------------------------- 976 31 P (Parent PCE Request bit) This I.D. 978 7.3. Domain-ID TLV Domain type 980 This document requests that a new sub-registry, named "Domain-ID TLV 981 Domain type", is created within the "Path Computation Element 982 Protocol (PCEP) Numbers" registry to manage the Domain-Type field of 983 the Domain-ID TLV. The allocation policy for this new sub-registry is 984 IETF Review [RFC8126]. 986 Value Meaning 987 ----------------------------------------------- 988 1 2-byte AS number 989 2 4-byte AS number 990 3 4-byte OSPF area ID 991 4 Variable length IS-IS area ID 993 7.4. H-PCE-FLAG TLV Flags 995 This document requests that a new sub-registry, named "H-PCE-FLAGS 996 TLV Flag Field", is created within the "Path Computation Element 997 Protocol (PCEP) Numbers" registry to manage the Flag field in the H- 998 PCE-FLAGS TLV of the PCEP RP object. New values are to be assigned 999 by Standards Action [RFC8126]. Each bit should be tracked with the 1000 following qualities: 1002 o Bit number (counting from bit 0 as the most significant bit) 1004 o Capability description 1006 o Defining RFC 1007 The following values are defined in this document: 1009 Bit Description Reference 1010 ----------------------------------------------- 1011 31 S (Domain This I.D. 1012 Sequence bit) 1013 30 D (Disallow Domain This I.D. 1014 Re-entry bit) 1016 7.5. OF Codes 1018 IANA maintains a registry of Objective Function (described in 1019 [RFC5541]) at the sub-registry "Objective Function". Three new 1020 Objective Functions have been defined in this document. 1022 IANA is requested to make the following allocations: 1024 Code 1025 Point Name Reference 1026 ------------------------------------------------------ 1027 TBD4 Minimum number of Transit This I.D. 1028 Domains (MTD) 1029 TBD5 Minimize number of Border This I.D. 1030 Nodes (MBN) 1031 TBD13 Minimize the number of This I.D. 1032 Common Transit Domains 1033 (MCTD) 1035 7.6. METRIC Types 1037 IANA maintains one sub-registry for "METRIC object T field". Two new 1038 metric types are defined in this document for the METRIC object 1039 (specified in [RFC5440]). 1041 IANA is requested to make the following allocations: 1043 Value Description Reference 1044 ---------------------------------------------------------- 1045 TBD6 Domain Count metric This I.D. 1046 TBD7 Border Node Count metric This I.D. 1048 7.7. New PCEP Error-Types and Values 1050 IANA maintains a registry of Error-Types and Error-values for use in 1051 PCEP messages. This is maintained as the "PCEP-ERROR Object Error 1052 Types and Values" sub-registry of the "Path Computation Element 1053 Protocol (PCEP) Numbers" registry. 1055 IANA is requested to make the following allocations: 1057 Error-Type Meaning and error values Reference 1058 ------------------------------------------------------ 1059 TBD8 H-PCE Error This I.D. 1061 Error-value=1 H-PCE 1062 Capability not advertised 1064 Error-value=2 Parent PCE 1065 Capability cannot be provided 1067 10 Reception of an invalid object [RFC5440] 1069 Error-value=TBD15: Incompatible This I.D. 1070 OF codes in H-PCE 1072 7.8. New NO-PATH-VECTOR TLV Bit Flag 1074 IANA maintains a sub-registry "NO-PATH-VECTOR TLV Flag Field" of 1075 bit flags carried in the PCEP NO-PATH-VECTOR TLV in the PCEP NO-PATH 1076 object as defined in [RFC5440]. IANA is requested to assign three 1077 new bit flag as follows: 1079 Bit Number Name Flag Reference 1080 ------------------------------------------------------ 1081 TBD9 Destination Domain unknown This I.D. 1082 TBD10 Unresponsive child PCE(s) This I.D. 1083 TBD11 No available resource in This I.D. 1084 one or more domain 1085 TBD12 Destination is not found This I.D. 1086 in the indicated domain. 1088 7.9. SVEC Flag 1090 IANA maintains a sub-registry "SVEC Object Flag Field" of bit flags 1091 carried in the PCEP SVEC object as defined in [RFC5440]. IANA is 1092 requested to assign one new bit flag as follows: 1094 Bit Number Name Flag Reference 1095 ------------------------------------------------------ 1096 TBD14 Domain Diverse This I.D. 1098 8. Security Considerations 1100 The hierarchical PCE procedure relies on PCEP and inherits the 1101 security requirements defined in [RFC5440]. As PCEP operates over 1102 TCP, it may also make use of TCP security mechanisms, such as TCP 1103 Authentication Option (TCP-AO) [RFC5925] or Transport Layer 1104 Security (TLS) [RFC8253]. 1106 Any multi-domain operation necessarily involves the exchange of 1107 information across domain boundaries. This may represent a 1108 significant security and confidentiality risk especially when the 1109 child domains are controlled by different commercial concerns. PCEP 1110 allows individual PCEs to maintain the confidentiality of their 1111 domain path information using path-keys [RFC5520], and the H-PCE 1112 architecture is specifically designed to enable as much isolation of 1113 domain topology and capabilities information as is possible. 1115 For further considerations of the security issues related to inter-AS 1116 path computation, see [RFC5376]. 1118 9. Contributing Authors 1120 Xian Zhang 1121 Huawei 1122 EMail: zhang.xian@huawei.com 1124 Dhruv Dhody 1125 Huawei Technologies 1126 Divyashree Techno Park, Whitefield 1127 Bangalore, Karnataka 560066 1128 India 1130 EMail: dhruv.ietf@gmail.com 1132 10.Acknowledgements 1134 The authors would like to thank Mike McBride for his detailed review, 1135 comments and suggestions which helped improve this document. 1137 11. References 1139 11.1. Normative References 1141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1142 Requirement Levels", BCP 14, RFC 2119, 1143 DOI 10.17487/RFC2119, March 1997, 1144 . 1146 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1147 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1148 DOI 10.17487/RFC5440, March 2009, 1149 . 1151 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1152 Objective Functions in the Path Computation Element 1153 Communication Protocol (PCEP)", RFC 5541, 1154 DOI 10.17487/RFC5541, June 2009, 1155 . 1157 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1158 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1159 May 2017, . 1161 11.2. Informative References 1163 [RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. Boyle, Ed., 1164 "Requirements for Inter-Area MPLS Traffic Engineering", 1165 RFC 4105, DOI 10.17487/RFC4105, June 2005, 1166 . 1168 [RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous 1169 System (AS) Traffic Engineering (TE) Requirements", 1170 RFC 4216, DOI 10.17487/RFC4216, November 2005, 1171 . 1173 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1174 Element (PCE)-Based Architecture", RFC 4655, 1175 DOI 10.17487/RFC4655, August 2006, 1176 . 1178 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 1179 Inter-Domain Multiprotocol Label Switching Traffic 1180 Engineering", RFC 4726, DOI 10.17487/RFC4726, November 1181 2006, . 1183 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 1184 Per-Domain Path Computation Method for Establishing Inter- 1185 Domain Traffic Engineering (TE) Label Switched Paths 1186 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 1187 . 1189 [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS 1190 Requirements for the Path Computation Element 1191 Communication Protocol (PCECP)", RFC 5376, 1192 DOI 10.17487/RFC5376, November 2008, 1193 . 1195 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 1196 "Policy-Enabled Path Computation Framework", RFC 5394, 1197 DOI 10.17487/RFC5394, December 2008, 1198 . 1200 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1201 "Preserving Topology Confidentiality in Inter-Domain Path 1202 Computation Using a Path-Key-Based Mechanism", RFC 5520, 1203 DOI 10.17487/RFC5520, April 2009, 1204 . 1206 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 1207 "A Backward-Recursive PCE-Based Computation (BRPC) 1208 Procedure to Compute Shortest Constrained Inter-Domain 1209 Traffic Engineering Label Switched Paths", RFC 5441, 1210 DOI 10.17487/RFC5441, April 2009, 1211 . 1213 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1214 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1215 June 2010, . 1217 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1218 Path Computation Element Architecture to the Determination 1219 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1220 DOI 10.17487/RFC6805, November 2012, 1221 . 1223 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1224 Computation Element Architecture", RFC 7399, 1225 DOI 10.17487/RFC7399, October 2014, 1226 . 1228 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1229 Hardwick, "Path Computation Element Communication Protocol 1230 (PCEP) Management Information Base (MIB) Module", 1231 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1232 . 1234 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1235 S. Ray, "North-Bound Distribution of Link-State and 1236 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1237 DOI 10.17487/RFC7752, March 2016, 1238 . 1240 [RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects 1241 for the Path Computation Element Communication Protocol 1242 (PCEP)", RFC 7897, DOI 10.17487/RFC7897, June 2016, 1243 . 1245 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1246 Writing an IANA Considerations Section in RFCs", BCP 26, 1247 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1248 . 1250 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1251 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1252 Path Computation Element Communication Protocol (PCEP)", 1253 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1254 . 1256 [I-D.ietf-pce-pcep-yang] 1257 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1258 YANG Data Model for Path Computation Element 1259 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1260 yang-09 (work in progress), October 2018. 1262 [I-D.ietf-pce-stateful-hpce] 1263 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 1264 and O. Dios, "Hierarchical Stateful Path Computation 1265 Element (PCE).", draft-ietf-pce-stateful-hpce-06 (work in 1266 progress), June 2018. 1268 Authors' Addresses 1270 Fatai Zhang 1271 Huawei 1272 Huawei Base, Bantian, Longgang District 1273 Shenzhen 518129 1274 China 1276 EMail: zhangfatai@huawei.com 1278 Quintin Zhao 1279 Huawei 1280 125 Nagog Technology Park 1281 Acton, MA 01719 1282 USA 1284 EMail: quintin.zhao@huawei.com 1286 Oscar Gonzalez de Dios 1287 Telefonica I+D 1288 Don Ramon de la Cruz 82-84 1289 Madrid 28045 1290 Spain 1292 EMail: ogondio@tid.es 1294 Ramon Casellas 1295 CTTC 1296 Av. Carl Friedrich Gauss n.7 1297 Barcelona, Castelldefels 1298 Spain 1300 EMail: ramon.casellas@cttc.es 1302 Daniel King 1303 Old Dog Consulting 1304 UK 1306 EMail: daniel@olddog.co.uk 1308 Appendix 1310 A1. Implementation Status 1312 The H-PCE architecture and protocol procedures describe in this I-D 1313 were implemented and tested for a variety of optical research 1314 applications. 1316 The Appendix should be removed before publication. 1318 A1.1. Inter-layer traffic engineering with H-PCE 1320 This work was led by: 1322 o Ramon Casellas [ramon.casellas@cttc.es] 1324 o Centre Tecnologic de Telecomunicacions de Catalunya (CTTC) 1326 The H-PCE instances (parent and child) were multi-threaded 1327 asynchronous processes. Implemented in C++11, using C++ Boost 1328 Libraries. The targeted system used to deploy and run H-PCE 1329 applications was a POSIX system (Debian GNU/Linux operating system). 1331 Some parts of the software may require a Linux Kernel, the 1332 availability of a Routing Controller running collocated in the same 1333 host and the usage of libnetfilter / libipq and GNU/Linux firewalling 1334 capabilities. Most of the functionality, including algorithms is 1335 done by means of plugins (e.g., as shared libraries or .so files in 1336 Unix systems). 1338 The CTTC PCE supports the H-PCE architecture, but also supports 1339 stateful PCE with active capabilities, as an OpenFlow controller, and 1340 has dedicated plugins to support monitoring, BRPC, P2MP, path keys, 1341 back end PCEs. Management of the H-PCE entities was supported via 1342 HTTP and CLI via Telnet. 1344 Further details of the H-PCE prototyping and experimentation can be 1345 found in the following scientific papers: 1347 R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I. 1348 Morita, "Inter-layer traffic engineering with hierarchical-PCE in 1349 MPLS-TP over wavelength switched optical networks" , Optics 1350 Express, Vol. 20, No. 28, December 2012. 1352 R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I. 1353 Morita, M. Msurusawa, "Dynamic virtual link mesh topology 1354 aggregation in multi-domain translucent WSON with hierarchical- 1355 PCE", Optics Express Journal, Vol. 19, No. 26, December 2011. 1357 R. Casellas, R. Munoz, R. Martinez, R. Vilalta, L. Liu, T. 1358 Tsuritani, I. Morita, V. Lopez, O. Gonzalez de Dios, J. P. 1359 Fernandez-Palacios, "SDN based Provisioning Orchestration of 1360 OpenFlow/GMPLS Flexi-grid Networks with a Stateful Hierarchical 1361 PCE", in Proceedings of Optical Fiber Communication Conference and 1362 Exposition (OFC), 9-13 March, 2014, San Francisco (EEUU). 1363 Extended Version to appear in Journal Of Optical Communications 1364 and Networking January 2015 1366 F. Paolucci, O. Gonzalez de Dios, R. Casellas, S. Duhovnikov, 1367 P. Castoldi, R. Munoz, R. Martinez, "Experimenting Hierarchical 1368 PCE Architecture in a Distributed Multi-Platform Control Plane 1369 Testbed" , in Proceedings of Optical Fiber Communication 1370 Conference and Exposition (OFC) and The National Fiber Optic 1371 Engineers Conference (NFOEC), 4-8 March, 2012, Los Angeles, 1372 California (USA). 1374 R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I. 1375 Morita, M. Tsurusawa, "Dynamic Virtual Link Mesh Topology 1376 Aggregation in Multi-Domain Translucent WSON with Hierarchical- 1377 PCE", in Proceedings of 37th European Conference and Exhibition on 1378 Optical Communication (ECOC 2011), 18-22 September 2011, Geneve ( 1379 Switzerland). 1381 R. Casellas, R. Munoz, R. Martinez, "Lab Trial of Multi-Domain 1382 Path Computation in GMPLS Controlled WSON Using a Hierarchical 1383 PCE", in Proceedings of OFC/NFOEC Conference (OFC2011), 10 March 1384 2011, Los Angeles (USA). 1386 A1.2. Telefonica Netphony (Open Source PCE) 1388 The Telefonica Netphony PCE is an open source Java-based 1389 implementation of a Path Computation Element, with several flavours, 1390 and a Path Computation Client. The PCE follows a modular 1391 architecture and allows to add customized algorithms. The PCE has 1392 also stateful and remote initiation capabilities. In current 1393 version, three components can be built, a domain PCE (aka child PCE), 1394 a parent PCE (ready for the H-PCE architecture) and a PCC (path 1395 computation client). 1397 This work was led by: 1399 o Oscar Gonzalez de Dios [oscar.gonzalezdedios@telefonica.com] 1401 o Victor Lopez Alvarez [victor.lopezalvarez@telefonica.com] 1403 o Telefonica I+D, Madrid, Spain 1405 The PCE code is publicly available in a GitHub repository: 1407 o https://github.com/telefonicaid/netphony-pce 1409 The PCEP protocol encodings are located in the following repository: 1411 o https://github.com/telefonicaid/netphony-network protocols 1413 The traffic engineering database and a BGP-LS speaker to fill the 1414 database is located in: 1416 o https://github.com/telefonicaid/netphony-topology 1418 The parent and child PCE are multi-threaded java applications. The 1419 path computation uses the jgrapht free Java class library (0.9.1) 1420 that provides mathematical graph-theory objects and algorithms. 1421 Current version of netphony PCE runs on java 1.7 and 1.8, and has 1422 been tested in GNU/Linux, Mac OS-X and Windows environments. The 1423 management of the parent and domain PCEs is supported though CLI via 1424 Telnet, and configured via XML files. 1426 Further details of the netphony H-PCE prototyping and experimentation 1427 can be found in the following research papers: 1429 o O. Gonzalez de Dios, R. Casellas, F. Paolucci, A. Napoli, L. 1430 Gifre, A. Dupas, E, Hugues-Salas, R. Morro, S. Belotti, G. 1431 Meloni, T. Rahman, V.P Lopez, R. Martinez, F. Fresi, M. Bohn, 1432 S. Yan, L. Velasco, . Layec and J. P. Fernandez-Palacios: 1433 Experimental Demonstration of Multivendor and Multidomain EON With 1434 Data and Control Interoperability Over a Pan-European Test Bed, in 1435 Journal of Lightwave Technology, Dec. 2016, Vol. 34, Issue 7, pp. 1436 1610-1617. 1438 o O. Gonzalez de Dios, R. Casellas, R. Morro, F. Paolucci, V. 1439 Lopez, R. Martinez, R. Munoz, R. Villalta, P. Castoldi: 1440 "Multi-partner Demonstration of BGP-LS enabled multi-domain EON, 1441 in Journal of Optical Communications and Networking, Dec. 2015, 1442 Vol. 7, Issue 12, pp. B153-B162. 1444 o F. Paolucci, O. Gonzalez de Dios, R. Casellas, S. Duhovnikov, 1445 P. Castoldi, R. Munoz, R. Martinez, "Experimenting Hierarchical 1446 PCE Architecture in a Distributed Multi-Platform Control Plane 1447 Testbed" , in Proceedings of Optical Fiber Communication 1448 Conference and Exposition (OFC) and The National Fiber Optic 1449 Engineers Conference (NFOEC), 4-8 March, 2012, Los Angeles, 1450 California (USA). 1452 A1.3. H-PCE Proof of Concept developed by Huawei 1454 Huawei developed this H-PCE on the Huawei Versatile Routing Platform 1455 (VRP) to experiment with the hierarchy of PCE. Both end to end path 1456 computation as well as computation for domain-sequence are supported. 1458 This work was led by: 1460 o Udayasree Pallee [udayasreereddy@gmail.com] 1462 o Dhruv Dhody [dhruv.ietf@gmail.com] 1464 o Huawei Technologies, Bangalore, India 1466 Further work on stateful H-PCE [I-D.ietf-pce-stateful-hpce] is being 1467 carried out on ONOS.