idnits 2.17.1 draft-king-pce-hierarchy-fwk-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 (April 18, 2011) is 4728 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5316 (Obsoleted by RFC 9346) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. King (Ed.) 2 Internet-Draft Old Dog Consulting 3 Intended Status: Informational A. Farrel (Ed.) 4 Expires: October 18, 2011 Old Dog Consulting 5 April 18, 2011 7 The Application of the Path Computation Element Architecture to the 8 Determination of a Sequence of Domains in MPLS and GMPLS 10 draft-king-pce-hierarchy-fwk-06.txt 12 Abstract 14 Computing optimum routes for Label Switched Paths (LSPs) across 15 multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS 16 networks presents a problem because no single point of path 17 computation is aware of all of the links and resources in each 18 domain. A solution may be achieved using the Path Computation 19 Element (PCE) architecture. 21 Where the sequence of domains is known a priori, various techniques 22 can be employed to derive an optimum path. If the domains are 23 simply-connected, or if the preferred points of interconnection are 24 also known, the Per-Domain Path Computation technique can be used. 25 Where there are multiple connections between domains and there is 26 no preference for the choice of points of interconnection, the 27 Backward Recursive Path Computation Procedure (BRPC) can be used to 28 derive an optimal path. 30 This document examines techniques to establish the optimum path when 31 the sequence of domains is not known in advance. The document 32 shows how the PCE architecture can be extended to allow the optimum 33 sequence of domains to be selected, and the optimum end-to-end path 34 to be derived through the use of a hierarchical relationship between 35 domains. 37 Status of this Memo 39 This Internet-Draft is submitted to IETF in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF), its areas, and its working groups. Note that 44 other groups may also distribute working documents as Internet- 45 Drafts. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt. 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html. 57 This Internet-Draft will expire on October 18, 2011. 59 Copyright Notice 61 Copyright (c) 2011 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Contents 76 1. Introduction..................................................3 77 1.1 Problem Statement.........................................4 78 1.2 Definition of a Domain............. ......................5 79 1.3 Assumptions and Requirements..............................5 80 1.3.1 Metric Objectives...................................6 81 1.3.2 Domain Diversity....................................6 82 1.3.3 Existing Traffic Engineering Constraints............7 83 1.3.4 Commercial Constraints..............................7 84 1.3.5 Domain Confidentiality..............................7 85 1.3.6 Limiting Information Aggregation....................7 86 1.3.7 Domain Interconnection Discovery....................7 87 1.4 Terminology...............................................7 88 2. Per Domain Path Computation...................................8 89 3. Backward Recursive Path Computation...........................9 90 3.1. Applicability of BRPC when the Domain Path is not Known..10 91 4. Hierarchical PCE..............................................10 92 5. Hierarchical PCE Procedures...................................11 93 5.1 Objective Functions and Policy............................11 94 5.2 Maintaining Domain Confidentiality........................12 95 5.3 PCE Discovery.............................................12 96 5.4 Parent Domain Traffic Engineering Database................13 97 5.5 Determination of Destination Domain ......................14 98 5.6 Hierarchical PCE Examples.................................14 99 5.6.1 Hierarchical PCE Initial Information Exchange.......17 100 5.6.2 Hierarchical PCE End-to-End Path Computation 101 Procedure Example.........................................17 102 5.7 Hierarchical PCE Error Handling...........................17 103 5.8 Hierarchical PCEP Protocol Extensions.....................18 104 5.8.1 PCEP Request Qualifiers.............................18 105 5.8.2 Indication of H-PCE Capability......................18 106 5.8.3 Intention to Utilize Parent PCE Capabilities........19 107 5.8.4 Communication of Domain Connectivity Information....19 108 5.8.5 Domain Identifiers..................................19 109 6. Hierarchical PCE Applicability................................20 110 6.1 Antonymous Systems and Areas..............................20 111 6.2 ASON architecture (G-7715-2)..............................20 112 6.2.1 Implicit Consistency Between Hierarchical PCE and 113 G.7715.2..................................................21 114 6.2.2 Benefits of Hierarchical PCEs in ASON...............23 115 7. Management Considerations ....................................23 116 7.1 Control of Function and Policy............................23 117 7.1.1 Child PCE...........................................23 118 7.1.2 Parent PCE..........................................23 119 7.1.3 Policy Control......................................24 120 7.2 Information and Data Models...............................24 121 7.3 Liveness Detection and Monitoring.........................24 122 7.4 Verifying Correct Operation...............................24 123 7.5. Impact on Network Operation..............................25 124 8. Security Considerations ......................................25 125 9. IANA Considerations ..........................................25 126 10. Acknowledgements ............................................25 127 11. References ..................................................26 128 11.1. Normative References....................................26 129 11.2. Informative References .................................26 130 12. Authors' Addresses ..........................................27 132 1. Introduction 134 The capability to compute the routes of end-to-end inter-domain MPLS 135 Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs) may be 136 provided by a Path Computation Element (PCE). The PCE architecture is 137 defined in [RFC4655]. The methods for establishing and controlling 138 inter-domain MPLS-TE and GMPLS LSPs are documented in [RFC4726]. 140 A domain can be defined as a separate administrative, geographic, or 141 switching environment within the network. A domain may be further 142 defined as a zone of routing or computational ability. Under these 143 definitions a domain might be categorized as an Antonymous System 144 (AS) or an Interior Gateway Protocol (IGP) area [RFC4726] and 145 [RFC4655]. Domains are connected through ingress and egress 146 boundary nodes (BNs). A more detailed definition is given in 147 Section 1.2. 149 In a multi-domain environment, the determination of an end-to-end 150 traffic engineered path is a problem because no single point of path 151 computation is aware of all of the links and resources in each 152 domain. PCEs can be used to compute end-to-end paths using a per- 153 domain path computation technique [RFC5152]. Alternatively, the 154 backward recursive path computation (BRPC) mechanism [RFC5441] 155 allows multiple PCEs to collaborate in order to select an optimal 156 end-to-end path that crosses multiple domains. Both mechanisms 157 assume that the sequence of domains to be crossed between ingress 158 and egress in known in advance. 160 This document examines techniques to establish the optimum path when 161 the sequence of domains is not known in advance. It shows how the PCE 162 architecture can be extended to allow the optimum sequence of domains 163 to be selected, and the optimum end-to-end path to be derived. 165 The model described in this document introduces a hierarchical 166 relationship between domains. It is applicable to environments with 167 small groups of domains where visibility from the ingress Label 168 Switching Router (LSR) is limited. Applying the hierarchical PCE 169 model to large groups of domains such as the Internet, is not 170 considered feasible or desirable, and is out of scope for this 171 document. 173 1.1 Problem Statement 175 Using a PCE to compute a path between nodes within a single domain is 176 relatively straightforward. Computing an end-to-end path when the 177 source and destination nodes are located in different domains 178 requires co-operation between multiple PCEs, each responsible for 179 its own domain. 181 Techniques for inter-domain path computation described so far 182 ([RFC5152] and [RFC5441]) assume that the sequence of domains to be 183 crossed from source to destination is well known. No explanation is 184 given (for example, in [RFC4655]) of how this sequence is generated 185 or what criteria may be used for the selection of paths between 186 domains. In small clusters of domains, such as simple cooperation 187 between adjacent ISPs, this selection process is not complex. In more 188 advanced deployments (such as optical networks constructed from 189 multiple sub-domains, or multi-AS environments) the choice of domains 190 in the end-to-end domain sequence can be critical to the 191 determination of an optimum end-to-end path. 193 This document introduces the concept of a hierarchical PCE 194 architecture and shows how to coordinate PCEs in peer domains in 195 order to derive an optimal end-to-end path. 197 The work is currently scoped to operate with a small group of domains 198 and there is no intent to apply this model to a large group of 199 domains, e.g., to the Internet. 201 1.2 Definition of a Domain 203 A domain is defined in [RFC4726] as any collection of network 204 elements within a common sphere of address management or path 205 computational responsibility. Examples of such domains include 206 IGP areas and Autonomous Systems. Wholly or partially overlapping 207 domains are not within the scope of this document. 209 In the context of GMPLS, a particularly important example of a domain 210 is the Automatically Switched Optical Network (ASON) subnetwork 211 [G-8080]. In this case, computation of an end-to-end path requires 212 the selection of nodes and links within a parent domain where some 213 nodes may, in fact, be subnetworks. Furthermore, a domain might be an 214 ASON routing area [G-7715]. A PCE may perform the path computation 215 function of an ASON routing controller as described in [G-7715-2]. 217 See Section 6.2 for a further discussion of the applicability to the 218 ASON architecture. 220 This document assumes that the selection of a sequence of domains for 221 an end-to-end path is in some sense a hierarchical path computation 222 problem. That is, where one mechanism is used to determine a path 223 across a domain, a separate mechanism (or at least a separate set 224 of paradigms) is used to determine the sequence of domains. 226 1.3 Assumptions and Requirements 228 Networks are often constructed from multiple domains. These 229 domains are often interconnected via multiple interconnect points. 230 Its assumed that the sequence of domains for an end-to-end path is 231 not always well known; that is, an application requesting end-to-end 232 connectivity has no preference for, or no ability to specify, the 233 sequence of domains to be crossed by the path. 235 The traffic engineering properties of a domain cannot be seen from 236 outside the domain. Traffic engineering aggregation or abstraction, 237 hides information and can lead to failed path setup or the selection 238 of suboptimal end-to-end paths [RFC4726]. The aggregation process 239 may also have significant scaling issues for networks with many 240 possible routes and multiple TE metrics. Flooding TE information 241 breaks confidentiality and does not scale in the routing protocol. 243 The primary goal of this document is to define how to derive optimal 244 end-to-end, multi-domain paths when the sequence of domains is not 245 known in advance. The solution needs to be scalable and to maintain 246 internal domain topology confidentiality while providing the optimal 247 end-to-end path. It cannot rely on the exchange of TE information 248 between domains, and it cannot utilise a computation element that has 249 universal knowledge of TE properties and topology of all domains. 251 The sub-sections that follow set out the primary objectives and 252 requirements to be satisfied by a PCE solution to multi-domain path 253 computation. 255 1.3.1 Metric Objectives 257 The definition of optimality is dependent on policy, and is based on 258 a single objective or a group objectives. An objective is expressed 259 as an objective function [RFC5541] and may be specified on a path 260 computation request. The following objective functions are identified 261 in this document. They define how the path metrics and TE link 262 qualities are manipulated during inter-domain path computation. The 263 list is not proscriptive and may be expanded in other documents. 265 o Minimize the cost of the path [RFC5541] 266 o Select a path using links with the minimal load [RFC5541] 267 o Select a path that leaves the maximum residual bandwidth [RFC5541] 268 o Minimize aggregate bandwidth consumption [RFC5541] 269 o Minimize the Load of the most loaded Link [RFC5541] 270 o Minimize the Cumulative Cost of a set of paths [RFC5541] 271 o Minimize the number of boundary nodes used 272 o Limit the number of domains crossed 273 o Disallow domain re-entry 275 See Section 5.1 for further discussion of objective functions. 277 1.3.2 Domain Diversity 279 A pair of paths are domain-diverse if they do not transit any of the 280 same domains. A pair of paths that share a common ingress and egress 281 are domain-diverse if they only share the same domains at the ingress 282 and egress (the ingress and egress domains). Domain diversity may be 283 maximized for a pair of paths by selecting paths that have the 284 smallest number of shared domains. (Note that this is not the same 285 as finding paths with the greatest number of distinct domains!) 287 Path computation should facilitate the selection of paths that share 288 ingress and egress domains, but do not share any transit domains. 289 This provides a way to reduce the risk of shared failure along any 290 path, and automatically helps to ensure path diversity for most of 291 the route of a pair of LSPs. 293 Thus, domain path selection should provide the capability to include 294 or exclude specific domains and specific boundary nodes. 296 1.3.3 Existing Traffic Engineering Constraints 298 Any solution should take advantage of typical traffic engineering 299 constraints (hop count, bandwidth, lambda continuity, path cost, 300 etc.) to meet the service demands expressed in the path computation 301 request [RFC4655]. 303 1.3.4 Commercial Constraints 305 The solution should provide the capability to include commercially 306 relevant constraints such as policy, SLAs, security, peering 307 preferences, and dollar costs. 309 Additionally it may be necessary for the service provider to 310 request that specific domains are included or excluded based on 311 commercial relationships, security implications, and reliability. 313 1.3.5 Domain Confidentiality 315 A key requirement is the ability to maintain domain confidentiality 316 when computing inter-domain end-to-end paths. When required by local 317 policy, a PCE should not need to disclose to any other PCE the intra- 318 domain paths it computes or the internal topology of the domain it 319 serves. 321 1.3.6 Limiting Information Aggregation 323 It is important to minimise the amount of aggregation within the 324 solution. There should be no associated computation burden or 325 requirement to aggregate and abstract traffic engineering link 326 information. 328 1.3.7 Domain Interconnection Discovery 330 To support domain mesh topologies, the solution should allow the 331 discovery and selection of domain inter-connections. Pre- 332 configuration of preferred domain interconnections should also be 333 supported for network operators that have bilateral agreement, and 334 preference for the choice of points of interconnection. 336 1.4 Terminology 338 This document uses PCE terminology defined in [RFC4655], [RFC4875], 339 and [RFC5440]. Additional terms are defined below. 341 Domain Path: The sequence of domains for a path. 343 Ingress Domain: The domain that includes the ingress LSR of a path. 345 Transit Domain: A domain that has an upstream and downstream 346 neighbor domain for a specific path. 348 Egress Domain: The domain that includes the egress LSR of a path. 350 Boundary Nodes: Each Domain has entry LSRs and exit LSRs that could 351 be Area Border Routers (ABRs) or Autonomous System Border Routers 352 (ASBRs) depending on the type of domain. They are defined here more 353 generically as Boundary Nodes (BNs). 355 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) 356 on a path. 358 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) 359 on a path. 361 Parent Domain: A domain higher up in a domain hierarchy such 362 that it contains other domains (child domains) and potentially other 363 links and nodes. 365 Child Domain: A domain lower in a domain hierarchy such that it has 366 a parent domain. 368 Parent PCE: A PCE responsible for selecting a path across a parent 369 domain and any number of child domains by coordinating with child 370 PCEs and examining a topology map that shows domain inter- 371 connectivity. 373 Child PCE: A PCE responsible for computing the path across one or 374 more specific (child) domains. A child PCE maintains a relationship 375 with at least one parent PCE. 377 OF: Objective Function: A set of one or more optimization 378 criteria used for the computation of a single path (e.g., path cost 379 minimization), or the synchronized computation of a set of paths 380 (e.g., aggregate bandwidth consumption minimization). See [RFC4655] 381 and [RFC5541]. 383 2. Per-Domain Path Computation 385 The per-domain path computation method for establishing inter-domain 386 TE-LSPs [RFC5152] defines a technique whereby the path is computed 387 during the signalling process on a per-domain basis. The entry BN of 388 each domain is responsible for performing the path computation for 389 the section of the LSP that crosses the domain, or for requesting 390 that a PCE for that domain computes that piece of the path. 392 During per-domain path computation, each computation results in the 393 best path across the domain to provide connectivity to the next 394 domain in the domain sequence (usually indicated in signalling by an 395 identifier of the next domain or the identity of the next entry BN). 397 Per-domain path computation may lead to sub-optimal end-to-end paths 398 because the most optimal path in one domain may lead to the choice of 399 an entry BN for the next domain that results in a very poor path 400 across that next domain. 402 In the case that the domain path (in particular, the sequence of 403 boundary nodes) is not known, the PCE must select an exit BN based on 404 some determination of how to reach the destination that is outside 405 the domain for which the PCE has computational responsibility. 406 [RFC5152] suggest that this might be achieved using the IP shortest 407 path as advertise by BGP. Note, however, that the existence of an IP 408 forwarding path does guarantee the presence of sufficient bandwidth, 409 let alone an optimal TE path. Furthermore, in many GMPLS systems 410 inter-domain IP routing will not be present. Thus, per-domain path 411 computation may require a significant number of crankback routing 412 attempts to establish even a sub-optimal path. 414 Note also that the PCEs in each domain may have different computation 415 capabilities, may run different path computation algorithms, and may 416 apply different sets of constraints and optimization criteria, etc. 417 This can result in the end-to-end path being inconsistent and sub- 418 optimal. 420 Per-domain path computation can suit simply-connected domains where 421 the preferred points of interconnection are known. 423 3. Backward Recursive Path Computation 425 The Backward Recursive Path Computation (BRPC) [RFC5441] procedure 426 involves cooperation and communication between PCEs in order to 427 compute an optimal end-to-end path across multiple domains. The 428 sequence of domains to be traversed can either be determined before 429 or during the path computation. In the case where the sequence of 430 domains is known, the ingress Path Computation Client (PCC) sends a 431 path computation request to the PCE responsible for the ingress 432 domain. This request is forwarded between PCEs, domain-by-domain, to 433 the PCE responsible for the egress domain. The PCE in the egress 434 domain creates a set of optimal paths from all of the domain entry 435 BNs to the egress LSR. This set is represented as a tree of potential 436 paths called a Virtual Shortest Path Tree (VSPT), and the PCE passes 437 it back to the previous PCE on the domain path. As the VSPT is passed 438 back toward the ingress domain, each PCE computes the optimal paths 439 from its entry BNs to its exit BNs that connect to the rest of the 440 tree. It adds these paths to the VSPT and passes the VSPT on until 441 the PCE for the ingress domain is reached and computes paths from the 442 ingress LSR to connect to the rest of the tree. The ingress PCE then 443 selects the optimal end-to-end path from the tree, and returns the 444 path to the initiating PCC. 446 BRPC may suit environments where multiple connections exist between 447 domains and there is no preference for the choice of points of 448 interconnection. It is best suited to scenarios where the domain 449 path is known in advance, but can also be used when the domain path 450 is not known. 452 3.1. Applicability of BRPC when the Domain Path is Not Known 454 As described above BRPC can be used to determine an optimal inter- 455 domain path when the sequence is known. Even when the sequence of 456 domains is not known BRPC could be used as follows. 458 o The PCC sends a request to the PCE for the ingress domain (the 459 ingress PCE). 461 o The ingress PCE sends the path computation request direct to the 462 PCE responsible for the domain containing the destination node (the 463 egress PCE). 465 o The egress PCE computes an egress VSPT and passes it to a PCE 466 responsible for each of the adjacent (potentially upstream) 467 domains. 469 o Each PCE in turn constructs a VSPT and passes it on to all of its 470 neighboring PCEs. 472 o When the ingress PCE has received a VSPT from each of its 473 neighboring domains it is able to select the optimum path. 475 Clearly this mechanism (which could be called path computation 476 flooding) has significant scaling issues. It could be improved by 477 the application of policy and filtering, but such mechanisms are not 478 simple and would still leave scaling concerns. 480 4. Hierarchical PCE 482 In the hierarchical PCE architecture, a parent PCE maintains a domain 483 topology map that contains the child domains (seen as vertices in the 484 topology) and their interconnections (links in the topology). The 485 parent PCE has no information about the content of the child domains; 486 that is, the parent PCE does not know about the resource availability 487 within the child domains, nor about the availability of connectivity 488 across each domain. The parent PCE is aware of the TE capabilities of 489 the interconnections between child domains as these interconnections 490 are links in its own topology map. 492 Note that in the case that the domains are IGP areas, there is no 493 link between the domains (the ABRs have a presence in both 494 neighboring areas). The parent domain may choose to represent this in 495 its TED as a virtual link that is unconstrained and has zero cost, 496 but this is entirely an implementation issue. 498 Each child domain has at least one PCE capable of computing paths 499 across the domain. These PCEs are known as child PCEs and have a 500 relationship with the parent PCE. Each child PCE also knows the 501 identity of the domains that neighbor its own domain. A child PCE 502 only knows the topology of the domain that it serves and does not 503 know the topology of other child domains. Child PCEs are also not 504 aware of the general domain mesh connectivity (i.e., the domain 505 topology map) beyond the connectivity to the immediate neighbor 506 domains of the domain it serves. 508 The parent PCE builds the domain topology map either from 509 configuration or from information received from each child PCE. This 510 tells it how the domains are interconnected including the TE 511 properties of the domain interconnections. But the parent PCE does 512 not know the contents of the child domains. Discovery of the domain 513 topology and domain interconnections is discussed further in Section 514 5.3. 516 When a multi-domain path is needed, the ingress PCE sends a request 517 to the parent PCE (using the path computation element protocol, PCEP 518 [RFC5440]). The parent PCE selects a set of candidate domain paths 519 based on the domain topology and the state of the inter-domain links. 520 It then sends computation requests to the child PCEs responsible for 521 each of the domains on the candidate domain paths. 523 Each child PCE computes a set of candidate path segments across its 524 domain and sends the results to the parent PCE. The parent PCE uses 525 this information to select path segments and concatenate them to 526 derive the optimal end-to-end inter-domain path. The end-to-end path 527 is then sent to the child PCE which received the initial path request 528 and this passes the path on to the PCC that issues the original 529 request. 531 5. Hierarchical PCE Procedures 533 5.1 Objective Functions and Policy 535 Deriving the optimal end-to-end domain path sequence is dependent on 536 the policy applied during domain path computation. An Objective 537 Function (OF) [RFC5541], or set of OFs, may be applied to define the 538 policy being applied to the domain path computation. 540 The OF specifies the desired outcome of the computation. It does 541 not describe the algorithm to use. When computing end-to-end inter- 542 domain paths, required OFs may include (see Section 1.3.1): 544 o Minimum cost path 545 o Minimum load path 546 o Maximum residual bandwidth path 547 o Minimize aggregate bandwidth consumption 548 o Minimize the number of boundary nodes used 549 o Minimize the number of transit domains 550 o Disallow domain re-entry 552 The objective function may be requested by the PCC, the ingress 553 domain PCE (according to local policy), or maybe applied by the 554 parent PCE according to inter-domain policy. 556 5.2 Maintaining Domain Confidentiality 558 Information about the content of child domains is not shared for 559 scaling and confidentiality reasons. This means that a parent PCE is 560 aware of the domain topology and the nature of the connections 561 between domains, but is not aware of the content of the domains. 562 Similarly, a child PCE cannot know the internal topology of another 563 child domain. Child PCEs also do not know the general domain mesh 564 connectivity, this information is only known by the parent PCE. 566 As described in the earlier sections of this document, PCEs can 567 exchange path information in order to construct an end-to-end inter- 568 domain path. Each per-domain path fragment reveals information about 569 the topology and resource availability within a domain. Some 570 management domains or ASes will not want to share this information 571 outside of the domain (even with a trusted parent PCE). In order to 572 conceal the information, a PCE may replace a path segment with a 573 path-key [RFC5520]. This mechanism effectively hides the content of a 574 segment of a path. 576 5.3 PCE Discovery 578 It is a simple matter for each child PCE to be configured with the 579 address of its parent PCE. Typically, there will only be one or two 580 parents of any child. 582 The parent PCE also needs to be aware of the child PCEs for all child 583 domains that it can see. This information is most likely to be 584 configured (as part of the administrative definition of each 585 domain). 587 Discovery of the relationships between parent PCEs and child PCEs 588 does not form part of the H-PCE architecture. Mechanisms that rely on 589 advertising or querying PCE locations across domain or provider 590 boundaries are undesirable for security, scaling, commercial, and 591 confidentiality reasons. 593 The parent PCE also needs to know the inter-domain connectivity. 594 This information could be configured with suitable policy and 595 commercial rules, or could be learned from the child PCEs as 596 described in Section 4. 598 In order for the parent PCE to learn about domain interconnection 599 the child PCE will report the identity of its neighbor domains. The 600 IGP in each neighbor domain can advertise its inter-domain TE 601 link capabilities [RFC5316], [RFC5392]. This information can be 602 collected by the child PCEs and forwarded to the parent PCE, or the 603 parent PCE could participate in the IGP in the child domains. 605 5.4 Parent Domain Traffic Engineering Database 607 The parent PCE maintains a domain topology map of the child domains 608 and their interconnectivity. Where inter-domain connectivity is 609 provided by TE links the capabilities of those links must also be 610 known to the parent PCE. Furthermore the parent domain 611 may contain nodes and links in its own right. Therefore, the 612 parent PCE maintains a traffic engineering database (TED) for 613 the parent domain in the same way that any PCE does. 615 The parent domain may just be the collection of child domains and the 616 inter-domain links, or it may contain nodes and links in its own 617 right. 619 The mechanism for building the parent TED is likely to rely heavily 620 on administrative configuration and commercial issues because the 621 network was probably partitioned into domains specifically to address 622 these issues. 624 In practice, certain information may be passed from the child domains 625 to the parent PCE to help build the parent TED. In theory, the parent 626 PCE could listen to the routing protocols in the child domains, but 627 this would violate the confidentiality and scaling issues that may be 628 responsible for the partition of the network into domains. So it is 629 much more likely that a suitable solution will involve specific 630 communication from an entity in the child domain (such as the child 631 PCE) to convey the necessary information. As already mentioned, the 632 "necessary information" relates to how the child domains are inter- 633 connected. The topology and available resources within the child 634 domain do not need to be communicated to the parent PCE: doing so 635 would violate the PCE architecture. Mechanisms for reporting this 636 information are described in the examples in Section 5.6 in abstract 637 terms as "a child PCE reports its neighbor domain connectivity to its 638 parent PCE"; the specifics of a solution are out of scope of this 639 document, but the requirements are indicated in Section 5.8. 641 In models such as ASON (see Section 6.2), it is possible to consider 642 a separate instance of an IGP running within the parent domain where 643 the participating protocol speakers are the nodes directly present in 644 that domain and the PCEs (routing controllers) responsible for each 645 of the child domains. 647 5.5 Determination of Destination Domain 649 The PCC asking for an inter-domain path computation is aware of the 650 identity of the destination node by definition. If it knows the 651 egress domain it can supply this information as part of the path 652 computation request. However, if it does not know the egress domain 653 this information must be determined by the parent PCE. 655 In some specialist topologies the parent PCE could determine the 656 destination domain based on the destination address, for example from 657 configuration. However, this is not appropriate for many multi-domain 658 addressing scenarios. In IP-based multi-domain networks the 659 parent PCE may be able to determine the destination domain by 660 participating in inter-domain routing. Finally, the parent PCE could 661 issue specific requests to the child PCEs to discover if they contain 662 the destination node, but this has scaling implications. 664 5.6 Hierarchical PCE Examples 666 The following example describes the hierarchical domain topology. 667 Figure 1 (sample hierarchical domain topology) demonstrates four 668 interconnected domains within a fifth parent domain. Each domain 669 contains a single PCE: 671 o Domain 1 is the ingress domain and child PCE 1 is able to compute 672 paths within the domain. Its neighbors are Domain 2 and Domain 4. 673 The domain also contains the source LSR (S) and three egress 674 boundary nodes (BN11, BN12, and BN13). 676 o Domain 2 is served by child PCE 2. Its neighbors are Domain 1 and 677 Domain 3. The domain also contains four boundary nodes (BN21, BN22, 678 BN23, and BN24). 680 o Domain 3 is the egress domain and is served by child PCE 3. Its 681 neighbors are Domain 2 and Domain 4. The domain also contains the 682 destination LSR (D) and three ingress boundary nodes (BN31, BN32, 683 and BN33). 685 o Domain 4 is served by child PCE 4. Its neighbors are Domain 2 and 686 Domain 3. The domain also contains two boundary nodes (BN41 and 687 BN42). 689 All of these domains are encompassed within Domain 5 which is served 690 by the parent PCE (PCE 5). 692 ----------------------------------------------------------------- 693 | Domain 5 | 694 | ----- | 695 | |PCE 5| | 696 | ----- | 697 | | 698 | ---------------- ---------------- ---------------- | 699 | | Domain 1 | | Domain 2 | | Domain 3 | | 700 | | | | | | | | 701 | | ----- | | ----- | | ----- | | 702 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 703 | | ----- | | ----- | | ----- | | 704 | | | | | | | | 705 | | ----| |---- ----| |---- | | 706 | | |BN11+---+BN21| |BN23+---+BN31| | | 707 | | - ----| |---- ----| |---- - | | 708 | | |S| | | | | |D| | | 709 | | - ----| |---- ----| |---- - | | 710 | | |BN12+---+BN22| |BN24+---+BN32| | | 711 | | ----| |---- ----| |---- | | 712 | | | | | | | | 713 | | ---- | | | | ---- | | 714 | | |BN13| | | | | |BN33| | | 715 | -----------+---- ---------------- ----+----------- | 716 | \ / | 717 | \ ---------------- / | 718 | \ | | / | 719 | \ |---- ----| / | 720 | ----+BN41| |BN42+---- | 721 | |---- ----| | 722 | | | | 723 | | ----- | | 724 | | |PCE 4| | | 725 | | ----- | | 726 | | | | 727 | | Domain 4 | | 728 | ---------------- | 729 | | 730 ----------------------------------------------------------------- 732 Figure 1 : Sample Hierarchical Domain Topology 734 Figure 2, shows the view of the domain topology as seen by the parent 735 PCE (PCE 5). This view is an abstracted topology; PCE 5 is aware of 736 domain connectivity, but not of the internal topology within each 737 domain. 739 ---------------------------- 740 | Domain 5 | 741 | ---- | 742 | |PCE5| | 743 | ---- | 744 | | 745 | ---- ---- ---- | 746 | | |---| |---| | | 747 | | D1 | | D2 | | D3 | | 748 | | |---| |---| | | 749 | ---- ---- ---- | 750 | \ ---- / | 751 | \ | | / | 752 | ----| D4 |---- | 753 | | | | 754 | ---- | 755 | | 756 ---------------------------- 758 Figure 2 : Abstract Domain Topology as Seen by the Parent PCE 760 5.6.1 Hierarchical PCE Initial Information Exchange 762 Based on the Figure 1 topology, the following is an illustration of 763 the initial hierarchical PCE information exchange. 765 1. Child PCE 1, the PCE responsible for Domain 1, is configured 766 with the location of its parent PCE (PCE5). 768 2. Child PCE 1 establishes contact with its parent PCE. The parent 769 applies policy to ensure that communication with PCE 1 is allowed. 771 3. Child PCE 1 listens to the IGP in its domain and learns its 772 inter-domain connectivity. That is, it learns about the links 773 BN11-BN21, BN12-BN22, and BN13-BN41. 775 4. Child PCE 1 reports its neighbor domain connectivity to its parent 776 PCE. 778 5. Child PCE 1 reports any change in the resource availability on its 779 inter-domain links to its parent PCE. 781 Each child PCE performs steps 1 through 5 so that the parent PCE can 782 create a domain topology view as shown in Figure 2. 784 5.6.2 Hierarchical PCE End-to-End Path Computation Procedure 786 The procedure below is an example of a source PCC requesting an 787 end-to-end path in a multi-domain environment. The topology is 788 represented in Figure 1. It is assumed that the each child PCE has 789 connected to its parent PCE and exchanged the initial information 790 required for the parent PCE to create its domain topology view as 791 described in Section 5.6.1. 793 1. The source PCC (the ingress LSR in our example), sends a request 794 to the PCE responsible for its domain (PCE1) for a path to the 795 destination LSR. 797 2. PCE 1 determines the destination, is not in domain 1. 799 3. PCE 1 sends a computation request to its parent PCE (PCE 5). 801 4. The parent PCE determines that the destination is in Domain 3. 802 (See Section 5.5). 804 5. PCE 5 determines the likely domain paths according to the domain 805 interconnectivity and TE capabilities between the domains. For 806 example, three domain paths (S-BN11-BN21-D2-BN23-BN31-D, S-BN11- 807 BN21-D2-BN24-BN32-D, and S-BN13-BN41-D4-BN42-BN33-D) are 808 determined (assuming the link BN12-BN22 is not suitable for the 809 requested path). 811 6. PCE 5 sends edge-to-edge path computation requests to PCE 2 812 which is responsible for Domain 2 (e.g., BN21-BN23 and BN21-BN24) 813 and to PCE 4 for Domain 4 (e.g., BN41-BN42). 815 7. PCE 5 sends source-to-edge path computation requests to PCE 1 816 which is responsible for Domain 1 (e.g., S-BN11 and S-BN13). 818 8. PCE 5 sends edge-to-egress path computation requests to PCE3 819 which is responsible for Domain 3 (e.g., BN31-D, BN32-D, and 820 BN33-D). 822 9. PCE 5 correlates all the computation responses from each child 823 PCE, adds in the information about the inter-domain links, and 824 applies any requested and locally configured policies. 826 10. PCE 5 then selects the optimal end-to-end multi-domain path 827 that meets the policies and objective functions, and supplies the 828 resulting path to PCE 1. 830 11. PCE 1 forwards the path to the PCC (the ingress LSR). 832 5.7 Hierarchical PCE Error Handling 834 In the event that a child PCE in a domain cannot find a suitible 835 path to the egress. The child PCE should return the relevent 836 error notifying the parent PCE. Depending on the error response the 837 parent PCE can elect to: 839 o Cancel the request and send the relevent response back to the 840 intial child PCE requesting an end-to-end path. 841 o Relax the contraints associated with the intial path request; 842 o Select another candidate domain and send the path request to the 843 child PCE responsible for the domain. 845 If the parent PCE does not recieve a response from a child PCE within 846 an alloted time period. The parent PCE can either: 848 o Send the path request to another child PCE in the same domain, if a 849 secoundary child PCE exists; 850 o Select another candidate domain and send the path request to the 851 child PCE responsible for that domain. 853 5.8 Requirements for Hierarchical PCEP Protocol Extensions 855 This section lists the high-level requirements for extensions to the 856 PCEP to support the hierachical PCE model. 858 [Editors Note: This section may be expanded as work progresses.] 860 5.8.1 PCEP Request Qualifiers 862 PCEP request (PCReq) messages are used by a PCC or a PCE to make a 863 computation request or enquiry to a PCE. The requests are qualified 864 so that the PCE knows what type of action is required. 866 Support of the H-PCE architecture will introduce two new 867 qualifications as follows: 869 o It must be possible for a child PCE to indicate that the request it 870 sends to a parent PCE shold be satisfied by a domain sequence only, 871 that is, not by a full end-to-end path. This allows the child PCE 872 to initiate per-domain or backward recursive path computation. 874 o A parent PCE needs to be able to ask a child PCE whether a 875 particular node address (the destination of an end-to-end path) is 876 present in the domain that the child PCE serves. 878 In PCEP, such request qualifications are carried as bit-flags in the 879 RP object carried within the PCReq message. 881 5.8.2 Indication of H-PCE Capability 883 Although parent/child PCE relationships are likely configured, it 884 assist network operations if the parent PCE is able to indicate to 885 the child that it really is capable of acting as a parent PCE. This 886 will help to trap misconfigurations. 888 A parent PCE needs a way to indicate that is capable of acting as a 889 parent PCE, and should also be able to indicate the identity of the 890 parent domain. This informaiton is most obviously carried in the Open 891 Object within the Open message. 893 5.8.3 Intention to Utilize Parent PCE Capabilities 895 A PCE that is capable of acting as a parent PCE might not be 896 configured or willing to act as the parent for a specific child PCE. 897 This fact could be determined when the child sends a PCReq that 898 requires parental activity (such as querying other child PCEs), and 899 could result in a negative response in a PCEP Error (PCErr) message. 901 However, the expense of a poorly targetted PCReq can be avoided if 902 the child PCE indicates that it might wish to use the parent as a 903 parent (for example, on the Open message), and if the parent 904 determines at that time whether it is willing to act as a parent to 905 this child. 907 5.8.4 Communication of Domain Connectivity Information 909 Section 5.4 describes how the parent PCE needs a parent TED and 910 indicates that the information might be supplied from the child PCEs 911 in each domain. This requires a mechanism whereby information about 912 inter-domain links can be supplied by a child PCE to a parent PCE, 913 for example on a PCEP Notify (PCNtf) message. 915 The information that would be exchanged includes: 917 o Identifier of advertising child PCE 918 o Identifier of PCE's domain 919 o Identifier of the link 920 o TE properties of the link (metrics, bandwidth) 921 o Other properties of the link (technology-specific) 922 o Identifier of link end-points 923 o Identifier of adjacent domain 925 It may be desirable for this information to be periodically updated, 926 for example, when available bandwidth changes. In this case, the 927 parent PCE might be given the ability to configure thresholds in the 928 child PCE to prevent flapping of information. 930 5.8.5 Domain Identifiers 932 Domain identifiers are already needed to allow a PCE to indicate 933 which domains it serves, and to allow the representation of domains 934 as abstract nodes in paths. The wider use of domains in the context 935 of this work on H-PCE will require that domains can be identified in 936 more places within objects in PCEP messages. This should pose no 937 problems. 939 However, more attention may need to be applied to the precision of 940 domian identifier definitions. 942 6. Hierarchical PCE Applicability 944 As per [RFC4655], PCE can inherently support inter-domain path 945 computation for any definition of a domain as set out in Section 1.2. 947 Hierarchical PCE can be applied to inter-domain environments, 948 including Antonymous Systems and IGP areas. The hierarchical PCE 949 procedures make no distinction between, Antonymous Systems and IGP 950 area applications, although it should be noted that the TED 951 maintained by a parent PCE must be able to support the concept of 952 child domains connected by inter-domain links or directly connected 953 at boundary nodes (see Section 4). 955 This section sets out the applicability of hierarchical PCE to three 956 environments: 958 o MPLS traffic engineering across multiple Autonomous Systems 959 o MPLS traffic engineering across multiple IGP areas 960 o GMPLS traffic engineering in the ASON architecture 962 6.1 Antonymous Systems and Areas 964 Networks are comprised of domains. A domain can be considered to be 965 a collection of network elements within an AS or area that has a 966 common sphere of address management or path computational 967 responsibility. 969 As networks increase in size and complexity it may be required to 970 introduce scaling methods to reduce the amount information flooded 971 within the network and make the network more manageable. An IGP 972 hierarchy is designed to improve IGP scalability by dividing the 973 IGP domain into areas and limiting the flooding scope of topology 974 information to within area boundaries. This restricts visibility of 975 the area to routers in a single area. If a router needs to compute a 976 route to destination located in another AS or area a method is 977 required to compute a path across teh AS and area boundaries. 979 When an LSR within an AS or area needs to compute a path across an 980 area or AS boundary it must also use an inter-AS computation 981 technique. Hierachical PCE is equally applicable to computing 982 inter-area and inter-AS MPLS and GMPLS paths across domain 983 boundaries. 985 6.2 ASON Architecture 986 The International Telecommunications Union (ITU) defines the ASON 987 architecture in [G-8080]. [G-7715] defines the routing architecture 988 for ASON and introduces a hierarchical architecture. In this 989 architecture, the Routing Areas (RAs) have a hierarchical 990 relationship between different routing levels, which means a parent 991 (or higher level) RA can contain multiple child RAs. The 992 interconnectivity of the lower RAs is visible to the higher level RA. 993 Note that the RA hierarchy can be recursive. 995 In the ASON framework, a path computation request is termed a Route 996 Query. This query is executed before signaling is used to establish 997 an LSP termed a Switched Connection (SC) or a Soft Permanent 998 Connection (SPC). [G-7715-2] defines the requirements and 999 architecture for the functions performed by Routing Controllers (RC) 1000 during the operation of remote route queries - an RC is synonymous 1001 with a PCE. For an end-to-end connection, the route may be computed 1002 by a single RC or multiple RCs in a collaborative manner (i.e., RC 1003 federations). In the case of RC federations, [G-7715-2] describes 1004 three styles during remote route query operation: 1006 o Step-by-step remote path computation 1007 o Hierarchical remote path computation 1008 o A combination of the above. 1010 In a hierarchical ASON routing environment, a child RC may 1011 communicate with its parent RC (at the next higher level of the ASON 1012 routing hierarchy) to request the computation of an end-to-end path 1013 across several RAs. It does this using a route query message (known 1014 as the abstract message RI_QUERY). The corresponding parent RC may 1015 communicate with other child RCs that belong to other child RAs at 1016 the next lower hierarchical level. Thus, a parent RC can act as 1017 either a Route Query Requester or Route Query Responder. 1019 It can be seen that the hierarchical PCE architecture fits the 1020 hierarchical ASON routing architecture well. It can be used to 1021 provide paths across subnetworks, and to determine end-to-end paths 1022 in networks constructed from multiple subnetworks or RAs. 1024 When hierarchical PCE is applied to implement hierarchical remote 1025 path computation in [G-7715-2], it is very important for operators to 1026 understand the different terminology and implicit consistency 1027 between hierarchical PCE and [G-7715-2]. 1029 6.2.1 Implicit Consistency Between Hierarchical PCE and G.7715.2 1031 This section highlights the correspondence between features of the 1032 hierarchical PCE architecture and the ASON routing architecture. 1034 (1) RC (Routing Controller) and PCE (Path Computation Element) 1036 [G-8080] describes the Routing Controller Component as an 1037 abstract entity, which is responsible for responding to requests 1038 for path (route) information and topology information. It can be 1039 implemented as a single entity, or as a distributed set of 1040 entities that make up a cooperative federation. 1042 [RFC4655] describes PCE (Path Computation Element) is an entity 1043 (component, application, or network node) that is capable of 1044 computing a network path or route based on a network graph and 1045 applying computational constraints. 1047 Therefore, in the ASON architecture, a PCE can be regarded as a 1048 realizations of the RC. 1050 (2) Route Query Requester/Route Query Responder and PCC/PCE 1052 [G-7715-2] describes the Route Query Requester as a Connection 1053 Controller or Routing Controller that sends a route query message 1054 to a Routing Controller requesting for one or more paths that 1055 satisfy a set of routing constraints. The Route Query Responder 1056 is a Routing Controller that performs path computation upon 1057 receipt of a route query message from a Route Query Requester, 1058 sending a response back at the end of the path computation. 1060 In the context of ASON, a signaling controller initiates and 1061 processes signaling messages and closely coupled to a signaling 1062 protocol speaker. A routing controller makes routing decisions 1063 and is usually coupled to configuration entities and/or routing a 1064 protocol speaker. 1066 It can be seen that a PCC corresponds to a Route Query Requester, 1067 and a PCE corresponds to a Route Query Responder. A PCE/RC can 1068 also act as a Route Query Requester sending requests to another 1069 Route Query Responder. 1071 The PCEP path computation request (PCReq) and path computation 1072 reply (PCRep) messages between PCC and PCE correspond to the 1073 RI_QUERY and RI_UPDATE messages in [G-7715-2]. 1075 (3) Routing Area Hierarchy and Hierarchical Domain 1077 The ASON routing hierarchy model is shown in Figure 6 of 1078 [G-7715] through an example that illustrates routing area levels. 1079 If the hierarchical remote path computation mechanism of 1080 [G-7715-2] is applied in this scenario, each routing area should 1081 have at least one RC for route query function and there is a 1082 parent RC for the child RCs in each routing area. 1084 According to [G-8080], the parent RC has visibility of the 1085 structure of the lower level, so it knows the interconnectivity 1086 of the RAs in the lower level. Each child RC can compute edge-to- 1087 edge paths across its own child RA. 1089 Thus, an RA corresponds to a domain, and the hierarchical 1090 relationship between RAs corresponds to the hierarchical 1091 relationship between domains. Furthermore, a parent PCE in a 1092 parent domain can be regarded as parent RC in a higher routing 1093 level, and a child PCE in a child domain can be regarded as child 1094 RC in a lower routing level. 1096 6.2.2 Benefits of Hierarchical PCEs in ASON 1098 RCs in an ASON environment can use the hierarchical PCE model to 1099 fully match the ASON hierarchical routing model, so the hierarchical 1100 PCE mechanisms can be applied to fully satisfy the architecture and 1101 requirements of [G-7715-2] without any changes. If the hierarchical 1102 PCE mechanism is applied in ASON, it can be used to determine end-to- 1103 end optimized paths across sub-networks and RAs before initiating 1104 signaling to create the connection. It can also improve the 1105 efficiency of connection setup to avoid crankback. 1107 7. Management Considerations 1109 General PCE management considerations are discussed in [RFC4655]. In 1110 the case of the hierarchical PCE architecture, there are additional 1111 management considerations. 1113 The administrative entity responsible for the management of the 1114 parent PCEs must be determined. In the case of multi-domains (e.g., 1115 IGP areas or multiple ASes) within a single service provider 1116 network, the management responsibility for the parent PCE would most 1117 likely be handled by the service provider. In the case of multiple 1118 ASes within different service provider networks, it may be necessary 1119 for a third-party to manage the parent PCEs according to commercial 1120 and policy agreements from each of the participating service 1121 providers. 1123 7.1 Control of Function and Policy 1125 7.1.1 Child PCE 1127 Support of the hierarchical procedure will be controlled by the 1128 management organization responsible for each child PCE. A child PCE 1129 must be configured with the address of its parent PCE in order for 1130 it to interact with its parent PCE. The child PCE must also be 1131 authorized to peer with the parent PCE. 1133 7.1.2 Parent PCE 1135 The parent PCE must only accept path computation requests from 1136 authorized child PCEs. If a parent PCE receives requests from an 1137 unauthorized child PCE, the request should be dropped. 1139 This means that a parent PCE must be configured with the identities 1140 and security credentials of all of its child PCEs, or there must be 1141 some form of shared secret that allows an unknown child PCE to be 1142 authorized by the parent PCE. 1144 7.1.3 Policy Control 1146 It may be necessary to maintain a policy module on the parent PCE 1147 [RFC5394]. This would allow the parent PCE to apply commercially 1148 relevant constraints such as SLAs, security, peering preferences, and 1149 dollar costs. 1151 It may also be necessary for the parent PCE to limit end-to-end path 1152 selection by including or excluding specific domains based on 1153 commercial relationships, security implications, and reliability. 1155 7.2 Information and Data Models 1157 A PCEP MIB module is defined in [PCEP-MIB] that describes managed 1158 objects for modeling of PCEP communication. An additional PCEP MIB 1159 will be required to report parent PCE and child PCE information, 1160 including: 1162 o Parent PCE configuration and status, 1164 o Child PCE configuration and information, 1166 o Notifications to indicate session changes between parent PCEs and 1167 child PCEs. 1169 o Notification of parent PCE TED updates and changes. 1171 7.3 Liveness Detection and Monitoring 1173 The hierarchical procedure requires interaction with multiple PCEs. 1174 Once a child PCE requests an end-to-end path, a sequence of events 1175 occurs that requires interaction between the parent PCE and each 1176 child PCE. If a child PCE is not operational, and an alternate 1177 transit domain is not available, then a failure must be reported. 1179 7.4 Verifying Correct Operation 1181 Verifying the correct operation of a parent PCE can be performed by 1182 monitoring a set of parameters. The parent PCE implementation should 1183 provide the following parameters: 1185 Parameters monitored by the parent PCE: 1187 o Number of child PCE requests. 1189 o Number of successful hierarchical PCE procedures completions on a 1190 per-PCE-peer basis. 1192 o Number of hierarchical PCE procedure completion failures on a per- 1193 PCE-peer basis. 1195 o Number of hierarchical PCE procedure requests from unauthorized 1196 child PCEs. 1198 7.5. Impact on Network Operation 1200 The hierarchical PCE procedure is a multiple-PCE path computation 1201 scheme. Subsequent requests to and from the child and parent PCEs do 1202 not differ from other path computation requests and should not have 1203 any significant impact on network operations. 1205 8. Security Considerations 1207 The hierarchical PCE procedure relies on PCEP and inherits the 1208 security requirements defined [RFC5440]. Any multi-domain 1209 operation necessarily involves the exchange of information across 1210 domain boundaries. This is bound to represent a significant 1211 security and confidentiality risk especially when the child 1212 domains are controlled by different commercial concerns. 1214 The hierarchical PCE architecture makes use of PCE policy 1215 [RFC5394] and the security aspects of the PCE communication protocol 1216 documented in [RFC5440]. It is expected that the parent PCE will 1217 require all child PCEs to use full security when communicating with 1218 the parent and that security will be maintained by not supporting the 1219 discovery by a parent of child PCEs. 1221 Confidentiality may be enhanced by the use of Path Keys [RFC5520]. 1223 Further considerations of the security issues related to inter-AS 1224 path computation see [RFC5376]. 1226 9. IANA Considerations 1228 This document makes no requests for IANA action. 1230 10. Acknowledgements 1232 The authors would like to thank David Amzallag, Oscar Gonzalez de 1233 Diosm and Franz Rambach for their comments and suggestions. 1235 11. References 1237 11.1 Normative References 1239 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1240 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1242 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1243 Path Computation Method for Establishing Inter-Domain 1244 Traffic Engineering (TE) Label Switched Paths (LSPs)", 1245 RFC 5152, February 2008. 1247 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 1248 "Policy-Enabled Path Computation Framework", RFC 5394, 1249 December 2008. 1251 [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, 1252 A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, 1253 "Path Computation Element (PCE) Communication Protocol 1254 (PCEP)", RFC 5440, March 2009. 1256 [RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based 1257 Computation (BRPC) procedure to compute shortest inter- 1258 domain Traffic Engineering Label Switched Paths", RFC 1259 5441, April 2009. 1261 [RFC5520] Brandford, R., Vasseur J.P., and Farrel A., "Preserving 1262 Topology Confidentiality in Inter-Domain Path 1263 Computation Using a Key-Based Mechanism 1264 RFC5520, April 2009. 1266 [G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for 1267 the automatically switched optical network (ASON). 1269 [G-7715] ITU-T Recommendation G.7715 (2002), Architecture 1270 and Requirements for the Automatically 1271 Switched Optical Network (ASON). 1273 [G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON 1274 routing architecture and requirements for remote route 1275 query. 1277 11.2. Informative References 1279 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework 1280 for Inter-Domain Multiprotocol Label Switching Traffic 1281 Engineering", RFC 4726, November 2006. 1283 [RFC4875] Aggarwal, R., Papadimitriou, D., and Yasukawa, S., 1284 "Extensions to Resource Reservation Protocol - Traffic 1285 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1286 Switched Paths (LSPs)", RFC 4875, May 2007. 1288 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1289 Path Computation Method for Establishing Inter-Domain 1290 Traffic Engineering (TE) Label Switched Paths (LSPs)", 1291 RFC 5152, February 2008. 1293 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 1294 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1295 Traffic Engineering", RFC 5316, December 2008. 1297 [RFC5376] Bitar, N., et al., "Inter-AS Requirements for the 1298 Path Computation Element Communication Protocol 1299 (PCECP)", RFC 5376, November 2008. 1301 [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 1302 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1303 Traffic Engineering", RFC 5392, January 2009. 1305 [RFC5541] Roux, J., Vasseur, J., and Y. Lee, "Encoding 1306 of Objective Functions in the Path 1307 Computation Element Communication 1308 Protocol (PCEP)", RFC5541, December 2008. 1310 [PCEP-MIB] Stephan, E., K. Koushik, Q. Zhao, and D. King, "PCE 1311 communication protocol (PCEP) Management Information 1312 Base", Work in Progress, June 2010 1314 12. Authors' Addresses 1316 Daniel King 1317 Old Dog Consulting 1318 Email: daniel@olddog.co.uk 1320 Adrian Farrel 1321 Old Dog Consulting 1322 Email: adrian@olddog.co.uk 1324 Quintin Zhao 1325 Huawei Technology 1326 125 Nagog Technology Park 1327 Acton, MA 01719 1328 US 1329 Email: qzhao@huawei.com 1330 Fatai Zhang 1331 Huawei Technologies 1332 F3-5-B R&D Center, Huawei Base 1333 Bantian, Longgang District 1334 Shenzhen 518129 P.R.China 1335 Email: zhangfatai@huawei.com