idnits 2.17.1 draft-ietf-pce-hierarchy-extensions-11.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 (June 1, 2019) is 1790 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-11 == Outdated reference: A later version (-15) exists of draft-ietf-pce-stateful-hpce-07 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-13 Summary: 0 errors (**), 0 flaws (~~), 4 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: December 2, 2019 O. Gonzalez de Dios 6 Telefonica I+D 7 R. Casellas 8 CTTC 9 D. King 10 Old Dog Consulting 11 June 1, 2019 13 Extensions to Path Computation Element Communication Protocol (PCEP) for 14 Hierarchical Path Computation Elements (PCE) 15 draft-ietf-pce-hierarchy-extensions-11 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 December 2, 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 . . . . . . . . . . . . . . . . . . . . . . . .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 . . . . . . . . . . . . . . . .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 . . . . . . . . . . . . . . . .7 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 . . . . . . . . . . . . . . . . . . . .12 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 . . . . . . . . . . . . . . . . . . . . . . .15 88 3.7. PCEP-ERROR Object . . . . . . . . . . . . . . . . . . . .15 89 3.7.1. Hierarchy PCE Error-Type . . . . . . . . . . . . . .15 90 3.8. NO-PATH Object . . . . . . . . . . . . . . . . . . . . .16 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 . . . . . . . . . . . . . . . .18 96 6.1. Control of Function and Policy . . . . . . . . . . . . .18 97 6.1.1. Child PCE . . . . . . . . . . . . . . . . . . . . . .18 98 6.1.2. Parent PCE . . . . . . . . . . . . . . . . . . . . . 100 6.1.3. Policy Control . . . . . . . . . . . . . . . . . . .19 101 6.2. Information and Data Models . . . . . . . . . . . . . . .19 102 6.3. Liveness Detection and Monitoring . . . . . . . . . . . .20 103 6.4. Verify Correct Operations . . . . . . . . . . . . . . . .20 104 6.5. Requirements On Other Protocols . . . . . . . . . . . . .20 105 6.6. Impact On Network Operations . . . . . . . . . . . . . .20 106 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . .20 107 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . .20 108 7.2. H-PCE-CAPABILITY TLV Flags . . . . . . . . . . . . . . .21 109 7.3. Domain-ID TLV Domain type . . . . . . . . . . . . . . . .21 110 7.4. H-PCE-FLAG TLV Flags . . . . . . . . . . . . . . . . . .22 111 7.5. OF Codes . . . . . . . . . . . . . . . . . . . . . . . .22 112 7.6. METRIC Types . . . . . . . . . . . . . . . . . . . . . .22 113 7.7. New PCEP Error-Types and Values . . . . . . . . . . . . .23 114 7.8. New NO-PATH-VECTOR TLV Bit Flag . . . . . . . . . . . . .23 115 7.9. SVEC Flag . . . . . . . . . . . . . . . . . . . . . . . .24 116 7.10. NO-PATH VECTOR TLV Bit Flag. . . . . . . . . . . . . . .24 117 8. Security Considerations . . . . . . . . . . . . . . . . . . .24 118 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . .24 119 10.Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .25 120 11. References . . . . . . . . . . . . . . . . . . . . . . . . .25 121 11.1. Normative References . . . . . . . . . . . . . . . . . .25 122 11.2. Informative References . . . . . . . . . . . . . . . . .25 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .28 124 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 125 A1. Implementation Status . . . . . . . . . . . . . . . . . . .28 126 A1.1. Inter-layer traffic engineering with H-PCE . . . . . . .29 127 A1.2. Telefonica Netphony (Open Source PCE) . . . . . . . . .30 128 A1.3. H-PCE Proof of Concept developed by Huawei . . . . . . .31 130 1. Introduction 132 The Path Computation Element communication Protocol (PCEP) provides 133 a mechanism for Path Computation Elements (PCEs) and Path Computation 134 Clients (PCCs) to exchange requests for path computation and 135 responses that provide computed paths. 137 The capability to compute the routes of end-to-end inter-domain MPLS 138 Traffic Engineering (MPLS-TE) and GMPLS Label Switched Paths (LSPs) 139 is expressed as requirements in [RFC4105] and [RFC4216]. This 140 capability may be realized by a PCE [RFC4655]. The methods for 141 establishing and controlling inter-domain MPLS-TE and GMPLS LSPs are 142 documented in [RFC4726]. 144 [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can 145 be used for computing end-to-end paths for inter-domain MPLS Traffic 146 Engineering (TE) and GMPLS Label Switched Paths (LSPs). 148 Within the hierarchical PCE architecture, the parent PCE is used to 149 compute a multi-domain path based on the domain connectivity 150 information. A child PCE may be responsible for single or multiple 151 domains and is used to compute the intra-domain path based on its 152 own domain topology information. 154 The H-PCE end-to-end domain path computation procedure is described 155 below: 157 o A path computation client (PCC) sends the inter-domain path 158 computation requests to the child PCE responsible for its domain; 160 o The child PCE forwards the request to the parent PCE; 162 o The parent PCE computes the likely domain paths from the ingress 163 domain to the egress domain; 165 o The parent PCE sends the intra-domain path computation requests 166 (between the domain border nodes) to the child PCEs which are 167 responsible for the domains along the domain path; 169 o The child PCEs return the intra-domain paths to the parent PCE; 171 o The parent PCE constructs the end-to-end inter-domain path based 172 on the intra-domain paths; 174 o The parent PCE returns the inter-domain path to the child PCE; 176 o The child PCE forwards the inter-domain path to the PCC. 178 The parent PCE may be requested to provide only the sequence of 179 domains to a child PCE so that alternative inter-domain path 180 computation procedures, including Per Domain (PD) [RFC5152] and 181 Backwards Recursive Path Computation (BRPC) [RFC5441], may be used. 183 This document defines the PCEP extensions for the purpose of 184 implementing Hierarchical PCE procedures, which are described in 185 [RFC6805]. 187 1.1. Scope 189 The following functions are out of scope of this document: 191 o Determination of Destination Domain (section 4.5 of [RFC6805]): 193 * via a collection of reachability information from child domain; 195 * via requests to the child PCEs to discover if they contain the 196 destination node; 198 * or any other methods. 200 o Parent Traffic Engineering Database (TED) methods (section 4.4 of 201 [RFC6805]), although suitable mechanisms include: 203 * YANG-based management interfaces; 205 * BGP-LS [RFC7752]; 207 * Future extension to PCEP (such as [I-D.dhodylee-pce-pcep-ls]). 209 o Learning of Domain connectivity and boundary nodes (BN) addresses, 210 methods to achieve this function include: 212 * YANG-based management interfaces; 214 * BGP-LS [RFC7752]; 216 * Future extension to PCEP (such as [I-D.dhodylee-pce-pcep-ls]). 218 o Stateful PCE Operations (Refer [I-D.ietf-pce-stateful-hpce]) 220 o Applicability of hierarchical PCE to large multi-domain 221 environments. 223 * The hierarchical relationship model is described in [RFC6805]. 224 It is applicable to environments with small groups of domains 225 where visibility from the ingress LSRs is limited. As highlighted 226 in [RFC7399] applying the hierarchical PCE model to very large 227 groups of domains, such as the Internet, is not considered 228 feasible or desirable. 230 1.2. Terminology 232 This document uses the terminology defined in [RFC4655], [RFC5440] 233 and the additional terms defined in Section 1.4 of [RFC6805]. 235 1.3. Requirements Language 237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 239 "OPTIONAL" in this document are to be interpreted as described in BCP 240 14 [RFC2119] [RFC8174] when, and only when, they appear in all 241 capitals, as shown here. 243 2. Requirements for H-PCE 244 This section compiles the set of requirements to the PCEP extensions 245 to support the H-PCE architecture and procedures. 246 [RFC6805] identifies high-level requirements of PCEP extensions 247 required to support the hierarchical PCE model. 249 2.1. Path Computation Request 251 The Path Computation Request (PCReq) [RFC5440] messages are used by 252 a PCC or a PCE to make a path computation request to a PCE. In order 253 to achieve the full functionality of the H-PCE procedures, the PCReq 254 message needs to include: 256 o Qualification of PCE Requests (Section 4.8.1. of [RFC6805]); 258 o Multi-domain Objective Functions (OF); 260 o Multi-domain Metrics. 262 2.1.1. Qualification of PCEP Requests 264 As described in Section 4.8.1 of [RFC6805], the H-PCE architecture 265 introduces new request qualifications, which are: 267 o The ability for a child PCE to indicate that a path computation 268 request sent to a parent PCE should be satisfied by a domain 269 sequence only, that is, not by a full end-to-end path. This allows 270 the child PCE to initiate a per-domain (PD) [RFC5152] or a 271 backward recursive path computation (BRPC) [RFC5441]. 273 o As stated in [RFC6805], Section 4.5, if a PCC knows the egress 274 domain, it can supply this information as the path computation 275 request. The PCC may also want to specify the destination domain 276 information in a PCEP request, if it is known. 278 o An inter domain path computed by parent PCE should be capable of 279 disallowing specific domain re-entry. 281 2.1.2. Multi-domain Objective Functions 283 For H-PCE inter-domain path computation, there are three new 284 Objective Functions defined in this document: 286 o Minimize the number of Transit Domains (MTD) 287 o Minimize the number of border nodes (MBN) 288 o Minimize the number of Common Transit Domains (MCTD) 290 The PCC may specify the multi-domain Objective Function code to 291 use when requesting inter-domain path computation, it may also 292 include intra-domain OFs, such as Minimum Cost Path (MCP) [RFC5441], 293 which must be considered by participating child PCEs. 295 2.1.3. Multi-domain Metrics 297 For inter-domain path computation, there are several path metrics of 298 interest. 300 o Domain count (number of domains crossed); 302 o Border Node count. 304 A PCC may be able to limit the number of domains crossed by applying 305 a limit on these metrics. Details in Section 3.4. 307 2.2. Parent PCE Capability Advertisement 309 A PCEP Speaker (Parent PCE or Child PCE) that supports and wishes 310 to use the procedures described in this document must advertise 311 the fact and negotiate its role with its PCEP peers. It does this 312 using the "H-PCE Capability" TLV, described in Section 3.2.1, in the 313 OPEN Object to advertise its support for PCEP extensions for H-PCE 314 Capability. 316 During the PCEP session establishment procedure, the child PCE needs 317 to be capable of indicating to the parent PCE whether it requests the 318 parent PCE capability or not. 320 2.3. PCE Domain Identification 322 A PCE domain is a single domain with an associated PCE. Although it 323 is possible for a PCE to manage multiple domains simultaneously. The 324 PCE domain could be an IGP area or AS. 326 The PCE domain identifiers MAY be provided during the PCEP session 327 establishment procedure. 329 2.4. Domain Diversity 331 In a multi-domain environment, Domain Diversity is defined in 332 [RFC6805] and described as "A pair of paths are domain-diverse if 333 they do not transit any of the same domains. A pair of paths that 334 share a common ingress and egress are domain-diverse if they only 335 share the same domains at the ingress and egress (the ingress and 336 egress domains). Domain diversity may be maximized for a pair of 337 paths by selecting paths that have the smallest number of shared 338 domains." 339 The main motivation behind domain diversity is to avoid fate sharing, 340 but it can also be because of some geo-political reasons and 341 commercial relationships that would require domain diversity. For 342 example, a pair of paths should choose different transit Autonomous 343 System (AS) because of some policy considerations. 345 In the case when full domain diversity could not be achieved, it is 346 helpful to minimize the commonly shared domains. Also, it is 347 interesting to note that other scope of diversity (node, link, SRLG 348 etc.) can still be applied inside the commonly shared domains. 350 3. PCEP Extensions 352 This section defines extensions to PCEP [RFC5440] to support the 353 H-PCE procedures. 355 3.1 Applicability to PCC-PCE Communications 357 Although the extensions defined in this document are intended 358 primarily for use between a child PCE and a parent PCE, they are 359 also applicable for communications between a PCC and its PCE. 361 Thus, the information that may be encoded in a PCReq can be sent 362 from a PCC towards the child PCE. This includes the RP object 363 (Section 3.3) and the Objective Function (OF) codes and objects 364 (Section 3.4). A PCC and a child PCE could also exchange the 365 capability (Section 3.2.1) during its session. 367 This allows a PCC to request paths that transit multiple 368 domains utilizing the capabilities defined in this document. 370 3.2. OPEN Object 372 Two new TLVs are defined in this document to be carried within an 373 OPEN object. This way, during the PCEP session establishment, the 374 H-PCE capability and Domain information can be advertised. 376 3.2.1. H-PCE Capability TLV 378 The H-PCE-CAPABILITY TLV is an optional TLV associated with the OPEN 379 Object [RFC5440] to exchange H-PCE capability of PCEP speakers. 381 Its format is shown in the following figure: 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Type= TBD1 | Length=4 | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Flags |P| 389 +---------------------------------------------------------------+ 391 Figure 1: H-PCE-CAPABILITY TLV format 393 The type of the TLV is TBD1 (to be assigned by IANA), and it has a 394 fixed length of 4 octets. 396 The value comprises a single field - Flags (32 bits): 398 P (Parent PCE Request bit): if set, will signal that the child PCE 399 wishes to use the peer PCE as a parent PCE. 401 Unassigned bits MUST be set to 0 on transmission and MUST be ignored 402 on receipt. 404 The inclusion of this TLV in an OPEN object indicates that the H-PCE 405 extensions are supported by the PCEP speaker. The child PCE MUST 406 include this TLV and set the P flag. The parent PCE MUST include 407 this TLV and unset the P flag. 409 The setting of the P flag (parent PCE request bit) would mean that 410 the PCEP speaker wants the peer to be a parent PCE, so in the case 411 of a PCC to Child-PCE relationship, neither entity would set the P 412 flag. 414 If both peers attempt to set the P flag then the session 415 establishment MUST fail, and the PCEP speaker MUST respond with PCErr 416 message using Error-Type 1: "PCEP Session Establishment Failure" as 417 per [RFC5440]. 419 If the PCE understands the H-PCE path computation request but did not 420 advertise its H-PCE capability, it MUST send a PCErr message with 421 Error-Type=TBD8 ("H-PCE error") and Error-Value=1 ("H-PCE Capability 422 not advertised"). 424 3.2.1.1 Backwards Compatibility 426 Section 7.1 of [RFC5440] requires that "Unrecognized TLVs MUST be 427 ignored. 429 That means that a PCE that does not support this document but that 430 receives an Open Message containing an Open Object that includes 431 an H-PCE-CAPABILITIES TLV will ignore that TLV and will continue to 432 attempt to establish a PCEP session. It will, however, not include 433 the TLV in the Open message that it sends, so the H-PCE relationship 434 will not be created. 436 If a PCE does not support the extensions defined in this document but 437 receives them in a PCEP message (notwithstanding the fact that the 438 session was not established as supporting a H-PCE relationship), the 439 receiving PCE will ignore the H-PCE related parameters because they 440 are all encoded in TLVs within standard PCEP objects. 442 3.2.2. Domain-ID TLV 444 The Domain-ID TLV, when used in the OPEN object, identifies the 445 domains served by the PCE. The child PCE uses this mechanism to 446 inform the domain information to the parent PCE. 448 The Domain-ID TLV is defined below: 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Type= TBD2 | Length | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Domain Type | Reserved | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | | 458 // Domain ID // 459 | | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Figure 2: Domain-ID TLV format 464 The type of the TLV is TBD2 (to be assigned by IANA), and it has a 465 variable Length of the value portion. The value part comprises: 467 Domain Type (8 bits): Indicates the domain type. Four types of 468 domain are currently defined: 470 * Type=1: the Domain ID field carries a 2-byte AS number. Padded 471 with trailing zeros to a 4-byte boundary. 473 * Type=2: the Domain ID field carries a 4-byte AS number. 475 * Type=3: the Domain ID field carries a 4-byte OSPF area ID. 477 * Type=4: the Domain ID field carries (2-byte Area-Len, variable 478 length IS-IS area ID). Padded with trailing zeros to a 4-byte 479 boundary. 481 Reserved: Zero at transmission; ignored at the receipt. 483 Domain ID (variable): Indicates an IGP Area ID or AS number as 484 per the Domain Type field. It can be 2 bytes, 4 bytes or variable 485 length depending on the domain identifier used. It is padded with 486 trailing zeros to a 4-byte boundary. In case of IS-IS it includes 487 the Area-Len as well. 489 In the case a PCE serves more than one domain, multiple Domain-ID 490 TLVs are included for each domain it serves. 492 3.3. RP Object 494 3.3.1. H-PCE-FLAG TLV 496 The H-PCE-FLAG TLV is an optional TLV associated with the RP Object 497 [RFC5440] to indicate the H-PCE path computation request and options. 499 Its format is shown in the following figure: 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Type= TBD3 | Length=4 | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Flags |D|S| 507 +---------------------------------------------------------------+ 509 Figure 3: H-PCE-FLAG TLV format 511 The type of the TLV is TBD3 (to be assigned by IANA), and it has a 512 fixed length of 4 octets. 514 The value comprises a single field - Flags (32 bits): 516 S (Domain Sequence bit): if set, will signal that the child PCE 517 wishes to get only the domain sequence in the path computation 518 reply. Refer to Section 3.7 of [RFC7897] for details. 520 D (Disallow Domain Re-entry bit): if set, will signal that the 521 computed path does not enter a domain more than once. 523 Unassigned bits MUST be set to 0 on transmission and MUST be ignored 524 on receipt. 526 The presence of the TLV indicates that the H-PCE based path 527 computation is requested as per this document. 529 3.3.2. Domain-ID TLV 531 The Domain-ID TLV, carried in an OPEN object, is used to indicate a 532 (list of) managed domains and is described in Section 3.3.1. This 533 TLV, when carried in an RP object, indicates the destination domain 534 ID. If a PCC knows the egress domain, it can supply this information 535 in the PCReq message. The format and procedure of this TLV are 536 defined in Section 3.2.2. 538 If a Domain-id TLV is used in the RP object, and the destination is 539 not actually in the indicated domain, then the parent 540 PCE should respond with a NO-PATH object and NO-PATH VECTOR TLV 541 should be used. A new bit number is assigned to indicate 542 "Destination not found in the indicated domain" (see Section 3.7). 544 3.4. Objective Functions 546 3.4.1. OF Codes 548 [RFC5541] defines a mechanism to specify an Objective Function that 549 is used by a PCE when it computes a path. Three new Objective 550 Functions are defined for H-PCE, these are: 552 o MTD 554 * Name: Minimize the number of Transit Domains (MTD) 556 * Objective Function Code - TBD4 (to be assigned by IANA) 558 * Description: Find a path P such that it passes through the 559 least number of transit domains. 561 * Objective functions are formulated using the following 562 terminology: 564 + A network comprises a set of N domains {Di, (i=1...N)}. 566 + A path P passes through K unique domains {Dpi,(i=1...K)}. 568 + Find a path P such that the value of K is minimized. 570 o MBN 572 * Name: Minimize the number of border nodes. 574 * Objective Function Code - TBD5 (to be assigned by IANA) 575 * Description: Find a path P such that it passes through the 576 least number of border nodes. 578 * Objective functions are formulated using the following 579 terminology: 581 + A network comprises a set of N links {Li, (i=1...N)}. 583 + A path P is a list of K links {Lpi,(i=1...K)}. 585 + D(Lpi) if a function that determines if the links Lpi 586 and Lpi+1 belong to different domains, D(Li) = 1 if link 587 Li and Li+1 belong to different domains, D(Lk) = 0 if 588 link Lk and Lk+1 belong to the same domain. 590 + The number of border node in a path P is denoted by B(P), 591 where B(P) = sum{D(Lpi),(i=1...K-1)}. 593 + Find a path P such that B(P) is minimized. 595 There is one objective function that applies to a set of 596 synchronized path computation requests to increase the domain 597 diversity: 599 o MCTD 601 * Name: Minimize the number of Common Transit Domains 603 * Objective Function Code - TBD13 (to be assigned by IANA) 605 * Description: Find a set of paths such that it passes through 606 the least number of common transit domains. 608 + A network comprises a set of N domains {Di, (i=1...N)}. 610 + A path P passes through K unique domains {Dpi,(i=1...K)}. 612 + A set of paths {P1...Pm} have L transit domains that are 613 common to more than one path {Dpi,(i=1...L)}. 615 + Find a set of paths such that the value of L is minimized. 617 3.4.2. OF Object 619 The OF (Objective Function) object [RFC5541] is carried within a 620 PCReq message so as to indicate the desired/required objective 621 function to be applied by the PCE during path computation. As per 622 Section 3.2 of [RFC5541] a single OF object may be included in a path 623 computation request. 625 The new OF codes described in Section 3.4.1 are applicable at the 626 inter-domain path computation performed by the parent PCE, it is 627 also necessary to specify the OF code that may be applied for the 628 intra-domain path computation performed by the child PCE. To 629 accommodate this, the OF-List TLV (described in Section 2.1. of 630 [RFC5541]) is included in the OF object as an optional TLV. 632 The OF-List TLV allows encoding of multiple OF codes. When this TLV 633 is included inside the OF object, only the first OF-code in the 634 OF-LIST TLV is considered. The parent PCE MUST use this OF code in 635 the OF object when sending the intra domain path computation request 636 to the child PCE. If the OF list TLV is included in the OF Object, 637 the OF Code inside the OF Object MUST include one of the H-PCE 638 Objective Functions defined in this document, the OF Code inside the 639 OF List TLV MUST NOT include an H-PCE Objective Function. If this 640 condition is not met, the PCEP speaker MUST respond with a PCErr 641 message with Error-Type=10 (Reception of an invalid object) and 642 Error-Value=TBD15 (Incompatible OF codes in H-PCE). 644 If the Objective Functions defined in this document are unknown or 645 unsupported by a PCE, then the procedure as defined in [RFC5541] 646 is followed. 648 3.5. Metric Object 650 The METRIC object is defined in Section 7.8 of [RFC5440], comprising 651 of metric-value, metric-type (T field) and flags. This document 652 defines the following types for the METRIC object for H-PCE: 654 o T=TBD6: Domain count metric (number of domains crossed); 656 o T=TBD7: Border Node count metric (number of border nodes crossed). 658 The domain count metric type of the METRIC object encodes the number 659 of domains crossed in the path. The border node count metric type of 660 the METRIC object encodes the number of border nodes in the path. If 661 a domain is re-entered, then domain should be double counted. 663 A PCC or child PCE MAY use the metric in a PCReq message for an 664 inter-domain path computation, meeting the number of domain or border 665 nodes crossing requirement. As per [RFC5440], in this case, the B bit 666 is set to suggest a bound (a maximum) for the metric that must not be 667 exceeded for the PCC to consider the computed path as acceptable. 669 A PCC or child PCE MAY also use this metric to ask the PCE to 670 optimize the metric during inter-domain path computation. In this 671 case, the B flag is cleared, and the C flag is set. 673 The Parent PCE MAY use the metric in a PCRep message along with a 674 NO-PATH object in the case where the PCE cannot compute a path 675 meeting this constraint. A PCE MAY also use this metric to send the 676 computed end to end metric value in a reply message. 678 3.6. SVEC Object 680 [RFC5440] defines SVEC object which includes flags for the potential 681 dependency between the set of path computation requests (Link, Node 682 and SRLG diverse). This document defines a new flag O for domain 683 diversity. 685 The following new bit is added to the Flags field: 687 o Domain Diverse O-bit - TBD14 : when set, this indicates that the 688 computed paths corresponding to the requests specified by the 689 following RP objects MUST NOT have any transit domains in 690 common. 692 The Domain Diverse O-bit can be used in Hierarchical PCE path 693 computation to compute synchronized domain diverse end to end path or 694 diverse domain sequences. 696 When domain diverse O bit is set, it is applied to the transit 697 domains. The other bit in SVEC object (N, L, S etc.) MAY be set and 698 MUST still be applied in the ingress and egress shared domain. 700 3.7. PCEP-ERROR Object 702 3.7.1. Hierarchy PCE Error-Type 704 A new PCEP Error-Type [RFC5440] is used for the H-PCE extension as 705 defined below: 707 +------------+-----------------------------------------+ 708 | Error-Type | Meaning | 709 +------------+-----------------------------------------+ 710 | TBD8 | H-PCE error | 711 | | Error-value=1: H-PCE capability | 712 | | was not advertised | 713 | | Error-value=2: parent PCE capability | 714 | | cannot be provided | 715 +------------+-----------------------------------------+ 717 Figure 4: H-PCE error 719 3.8. NO-PATH Object 721 To communicate the reason(s) for not being able to find a multi- 722 domain path or domain sequence, the NO-PATH object can be used in the 723 PCRep message. [RFC5440] defines the format of the NO-PATH object. 724 The object may contain a NO-PATH-VECTOR TLV to provide additional 725 information about why a path computation has failed. 727 Three new bit flags are defined to be carried in the Flags field in 728 the NO-PATH-VECTOR TLV carried in the NO-PATH Object. 730 o Bit number TBD9: When set, the parent PCE indicates that 731 destination domain unknown; 733 o Bit number TBD10: When set, the parent PCE indicates unresponsive 734 child PCE(s); 736 o Bit number TBD11: When set, the parent PCE indicates no available 737 resource available in one or more domains. 739 o Bit number TBD12: When set, the parent PCE indicates that 740 the destination is not found in the indicated domain. 742 4. H-PCE Procedures 744 The H-PCE path computation procedure is described in [RFC6805]. 746 4.1. OPEN Procedure between Child PCE and Parent PCE 748 If a child PCE wants to use the peer PCE as a parent, it MUST set the 749 P (parent PCE request flag) in the H-PCE-CAPABILITY TLV inside the 750 OPEN object carried in the Open message during the PCEP session 751 initialization procedure. 753 The child PCE MAY also report its list of domain IDs, to the parent 754 PCE, by specifying them in the Domain-ID TLVs in the OPEN object. 755 This object is carried in the OPEN message during the PCEP session 756 initialization procedure 758 The OF codes defined in this document can be carried in the OF-list 759 TLV of the OPEN object. If the OF-list TLV carries the OF codes, it 760 means that the PCE is capable of implementing the corresponding 761 objective functions. This information can be used for selecting a 762 proper parent PCE when a child PCE wants to get a path that satisfies 763 a certain Objective Function. 765 When a child PCE sends a PCReq to a peer PCE, which requires parental 766 activity and H-PCE capability flags TLV but which were not included 767 in the session establishment procedure described above, the peer PCE 768 SHOULD send a PCErr message to the child PCE and MUST specify the 769 error-type=TBD8 (H-PCE error) and error-value=1 (H-PCE capability was 770 not advertised) in the PCEP-ERROR object. 772 When a specific child PCE sends a PCReq to a peer PCE, that requires 773 parental activity and the peer PCE does not want to act as the parent 774 for it, the peer PCE SHOULD send a PCErr message to the child PCE and 775 MUST specify the error-type=TBD8 (H-PCE error) and error-value=2 776 (Parent PCE capability cannot be provided) in the PCEP-ERROR object. 778 4.2. Procedure to Obtain Domain Sequence 780 If a child PCE only wants to get the domain sequence for a multi- 781 domain path computation from a parent PCE, it can set the Domain Path 782 Request bit in the H-PCE-FLAG TLV in the RP object carried in a PCReq 783 message. The parent PCE which receives the PCReq message tries to 784 compute a domain sequence for it (instead of the E2E path). If the 785 domain path computation succeeds the parent PCE sends a PCRep message 786 which carries the domain sequence in the Explicit Route Object (ERO) 787 to the child PCE. Refer to [RFC7897] for more details about domain 788 sub-objects in the ERO. Otherwise, it sends a PCReq message which 789 carries the NO-PATH object to the child PCE. 791 5. Error Handling 793 A PCE that is capable of acting as a parent PCE might not be 794 configured or willing to act as the parent for a specific child PCE. 795 This fact could be determined when the child sends a PCReq that 796 requires parental activity, and could result in a negative response 797 in a PCEP Error (PCErr) message and indicate the hierarchy PCE error- 798 type=TBD8 (H-PCE error) and suitable error-value. (Section 3.7) 800 Additionally, the parent PCE may fail to find the multi-domain path 801 or domain sequence due to one or more of the following reasons: 803 o A child PCE cannot find a suitable path to the egress; 805 o The parent PCE does not hear from a child PCE for a specified 806 time; 808 o The Objective Functions specified in the path request cannot be 809 met. 811 In this case, the parent PCE MAY need to send a negative path 812 computation reply specifying the reason. This can be achieved by 813 including NO-PATH object in the PCRep message. Extension to NO-PATH 814 object is needed to include the aforementioned reasons described in 815 Section 3.7. 817 6. Manageability Considerations 819 General PCE and PCEP management considerations are discussed in 820 [RFC4655] and [RFC5440]. There are additional management 821 considerations for H-PCE which are described in [RFC6805], and 822 repeated in this section. 824 The administrative entity responsible for the management of the 825 parent PCEs must be determined for the following cases: 827 o multi-domains (e.g., IGP areas or multiple ASes) within a single 828 service provider network, the management responsibility for the 829 parent PCE would most likely be handled by the service provider, 831 o multiple ASes within different service provider networks, it may 832 be necessary for a third party to manage the parent PCEs according 833 to commercial and policy agreements from each of the participating 834 service providers. 836 6.1. Control of Function and Policy 838 Control and function will need to be carefully managed in an H-PCE 839 network. A child PCE will need to be configured with the address of 840 its parent PCE. It is expected that there will only be one or two 841 parents of any child. 843 The parent PCE also needs to be aware of the child PCEs for all child 844 domains that it can see. This information is most likely to be 845 configured (as part of the administrative definition of each domain). 847 Discovery of the relationships between parent PCEs and child PCEs 848 do not form part of the hierarchical PCE architecture. Mechanisms 849 that rely on advertising or querying PCE locations across domain or 850 provider boundaries are undesirable for security, scaling, 851 commercial, and confidentiality reasons. The specific behaviour of 852 the child and parent PCE are described in the following sub-sections. 854 6.1.1. Child PCE 856 Support of the hierarchical procedure will be controlled by the 857 management organization responsible for each child PCE. A child PCE 858 must be configured with the address of its parent PCE in order for it 859 to interact with its parent PCE. The child PCE must also be 860 authorized to peer with the parent PCE. 862 6.1.2. Parent PCE 864 The parent PCE MUST only accept path computation requests from 865 authorized child PCEs. If a parent PCE receives requests from an 866 unauthorized child PCE, the request SHOULD be dropped. This means 867 that a parent PCE MUST be able to cryptographically authenticate 868 requests from child PCEs. 870 Multi-party shared key authentication schemes are not recommended for 871 inter-domain relationships because of the potential for impersonation 872 and repudiation and for the operational difficulties should 873 revocation be required. 875 The choice of authentication schemes to employ may be left to 876 implementers of H-PCE and are not discussed further in this document. 878 6.1.3. Policy Control 880 It may be necessary to maintain a policy module on the parent PCE 881 [RFC5394]. This would allow the parent PCE to apply commercially 882 relevant constraints such as SLAs, security, peering preferences, and 883 monetary costs. 885 It may also be necessary for the parent PCE to limit the 886 end-to-end path selection by including or excluding specific domains 887 based on commercial relationships, security implications, and 888 reliability. 890 6.2. Information and Data Models 892 A MIB module for PCEP was published as RFC 7420 [RFC7420] that 893 describes managed objects for modelling of PCEP communication. A 894 YANG module for PCEP has also been proposed [I-D.ietf-pce-pcep-yang]. 896 Additionally, H-PCE MIB module, or additional data model, will be 897 required to report parent PCE and child PCE information, including: 899 o parent PCE configuration and status, 901 o child PCE configuration and information, 903 o notifications to indicate session changes between parent PCEs and 904 child PCEs, and 906 o notification of parent PCE TED updates and changes. 908 6.3. Liveness Detection and Monitoring 910 The hierarchical procedure requires interaction with multiple PCEs. 911 Once a child PCE requests an end-to-end path, a sequence of events 912 occurs that requires interaction between the parent PCE and each 913 child PCE. If a child PCE is not operational, and an alternate 914 transit domain is not available, then the failure must be reported. 916 6.4. Verify Correct Operations 918 Verifying the correct operation of a parent PCE can be performed by 919 monitoring a set of parameters. The parent PCE implementation should 920 provide the following parameters monitored at the parent PCE: 922 o number of child PCE requests, 924 o number of successful hierarchical PCE procedures completions on a 925 per-PCE-peer basis, 927 o number of hierarchical PCE procedure completion failures on a per- 928 PCE-peer basis, and 930 o number of hierarchical PCE procedure requests from unauthorized 931 child PCEs. 933 6.5. Requirements On Other Protocols 935 Mechanisms defined in this document do not imply any new requirements 936 on other protocols. 938 6.6. Impact On Network Operations 940 The hierarchical PCE procedure is a multiple-PCE path computation 941 scheme. Subsequent requests to and from the child and parent PCEs do 942 not differ from other path computation requests and should not have 943 any significant impact on network operations. 945 7. IANA Considerations 947 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 948 registry. This document requests IANA actions to allocate code 949 points for the protocol elements defined in this document. 951 7.1. PCEP TLV Type Indicators 953 IANA Manages the PCEP TLV code point registry (see [RFC5440]). This 954 is maintained as the "PCEP TLV Type Indicators" sub-registry of the 955 "Path Computation Element Protocol (PCEP) Numbers" registry. 957 This document defines three new PCEP TLVs. IANA is requested to make 958 the following allocation: 960 Type TLV name References 961 ----------------------------------------------- 962 TBD1 H-PCE-CAPABILITY TLV This I-D 963 TBD2 Domain-ID TLV This I-D 964 TBD3 H-PCE-FLAG TLV This I-D 966 7.2. H-PCE-CAPABILITY TLV Flags 968 This document requests that a new sub-registry, named "H-PCE- 969 CAPABILITY TLV Flag Field", is created within the "Path Computation 970 Element Protocol (PCEP) Numbers" registry to manage the Flag field in 971 the H-PCE-CAPABILITY TLV of the PCEP OPEN object. 973 New values are to be assigned by Standards Action [RFC8126]. Each 974 bit should be tracked with the following qualities: 976 o Bit number (counting from bit 0 as the most significant bit) 978 o Capability description 980 o Defining RFC 982 The following values are defined in this document: 984 Bit Description Reference 985 -------------------------------------------------- 986 31 P (Parent PCE Request bit) This I.D. 988 7.3. Domain-ID TLV Domain type 990 This document requests that a new sub-registry, named "Domain-ID TLV 991 Domain type", is created within the "Path Computation Element 992 Protocol (PCEP) Numbers" registry to manage the Domain-Type field of 993 the Domain-ID TLV. The allocation policy for this new sub-registry is 994 IETF Review [RFC8126]. 996 Value Meaning 997 ----------------------------------------------- 998 1 2-byte AS number 999 2 4-byte AS number 1000 3 4-byte OSPF area ID 1001 4 Variable length IS-IS area ID 1003 7.4. H-PCE-FLAG TLV Flags 1005 This document requests that a new sub-registry, named "H-PCE-FLAG 1006 TLV Flag Field", is created within the "Path Computation Element 1007 Protocol (PCEP) Numbers" registry to manage the Flag field in the H- 1008 PCE-FLAGS TLV of the PCEP RP object. New values are to be assigned 1009 by Standards Action [RFC8126]. Each bit should be tracked with the 1010 following qualities: 1012 o Bit number (counting from bit 0 as the most significant bit) 1014 o Capability description 1016 o Defining RFC 1018 The following values are defined in this document: 1020 Bit Description Reference 1021 ----------------------------------------------- 1022 31 S (Domain This I.D. 1023 Sequence bit) 1024 30 D (Disallow Domain This I.D. 1025 Re-entry bit) 1027 7.5. OF Codes 1029 IANA maintains a registry of Objective Function (described in 1030 [RFC5541]) at the sub-registry "Objective Function". Three new 1031 Objective Functions have been defined in this document. 1033 IANA is requested to make the following allocations: 1035 Code 1036 Point Name Reference 1037 ------------------------------------------------------ 1038 TBD4 Minimum number of Transit This I.D. 1039 Domains (MTD) 1040 TBD5 Minimize number of Border This I.D. 1041 Nodes (MBN) 1042 TBD13 Minimize the number of This I.D. 1043 Common Transit Domains 1044 (MCTD) 1046 7.6. METRIC Types 1048 IANA maintains one sub-registry for "METRIC object T field". Two new 1049 metric types are defined in this document for the METRIC object 1050 (specified in [RFC5440]). 1052 IANA is requested to make the following allocations: 1054 Value Description Reference 1055 ---------------------------------------------------------- 1056 TBD6 Domain Count metric This I.D. 1057 TBD7 Border Node Count metric This I.D. 1059 7.7. New PCEP Error-Types and Values 1061 IANA maintains a registry of Error-Types and Error-values for use in 1062 PCEP messages. This is maintained as the "PCEP-ERROR Object Error 1063 Types and Values" sub-registry of the "Path Computation Element 1064 Protocol (PCEP) Numbers" registry. 1066 IANA is requested to make the following allocations: 1068 Error-Type Meaning and error values Reference 1069 ------------------------------------------------------ 1070 TBD8 H-PCE Error This I.D. 1072 Error-value=1 H-PCE 1073 Capability not advertised 1075 Error-value=2 Parent PCE 1076 Capability cannot be provided 1078 10 Reception of an invalid object [RFC5440] 1080 Error-value=TBD15: Incompatible This I.D. 1081 OF codes in H-PCE 1083 7.8. New NO-PATH-VECTOR TLV Bit Flag 1085 IANA maintains a sub-registry "NO-PATH-VECTOR TLV Flag Field" of 1086 bit flags carried in the PCEP NO-PATH-VECTOR TLV in the PCEP NO-PATH 1087 object as defined in [RFC5440]. IANA is requested to assign three 1088 new bit flag as follows: 1090 Bit Number Name Flag Reference 1091 ------------------------------------------------------ 1092 TBD9 Destination Domain unknown This I.D. 1093 TBD10 Unresponsive child PCE(s) This I.D. 1094 TBD11 No available resource in This I.D. 1095 one or more domain 1096 TBD12 Destination is not found This I.D. 1097 in the indicated domain. 1099 7.9. SVEC Flag 1101 IANA maintains a sub-registry "SVEC Object Flag Field" of bit flags 1102 carried in the PCEP SVEC object as defined in [RFC5440]. IANA is 1103 requested to assign one new bit flag as follows: 1105 Bit Number Name Flag Reference 1106 ------------------------------------------------------ 1107 TBD14 Domain Diverse O-bit This I.D. 1109 8. Security Considerations 1111 The hierarchical PCE procedure relies on PCEP and inherits the 1112 security considerations defined in [RFC5440]. As PCEP operates over 1113 TCP, it may also make use of TCP security mechanisms, such as TCP 1114 Authentication Option (TCP-AO) [RFC5925] or Transport Layer 1115 Security (TLS) [RFC8253]. 1117 Any multi-domain operation necessarily involves the exchange of 1118 information across domain boundaries. This may represent a 1119 significant security and confidentiality risk especially when the 1120 child domains are controlled by different commercial concerns. PCEP 1121 allows individual PCEs to maintain the confidentiality of their 1122 domain path information using path-keys [RFC5520], and the H-PCE 1123 architecture is specifically designed to enable as much isolation of 1124 domain topology and capabilities information as is possible. 1126 For further considerations of the security issues related to inter-AS 1127 path computation, see [RFC5376]. 1129 9. Contributing Authors 1131 Xian Zhang 1132 Huawei 1133 EMail: zhang.xian@huawei.com 1135 Dhruv Dhody 1136 Huawei Technologies 1137 Divyashree Techno Park, Whitefield 1138 Bangalore, Karnataka 560066 1139 India 1141 EMail: dhruv.ietf@gmail.com 1143 10.Acknowledgements 1145 The authors would like to thank Mike McBride, Kyle Rose, Roni Even 1146 for their detailed review, comments and suggestions which helped 1147 improve this document. 1149 11. References 1151 11.1. Normative References 1153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1154 Requirement Levels", BCP 14, RFC 2119, 1155 DOI 10.17487/RFC2119, March 1997, 1156 . 1158 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1159 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1160 DOI 10.17487/RFC5440, March 2009, 1161 . 1163 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 1164 Objective Functions in the Path Computation Element 1165 Communication Protocol (PCEP)", RFC 5541, 1166 DOI 10.17487/RFC5541, June 2009, 1167 . 1169 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1170 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1171 May 2017, . 1173 11.2. Informative References 1175 [RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. Boyle, Ed., 1176 "Requirements for Inter-Area MPLS Traffic Engineering", 1177 RFC 4105, DOI 10.17487/RFC4105, June 2005, 1178 . 1180 [RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous 1181 System (AS) Traffic Engineering (TE) Requirements", 1182 RFC 4216, DOI 10.17487/RFC4216, November 2005, 1183 . 1185 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1186 Element (PCE)-Based Architecture", RFC 4655, 1187 DOI 10.17487/RFC4655, August 2006, 1188 . 1190 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 1191 Inter-Domain Multiprotocol Label Switching Traffic 1192 Engineering", RFC 4726, DOI 10.17487/RFC4726, November 1193 2006, . 1195 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 1196 Per-Domain Path Computation Method for Establishing Inter- 1197 Domain Traffic Engineering (TE) Label Switched Paths 1198 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 1199 . 1201 [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS 1202 Requirements for the Path Computation Element 1203 Communication Protocol (PCECP)", RFC 5376, 1204 DOI 10.17487/RFC5376, November 2008, 1205 . 1207 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 1208 "Policy-Enabled Path Computation Framework", RFC 5394, 1209 DOI 10.17487/RFC5394, December 2008, 1210 . 1212 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1213 "Preserving Topology Confidentiality in Inter-Domain Path 1214 Computation Using a Path-Key-Based Mechanism", RFC 5520, 1215 DOI 10.17487/RFC5520, April 2009, 1216 . 1218 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 1219 "A Backward-Recursive PCE-Based Computation (BRPC) 1220 Procedure to Compute Shortest Constrained Inter-Domain 1221 Traffic Engineering Label Switched Paths", RFC 5441, 1222 DOI 10.17487/RFC5441, April 2009, 1223 . 1225 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1226 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1227 June 2010, . 1229 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 1230 Path Computation Element Architecture to the Determination 1231 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1232 DOI 10.17487/RFC6805, November 2012, 1233 . 1235 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 1236 Computation Element Architecture", RFC 7399, 1237 DOI 10.17487/RFC7399, October 2014, 1238 . 1240 [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 1241 Hardwick, "Path Computation Element Communication Protocol 1242 (PCEP) Management Information Base (MIB) Module", 1243 RFC 7420, DOI 10.17487/RFC7420, December 2014, 1244 . 1246 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1247 S. Ray, "North-Bound Distribution of Link-State and 1248 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1249 DOI 10.17487/RFC7752, March 2016, 1250 . 1252 [RFC7897] Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects 1253 for the Path Computation Element Communication Protocol 1254 (PCEP)", RFC 7897, DOI 10.17487/RFC7897, June 2016, 1255 . 1257 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1258 Writing an IANA Considerations Section in RFCs", BCP 26, 1259 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1260 . 1262 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1263 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1264 Path Computation Element Communication Protocol (PCEP)", 1265 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1266 . 1268 [I-D.ietf-pce-pcep-yang] 1269 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1270 YANG Data Model for Path Computation Element 1271 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1272 yang-11 (work in progress), March 2019. 1274 [I-D.ietf-pce-stateful-hpce] 1275 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 1276 and O. Dios, "Hierarchical Stateful Path Computation 1277 Element (PCE).", draft-ietf-pce-stateful-hpce-07 (work in 1278 progress), April 2019. 1280 [I-D.dhodylee-pce-pcep-ls] 1281 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 1282 Distribution of Link-State and TE Information.", draft- 1283 dhodylee-pce-pcep-ls-13 (work in progress), February 2019. 1285 Authors' Addresses 1287 Fatai Zhang 1288 Huawei 1289 Huawei Base, Bantian, Longgang District 1290 Shenzhen 518129 1291 China 1293 EMail: zhangfatai@huawei.com 1295 Quintin Zhao 1296 Huawei 1297 125 Nagog Technology Park 1298 Acton, MA 01719 1299 USA 1301 EMail: quintin.zhao@huawei.com 1303 Oscar Gonzalez de Dios 1304 Telefonica 1305 Don Ramon de la Cruz 82-84 1306 Madrid 28045 1307 Spain 1309 EMail: oscar.gonzalezdedios@telefonica.com 1311 Ramon Casellas 1312 CTTC 1313 Av. Carl Friedrich Gauss n.7 1314 Barcelona, Castelldefels 1315 Spain 1317 EMail: ramon.casellas@cttc.es 1319 Daniel King 1320 Old Dog Consulting 1321 UK 1323 EMail: daniel@olddog.co.uk 1325 Appendix 1327 A1. Implementation Status 1328 The H-PCE architecture and protocol procedures describe in this I-D 1329 were implemented and tested for a variety of optical research 1330 applications. 1332 The Appendix should be removed before publication. 1334 A1.1. Inter-layer traffic engineering with H-PCE 1336 This work was led by: 1338 o Ramon Casellas [ramon.casellas@cttc.es] 1340 o Centre Tecnologic de Telecomunicacions de Catalunya (CTTC) 1342 The H-PCE instances (parent and child) were multi-threaded 1343 asynchronous processes. Implemented in C++11, using C++ Boost 1344 Libraries. The targeted system used to deploy and run H-PCE 1345 applications was a POSIX system (Debian GNU/Linux operating system). 1347 Some parts of the software may require a Linux Kernel, the 1348 availability of a Routing Controller running collocated in the same 1349 host and the usage of libnetfilter / libipq and GNU/Linux firewalling 1350 capabilities. Most of the functionality, including algorithms is 1351 done by means of plugins (e.g., as shared libraries or .so files in 1352 Unix systems). 1354 The CTTC PCE supports the H-PCE architecture, but also supports 1355 stateful PCE with active capabilities, as an OpenFlow controller, and 1356 has dedicated plugins to support monitoring, BRPC, P2MP, path keys, 1357 back end PCEs. Management of the H-PCE entities was supported via 1358 HTTP and CLI via Telnet. 1360 Further details of the H-PCE prototyping and experimentation can be 1361 found in the following scientific papers: 1363 R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I. 1364 Morita, "Inter-layer traffic engineering with hierarchical-PCE in 1365 MPLS-TP over wavelength switched optical networks" , Optics 1366 Express, Vol. 20, No. 28, December 2012. 1368 R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I. 1369 Morita, M. Msurusawa, "Dynamic virtual link mesh topology 1370 aggregation in multi-domain translucent WSON with hierarchical- 1371 PCE", Optics Express Journal, Vol. 19, No. 26, December 2011. 1373 R. Casellas, R. Munoz, R. Martinez, R. Vilalta, L. Liu, T. 1374 Tsuritani, I. Morita, V. Lopez, O. Gonzalez de Dios, J. P. 1375 Fernandez-Palacios, "SDN based Provisioning Orchestration of 1376 OpenFlow/GMPLS Flexi-grid Networks with a Stateful Hierarchical 1377 PCE", in Proceedings of Optical Fiber Communication Conference and 1378 Exposition (OFC), 9-13 March, 2014, San Francisco (EEUU). 1379 Extended Version to appear in Journal Of Optical Communications 1380 and Networking January 2015 1382 F. Paolucci, O. Gonzalez de Dios, R. Casellas, S. Duhovnikov, 1383 P. Castoldi, R. Munoz, R. Martinez, "Experimenting Hierarchical 1384 PCE Architecture in a Distributed Multi-Platform Control Plane 1385 Testbed" , in Proceedings of Optical Fiber Communication 1386 Conference and Exposition (OFC) and The National Fiber Optic 1387 Engineers Conference (NFOEC), 4-8 March, 2012, Los Angeles, 1388 California (USA). 1390 R. Casellas, R. Martinez, R. Munoz, L. Liu, T. Tsuritani, I. 1391 Morita, M. Tsurusawa, "Dynamic Virtual Link Mesh Topology 1392 Aggregation in Multi-Domain Translucent WSON with Hierarchical- 1393 PCE", in Proceedings of 37th European Conference and Exhibition on 1394 Optical Communication (ECOC 2011), 18-22 September 2011, Geneve ( 1395 Switzerland). 1397 R. Casellas, R. Munoz, R. Martinez, "Lab Trial of Multi-Domain 1398 Path Computation in GMPLS Controlled WSON Using a Hierarchical 1399 PCE", in Proceedings of OFC/NFOEC Conference (OFC2011), 10 March 1400 2011, Los Angeles (USA). 1402 A1.2. Telefonica Netphony (Open Source PCE) 1404 The Telefonica Netphony PCE is an open source Java-based 1405 implementation of a Path Computation Element, with several flavours, 1406 and a Path Computation Client. The PCE follows a modular 1407 architecture and allows to add customized algorithms. The PCE has 1408 also stateful and remote initiation capabilities. In current 1409 version, three components can be built, a domain PCE (aka child PCE), 1410 a parent PCE (ready for the H-PCE architecture) and a PCC (path 1411 computation client). 1413 This work was led by: 1415 o Oscar Gonzalez de Dios [oscar.gonzalezdedios@telefonica.com] 1417 o Victor Lopez Alvarez [victor.lopezalvarez@telefonica.com] 1419 o Telefonica I+D, Madrid, Spain 1421 The PCE code is publicly available in a GitHub repository: 1423 o https://github.com/telefonicaid/netphony-pce 1424 The PCEP protocol encodings are located in the following repository: 1426 o https://github.com/telefonicaid/netphony-network protocols 1428 The traffic engineering database and a BGP-LS speaker to fill the 1429 database is located in: 1431 o https://github.com/telefonicaid/netphony-topology 1433 The parent and child PCE are multi-threaded java applications. The 1434 path computation uses the jgrapht free Java class library (0.9.1) 1435 that provides mathematical graph-theory objects and algorithms. 1436 Current version of netphony PCE runs on java 1.7 and 1.8, and has 1437 been tested in GNU/Linux, Mac OS-X and Windows environments. The 1438 management of the parent and domain PCEs is supported though CLI via 1439 Telnet, and configured via XML files. 1441 Further details of the netphony H-PCE prototyping and experimentation 1442 can be found in the following research papers: 1444 o O. Gonzalez de Dios, R. Casellas, F. Paolucci, A. Napoli, L. 1445 Gifre, A. Dupas, E, Hugues-Salas, R. Morro, S. Belotti, G. 1446 Meloni, T. Rahman, V.P Lopez, R. Martinez, F. Fresi, M. Bohn, 1447 S. Yan, L. Velasco, . Layec and J. P. Fernandez-Palacios: 1448 Experimental Demonstration of Multivendor and Multidomain EON With 1449 Data and Control Interoperability Over a Pan-European Test Bed, in 1450 Journal of Lightwave Technology, Dec. 2016, Vol. 34, Issue 7, pp. 1451 1610-1617. 1453 o O. Gonzalez de Dios, R. Casellas, R. Morro, F. Paolucci, V. 1454 Lopez, R. Martinez, R. Munoz, R. Villalta, P. Castoldi: 1455 "Multi-partner Demonstration of BGP-LS enabled multi-domain EON, 1456 in Journal of Optical Communications and Networking, Dec. 2015, 1457 Vol. 7, Issue 12, pp. B153-B162. 1459 o F. Paolucci, O. Gonzalez de Dios, R. Casellas, S. Duhovnikov, 1460 P. Castoldi, R. Munoz, R. Martinez, "Experimenting Hierarchical 1461 PCE Architecture in a Distributed Multi-Platform Control Plane 1462 Testbed" , in Proceedings of Optical Fiber Communication 1463 Conference and Exposition (OFC) and The National Fiber Optic 1464 Engineers Conference (NFOEC), 4-8 March, 2012, Los Angeles, 1465 California (USA). 1467 A1.3. H-PCE Proof of Concept developed by Huawei 1469 Huawei developed this H-PCE on the Huawei Versatile Routing Platform 1470 (VRP) to experiment with the hierarchy of PCE. Both end to end path 1471 computation as well as computation for domain-sequence are supported. 1473 This work was led by: 1475 o Udayasree Pallee [udayasreereddy@gmail.com] 1477 o Dhruv Dhody [dhruv.ietf@gmail.com] 1479 o Huawei Technologies, Bangalore, India 1481 Further work on stateful H-PCE [I-D.ietf-pce-stateful-hpce] is being 1482 carried out on ONOS.