idnits 2.17.1 draft-ietf-pce-hierarchy-extensions-06.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 (November 5, 2018) is 1999 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 5226 (Obsoleted by RFC 8126) -- 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 (==), 3 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: May 6, 2019 O. Gonzalez de Dios 6 Telefonica I+D 7 R. Casellas 8 CTTC 9 D. King 10 Old Dog Consulting 11 November 5, 2018 13 Extensions to Path Computation Element Communication Protocol (PCEP) for 14 Hierarchical Path Computation Elements (PCE) 15 draft-ietf-pce-hierarchy-extensions-06 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 May 6, 2019. 45 Copyright Notice 47 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . .3 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 . . . . . . . . . . . . . . . .5 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 . . . . . . . . . . .6 72 2.3. PCE Domain Identification . . . . . . . . . . . . . . . .7 73 2.4. Domain Diversity . . . . . . . . . . . . . . . . . . . .7 74 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . .7 75 3.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . .8 76 3.1.1. H-PCE Capability TLV . . . . . . . . . . . . . . . .8 77 3.1.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .9 78 3.2. RP Object . . . . . . . . . . . . . . . . . . . . . . . .10 79 3.2.1. H-PCE-FLAG TLV . . . . . . . . . . . . . . . . . . .10 80 3.2.2. Domain-ID TLV . . . . . . . . . . . . . . . . . . . .10 81 3.3. Objective Functions . . . . . . . . . . . . . . . . . . .11 82 3.3.1. OF Codes . . . . . . . . . . . . . . . . . . . . . .11 83 3.3.2. OF Object . . . . . . . . . . . . . . . . . . . . . .12 84 3.4. Metric Object . . . . . . . . . . . . . . . . . . . . . .13 85 3.5. SVEC Object . . . . . . . . . . . . . . . . . . . . . . .13 86 3.6. PCEP-ERROR object . . . . . . . . . . . . . . . . . . . .14 87 3.6.1. Hierarchy PCE Error-Type . . . . . . . . . . . . . .14 88 3.7. NO-PATH Object . . . . . . . . . . . . . . . . . . . . .14 89 4. H-PCE Procedures . . . . . . . . . . . . . . . . . . . . . .15 90 4.1. OPEN Procedure between Child PCE and Parent PCE . . . . .15 91 4.2. Procedure to Obtain Domain Sequence . . . . . . . . . . .16 92 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . .16 93 6. Manageability Considerations . . . . . . . . . . . . . . . .16 94 6.1. Control of Function and Policy . . . . . . . . . . . . .17 95 6.1.1. Child PCE . . . . . . . . . . . . . . . . . . . . . .17 96 6.1.2. Parent PCE . . . . . . . . . . . . . . . . . . . . .17 97 6.1.3. Policy Control . . . . . . . . . . . . . . . . . . .17 98 6.2. Information and Data Models . . . . . . . . . . . . . . .18 99 6.3. Liveness Detection and Monitoring . . . . . . . . . . . .18 100 6.4. Verify Correct Operations . . . . . . . . . . . . . . . .18 101 6.5. Requirements On Other Protocols . . . . . . . . . . . . .19 102 6.6. Impact On Network Operations . . . . . . . . . . . . . .19 103 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .19 104 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . .19 105 7.2. H-PCE-CAPABILITY TLV Flags . . . . . . . . . . . . . . .19 106 7.3. Domain-ID TLV Domain type . . . . . . . . . . . . . . . .20 107 7.4. H-PCE-FLAG TLV Flags . . . . . . . . . . . . . . . . . .21 108 7.5. OF Codes . . . . . . . . . . . . . . . . . . . . . . . .21 109 7.6. METRIC Types . . . . . . . . . . . . . . . . . . . . . .21 110 7.7. New PCEP Error-Types and Values . . . . . . . . . . . . .22 111 7.8. New NO-PATH-VECTOR TLV Bit Flag . . . . . . . . . . . . .22 112 7.9. SVEC Flag . . . . . . . . . . . . . . . . . . . . . . . .22 113 7.10. NO-PATH VECTOR TLV Bit Flag. . . . . . . . . . . . . . .22 114 8. Security Considerations . . . . . . . . . . . . . . . . . . .22 115 9. Contributing Authors. . . . . . . . . . . . . . . . . . . . .23 116 10. References . . . . . . . . . . . . . . . . . . . . . . . . .23 117 10.1. Normative References . . . . . . . . . . . . . . . . . .23 118 10.2. Informative References . . . . . . . . . . . . . . . . .24 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .27 120 A1. Implementation Status . . . . . . . . . . . . . . . . . . .28 121 A1.1. Inter-layer traffic engineering with H-PCE . . . . . . .28 122 A1.2. Telefonica Netphony (Open Source PCE) . . . . . . . . .30 123 A1.3. Implementation 3: H-PCE Proof of Concept developed by 124 Huawei . . . . . . . . . . . . . . . . . . . . . . . . .31 126 1. Introduction 128 The Path Computation Element communication Protocol (PCEP) provides 129 a mechanism for Path Computation Elements (PCEs) and Path Computation 130 Clients (PCCs) to exchange requests for path computation and 131 responses that provide computed paths. 133 The capability to compute the routes of end-to-end inter-domain MPLS 134 Traffic Engineering (MPLS-TE) and GMPLS Label Switched Paths (LSPs) 135 is expressed as requirements in [RFC4105] and [RFC4216]. This 136 capability may be realized by a PCE [RFC4655]. The methods for 137 establishing and controlling inter-domain MPLS-TE and GMPLS LSPs are 138 documented in [RFC4726]. 140 [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can 141 be used for computing end-to-end paths for inter-domain MPLS Traffic 142 Engineering (TE) and GMPLS Label Switched Paths (LSPs). 144 Within the hierarchical PCE architecture, the parent PCE is used to 145 compute a multi-domain path based on the domain connectivity 146 information . A child PCE may be responsible for a single domain or 147 multiple domains, it is used to compute the intra-domain path based 148 on its own domain topology information. 150 The H-PCE end-to-end domain path computation procedure is described 151 below: 153 o A path computation client (PCC) sends the inter-domain path 154 computation requests to the child PCE responsible for its domain; 156 o The child PCE forwards the request to the parent PCE; 158 o The parent PCE computes the likely domain paths from the ingress 159 domain to the egress domain; 161 o The parent PCE sends the intra-domain path computation requests 162 (between the domain border nodes) to the child PCEs which are 163 responsible for the domains along the domain path; 165 o The child PCEs return the intra-domain paths to the parent PCE; 167 o The parent PCE constructs the end-to-end inter-domain path based 168 on the intra-domain paths; 170 o The parent PCE returns the inter-domain path to the child PCE; 172 o The child PCE forwards the inter-domain path to the PCC. 174 In addition, the parent PCE may be requested to provide only the 175 sequence of domains to a child PCE so that alternative inter-domain 176 path computation procedures, including Per Domain (PD) [RFC5152] and 177 Backwards Recursive Path Computation (BRPC) [RFC5441] may be used. 179 This document defines the PCEP extensions for the purpose of 180 implementing Hierarchical PCE procedures, which are described in 181 [RFC6805]. 183 1.1. Scope 185 The following functions are out of scope of this document. 187 o Determination of Destination Domain (section 4.5 of [RFC6805]) 189 * via a collection of reachability information from child domain; 191 * via requests to the child PCEs to discover if they contain the 192 destination node; 194 * or any other methods. 196 o Parent Traffic Engineering Database (TED) methods (section 4.4 of 197 [RFC6805]) 199 o Learning of Domain connectivity and boundary nodes (BN) addresses. 201 o Stateful PCE Operations. (Refer [I-D.ietf-pce-stateful-hpce]) 203 The hierarchical relationship model is described in [RFC6805]. It is 204 applicable to environments with small groups of domains where 205 visibility from the ingress LSRs is limited. As highlighted in 206 [RFC7399] applying the hierarchical PCE model to large groups of 207 domains such as the Internet is not considered feasible or desirable. 209 1.2. Terminology 211 This document uses the terminology defined in [RFC4655], [RFC5440] 212 and the additional terms defined in section 1.4 of [RFC6805]. 214 1.3. Requirements Language 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 218 "OPTIONAL" in this document are to be interpreted as described in BCP 219 14 [RFC2119] [RFC8174] when, and only when, they appear in all 220 capitals, as shown here. 222 2. Requirements for H-PCE 224 This section compiles the set of requirements of the PCEP protocol to 225 support the H-PCE architecture and procedures. 227 [RFC6805] identifies high-level requirements of PCEP extensions 228 required to support the hierarchical PCE model. 230 2.1. Path Computation Request 232 The Path Computation Request (PCReq) messages are used by a PCC or 233 PCE to make a path computation request to a PCE. In order to achieve 234 the full functionality of the H-PCE procedures, the PCReq message 235 needs to include: 237 o Qualification of PCE Requests; 239 o Multi-domain Objective Functions (OF); 241 o Multi-domain Metrics. 243 2.1.1. Qualification of PCEP Requests 245 As described in section 4.8.1 of [RFC6805], the H-PCE architecture 246 introduces new request qualifications, which are: 248 o It MUST be possible for a child PCE to indicate that a path 249 computation request sent to a parent PCE should be satisfied by a 250 domain sequence only, that is, not by a full end-to-end path. 251 This allows the child PCE to initiate a per-domain (PD) [RFC5152] 252 or a backward recursive path computation (BRPC) [RFC5441]. 254 o As stated in [RFC6805], section 4.5, if a PCC knows the egress 255 domain, it can supply this information as the path computation 256 request. It SHOULD be possible to specify the destination domain 257 information in a PCEP request, if it is known. 259 o It MAY be possible to indicate that the inter domain path computed 260 by parent PCE should disallow domain re-entry. 262 2.1.2. Multi-domain Objective Functions 264 For H-PCE inter-domain path computation, there is three new Objective 265 Functions defined in this document: 267 o Minimize the number of Transit Domains (MTD) 268 o Minimize the number of border nodes (MBN) 269 o Minimize the number of Common Transit Domains (MCTD) 271 The PCC may specify the multi-domain Objective Function code to 272 use when requesting inter-domain path computation, it may also 273 include intra-domain OFs, such as Minimum Cost Path (MCP) [RFC5441], 274 which must be considered by participating child PCEs 276 2.1.3. Multi-domain Metrics 278 For inter-domain path computation, there are several path metrics of 279 interest. 281 o Domain count (number of domains crossed); 283 o Border Node count. 285 A PCC may be able to limit the number of domains crossed by applying 286 a limit on these metrics. Details in Section 3.4. 288 2.2. Parent PCE Capability Advertisement 290 Parent and child PCE relationships are likely to be configured. 292 However, as mentioned in [RFC6805], it would assist network operators 293 if the child and parent PCEs could indicate their H-PCE capabilities. 295 During the PCEP session establishment procedure, the child PCE needs 296 to be capable of indicating to the parent PCE whether it requests the 297 parent PCE capability or not. Also, during the PCEP session 298 establishment procedure, the parent PCE needs to be capable of 299 indicating whether its parent capability can be provided or not. 301 A PCEP Speaker (Parent PCE or Child PCE or PCC) includes the "H-PCE 302 Capability" TLV, described in Section 3.1.1, in the OPEN Object to 303 advertise its support for PCEP extensions for H-PCE Capability. 305 2.3. PCE Domain Identification 307 A PCE domain is a single domain with an associated PCE. Although it 308 is possible for a PCE to manage multiple domains simultaneously. The 309 PCE domain could be an IGP area or AS. 311 The PCE domain identifiers MAY be provided during the PCEP session 312 establishment procedure. 314 2.4. Domain Diversity 316 In a multi-domain environment, Domain Diversity is defined in 317 [RFC6805]. A pair of paths are domain-diverse if they do not 318 traverse any of the same transit domains. Domain diversity may be 319 maximized for a pair of paths by selecting paths that have the 320 smallest number of shared domains. Path computation should 321 facilitate the selection of domain diverse paths as a way to reduce 322 the risk of shared failure and automatically helps to ensure path 323 diversity for most of the route of a pair of LSPs. 325 The main motivation behind domain diversity is to avoid fate sharing, 326 but it can also be because of some geo-political reasons and 327 commercial relationships that would require domain diversity. for 328 example, a pair of paths should choose different transit Autonomous 329 System (AS) because of some policy considerations. 331 In case when full domain diversity could not be achieved, it is 332 helpful to minimize the common shared domains. Also it is 333 interesting to note that other scope of diversity (node, link, SRLG 334 etc) can still be applied inside the common shared domains. 336 3. PCEP Extensions 338 This section defines extensions to PCEP [RFC5440] to support the 339 H-PCE procedures. 341 3.1. OPEN object 343 Two new TLVs are defined in this document to be carried within an 344 OPEN object. This way, during PCEP session establishment, the H-PCE 345 capability and Domain information can be advertised. 347 3.1.1. H-PCE Capability TLV 349 The H-PCE-CAPABILITY TLV is an optional TLV associated with the OPEN 350 Object [RFC5440] to exchange H-PCE capability of PCEP speakers. 352 Its format is shown in the following figure: 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Type= TBD1 | Length=4 | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Flags |P| 360 +---------------------------------------------------------------+ 362 Figure 1: H-PCE-CAPABILITY TLV format 364 The type of the TLV is TBD1 (to be assigned by IANA) and it has a 365 fixed length of 4 octets. 367 The value comprises a single field - Flags (32 bits): 369 P (Parent PCE Request bit): if set, will signal that the child PCE 370 wishes to use the peer PCE as a parent PCE. 372 The inclusion of this TLV in an OPEN object indicates that the H-PCE 373 extensions are supported by the PCEP speaker. The PCC MAY include 374 this TLV to indicate that it understands the H-PCE extensions. The 375 parent PCE MUST include this TLV and set the P flag. 377 If both peers attempt to set the P flag then the session 378 establishment MUST fail, using Error-Type 1: "PCEP Session 379 Establishment Failure" [RFC5440]. 381 If the PCE understands a H-PCE path computation request, but did not 382 advertise its H-PCE capability, it MUST send a PCErr message with 383 Error-Type=TBD8 (H-PCE error) and Error-Value=1 (Parent PCE 384 Capability not advertised). If the PCE does not understand or 385 support the H-PCE request. 387 3.1.1.1 Backwards Compatibility 389 If the PCE does not understand a H-PCE path computation request as 390 specified in this document, the PCE will ignore the H-PCE related 391 prameters, and behave as per [RFC5440] for any intra-domain Objective 392 Functions. 394 3.1.2. Domain-ID TLV 396 The Domain-ID TLV when used in OPEN object identify the domains 397 served by the PCE. The child PCE uses this mechanism to inform the 398 domain information to the parent PCE. 400 The Domain-ID TLV is defined below: 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Type= TBD2 | Length | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Domain Type | Reserved | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Domain ID | 410 // // 411 | | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Figure 2: Domain-ID TLV format 416 The type of the TLV is TBD2 (to be assigned by IANA) and it has a 417 variable Length of the value portion. The value part comprises of - 419 Domain Type (8 bits): Indicates the domain type. Four types of 420 domain are currently defined: 422 * Type=1: the Domain ID field carries a 2-byte AS number. Padded 423 with trailing zeros to a 4-byte boundary. 425 * Type=2: the Domain ID field carries a 4-byte AS number. 427 * Type=3: the Domain ID field carries a 4-byte OSPF area ID. 429 * Type=4: the Domain ID field carries (2-byte Area-Len, variable 430 length IS-IS area ID). Padded with trailing zeros to a 4-byte 431 boundary. 433 Reserved: Zero at transmission; ignored at receipt. 435 Domain ID (variable): Indicates an IGP Area ID or AS number. It 436 can be 2 bytes, 4 bytes or variable length depending on the domain 437 identifier used. It is padded with trailing zeros to a 4-byte 438 boundary. 440 In case a PCE serves more than one domain, multiple Domain-ID TLV is 441 included for each domain it serves. 443 3.2. RP Object 445 3.2.1. H-PCE-FLAG TLV 447 The H-PCE-FLAG TLV is an optional TLV associated with the RP Object 448 [RFC5440] to indicate the H-PCE path computation request and options. 450 Its format is shown in the following figure: 452 0 1 2 3 453 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 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Type= TBD3 | Length=4 | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Flags |D|S| 458 +---------------------------------------------------------------+ 460 Figure 3: H-PCE-FLAG TLV format 462 The type of the TLV is TBD3 (to be assigned by IANA) and it has a 463 fixed length of 4 octets. 465 The value comprises a single field - Flags (32 bits): 467 S (Domain Sequence bit): if set, will signal that the child PCE 468 wishes to get only the domain sequence in the path computation 469 reply. Refer section 3.7 of [RFC7897] for details. 471 D (Disallow Domain Re-entry bit): if set, will signal that the 472 computed path does not enter a domain more than once. 474 3.2.2. Domain-ID TLV 476 The usage of Domain-ID TLV carried in an OPEN object is used to 477 indicate a (list of) managed domains and is described in 478 Section 3.1.2. This TLV when carried in an RP object, indicates the 479 destination domain ID. If a PCC knows the egress domain, it can 480 supply this information in the PCReq message. The format and 481 procedure of this TLV are defined in Section 3.1.2. 483 If a Domain-id TLV is used in the RP object, and the destination is 484 not actually in the indicated domain, then the parent 485 PCE should respond with a NO-PATH object and NO-PATH VECTOR TLV 486 should be used, and a new bit number is assigned to indicate 487 "Destination not found in the indicated domain". 489 3.3. Objective Functions 491 3.3.1. OF Codes 493 [RFC5541] defines a mechanism to specify an Objective Function that 494 is used by a PCE when it computes a path. Three new Objective 495 Functions are defined for H-PCE, these are: 497 o MTD 499 * Name: Minimize the number of Transit Domains (MTD) 501 * Objective Function Code - TBD4 (to be assigned by IANA) 503 * Description: Find a path P such that it passes through the 504 least number of transit domains. 506 * Objective functions are formulated using the following 507 terminology: 509 + A network comprises a set of N domains {Di, (i=1...N)}. 511 + A path P passes through K unique domains {Dpi,(i=1...K)}. 513 + Find a path P such that the value of K is minimized. 515 o MBN 517 * Name: Minimize the number of border nodes. 519 * Objective Function Code - TBD5 (to be assigned by IANA) 521 * Description: Find a path P such that it passes through the 522 least number of border nodes. 524 * Objective functions are formulated using the following 525 terminology: 527 + A network comprises a set of N links {Li, (i=1...N)}. 529 + A path P is a list of K links {Lpi,(i=1...K)}. 531 + D(Lpi) if a function that determines if the links Lpi 532 and Lpi+1 belong to different domains, D(Li) = 1 if link 533 Li and Li+1 belong to different domains, D(Lk) = 0 if 534 link Lk and Lk+1 belong to the same domain. 536 + The number of border node in a path P is denoted by B(P), 537 where B(P) = sum{D(Lpi),(i=1...K-1)}. 539 + Find a path P such that B(P) is minimized. 541 There is one objective function that applies to a set of syncronized 542 path computation requests to increase the domain diversity: 544 MCTD 546 o Name: Minimize the number of Common Transit Domains 548 o Objective Function Code - TBD12 (to be assigned by IANA) 550 o Description: Find a set of paths such that it passes through the 551 least number of common transit domains. 553 + A network comprises a set of N domains {Di, (i=1...N)}. 555 + A path P passes through K unique domains {Dpi,(i=1...K)}. 557 + A set of paths {P1...Pm} have L transit domains that are 558 common to more than one path {Dpi,(i=1...L)}. 560 + Find a set of paths such that the value of L is minimized. 562 3.3.2. OF Object 564 The OF (Objective Function) object [RFC5541] is carried within a 565 PCReq message so as to indicate the desired/required objective 566 function to be applied by the PCE during path computation. As per 567 section 3.2 of [RFC5541] a single OF object may be included in a path 568 computation request. 570 The new OF codes described in Section 3.3.1 are applicable at the 571 inter-domain path computation performed by the parent PCE, it is 572 also necessary to specify the OF code that may be applied for the 573 intra-domain path computation performed by the child PCE. To 574 accommodate this, the OF-List TLV (described in section 2.1. of 575 [RFC5541]) is included in the OF object as an optional TLV. 577 The OF-List TLV allows encoding of multiple OF codes. When this TLV 578 is included inside the OF object, only the first OF-code in the 579 OF-LIST TLV is considered. The parent PCE MUST use this OF code in 580 the OF object when sending the intra domain path computation request 581 to the child PCE. If the OF list TLV is included in the OF Object, 582 the OF Code inside the OF Object MUST include one of the H-PCE 583 Objective Functions defined in this document, the OF Code inside the 584 OF List TLV MUST NOT include an H-PCE Objective Function. 586 If the Objective Functions defined in this document are unknown or 587 unsupported by a PCE, then the procedure as defined in [RFC5541] 588 should be followed. 590 3.4. Metric Object 592 The METRIC object is defined in section 7.8 of [RFC5440], comprising 593 metric-value, metric-type (T field) and flags. This document defines 594 the following types for the METRIC object for H-PCE: 596 o T=TBD6: Domain count metric (number of domains crossed); 598 o T=TBD7: Border Node count metric (number of border nodes crossed). 600 The domain count metric type of the METRIC object encodes the number 601 of domain crossed in the path. The border node count metric type of 602 the METRIC object encodes the number of border nodes in the path. If 603 a domain is rentered, then domain should be double counted. 605 A PCC or child PCE MAY use these metric in PCReq message an inter- 606 domain path meeting the number of domain or border nodes requirement. 607 As per [RFC5440], in this case, the B bit is set to suggest a bound 608 (a maximum) for the metric that must not be exceeded for the PCC to 609 consider the computed path as acceptable. 611 A PCC or child PCE MAY also use this metric to ask the PCE to 612 optimize the metric during inter-domain path computation. In this 613 case, the B flag is cleared. 615 The Parent PCE MAY use these metric in a PCRep message along with a 616 NO-PATH object in the case where the PCE cannot compute a path 617 meeting this constraint. A PCE MAY also use this metric to send the 618 computed end to end metric in a reply message. 620 3.5. SVEC Object 622 [RFC5440] defines SVEC object which includes flags for the potential 623 dependency between the set of path computation requests (Link, Node 624 and SRLG diverse). This document defines a new flag O for domain 625 diversity. 627 The following new bit is added to the Flags field: 629 o O (Domain diverse) bit - TBD12 : when set, this indicates that the 630 computed paths corresponding to the requests specified by the 631 following RP objects MUST NOT have any transit domains in 632 common. 634 The Domain Diverse O-bit can be used in Hierarchical PCE path 635 computation to compute synchronized domain diverse end to end path or 636 diverse domain sequences. 638 When domain diverse O bit is set, it is applied to the transit 639 domains. The other bit in SVEC object (N, L, S etc) MAY be set and 640 MUST still be applied in the ingress and egress shared domain. 642 3.6. PCEP-ERROR object 644 3.6.1. Hierarchy PCE Error-Type 646 A new PCEP Error-Type [RFC5440] is used for the H-PCE extension as 647 defined below: 649 +------------+-----------------------------------------+ 650 | Error-Type | Meaning | 651 +------------+-----------------------------------------+ 652 | TBD8 | H-PCE error | 653 | | Error-value=1: parent PCE capability | 654 | | was not advertised | 655 | | Error-value=2: parent PCE capability | 656 | | cannot be provided | 657 +------------+-----------------------------------------+ 659 Figure 4: H-PCE error 661 3.7. NO-PATH Object 663 To communicate the reason(s) for not being able to find a multi- 664 domain path or domain sequence, the NO-PATH object can be used in the 665 PCRep message. [RFC5440] defines the format of the NO-PATH object. 666 The object may contain a NO-PATH-VECTOR TLV to provide additional 667 information about why a path computation has failed. 669 Three new bit flags are defined to be carried in the Flags field in 670 the NO-PATH-VECTOR TLV carried in the NO-PATH Object. 672 o Bit number TBD9: When set, the parent PCE indicates that 673 destination domain unknown; 675 o Bit number TBD10: When set, the parent PCE indicates unresponsive 676 child PCE(s); 678 o Bit number TBD11: When set, the parent PCE indicates no available 679 resource available in one or more domains. 681 4. H-PCE Procedures 683 4.1. OPEN Procedure between Child PCE and Parent PCE 685 If a child PCE wants to use the peer PCE as a parent, it MUST set the 686 R (parent PCE request flag) in the H-PCE-CAPABILITY TLV inside the 687 OPEN object carried in the Open message during the PCEP session 688 initialization procedure. 690 If the parent PCE can provide the parent function to the peer PCE, it 691 MUST set the I (parent PCE indication flag) in the H-PCE-CAPABILITY 692 TLV inside the OPEN object carried in the Open message during the 693 PCEP session creation procedure. 695 The child PCE MAY also report its list of domain IDs to the parent 696 PCE by specifying them in the Domain-ID TLVs in the OPEN object 697 carried in the Open message during the PCEP session initialization 698 procedure. 700 The OF codes defined in this document can be carried in the OF-list 701 TLV of the OPEN object. If the OF-list TLV carries the OF codes, it 702 means that the PCE is capable of implementing the corresponding 703 objective functions. This information can be used for selecting a 704 proper parent PCE when a child PCE wants to get a path that satisfies 705 a certain Objective Function. 707 When a specific child PCE sends a PCReq to a peer PCE that requires 708 parental activity and H-PCE capability flags were not set in the 709 session establishment procedure as described above, the peer PCE 710 should send a PCErr message to the child PCE and specify the error- 711 type=TBD (H-PCE error) and error-value=1 (parent PCE capability was 712 not advertised) in the PCEP-ERROR object. 714 When a specific child PCE sends a PCReq to a peer PCE that requires 715 parental activity and the peer PCE does not want to act as the parent 716 for it, the peer PCE should send a PCErr message to the child PCE and 717 specify the error-type=TBD (H-PCE error) and error-value=2 (parent 718 PCE capability cannot be provided) in the PCEP-ERROR object. 720 4.2. Procedure to Obtain Domain Sequence 722 If a child PCE only wants to get the domain sequence for a multi- 723 domain path computation from a parent PCE, it can set the Domain Path 724 Request bit in the H-PCE-FLAG TLV in the RP object carried in a PCReq 725 message. The parent PCE which receives the PCReq message tries to 726 compute a domain sequence for it (instead of the E2E path). If the 727 domain path computation succeeds the parent PCE sends a PCRep message 728 which carries the domain sequence in the ERO to the child PCE. Refer 729 [RFC7897] for more details about domain sub-objects in the ERO. 730 Otherwise, it sends a PCReq message which carries the NO-PATH object 731 to the child PCE. 733 5. Error Handling 735 A PCE that is capable of acting as a parent PCE might not be 736 configured or willing to act as the parent for a specific child PCE. 737 This fact could be determined when the child sends a PCReq that 738 requires parental activity, and could result in a negative response 739 in a PCEP Error (PCErr) message and indicate the hierarchy PCE error- 740 type=TBD8 (H-PCE error) and suitable error-value. (Section 3.6) 742 Additionally, the parent PCE may fail to find the multi-domain path 743 or domain sequence due to one or more of the following reasons: 745 o A child PCE cannot find a suitable path to the egress; 747 o The parent PCE do not hear from a child PCE for a specified time; 749 o The Objective Functions specified in the path request cannot be 750 met. 752 In this case, the parent PCE MAY need to send a negative path 753 computation reply specifying the reason. This can be achieved by 754 including NO-PATH object in the PCRep message. Extension to NO-PATH 755 object is needed to include the aforementioned reasons described in 756 Section 3.7. 758 6. Manageability Considerations 760 General PCE and PCEP management considerations are discussed in 761 [RFC4655] and [RFC5440]. There are additional management 762 considerations for H-PCE which are described in [RFC6805], and 763 repeated in this section. 765 The administrative entity responsible for the management of the 766 parent PCEs must be determined for the following cases: 768 o multi-domains (e.g., IGP areas or multiple ASes) within a single 769 service provider network, the management responsibility for the 770 parent PCE would most likely be handled by the service provider, 772 o multiple ASes within different service provider networks, it may 773 be necessary for a third party to manage the parent PCEs according 774 to commercial and policy agreements from each of the participating 775 service providers. 777 6.1. Control of Function and Policy 779 Control and function will need to be carefully managed in a H-PCE 780 network. A child PCE will need to be configured with the address of 781 its parent PCE. It is expected that there will only be one or two 782 parents of any child. 784 The parent PCE also needs to be aware of the child PCEs for all child 785 domains that it can see. This information is most likely to be 786 configured (as part of the administrative definition of each domain). 788 Discovery of the relationships between parent PCEs and child PCEs 789 do not form part of the hierarchical PCE architecture. Mechanisms 790 that rely on advertising or querying PCE locations across domain or 791 provider boundaries are undesirable for security, scaling, 792 commercial, and confidentiality reasons. The specific behavior of 793 the child and parent PCE are described in the following sub-sections. 795 6.1.1. Child PCE 797 Support of the hierarchical procedure will be controlled by the 798 management organization responsible for each child PCE. A child PCE 799 must be configured with the address of its parent PCE in order for it 800 to interact with its parent PCE. The child PCE must also be 801 authorized to peer with the parent PCE. 803 6.1.2. Parent PCE 805 The parent PCE must only accept path computation requests from 806 authorized child PCEs. If a parent PCE receives requests from an 807 unauthorized child PCE, the request should be dropped. This means 808 that a parent PCE must be configured with the identities and security 809 credentials of all of its child PCEs, or there must be some form of 810 shared secret that allows an unknown child PCE to be authorized by 811 the parent PCE. 813 6.1.3. Policy Control 815 It may be necessary to maintain a policy module on the parent PCE 817 [RFC5394]. This would allow the parent PCE to apply commercially 818 relevant constraints such as SLAs, security, peering preferences, and 819 monetary costs. 821 It may also be necessary for the parent PCE to limit end-to-end path 822 selection by including or excluding specific domains based on 823 commercial relationships, security implications, and reliability. 825 6.2. Information and Data Models 827 A MIB module for PCEP was published as RFC 7420 [RFC7420] that 828 describes managed objects for modeling of PCEP communication. A YANG 829 module for PCEP has also been proposed [I-D.ietf-pce-pcep-yang]. 831 A H-PCE MIB module, or additional data model, will be required to 832 report parent PCE and child PCE information, including: 834 o parent PCE configuration and status, 836 o child PCE configuration and information, 838 o notifications to indicate session changes between parent PCEs and 839 child PCEs, and 841 o notification of parent PCE TED updates and changes. 843 6.3. Liveness Detection and Monitoring 845 The hierarchical procedure requires interaction with multiple PCEs. 846 Once a child PCE requests an end-to-end path, a sequence of events 847 occurs that requires interaction between the parent PCE and each 848 child PCE. If a child PCE is not operational, and an alternate 849 transit domain is not available, then a failure must be reported. 851 6.4. Verify Correct Operations 853 Verifying the correct operation of a parent PCE can be performed by 854 monitoring a set of parameters. The parent PCE implementation should 855 provide the following parameters monitored by the parent PCE: 857 o number of child PCE requests, 859 o number of successful hierarchical PCE procedures completions on a 860 per-PCE-peer basis, 862 o number of hierarchical PCE procedure completion failures on a per- 863 PCE-peer basis, and 865 o number of hierarchical PCE procedure requests from unauthorized 866 child PCEs. 868 6.5. Requirements On Other Protocols 870 Mechanisms defined in this document do not imply any new requirements 871 on other protocols. 873 6.6. Impact On Network Operations 875 The hierarchical PCE procedure is a multiple-PCE path computation 876 scheme. Subsequent requests to and from the child and parent PCEs do 877 not differ from other path computation requests and should not have 878 any significant impact on network operations. 880 7. IANA Considerations 882 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 883 registry. This document requests IANA actions to allocate code 884 points for the protocol elements defined in this document. 886 7.1. PCEP TLV Type Indicators 888 IANA Manages the PCEP TLV code point registry (see [RFC5440]). This 889 is maintained as the "PCEP TLV Type Indicators" sub-registry of the 890 "Path Computation Element Protocol (PCEP) Numbers" registry. 892 This document defines three new PCEP TLVs. IANA is requested to make 893 the following allocation: 895 Type TLV name References 896 ----------------------------------------------- 897 TBD1 H-PCE-CAPABILITY TLV This I-D 898 TBD2 Domain-ID TLV This I-D 899 TBD3 H-PCE-FLAG TLV This I-D 901 7.2. H-PCE-CAPABILITY TLV Flags 903 This document requests that a new sub-registry, named " H-PCE- 904 CAPABILITY TLV Flag Field", is created within the "Path Computation 905 Element Protocol (PCEP) Numbers" registry to manage the Flag field in 906 the H-PCE-CAPABILITY TLV of the PCEP OPEN object. 908 New values are to be assigned by Standards Action [RFC5226]. Each 909 bit should be tracked with the following qualities: 911 o Bit number (counting from bit 0 as the most significant bit) 912 o Capability description 914 o Defining RFC 916 The following values are defined in this document: 918 Bit Description Reference 919 -------------------------------------------------- 920 31 P (Parent PCE bit) This I.D. 922 7.3. Domain-ID TLV Domain type 924 This document requests that a new sub-registry, named " Domain-ID TLV 925 Domain type", is created within the "Path Computation Element 926 Protocol (PCEP) Numbers" registry to manage the Domain-Type field of 927 the Domain-ID TLV. 929 Value Meaning 930 ----------------------------------------------- 931 1 2-byte AS number 932 2 4-byte AS number 933 3 4-byte OSPF area ID 934 4 Variable length IS-IS area ID 936 7.4. H-PCE-FLAG TLV Flags 938 This document requests that a new sub-registry, named "H-PCE-FLAGS 939 TLV Flag Field", is created within the "Path Computation Element 940 Protocol (PCEP) Numbers" registry to manage the Flag field in the H- 941 PCE-FLAGS TLV of the PCEP RP object. New values are to be assigned 942 by Standards Action [RFC5226]. Each bit should be tracked with the 943 following qualities: 945 o Bit number (counting from bit 0 as the most significant bit) 947 o Capability description 949 o Defining RFC 951 The following values are defined in this document: 953 Bit Description Reference 954 ----------------------------------------------- 955 31 S (Domain This I.D. 956 Sequence bit) 957 30 D (Disallow Domain This I.D. 958 Re-entry bit) 960 7.5. OF Codes 962 IANA maintains registry of Objective Function (described in 963 [RFC5541]) at the sub-registry "Objective Function". Two new 964 Objective Functions have been defined in this document. 966 IANA is requested to make the following allocations: 968 Code 969 Point Name Reference 970 ------------------------------------------------------ 971 TBD4 Minimum number of Transit This I.D. 972 Domains (MTD) 973 TBD5 Minimize number of Border This I.D. 974 Nodes (MBN) 975 TBD12 Minimize the number of This I.D. 976 Common Transit Domains. 977 (MCTD) 979 7.6. METRIC Types 981 IANA maintains one sub-registry for "METRIC object T field". Two new 982 metric types are defined in this document for the METRIC object 983 (specified in [RFC5440]). 985 IANA is requested to make the following allocations: 987 Value Description Reference 988 ---------------------------------------------------------- 989 TBD6 Domain Count metric This I.D. 990 TBD7 Border Node Count metric This I.D. 992 7.7. New PCEP Error-Types and Values 994 IANA maintains a registry of Error-Types and Error-values for use in 995 PCEP messages. This is maintained as the "PCEP-ERROR Object Error 996 Types and Values" sub-registry of the "Path Computation Element 997 Protocol (PCEP) Numbers" registry. 999 IANA is requested to make the following allocations: 1001 Error-Type Meaning and error values Reference 1002 ------------------------------------------------------ 1003 TBD8 H-PCE Error This I.D. 1005 Error-value=1 Parent PCE 1006 Capability not advertised 1007 Error-value=2 Parent PCE 1008 Capability not supported 1010 7.8. New NO-PATH-VECTOR TLV Bit Flag 1012 IANA maintains a registry of bit flags carried in the PCEP NO-PATH- 1013 VECTOR TLV in the PCEP NO-PATH object as defined in [RFC5440]. IANA 1014 Is requested to assign three new bit flag as follows: 1016 Bit Number Name Flag Reference 1017 ------------------------------------------------------ 1018 TBD9 Destination Domain unknown This I.D. 1019 TBD10 Unresponsive child PCE(s) This I.D. 1020 TBD11 No available resource in This I.D. 1021 one or more domain 1023 7.9. SVEC Flag 1025 IANA maintains a registry of bit flags carried in the PCEP SVEC 1026 object as defined in [RFC5440]. IANA Is requested to assign one new 1027 bit flag as follows: 1029 Bit Number Name Flag Reference 1030 ------------------------------------------------------ 1031 TBD12 Domain Diverse This I.D. 1033 7.10. NO-PATH VECTOR TLV Bit Flag 1035 IANA maintains a registry of bit flags carried in the PCEP NO-PATH- 1036 VECTOR TLV in the PCEP NO-PATH object as defined in [RFC5440]. IANA 1037 assigned a new bit flag as follows: 1039 Bit Number Name Flag Reference 1040 ------------------------------------------------------ 1041 TBD Destination not found This I.D. 1042 in the indicated domain 1044 8. Security Considerations 1046 The hierarchical PCE procedure relies on PCEP and inherits the 1047 security requirements defined in [RFC5440]. As PCEP operates over 1048 TCP, it may also make use of TCP security mechanisms, such as TCP 1049 Authentication Option (TCP-AO) [RFC5925] or Transport Layer 1050 Security (TLS) [RFC8253]. 1052 H-PCE operation also relies on information used to build the TED. 1053 Attacks on a parent or child PCE may be achieved by falsifying or 1054 impeding this flow of information. If the child PCE listens to the 1055 IGP or BGP-LS for populating the TED, then normal IGP or BGP-LS 1056 security measures may be applied, and it should be noted that an IGP 1057 routing system is generally assumed to be a trusted domain such that 1058 router subversion is not a risk. The parent PCE TED is constructed 1059 as described in this document and may involve: 1061 o multiple parent-child relationships using PCEP 1063 o the parent PCE listening to child domain IGPs (with the same 1064 security features as a child PCE listening to its IGP) 1066 o an external mechanism (such as [RFC7752]), which will need to be 1067 authorized and secured. 1069 Any multi-domain operation necessarily involves the exchange of 1070 information across domain boundaries. This is bound to represent a 1071 significant security and confidentiality risk especially when the 1072 child domains are controlled by different commercial concerns. PCEP 1073 allows individual PCEs to maintain confidentiality of their domain 1074 path information using path-keys [RFC5520], and the H-PCE 1075 architecture is specifically designed to enable as much isolation of 1076 domain topology and capabilities information as is possible. 1078 For further considerations of the security issues related to inter-AS 1079 path computation, see [RFC5376]. 1081 9. Contributing Authors 1083 Xian Zhang 1084 Huawei 1085 EMail: zhang.xian@huawei.com 1087 Dhruv Dhody 1088 Huawei Technologies 1089 Divyashree Techno Park, Whitefield 1090 Bangalore, Karnataka 560066 1091 India 1093 EMail: dhruv.ietf@gmail.com 1095 10. References 1097 10.1. Normative References 1099 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1100 Requirement Levels", BCP 14, RFC 2119, 1101 DOI 10.17487/RFC2119, March 1997, 1102 . 1104 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 1105 Per-Domain Path Computation Method for Establishing Inter- 1106 Domain Traffic Engineering (TE) Label Switched Paths 1107 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 1108 . 1110 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1111 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1112 DOI 10.17487/RFC5440, March 2009, 1113 . 1115 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1116 Objective Functions in the Path Computation Element 1117 Communication Protocol (PCEP)", RFC 5541, 1118 DOI 10.17487/RFC5541, June 2009, 1119 . 1121 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1122 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1123 May 2017, . 1125 10.2. Informative References 1127 [RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. Boyle, Ed., 1128 "Requirements for Inter-Area MPLS Traffic Engineering", 1129 RFC 4105, DOI 10.17487/RFC4105, June 2005, 1130 . 1132 [RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous 1133 System (AS) Traffic Engineering (TE) Requirements", 1134 RFC 4216, DOI 10.17487/RFC4216, November 2005, 1135 . 1137 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1138 Element (PCE)-Based Architecture", RFC 4655, 1139 DOI 10.17487/RFC4655, August 2006, 1140 . 1142 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 1143 Inter-Domain Multiprotocol Label Switching Traffic 1144 Engineering", RFC 4726, DOI 10.17487/RFC4726, November 1145 2006, . 1147 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1148 IANA Considerations Section in RFCs", RFC 5226, 1149 DOI 10.17487/RFC5226, May 2008, 1150 . 1152 [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS 1153 Requirements for the Path Computation Element 1154 Communication Protocol (PCECP)", RFC 5376, 1155 DOI 10.17487/RFC5376, November 2008, 1156 . 1158 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 1159 "Policy-Enabled Path Computation Framework", RFC 5394, 1160 DOI 10.17487/RFC5394, December 2008, 1161 . 1163 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1164 "Preserving Topology Confidentiality in Inter-Domain Path 1165 Computation Using a Path-Key-Based Mechanism", RFC 5520, 1166 DOI 10.17487/RFC5520, April 2009, 1167 . 1169 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 1170 "A Backward-Recursive PCE-Based Computation (BRPC) 1171 Procedure to Compute Shortest Constrained Inter-Domain 1172 Traffic Engineering Label Switched Paths", RFC 5441, 1173 DOI 10.17487/RFC5441, April 2009, 1174 . 1176 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1177 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1178 June 2010, . 1180 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1181 Path Computation Element Architecture to the Determination 1182 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1183 DOI 10.17487/RFC6805, November 2012, 1184 . 1186 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1187 Computation Element Architecture", RFC 7399, 1188 DOI 10.17487/RFC7399, October 2014, 1189 . 1191 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1192 Hardwick, "Path Computation Element Communication Protocol 1193 (PCEP) Management Information Base (MIB) Module", 1194 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1195 . 1197 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1198 S. Ray, "North-Bound Distribution of Link-State and 1199 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1200 DOI 10.17487/RFC7752, March 2016, 1201 . 1203 [RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects 1204 for the Path Computation Element Communication Protocol 1205 (PCEP)", RFC 7897, DOI 10.17487/RFC7897, June 2016, 1206 . 1208 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1209 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1210 Path Computation Element Communication Protocol (PCEP)", 1211 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1212 . 1214 [I-D.ietf-pce-pcep-yang] 1215 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1216 YANG Data Model for Path Computation Element 1217 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1218 yang-09 (work in progress), October 2018. 1220 [I-D.ietf-pce-stateful-hpce] 1221 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 1222 and O. Dios, "Hierarchical Stateful Path Computation 1223 Element (PCE).", draft-ietf-pce-stateful-hpce-06 (work in 1224 progress), June 2018. 1226 Authors' Addresses 1228 Fatai Zhang 1229 Huawei 1230 Huawei Base, Bantian, Longgang District 1231 Shenzhen 518129 1232 China 1234 EMail: zhangfatai@huawei.com 1236 Quintin Zhao 1237 Huawei 1238 125 Nagog Technology Park 1239 Acton, MA 01719 1240 USA 1242 EMail: quintin.zhao@huawei.com 1243 Oscar Gonzalez de Dios 1244 Telefonica I+D 1245 Don Ramon de la Cruz 82-84 1246 Madrid 28045 1247 Spain 1249 EMail: ogondio@tid.es 1251 Ramon Casellas 1252 CTTC 1253 Av. Carl Friedrich Gauss n.7 1254 Barcelona, Castelldefels 1255 Spain 1257 EMail: ramon.casellas@cttc.es 1259 Daniel King 1260 Old Dog Consulting 1261 UK 1263 EMail: daniel@olddog.co.uk 1265 Appendix 1267 A1. Implementation Status 1269 The H-PCE architecture and protocol procedures describe in this I-D 1270 were implemented and tested for a variety of optical research 1271 applications. 1273 The Appendix shold be removed before publication. 1275 A1.1. Inter-layer traffic engineering with H-PCE 1277 This work was led by: 1279 o Ramon Casellas [ramon.casellas@cttc.es] 1281 o Centre Tecnologic de Telecomunicacions de Catalunya (CTTC) 1283 The H-PCE instances (parent and child) were multi-threaded 1284 asynchronous processes. Implemented in C++11, using C++ Boost 1285 Libraries. The targeted system used to deploy and run H-PCE 1286 applications was a POSIX system (Debian GNU/Linux operating system). 1288 Some parts of the software may require a Linux Kernel, the 1289 availability of a Routing Controller running collocated in the same 1290 host and the usage of libnetfilter / libipq and GNU/Linux firewalling 1291 capabilities. Most of the functionality, including algorithms is 1292 done by means of plugins (e.g., as shared libraries or .so files in 1293 Unix systems). 1295 The CTTC PCE supports the H-PCE architecture, but also supports 1296 stateful PCE with active capabilities, as an OpenFlow controller, and 1297 has dedicated plugins to support monitoring, BRPC, P2MP, path keys, 1298 back end PCEs. Management of the H-PCE entities was supported via 1299 HTTP and CLI via Telnet. 1301 Further details of the H-PCE prototyping and experimentation can be 1302 found in the following scientific papers: 1304 R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I. 1305 Morita, "Inter-layer traffic engineering with hierarchical-PCE in 1306 MPLS-TP over wavelength switched optical networks" , Optics 1307 Express, Vol. 20, No. 28, December 2012. 1309 R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I. 1310 Morita, M. Msurusawa, "Dynamic virtual link mesh topology 1311 aggregation in multi-domain translucent WSON with hierarchical- 1312 PCE", Optics Express Journal, Vol. 19, No. 26, December 2011. 1314 R. Casellas, R. Munoz, R. Martinez, R. Vilalta, L. Liu, T. 1315 Tsuritani, I. Morita, V. Lopez, O. Gonzalez de Dios, J. P. 1316 Fernandez-Palacios, "SDN based Provisioning Orchestration of 1317 OpenFlow/GMPLS Flexi-grid Networks with a Stateful Hierarchical 1318 PCE", in Proceedings of Optical Fiber Communication Conference and 1319 Exposition (OFC), 9-13 March, 2014, San Francisco (EEUU). 1320 Extended Version to appear in Journal Of Optical Communications 1321 and Networking January 2015 1323 F. Paolucci, O. Gonzalez de Dios, R. Casellas, S. Duhovnikov, 1324 P. Castoldi, R. Munoz, R. Martinez, "Experimenting Hierarchical 1325 PCE Architecture in a Distributed Multi-Platform Control Plane 1326 Testbed" , in Proceedings of Optical Fiber Communication 1327 Conference and Exposition (OFC) and The National Fiber Optic 1328 Engineers Conference (NFOEC), 4-8 March, 2012, Los Angeles, 1329 California (USA). 1331 R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I. 1332 Morita, M. Tsurusawa, "Dynamic Virtual Link Mesh Topology 1333 Aggregation in Multi-Domain Translucent WSON with Hierarchical- 1334 PCE", in Proceedings of 37th European Conference and Exhibition on 1335 Optical Communication (ECOC 2011), 18-22 September 2011, Geneve ( 1336 Switzerland). 1338 R. Casellas, R. Munoz, R. Martinez, "Lab Trial of Multi-Domain 1339 Path Computation in GMPLS Controlled WSON Using a Hierarchical 1340 PCE", in Proceedings of OFC/NFOEC Conference (OFC2011), 10 March 1341 2011, Los Angeles (USA). 1343 A1.2. Telefonica Netphony (Open Source PCE) 1345 The Telefonica Netphony PCE is an open source Java-based 1346 implementation of a Path Computation Element, with several flavours, 1347 and a Path Computation Client. The PCE follows a modular 1348 architecture and allows to add customized algorithms. The PCE has 1349 also stateful and remote initiation capabilities. In current 1350 version, three components can be built, a domain PCE (aka child PCE), 1351 a parent PCE (ready for the H-PCE architecture) and a PCC (path 1352 computation client). 1354 This work was led by: 1356 o Oscar Gonzalez de Dios [oscar.gonzalezdedios@telefonica.com] 1358 o Victor Lopez Alvarez [victor.lopezalvarez@telefonica.com] 1360 o Telefonica I+D, Madrid, Spain 1362 The PCE code is publicly available in a GitHub repository: 1364 o https://github.com/telefonicaid/netphony-pce 1366 The PCEP protocol encodings are located in the following repository: 1368 o https://github.com/telefonicaid/netphony-network protocols 1370 The traffic engineering database and a BGP-LS speaker to fill the 1371 database is located in: 1373 o https://github.com/telefonicaid/netphony-topology 1375 The parent and child PCE are multi-threaded java applications. The 1376 path computation uses the jgrapht free Java class library (0.9.1) 1377 that provides mathematical graph-theory objects and algorithms. 1378 Current version of netphony PCE runs on java 1.7 and 1.8, and has 1379 been tested in GNU/Linux, Mac OS-X and Windows environments. The 1380 management of the parent and domain PCEs is supported though CLI via 1381 Telnet, and configured via XML files. 1383 Further details of the netphony H-PCE prototyping and experimentation 1384 can be found in the following research papers: 1386 o O. Gonzalez de Dios, R. Casellas, F. Paolucci, A. Napoli, L. 1387 Gifre, A. Dupas, E, Hugues-Salas, R. Morro, S. Belotti, G. 1388 Meloni, T. Rahman, V.P Lopez, R. Martinez, F. Fresi, M. Bohn, 1389 S. Yan, L. Velasco, . Layec and J. P. Fernandez-Palacios: 1390 Experimental Demonstration of Multivendor and Multidomain EON With 1391 Data and Control Interoperability Over a Pan-European Test Bed, in 1392 Journal of Lightwave Technology, Dec. 2016, Vol. 34, Issue 7, pp. 1393 1610-1617. 1395 o O. Gonzalez de Dios, R. Casellas, R. Morro, F. Paolucci, V. 1396 Lopez, R. Martinez, R. Munoz, R. Villalta, P. Castoldi: 1397 "Multi-partner Demonstration of BGP-LS enabled multi-domain EON, 1398 in Journal of Optical Communications and Networking, Dec. 2015, 1399 Vol. 7, Issue 12, pp. B153-B162. 1401 o F. Paolucci, O. Gonzalez de Dios, R. Casellas, S. Duhovnikov, 1402 P. Castoldi, R. Munoz, R. Martinez, "Experimenting Hierarchical 1403 PCE Architecture in a Distributed Multi-Platform Control Plane 1404 Testbed" , in Proceedings of Optical Fiber Communication 1405 Conference and Exposition (OFC) and The National Fiber Optic 1406 Engineers Conference (NFOEC), 4-8 March, 2012, Los Angeles, 1407 California (USA). 1409 A1.3. Implementation 3: H-PCE Proof of Concept developed by Huawei 1411 Huawei developed this H-PCE on the Huawei Versatile Routing Platform 1412 (VRP) to experiment with the hierarchy of PCE. Both end to end path 1413 computation as well as computation for domain-sequence are supported. 1415 This work was led by: 1417 o Udayasree Pallee [udayasreereddy@gmail.com] 1419 o Dhruv Dhody [dhruv.ietf@gmail.com] 1421 o Huawei Technologies, Bangalore, India 1423 Further work on stateful H-PCE [I-D.ietf-pce-stateful-hpce] is being 1424 carried out on ONOS.