idnits 2.17.1 draft-ietf-pce-hierarchy-fwk-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (28 June 2012) is 4292 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: 28 November 2012 Old Dog Consulting 5 28 June 2012 7 The Application of the Path Computation Element Architecture to the 8 Determination of a Sequence of Domains in MPLS and GMPLS 10 draft-ietf-pce-hierarchy-fwk-04.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 28 November 2012. 59 Copyright Notice 61 Copyright (c) 2012 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 Diversity...........................................6 82 1.3.2.1 Physical Diversity..........................6 83 1.3.2.2 Domain Diversity............................7 84 1.3.3 Existing Traffic Engineering Constraints............7 85 1.3.4 Commercial Constraints..............................7 86 1.3.5 Domain Confidentiality..............................7 87 1.3.6 Limiting Information Aggregation....................8 88 1.3.7 Domain Interconnection Discovery....................8 89 1.4 Terminology...............................................8 90 2. Examination of Existing PCE Mechanisms........................9 91 2.1 Per Domain Path Computation...............................9 92 2.2 Backward Recursive Path Computation.......................10 93 2.2.1 Applicability of BRPC when the Domain Path is not 94 Known.................................................10 95 3. Hierarchical PCE..............................................11 96 4. Hierarchical PCE Procedures...................................12 97 4.1 Objective Functions and Policy............................12 98 4.2 Maintaining Domain Confidentiality........................13 99 4.3 PCE Discovery.............................................13 100 4.4 Parent Domain Traffic Engineering Database................14 101 4.5 Determination of Destination Domain ......................15 102 4.6 Hierarchical PCE Examples.................................15 103 4.6.1 Hierarchical PCE Initial Information Exchange.......17 104 4.6.2 Hierarchical PCE End-to-End Path Computation 105 Procedure Example.........................................17 106 4.7 Hierarchical PCE Error Handling...........................19 107 4.8 Hierarchical PCEP Protocol Extensions.....................19 108 4.8.1 PCEP Request Qualifiers.............................19 109 4.8.2 Indication of H-PCE Capability......................20 110 4.8.3 Intention to Utilize Parent PCE Capabilities........20 111 4.8.4 Communication of Domain Connectivity Information....20 112 4.8.5 Domain Identifiers..................................21 113 5. Hierarchical PCE Applicability................................21 114 5.1 Antonymous Systems and Areas..............................21 115 5.2 ASON architecture (G-7715-2)..............................22 116 5.2.1 Implicit Consistency Between Hierarchical PCE and 117 G.7715.2..................................................23 118 5.2.2 Benefits of Hierarchical PCEs in ASON...............24 119 6. A Note on BGP-TE..............................................24 120 6.1 Use of BGP for TED Synchronization........................25 121 7. Management Considerations ....................................25 122 7.1 Control of Function and Policy............................25 123 7.1.1 Child PCE...........................................25 124 7.1.2 Parent PCE..........................................26 125 7.1.3 Policy Control......................................26 126 7.2 Information and Data Models...............................26 127 7.3 Liveness Detection and Monitoring.........................26 128 7.4 Verifying Correct Operation...............................26 129 7.5. Impact on Network Operation..............................27 130 8. Security Considerations ......................................27 131 9. IANA Considerations ..........................................28 132 10. Acknowledgements ............................................28 133 11. References ..................................................28 134 11.1. Normative References....................................28 135 11.2. Informative References .................................29 136 12. Authors' Addresses ..........................................12 138 1. Introduction 140 The capability to compute the routes of end-to-end inter-domain MPLS 141 Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs) is 142 expressed as requirements in [RFC4105] and [RFC4216]. This capability 143 may be realized by a Path Computation Element (PCE). The PCE 144 architecture is defined in [RFC4655]. The methods for establishing 145 and controlling inter-domain MPLS-TE and GMPLS LSPs are documented in 146 [RFC4726]. 148 In this context, a domain can be defined as a separate 149 administrative, geographic, or switching environment within the 150 network. A domain may be further defined as a zone of routing or 151 computational ability. Under these definitions a domain might be 152 categorized as an Antonymous System (AS) or an Interior Gateway 153 Protocol (IGP) area [RFC4726] and [RFC4655]. Domains are connected 154 through ingress and egress boundary nodes (BNs). A more detailed 155 definition is given in Section 1.2. 157 In a multi-domain environment, the determination of an end-to-end 158 traffic engineered path is a problem because no single point of path 159 computation is aware of all of the links and resources in each 160 domain. PCEs can be used to compute end-to-end paths using a per- 161 domain path computation technique [RFC5152]. Alternatively, the 162 backward recursive path computation (BRPC) mechanism [RFC5441] 163 allows multiple PCEs to collaborate in order to select an optimal 164 end-to-end path that crosses multiple domains. Both mechanisms 165 assume that the sequence of domains to be crossed between ingress 166 and egress is known in advance. 168 This document examines techniques to establish the optimum path when 169 the sequence of domains is not known in advance. It shows how the PCE 170 architecture can be extended to allow the optimum sequence of domains 171 to be selected, and the optimum end-to-end path to be derived. 173 The model described in this document introduces a hierarchical 174 relationship between domains. It is applicable to environments with 175 small groups of domains where visibility from the ingress Label 176 Switching Router (LSR) is limited. Applying the hierarchical PCE 177 model to large groups of domains such as the Internet, is not 178 considered feasible or desirable, and is out of scope for this 179 document. 181 This document does not specify any protocol extensions or 182 enhancements. That work is left for future protocol specification 183 documents. However, some assumptions are made about which protocols 184 will be used to provide specific functions, and guidelines to 185 future protocol developers are made in the form of requirements 186 statements. 188 1.1 Problem Statement 190 Using a PCE to compute a path between nodes within a single domain is 191 relatively straightforward. Computing an end-to-end path when the 192 source and destination nodes are located in different domains 193 requires co-operation between multiple PCEs, each responsible for 194 its own domain. 196 Techniques for inter-domain path computation described so far 197 ([RFC5152] and [RFC5441]) assume that the sequence of domains to be 198 crossed from source to destination is well known. No explanation is 199 given (for example, in [RFC4655]) of how this sequence is generated 200 or what criteria may be used for the selection of paths between 201 domains. In small clusters of domains, such as simple cooperation 202 between adjacent ISPs, this selection process is not complex. In more 203 advanced deployments (such as optical networks constructed from 204 multiple sub-domains, or in multi-AS environments) the choice of 205 domains in the end-to-end domain sequence can be critical to the 206 determination of an optimum end-to-end path. 208 1.2 Definition of a Domain 210 A domain is defined in [RFC4726] as any collection of network 211 elements within a common sphere of address management or path 212 computational responsibility. Examples of such domains include 213 IGP areas and Autonomous Systems. Wholly or partially overlapping 214 domains are not within the scope of this document. 216 In the context of GMPLS, a particularly important example of a domain 217 is the Automatically Switched Optical Network (ASON) subnetwork 218 [G-8080]. In this case, a domain might be an ASON Routing Area 219 [G-7715]. Furthermore, computation of an end-to-end path requires 220 the selection of nodes and links within a routing area where some 221 nodes may, in fact, be subnetworks. A PCE may perform the path 222 computation function of an ASON Routing Controller as described in 223 [G-7715-2]. See Section 5.2 for a further discussion of the 224 applicability to the ASON architecture. 226 This document assumes that the selection of a sequence of domains for 227 an end-to-end path is in some sense a hierarchical path computation 228 problem. That is, where one mechanism is used to determine a path 229 across a domain, a separate mechanism (or at least a separate set 230 of paradigms) is used to determine the sequence of domains. The 231 responsibility for the selection of domain interconnection can belong 232 to either or both of the mechanisms. 234 1.3 Assumptions and Requirements 236 Networks are often constructed from multiple domains. These 237 domains are often interconnected via multiple interconnect points. 238 Its assumed that the sequence of domains for an end-to-end path is 239 not always well known; that is, an application requesting end-to-end 240 connectivity has no preference for, or no ability to specify, the 241 sequence of domains to be crossed by the path. 243 The traffic engineering properties of a domain cannot be seen from 244 outside the domain. Traffic engineering aggregation or abstraction, 245 hides information and can lead to failed path setup or the selection 246 of suboptimal end-to-end paths [RFC4726]. The aggregation process 247 may also have significant scaling issues for networks with many 248 possible routes and multiple TE metrics. Flooding TE information 249 breaks confidentiality and does not scale in the routing protocol. 250 See Section 6 for a discussion of the concept of inter-domain traffic 251 engineering information exchange known as BGP-TE. 253 The primary goal of this document is to define how to derive optimal 254 end-to-end, multi-domain paths when the sequence of domains is not 255 known in advance. The solution needs to be scalable and to maintain 256 internal domain topology confidentiality while providing the optimal 257 end-to-end path. It cannot rely on the exchange of TE information 258 between domains, and for the confidentiality, scaling, and 259 aggregation reasons just cited, it cannot utilize a computation 260 element that has universal knowledge of TE properties and topology 261 of all domains. 263 The sub-sections that follow set out the primary objectives and 264 requirements to be satisfied by a PCE solution to multi-domain path 265 computation. 267 1.3.1 Metric Objectives 269 The definition of optimality is dependent on policy, and is based on 270 a single objective or a group objectives. An objective is expressed 271 as an objective function [RFC5541] and may be specified on a path 272 computation request. The following objective functions are identified 273 in this document. They define how the path metrics and TE link 274 qualities are manipulated during inter-domain path computation. The 275 list is not proscriptive and may be expanded in other documents. 277 o Minimize the cost of the path [RFC5541] 278 o Select a path using links with the minimal load [RFC5541] 279 o Select a path that leaves the maximum residual bandwidth [RFC5541] 280 o Minimize aggregate bandwidth consumption [RFC5541] 281 o Minimize the Load of the most loaded Link [RFC5541] 282 o Minimize the Cumulative Cost of a set of paths [RFC5541] 283 o Minimize or cap the number of domains crossed 284 o Disallow domain re-entry 286 See Section 5.1 for further discussion of objective functions. 288 1.3.2 Diversity 290 1.3.2.1 Physical Diversity 292 Within a Carrier's Carrier environment MPLS services may share common 293 underlying equipment and resources, including optical fiber and 294 nodes. An MPLS service request may require a path for traffic that is 295 physically disjointed from another service. Thus, if a physical link 296 or node fails on one of the disjoint paths, not all traffic is lost. 298 1.3.2.2 Domain Diversity 300 A pair of paths are domain-diverse if they do not transit any of the 301 same domains. A pair of paths that share a common ingress and egress 302 are domain-diverse if they only share the same domains at the ingress 303 and egress (the ingress and egress domains). Domain diversity may be 304 maximized for a pair of paths by selecting paths that have the 305 smallest number of shared domains. (Note that this is not the same 306 as finding paths with the greatest number of distinct domains!) 308 Path computation should facilitate the selection of paths that share 309 ingress and egress domains, but do not share any transit domains. 310 This provides a way to reduce the risk of shared failure along any 311 path, and automatically helps to ensure path diversity for most of 312 the route of a pair of LSPs. 314 Thus, domain path selection should provide the capability to include 315 or exclude specific domains and specific boundary nodes. 317 1.3.3 Existing Traffic Engineering Constraints 319 Any solution should take advantage of typical traffic engineering 320 constraints (hop count, bandwidth, lambda continuity, path cost, 321 etc.) to meet the service demands expressed in the path computation 322 request [RFC4655]. 324 1.3.4 Commercial Constraints 326 The solution should provide the capability to include commercially 327 relevant constraints such as policy, SLAs, security, peering 328 preferences, and monetary costs. 330 Additionally it may be necessary for the service provider to 331 request that specific domains are included or excluded based on 332 commercial relationships, security implications, and reliability. 334 1.3.5 Domain Confidentiality 336 A key requirement is the ability to maintain domain confidentiality 337 when computing inter-domain end-to-end paths. It should be possible 338 for local policy to require that a PCE not disclose to any other PCE 339 the intra-domain paths it computes or the internal topology of the 340 domain it serves. This requirement should have no impact in the 341 optimality or quality of the end-to-end path that is derived. 343 1.3.6 Limiting Information Aggregation 345 In order to reduce processing overhead and to not sacrifice 346 computational detail, there should be no requirement to aggregate or 347 abstract traffic engineering link information. 349 1.3.7 Domain Interconnection Discovery 351 To support domain mesh topologies, the solution should allow the 352 discovery and selection of domain inter-connections. Pre- 353 configuration of preferred domain interconnections should also be 354 supported for network operators that have bilateral agreement, and 355 preference for the choice of points of interconnection. 357 1.4 Terminology 359 This document uses PCE terminology defined in [RFC4655], [RFC4726], 360 and [RFC5440]. Additional terms are defined below. 362 Domain Path: The sequence of domains for a path. 364 Ingress Domain: The domain that includes the ingress LSR of a path. 366 Transit Domain: A domain that has an upstream and downstream 367 neighbor domain for a specific path. 369 Egress Domain: The domain that includes the egress LSR of a path. 371 Boundary Nodes: Each Domain has entry LSRs and exit LSRs that could 372 be Area Border Routers (ABRs) or Autonomous System Border Routers 373 (ASBRs) depending on the type of domain. They are defined here more 374 generically as Boundary Nodes (BNs). 376 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) 377 on a path. 379 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) 380 on a path. 382 Parent Domain: A domain higher up in a domain hierarchy such 383 that it contains other domains (child domains) and potentially other 384 links and nodes. 386 Child Domain: A domain lower in a domain hierarchy such that it has 387 a parent domain. 389 Parent PCE: A PCE responsible for selecting a path across a parent 390 domain and any number of child domains by coordinating with child 391 PCEs and examining a topology map that shows domain inter- 392 connectivity. 394 Child PCE: A PCE responsible for computing the path across one or 395 more specific (child) domains. A child PCE maintains a relationship 396 with at least one parent PCE. 398 OF: Objective Function: A set of one or more optimization 399 criteria used for the computation of a single path (e.g., path cost 400 minimization), or the synchronized computation of a set of paths 401 (e.g., aggregate bandwidth consumption minimization). See [RFC4655] 402 and [RFC5541]. 404 2. Examination of Existing PCE Mechanisms 406 This section provides a brief overview of two existing PCE 407 cooperation mechanisms called the per-domain path computation method, 408 and the backward recursive path computation method. It describes the 409 applicability of these methods to the multi-domain problem. 411 2.1 Per-Domain Path Computation 413 The per-domain path computation method for establishing inter-domain 414 TE-LSPs [RFC5152] defines a technique whereby the path is computed 415 during the signalling process on a per-domain basis. The entry BN of 416 each domain is responsible for performing the path computation for 417 the section of the LSP that crosses the domain, or for requesting 418 that a PCE for that domain computes that piece of the path. 420 During per-domain path computation, each computation results in the 421 best path across the domain to provide connectivity to the next 422 domain in the domain sequence (usually indicated in signalling by an 423 identifier of the next domain or the identity of the next entry BN). 425 Per-domain path computation may lead to sub-optimal end-to-end paths 426 because the most optimal path in one domain may lead to the choice of 427 an entry BN for the next domain that results in a very poor path 428 across that next domain. 430 In the case that the domain path (in particular, the sequence of 431 boundary nodes) is not known, the path computing entity must select 432 an exit BN based on some determination of how to reach the 433 destination that is outside the domain for which the path computing 434 entity has computational responsibility. [RFC5152] suggest that this 435 might be achieved using the IP shortest path as advertise by BGP. 436 Note, however, that the existence of an IP forwarding path does not 437 guarantee the presence of sufficient bandwidth, let alone an optimal 438 TE path. Furthermore, in many GMPLS systems inter-domain IP routing 439 will not be present. Thus, per-domain path computation may require a 440 significant number of crankback routing attempts to establish even a 441 sub-optimal path. 443 Note also that the path computing entities in each domain may have 444 different computation capabilities, may run different path 445 computation algorithms, and may apply different sets of constraints 446 and optimization criteria, etc. 448 This can result in the end-to-end path being inconsistent and sub- 449 optimal. 451 Per-domain path computation can suit simply-connected domains where 452 the preferred points of interconnection are known. 454 2.2 Backward Recursive Path Computation 456 The Backward Recursive Path Computation (BRPC) [RFC5441] procedure 457 involves cooperation and communication between PCEs in order to 458 compute an optimal end-to-end path across multiple domains. The 459 sequence of domains to be traversed can either be determined before 460 or during the path computation. In the case where the sequence of 461 domains is known, the ingress Path Computation Client (PCC) sends a 462 path computation request to a PCE responsible for the ingress 463 domain. This request is forwarded between PCEs, domain-by-domain, to 464 a PCE responsible for the egress domain. The PCE in the egress 465 domain creates a set of optimal paths from all of the domain entry 466 BNs to the egress LSR. This set is represented as a tree of potential 467 paths called a Virtual Shortest Path Tree (VSPT), and the PCE passes 468 it back to the previous PCE on the domain path. As the VSPT is passed 469 back toward the ingress domain, each PCE computes the optimal paths 470 from its entry BNs to its exit BNs that connect to the rest of the 472 tree. It adds these paths to the VSPT and passes the VSPT on until 473 the PCE for the ingress domain is reached and computes paths from the 474 ingress LSR to connect to the rest of the tree. The ingress PCE then 475 selects the optimal end-to-end path from the tree, and returns the 476 path to the initiating PCC. 478 BRPC may suit environments where multiple connections exist between 479 domains and there is no preference for the choice of points of 480 interconnection. It is best suited to scenarios where the domain 481 path is known in advance, but can also be used when the domain path 482 is not known. 484 2.2.1. Applicability of BRPC when the Domain Path is Not Known 486 As described above, BRPC can be used to determine an optimal inter- 487 domain path when the domain sequence is known. Even when the sequence 488 of domains is not known BRPC could be used as follows. 490 o The PCC sends a request to a PCE for the ingress domain (the 491 ingress PCE). 493 o The ingress PCE sends the path computation request direct to a 494 PCE responsible for the domain containing the destination node (the 495 egress PCE). 497 o The egress PCE computes an egress VSPT and passes it to a PCE 498 responsible for each of the adjacent (potentially upstream) 499 domains. 501 o Each PCE in turn constructs a VSPT and passes it on to all of its 502 neighboring PCEs. 504 o When the ingress PCE has received a VSPT from each of its 505 neighboring domains it is able to select the optimum path. 507 Clearly this mechanism (which could be called path computation 508 flooding) has significant scaling issues. It could be improved by 509 the application of policy and filtering, but such mechanisms are not 510 simple and would still leave scaling concerns. 512 3. Hierarchical PCE 514 In the hierarchical PCE architecture, a parent PCE maintains a domain 515 topology map that contains the child domains (seen as vertices in the 516 topology) and their interconnections (links in the topology). The 517 parent PCE has no information about the content of the child domains; 518 that is, the parent PCE does not know about the resource availability 519 within the child domains, nor about the availability of connectivity 520 across each domain because such knowledge would violate the 521 confidentiality requirement and would either require flooding of full 522 information to the parent (scaling issue) or would necessitate some 523 form of aggregation. The parent PCE is aware of the TE capabilities 524 of the interconnections between child domains as these 525 interconnections are links in its own topology map. 527 Note that in the case that the domains are IGP areas, there is no 528 link between the domains (the ABRs have a presence in both 529 neighboring areas). The parent domain may choose to represent this in 530 its TED as a virtual link that is unconstrained and has zero cost, 531 but this is entirely an implementation issue. 533 Each child domain has at least one PCE capable of computing paths 534 across the domain. These PCEs are known as child PCEs and have a 535 relationship with the parent PCE. Each child PCE also knows the 536 identity of the domains that neighbor its own domain. A child PCE 537 only knows the topology of the domain that it serves and does not 538 know the topology of other child domains. Child PCEs are also not 539 aware of the general domain mesh connectivity (i.e., the domain 540 topology map) beyond the connectivity to the immediate neighbor 541 domains of the domain it serves. 543 The parent PCE builds the domain topology map either from 544 configuration or from information received from each child PCE. This 545 tells it how the domains are interconnected including the TE 546 properties of the domain interconnections. But the parent PCE does 547 not know the contents of the child domains. Discovery of the domain 548 topology and domain interconnections is discussed further in Section 549 4.3. 551 When a multi-domain path is needed, the ingress PCE sends a request 552 to the parent PCE (using the path computation element protocol, PCEP 553 [RFC5440]). The parent PCE selects a set of candidate domain paths 554 based on the domain topology and the state of the inter-domain links. 555 It then sends computation requests to the child PCEs responsible for 556 each of the domains on the candidate domain paths. These requests may 557 be sequential or parallel depending on implementation details. 559 Each child PCE computes a set of candidate path segments across its 560 domain and sends the results to the parent PCE. The parent PCE uses 561 this information to select path segments and concatenate them to 562 derive the optimal end-to-end inter-domain path. The end-to-end path 563 is then sent to the child PCE which received the initial path request 564 and this child PCE passes the path on to the PCC that issued the 565 original request. 567 Specific deployment and implementation scenarios are out of scope of 568 this document. However the hierarchical PCE architecture described 569 does support the function of parent PCE and child PCE being 570 implemented as a common PCE. 572 4. Hierarchical PCE Procedures 574 4.1 Objective Functions and Policy 576 Deriving the optimal end-to-end domain path sequence is dependent on 577 the policy applied during domain path computation. An Objective 578 Function (OF) [RFC5541], or set of OFs, may be applied to define the 579 policy being applied to the domain path computation. 581 The OF specifies the desired outcome of the computation. It does 582 not describe the algorithm to use. When computing end-to-end inter- 583 domain paths, required OFs may include (see Section 1.3.1): 585 o Minimum cost path 586 o Minimum load path 587 o Maximum residual bandwidth path 588 o Minimize aggregate bandwidth consumption 589 o Minimize or cap the number of transit domains 590 o Disallow domain re-entry 592 The objective function may be requested by the PCC, the ingress 593 domain PCE (according to local policy), or applied by the parent PCE 594 according to inter-domain policy. 596 More than one OF (or a composite OF) may be chosen to apply to a 597 single computation provided they are not contradictory. Composite OFs 598 may include weightings and preferences for the fulfillment of pieces 599 of the desired outcome. 601 4.2 Maintaining Domain Confidentiality 603 Information about the content of child domains is not shared for 604 scaling and confidentiality reasons. This means that a parent PCE is 605 aware of the domain topology and the nature of the connections 606 between domains, but is not aware of the content of the domains. 607 Similarly, a child PCE cannot know the internal topology of another 608 child domain. Child PCEs also do not know the general domain mesh 609 connectivity, this information is only known by the parent PCE. 611 As described in the earlier sections of this document, PCEs can 612 exchange path information in order to construct an end-to-end inter- 613 domain path. Each per-domain path fragment reveals information about 614 the topology and resource availability within a domain. Some 615 management domains or ASes will not want to share this information 616 outside of the domain (even with a trusted parent PCE). In order to 617 conceal the information, a PCE may replace a path segment with a 618 path-key [RFC5520]. This mechanism effectively hides the content of a 619 segment of a path. 621 4.3 PCE Discovery 623 It is a simple matter for each child PCE to be configured with the 624 address of its parent PCE. Typically, there will only be one or two 625 parents of any child. 627 The parent PCE also needs to be aware of the child PCEs for all child 628 domains that it can see. This information is most likely to be 629 configured (as part of the administrative definition of each 630 domain). 632 Discovery of the relationships between parent PCEs and child PCEs 633 does not form part of the hierarchical PCE architecture. Mechanisms 634 that rely on advertising or querying PCE locations across domain or 635 provider boundaries are undesirable for security, scaling, 636 commercial, and confidentiality reasons. 638 The parent PCE also needs to know the inter-domain connectivity. 639 This information could be configured with suitable policy and 640 commercial rules, or could be learned from the child PCEs as 641 described in Section 4.4. 643 In order for the parent PCE to learn about domain interconnection 644 the child PCE will report the identity of its neighbor domains. The 645 IGP in each neighbor domain can advertise its inter-domain TE 646 link capabilities [RFC5316], [RFC5392]. This information can be 647 collected by the child PCEs and forwarded to the parent PCE, or the 648 parent PCE could participate in the IGP in the child domains. 650 4.4 Parent Domain Traffic Engineering Database 652 The parent PCE maintains a domain topology map of the child domains 653 and their interconnectivity. Where inter-domain connectivity is 654 provided by TE links the capabilities of those links may also be 655 known to the parent PCE. The parent PCE maintains a traffic 656 engineering database (TED) for the parent domain in the same way that 657 any PCE does. 659 The parent domain may just be the collection of child domains and 660 their interconnectivity, may include details of the inter-domain TE 661 links, and may contain nodes and links in its own right. 663 The mechanism for building the parent TED is likely to rely heavily 664 on administrative configuration and commercial issues because the 665 network was probably partitioned into domains specifically to address 666 these issues. 668 In practice, certain information may be passed from the child domains 669 to the parent PCE to help build the parent TED. In theory, the parent 670 PCE could listen to the routing protocols in the child domains, but 671 this would violate the confidentiality and scaling issues that may be 672 responsible for the partition of the network into domains. So it is 673 much more likely that a suitable solution will involve specific 674 communication from an entity in the child domain (such as the child 675 PCE) to convey the necessary information. As already mentioned, the 676 "necessary information" relates to how the child domains are inter- 677 connected. The topology and available resources within the child 678 domain do not need to be communicated to the parent PCE: doing so 679 would violate the PCE architecture. Mechanisms for reporting this 680 information are described in the examples in Section 4.6 in abstract 681 terms as "a child PCE reports its neighbor domain connectivity to its 682 parent PCE"; the specifics of a solution are out of scope of this 683 document, but the requirements are indicated in Section 4.8. See 684 Section 6 for a brief discussion of BGP-TE. 686 In models such as ASON (see Section 5.2), it is possible to consider 687 a separate instance of an IGP running within the parent domain where 688 the participating protocol speakers are the nodes directly present in 689 that domain and the PCEs (Routing Controllers) responsible for each 690 of the child domains. 692 4.5 Determination of Destination Domain 694 The PCC asking for an inter-domain path computation is aware of the 695 identity of the destination node by definition. If it knows the 696 egress domain it can supply this information as part of the path 697 computation request. However, if it does not know the egress domain 698 this information must be known by the child PCE or known/determined 699 by the parent PCE. 701 In some specialist topologies the parent PCE could determine the 702 destination domain based on the destination address, for example from 703 configuration. However, this is not appropriate for many multi-domain 704 addressing scenarios. In IP-based multi-domain networks the 705 parent PCE may be able to determine the destination domain by 706 participating in inter-domain routing. Finally, the parent PCE could 707 issue specific requests to the child PCEs to discover if they contain 708 the destination node, but this has scaling implications. 710 For the purposes of this document, the precise mechanism of the 711 discovery of the destination domain is left out of scope. Suffice to 712 say that for each multi-domain path computation some mechanism will 713 be required to determine the location of the destination. 715 4.6 Hierarchical PCE Examples 717 The following example describes the generic hierarchical domain 718 topology. Figure 1 demonstrates four interconnected domains within a 719 fifth, parent domain. Each domain contains a single PCE: 721 o Domain 1 is the ingress domain and child PCE 1 is able to compute 722 paths within the domain. Its neighbors are Domain 2 and Domain 4. 723 The domain also contains the source LSR (S) and three egress 724 boundary nodes (BN11, BN12, and BN13). 726 o Domain 2 is served by child PCE 2. Its neighbors are Domain 1 and 727 Domain 3. The domain also contains four boundary nodes (BN21, BN22, 728 BN23, and BN24). 730 o Domain 3 is the egress domain and is served by child PCE 3. Its 731 neighbors are Domain 2 and Domain 4. The domain also contains the 732 destination LSR (D) and three ingress boundary nodes (BN31, BN32, 733 and BN33). 735 o Domain 4 is served by child PCE 4. Its neighbors are Domain 2 and 736 Domain 3. The domain also contains two boundary nodes (BN41 and 737 BN42). 739 All of these domains are contained within Domain 5 which is served 740 by the parent PCE (PCE 5). 742 ----------------------------------------------------------------- 743 | Domain 5 | 744 | ----- | 745 | |PCE 5| | 746 | ----- | 747 | | 748 | ---------------- ---------------- ---------------- | 749 | | Domain 1 | | Domain 2 | | Domain 3 | | 750 | | | | | | | | 751 | | ----- | | ----- | | ----- | | 752 | | |PCE 1| | | |PCE 2| | | |PCE 3| | | 753 | | ----- | | ----- | | ----- | | 754 | | | | | | | | 755 | | ----| |---- ----| |---- | | 756 | | |BN11+---+BN21| |BN23+---+BN31| | | 757 | | - ----| |---- ----| |---- - | | 758 | | |S| | | | | |D| | | 759 | | - ----| |---- ----| |---- - | | 760 | | |BN12+---+BN22| |BN24+---+BN32| | | 761 | | ----| |---- ----| |---- | | 762 | | | | | | | | 763 | | ---- | | | | ---- | | 764 | | |BN13| | | | | |BN33| | | 765 | -----------+---- ---------------- ----+----------- | 766 | \ / | 767 | \ ---------------- / | 768 | \ | | / | 769 | \ |---- ----| / | 770 | ----+BN41| |BN42+---- | 771 | |---- ----| | 772 | | | | 773 | | ----- | | 774 | | |PCE 4| | | 775 | | ----- | | 776 | | | | 777 | | Domain 4 | | 778 | ---------------- | 779 | | 780 ----------------------------------------------------------------- 782 Figure 1 : Sample Hierarchical Domain Topology 784 Figure 2, shows the view of the domain topology as seen by the parent 785 PCE (PCE 5). This view is an abstracted topology; PCE 5 is aware of 786 domain connectivity, but not of the internal topology within each 787 domain. 789 ---------------------------- 790 | Domain 5 | 791 | ---- | 792 | |PCE5| | 793 | ---- | 794 | | 795 | ---- ---- ---- | 796 | | |---| |---| | | 797 | | D1 | | D2 | | D3 | | 798 | | |---| |---| | | 799 | ---- ---- ---- | 800 | \ ---- / | 801 | \ | | / | 802 | ----| D4 |---- | 803 | | | | 804 | ---- | 805 | | 806 ---------------------------- 808 Figure 2 : Abstract Domain Topology as Seen by the Parent PCE 810 4.6.1 Hierarchical PCE Initial Information Exchange 812 Based on the Figure 1 topology, the following is an illustration of 813 the initial hierarchical PCE information exchange. 815 1. Child PCE 1, the PCE responsible for Domain 1, is configured 816 with the location of its parent PCE (PCE5). 818 2. Child PCE 1 establishes contact with its parent PCE. The parent 819 applies policy to ensure that communication with PCE 1 is allowed. 821 3. Child PCE 1 listens to the IGP in its domain and learns its 822 inter-domain connectivity. That is, it learns about the links 823 BN11-BN21, BN12-BN22, and BN13-BN41. 825 4. Child PCE 1 reports its neighbor domain connectivity to its parent 826 PCE. 828 5. Child PCE 1 reports any change in the resource availability on its 829 inter-domain links to its parent PCE. 831 Each child PCE performs steps 1 through 5 so that the parent PCE can 832 create a domain topology view as shown in Figure 2. 834 4.6.2 Hierarchical PCE End-to-End Path Computation Procedure 836 The procedure below is an example of a source PCC requesting an 837 end-to-end path in a multi-domain environment. The topology is 838 represented in Figure 1. It is assumed that the each child PCE has 839 connected to its parent PCE and exchanged the initial information 840 required for the parent PCE to create its domain topology view as 841 described in Section 5.6.1. 843 1. The source PCC (the ingress LSR in our example), sends a request 844 to the PCE responsible for its domain (PCE 1) for a path to the 845 destination LSR (D). 847 2. PCE 1 determines the destination is not in domain 1. 849 3. PCE 1 sends a computation request to its parent PCE (PCE 5). 851 4. The parent PCE determines that the destination is in Domain 3. 852 (See Section 5.5). 854 5. PCE 5 determines the likely domain paths according to the domain 855 interconnectivity and TE capabilities between the domains. For 856 example, assuming that the link BN12-BN22 is not suitable for the 857 requested path, three domain paths are determined: 859 S-BN11-BN21-D2-BN23-BN31-D 860 S-BN11-BN21-D2-BN24-BN32-D 861 S-BN13-BN41-D4-BN42-BN33-D 863 6. PCE 5 sends edge-to-edge path computation requests to PCE 2 864 which is responsible for Domain 2 (i.e., BN21-to-BN23 and BN21- 865 to-BN24), and to PCE 4 for Domain 4 (i.e., BN41-to-BN42). 867 7. PCE 5 sends source-to-edge path computation requests to PCE 1 868 which is responsible for Domain 1 (i.e., S-to-BN11 and S-to- 869 BN13). 871 8. PCE 5 sends edge-to-egress path computation requests to PCE3 872 which is responsible for Domain 3 (i.e., BN31-to-D, BN32-to-D, 873 and BN33-to-D). 875 9. PCE 5 correlates all the computation responses from each child 876 PCE, adds in the information about the inter-domain links, and 877 applies any requested and locally configured policies. 879 10. PCE 5 then selects the optimal end-to-end multi-domain path 880 that meets the policies and objective functions, and supplies the 881 resulting path to PCE 1. 883 11. PCE 1 forwards the path to the PCC (the ingress LSR). 885 Note that there is no requirement for steps 6, 7, and 8 to be carried 886 out in parallel or in series. Indeed, they could be overlapped with 887 step 5. This is an implementation issue. 889 4.7 Hierarchical PCE Error Handling 891 In the event that a child PCE in a domain cannot find a suitable 892 path to the egress. The child PCE should return the relevant 893 error to notify the parent PCE. Depending on the error response the 894 parent PCE can elect to: 896 o Cancel the request and send the relevant response back to the 897 initial child PCE that requested an end-to-end path; 898 o Relax some of the constraints associated with the initial path 899 request; 900 o Select another candidate domain and send the path request to the 901 child PCE responsible for the domain. 903 If the parent PCE does not receive a response from a child PCE within 904 an allotted time period. The parent PCE can elect to: 906 o Cancel the request and send the relevant response back to the 907 initial child PCE that requested an end-to-end path; 908 o Send the path request to another child PCE in the same domain, if a 909 secondary child PCE exists; 910 o Select another candidate domain and send the path request to the 911 child PCE responsible for that domain. 913 The parent PCE may also want to prune any unresponsive child PCE 914 domain paths from the candidate set. 916 4.8 Requirements for Hierarchical PCEP Protocol Extensions 918 This section lists the high-level requirements for extensions to the 919 PCEP to support the hierarchical PCE model. It is provided to offer 920 guidance to PCEP protocol developers in designing a solution suitable 921 for use in a hierarchical PCE framework. 923 4.8.1 PCEP Request Qualifiers 925 PCEP request (PCReq) messages are used by a PCC or a PCE to make a 926 computation request or enquiry to a PCE. The requests are qualified 927 so that the PCE knows what type of action is required. 929 Support of the hierarchical PCE architecture will introduce two new 930 qualifications as follows: 932 o It must be possible for a child PCE to indicate that the response 933 it receives from the parent PCE should consist of a domain sequence 934 only (i.e., not a fully-specified end-to-end path). This allows the 935 child PCE to initiate per-domain or backward recursive path 936 computation. 938 o A parent PCE may need to be able to ask a child PCE whether a 939 particular node address (the destination of an end-to-end path) is 940 present in the domain that the child PCE serves. 942 In PCEP, such request qualifications are carried as bit-flags in the 943 RP object within the PCReq message. 945 4.8.2 Indication of Hierarchical PCE Capability 947 Although parent/child PCE relationships are likely configured, it 948 will assist network operations if the parent PCE is able to indicate 949 to the child that it really is capable of acting as a parent PCE. 950 This will help to trap misconfigurations. 952 In PCEP, such capabilities are carried in the Open Object within the 953 Open message. 955 4.8.3 Intention to Utilize Parent PCE Capabilities 957 A PCE that is capable of acting as a parent PCE might not be 958 configured or willing to act as the parent for a specific child PCE. 959 This fact could be determined when the child sends a PCReq that 960 requires parental activity (such as querying other child PCEs), and 961 could result in a negative response in a PCEP Error (PCErr) message. 963 However, the expense of a poorly targeted PCReq can be avoided if 964 the child PCE indicates that it might wish to use the parent-capable 965 as a parent (for example, on the Open message), and if the 966 parent-capable determines at that time whether it is willing to act 967 as a parent to this child. 969 4.8.4 Communication of Domain Connectivity Information 971 Section 4.4 describes how the parent PCE needs a parent TED and 972 indicates that the information might be supplied from the child PCEs 973 in each domain. This requires a mechanism whereby information about 974 inter-domain links can be supplied by a child PCE to a parent PCE, 975 for example on a PCEP Notify (PCNtf) message. 977 The information that would be exchanged includes: 979 o Identifier of advertising child PCE 980 o Identifier of PCE's domain 981 o Identifier of the link 982 o TE properties of the link (metrics, bandwidth) 983 o Other properties of the link (technology-specific) 984 o Identifier of link end-points 985 o Identifier of adjacent domain 987 It may be desirable for this information to be periodically updated, 988 for example, when available bandwidth changes. In this case, the 989 parent PCE might be given the ability to configure thresholds in the 990 child PCE to prevent flapping of information. 992 4.8.5 Domain Identifiers 994 Domain identifiers are already present in PCEP to allow a PCE to 995 indicate which domains it serves, and to allow the representation of 996 domains as abstract nodes in paths. The wider use of domains in the 997 context of this work on hierarchical PCE will require that domains 998 can be identified in more places within objects in PCEP messages. 999 This should pose no problems. 1001 However, more attention may need to be applied to the precision of 1002 domain identifier definitions to ensure that it is always possible to 1003 unambiguously identify a domain from its identifier. This work will 1004 be necessary in configuration, and also in protocol specifications 1005 (for example, an OSPF area identifier is sufficient within an 1006 Autonomous System, but becomes ambiguous in a path that crosses 1007 multiple Autonomous Systems). 1009 5. Hierarchical PCE Applicability 1011 As per [RFC4655], PCE can inherently support inter-domain path 1012 computation for any definition of a domain as set out in Section 1.2 1013 of this document. 1015 Hierarchical PCE can be applied to inter-domain environments, 1016 including Antonymous Systems and IGP areas. The hierarchical PCE 1017 procedures make no distinction between, Antonymous Systems and IGP 1018 area applications, although it should be noted that the TED 1019 maintained by a parent PCE must be able to support the concept of 1020 child domains connected by inter-domain links or directly connected 1021 at boundary nodes (see Section 3). 1023 This section sets out the applicability of hierarchical PCE to three 1024 environments: 1026 o MPLS traffic engineering across multiple Autonomous Systems 1027 o MPLS traffic engineering across multiple IGP areas 1028 o GMPLS traffic engineering in the ASON architecture 1030 5.1 Antonymous Systems and Areas 1032 Networks are comprised of domains. A domain can be considered to be 1033 a collection of network elements within an AS or area that has a 1034 common sphere of address management or path computational 1035 responsibility. 1037 As networks increase in size and complexity it may be required to 1038 introduce scaling methods to reduce the amount information flooded 1039 within the network and make the network more manageable. An IGP 1040 hierarchy is designed to improve IGP scalability by dividing the 1041 IGP domain into areas and limiting the flooding scope of topology 1042 information to within area boundaries. This restricts a router's 1043 visibility to information about links and other routers within the 1044 single area. If a router needs to compute a route to destination 1045 located in another area, a method is required to compute a path 1046 across the area boundary. 1048 When an LSR within an AS or area needs to compute a path across an 1049 area or AS boundary it must also use an inter-AS computation 1050 technique. Hierarchical PCE is equally applicable to computing 1051 inter-area and inter-AS MPLS and GMPLS paths across domain 1052 boundaries. 1054 5.2 ASON Architecture 1056 The International Telecommunications Union (ITU) defines the ASON 1057 architecture in [G-8080]. [G-7715] defines the routing architecture 1058 for ASON and introduces a hierarchical architecture. In this 1059 architecture, the Routing Areas (RAs) have a hierarchical 1060 relationship between different routing levels, which means a parent 1061 (or higher level) RA can contain multiple child RAs. The 1062 interconnectivity of the lower RAs is visible to the higher level RA. 1063 Note that the RA hierarchy can be recursive. 1065 In the ASON framework, a path computation request is termed a Route 1066 Query. This query is executed before signaling is used to establish 1067 an LSP termed a Switched Connection (SC) or a Soft Permanent 1068 Connection (SPC). [G-7715-2] defines the requirements and 1069 architecture for the functions performed by Routing Controllers (RC) 1070 during the operation of remote route queries - an RC is synonymous 1071 with a PCE. For an end-to-end connection, the route may be computed 1072 by a single RC or multiple RCs in a collaborative manner (i.e., RC 1073 federations). In the case of RC federations, [G-7715-2] describes 1074 three styles during remote route query operation: 1076 o Step-by-step remote path computation 1077 o Hierarchical remote path computation 1078 o A combination of the above. 1080 In a hierarchical ASON routing environment, a child RC may 1081 communicate with its parent RC (at the next higher level of the ASON 1082 routing hierarchy) to request the computation of an end-to-end path 1083 across several RAs. It does this using a route query message (known 1084 as the abstract message RI_QUERY). The corresponding parent RC may 1085 communicate with other child RCs that belong to other child RAs at 1086 the next lower hierarchical level. Thus, a parent RC can act as 1087 either a Route Query Requester or Route Query Responder. 1089 It can be seen that the hierarchical PCE architecture fits the 1090 hierarchical ASON routing architecture well. It can be used to 1091 provide paths across subnetworks, and to determine end-to-end paths 1092 in networks constructed from multiple subnetworks or RAs. 1094 When hierarchical PCE is applied to implement hierarchical remote 1095 path computation in [G-7715-2], it is very important for operators to 1096 understand the different terminology and implicit consistency 1097 between hierarchical PCE and [G-7715-2]. 1099 5.2.1 Implicit Consistency Between Hierarchical PCE and G.7715.2 1101 This section highlights the correspondence between features of the 1102 hierarchical PCE architecture and the ASON routing architecture. 1104 (1) RC (Routing Controller) and PCE (Path Computation Element) 1106 [G-8080] describes the Routing Controller component as an 1107 abstract entity, which is responsible for responding to requests 1108 for path (route) information and topology information. It can be 1109 implemented as a single entity, or as a distributed set of 1110 entities that make up a cooperative federation. 1112 [RFC4655] describes PCE (Path Computation Element) is an entity 1113 (component, application, or network node) that is capable of 1114 computing a network path or route based on a network graph and 1115 applying computational constraints. 1117 Therefore, in the ASON architecture, a PCE can be regarded as a 1118 realizations of the RC. 1120 (2) Route Query Requester/Route Query Responder and PCC/PCE 1122 [G-7715-2] describes the Route Query Requester as a Connection 1123 Controller or Routing Controller that sends a route query message 1124 to a Routing Controller requesting one or more paths that 1125 satisfy a set of routing constraints. The Route Query Responder 1126 is a Routing Controller that performs path computation upon 1127 receipt of a route query message from a Route Query Requester, 1128 sending a response back at the end of the path computation. 1130 In the context of ASON, a Signaling Controller initiates and 1131 processes signaling messages and is closely coupled to a 1132 Signaling Protocol Speaker. A Routing Controller makes routing 1133 decisions and is usually coupled to configuration entities 1134 and/or a Routing Protocol Speaker. 1136 It can be seen that a PCC corresponds to a Route Query Requester, 1137 and a PCE corresponds to a Route Query Responder. A PCE/RC can 1138 also act as a Route Query Requester sending requests to another 1139 Route Query Responder. 1141 The PCEP path computation request (PCReq) and path computation 1142 reply (PCRep) messages between PCC and PCE correspond to the 1143 RI_QUERY and RI_UPDATE messages in [G-7715-2]. 1145 (3) Routing Area Hierarchy and Hierarchical Domain 1147 The ASON routing hierarchy model is shown in Figure 6 of 1148 [G-7715] through an example that illustrates routing area levels. 1149 If the hierarchical remote path computation mechanism of 1150 [G-7715-2] is applied in this scenario, each routing area should 1151 have at least one RC for route query function and there is a 1152 parent RC for the child RCs in each routing area. 1154 According to [G-8080], the parent RC has visibility of the 1155 structure of the lower level, so it knows the interconnectivity 1156 of the RAs in the lower level. Each child RC can compute edge-to- 1157 edge paths across its own child RA. 1159 Thus, an RA corresponds to a domain in the PCE architecture, and 1160 the hierarchical relationship between RAs corresponds to the 1161 hierarchical relationship between domains in the hierarchical PCE 1162 architecture. Furthermore, a parent PCE in a parent domain can be 1163 regarded as parent RC in a higher routing level, and a child PCE 1164 in a child domain can be regarded as child RC in a lower routing 1165 level. 1167 5.2.2 Benefits of Hierarchical PCEs in ASON 1169 RCs in an ASON environment can use the hierarchical PCE model to 1170 fully match the ASON hierarchical routing model, so the hierarchical 1171 PCE mechanisms can be applied to fully satisfy the architecture and 1172 requirements of [G-7715-2] without any changes. If the hierarchical 1173 PCE mechanism is applied in ASON, it can be used to determine end-to- 1174 end optimized paths across sub-networks and RAs before initiating 1175 signaling to create the connection. It can also improve the 1176 efficiency of connection setup to avoid crankback. 1178 6. A Note on BGP-TE 1180 The concept of exchange of TE information between Autonomous Systems 1181 (ASes) is discussed in [BGP-TE]. The information exchanged in this 1182 way could be the full TE information from the AS, an aggregation of 1183 that information, or a representation of the potential connectivity 1184 across the AS. Furthermore, that information could be updated 1185 frequently (for example, for every new LSP that is set up across the 1186 AS) or only at threshold-crossing events. 1188 There are a number of discussion points associated with the use of 1189 [BGP-TE] concerning the volume of information, the rate of churn of 1190 information, the confidentiality of information, the accuracy of 1191 aggregated or potential-connectivity information, and the processing 1192 required to generate aggregated information. The PCE architecture and 1193 the architecture enabled by [BGP-TE] make different assumptions about 1194 the operational objectives of the networks, and this document does 1195 not attempt to make one of the approaches "right" and the other 1196 "wrong". Instead, this work assumes that a decision has been made to 1197 utilize the PCE architecture. 1199 6.1 Use of BGP for TED Synchronization 1201 Indeed, [BGP-TE] may have some uses within the PCE model. For 1202 example, [BGP-TE] could be used as a "northbound" TE advertisement 1203 such that a PCE does not need to listen to an IGP in its domain, but 1204 has its TED populated by messages received (for example) from a 1205 Route Reflector. Furthermore, the inter-domain connectivity and 1206 connectivity capabilities that is required information for a parent 1207 PCE could be obtained as a filtered subset of the information 1208 available in [BGP-TE]. This scenario is discussed further in 1209 [PCE-AREA-AS]. 1211 7. Management Considerations 1213 General PCE management considerations are discussed in [RFC4655]. In 1214 the case of the hierarchical PCE architecture, there are additional 1215 management considerations. 1217 The administrative entity responsible for the management of the 1218 parent PCEs must be determined. In the case of multi-domains (e.g., 1219 IGP areas or multiple ASes) within a single service provider 1220 network, the management responsibility for the parent PCE would most 1221 likely be handled by the service provider. In the case of multiple 1222 ASes within different service provider networks, it may be necessary 1223 for a third-party to manage the parent PCEs according to commercial 1224 and policy agreements from each of the participating service 1225 providers. 1227 7.1 Control of Function and Policy 1229 7.1.1 Child PCE 1231 Support of the hierarchical procedure will be controlled by the 1232 management organization responsible for each child PCE. A child PCE 1233 must be configured with the address of its parent PCE in order for 1234 it to interact with its parent PCE. The child PCE must also be 1235 authorized to peer with the parent PCE. 1237 7.1.2 Parent PCE 1239 The parent PCE must only accept path computation requests from 1240 authorized child PCEs. If a parent PCE receives requests from an 1241 unauthorized child PCE, the request should be dropped. 1243 This means that a parent PCE must be configured with the identities 1244 and security credentials of all of its child PCEs, or there must be 1245 some form of shared secret that allows an unknown child PCE to be 1246 authorized by the parent PCE. 1248 7.1.3 Policy Control 1250 It may be necessary to maintain a policy module on the parent PCE 1251 [RFC5394]. This would allow the parent PCE to apply commercially 1252 relevant constraints such as SLAs, security, peering preferences, and 1253 monetary costs. 1255 It may also be necessary for the parent PCE to limit end-to-end path 1256 selection by including or excluding specific domains based on 1257 commercial relationships, security implications, and reliability. 1259 7.2 Information and Data Models 1261 A PCEP MIB module is defined in [PCEP-MIB] that describes managed 1262 objects for modeling of PCEP communication. An additional PCEP MIB 1263 will be required to report parent PCE and child PCE information, 1264 including: 1266 o Parent PCE configuration and status, 1268 o Child PCE configuration and information, 1270 o Notifications to indicate session changes between parent PCEs and 1271 child PCEs. 1273 o Notification of parent PCE TED updates and changes. 1275 7.3 Liveness Detection and Monitoring 1277 The hierarchical procedure requires interaction with multiple PCEs. 1278 Once a child PCE requests an end-to-end path, a sequence of events 1279 occurs that requires interaction between the parent PCE and each 1280 child PCE. If a child PCE is not operational, and an alternate 1281 transit domain is not available, then a failure must be reported. 1283 7.4 Verifying Correct Operation 1285 Verifying the correct operation of a parent PCE can be performed by 1286 monitoring a set of parameters. The parent PCE implementation should 1287 provide the following parameters monitored by the parent PCE: 1289 o Number of child PCE requests. 1291 o Number of successful hierarchical PCE procedures completions on a 1292 per-PCE-peer basis. 1294 o Number of hierarchical PCE procedure completion failures on a per- 1295 PCE-peer basis. 1297 o Number of hierarchical PCE procedure requests from unauthorized 1298 child PCEs. 1300 7.5. Impact on Network Operation 1302 The hierarchical PCE procedure is a multiple-PCE path computation 1303 scheme. Subsequent requests to and from the child and parent PCEs do 1304 not differ from other path computation requests and should not have 1305 any significant impact on network operations. 1307 8. Security Considerations 1309 The hierarchical PCE procedure relies on PCEP and inherits the 1310 security requirements defined [RFC5440]. As noted in Section 7, 1311 there is a security relationship between child and parent PCEs. 1312 This relationship, like any PCEP relationship assumes 1313 pre-configuration of identities, authority, and keys, or can 1314 operate through any key distribution mechanism outside the scope of 1315 PCEP. As PCEP operates over TCP, it may make use of any TCP security 1316 mechanism. 1318 The hierarchical PCE architecture makes use of PCE policy 1319 [RFC5394] and the security aspects of the PCE communication protocol 1320 documented in [RFC5440]. It is expected that the parent PCE will 1321 require all child PCEs to use full security when communicating with 1322 the parent and that security will be maintained by not supporting the 1323 discovery by a parent of child PCEs. 1325 PCE operation also relies on information used to build the TED. 1326 Attacks on a PCE system may be achieved by falsifying or impeding 1327 this flow of information. The child PCE TEDs are constructed as 1328 described in [RFC4655] and are unchanged in this document: if the PCE 1329 listens to the IGP for this information, then normal IGP security 1330 measures may be applied, and it should be noted that an IGP routing 1331 system is generally assumed to be a trusted domain such that router 1332 subversion is not a risk. The parent PCE TED is constructed as 1333 described in this document and may involve: 1335 - multiple parent-child relationships using PCEP (as already 1336 described) 1338 - the parent PCE listening to child domain IGPs (with the same 1339 security features as a child PCE listening to its IGP) 1341 - an external mechanism (such as [BGP-TE]) which will need to be 1342 authorized and secured. 1344 Any multi-domain operation necessarily involves the exchange of 1345 information across domain boundaries. This is bound to represent a 1346 significant security and confidentiality risk especially when the 1347 child domains are controlled by different commercial concerns. PCEP 1348 allows individual PCEs to maintain confidentiality of their domain 1349 path information using Path Keys [RFC5520], and the hierarchical 1350 PCE architecture is specifically designed to enable as much isolation 1351 of domain topology and capabilities information as is possible. 1353 Further considerations of the security issues related to inter-AS 1354 path computation see [RFC5376]. 1356 9. IANA Considerations 1358 This document makes no requests for IANA action. 1360 10. Acknowledgements 1362 The authors would like to thank David Amzallag, Oscar Gonzalez de 1363 Dios, Franz Rambach, Ramon Casellas, Olivier Dugeon, Filippo Cugini, 1364 Dhruv Dhody and Julien Meuric for their comments and suggestions. 1366 11. References 1368 11.1 Normative References 1370 [RFC4655] Farrel, A., Vasseur, J., Ash, J., "A Path Computation 1371 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1373 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1374 Path Computation Method for Establishing Inter-Domain 1375 Traffic Engineering (TE) Label Switched Paths (LSPs)", 1376 RFC 5152, February 2008. 1378 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 1379 "Policy-Enabled Path Computation Framework", RFC 5394, 1380 December 2008. 1382 [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, 1383 A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, 1384 "Path Computation Element (PCE) Communication Protocol 1385 (PCEP)", RFC 5440, March 2009. 1387 [RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based 1388 Computation (BRPC) procedure to compute shortest inter- 1389 domain Traffic Engineering Label Switched Paths", RFC 1390 5441, April 2009. 1392 [RFC5520] Brandford, R., Vasseur J.P., and Farrel A., "Preserving 1393 Topology Confidentiality in Inter-Domain Path 1394 Computation Using a Key-Based Mechanism 1395 RFC5520, April 2009. 1397 11.2. Informative References 1399 [RFC4105] Le Roux, JL., Vasseur, J., Boyle, J., 1400 "Requirements for Inter-Area MPLS Traffic Engineering", 1401 RFC 4105, June 2005. 1403 [RFC4216] Zhang, R., and Vasseur, J., "MPLS Inter-Autonomous 1404 System (AS) Traffic Engineering (TE) Requirements", RFC 1405 4216, November 2005. 1407 [RFC4726] Farrel, A., Vasseur, J., Ayyangar, A., "A Framework 1408 for Inter-Domain Multiprotocol Label Switching Traffic 1409 Engineering", RFC 4726, November 2006. 1411 [RFC5152] Vasseur, JP., Ayyangar, A., Zhang, R., "A Per-Domain 1412 Path Computation Method for Establishing Inter-Domain 1413 Traffic Engineering (TE) Label Switched Paths (LSPs)", 1414 RFC 5152, February 2008. 1416 [RFC5316] Chen, M., Zhang, R., Duan, X., "ISIS Extensions in 1417 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1418 Traffic Engineering", RFC 5316, December 2008. 1420 [RFC5376] Bitar, N., et al., "Inter-AS Requirements for the 1421 Path Computation Element Communication Protocol 1422 (PCECP)", RFC 5376, November 2008. 1424 [RFC5392] Chen, M., Zhang, R., Duan, X., "OSPF Extensions in 1425 Support of Inter-Autonomous System (AS) MPLS and GMPLS 1426 Traffic Engineering", RFC 5392, January 2009. 1428 [RFC5541] Le Roux, J., Vasseur, J., Lee, Y., "Encoding 1429 of Objective Functions in the Path Computation Element 1430 Communication Protocol (PCEP)", RFC5541, December 2008. 1432 [G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for 1433 the automatically switched optical network (ASON). 1435 [G-7715] ITU-T Recommendation G.7715 (2002), Architecture 1436 and Requirements for the Automatically 1437 Switched Optical Network (ASON). 1439 [G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON 1440 routing architecture and requirements for remote route 1441 query. 1443 [BGP-TE] Gredler, H., Medved, J, Farrel, A. Previdi, S., 1444 "North-Bound Distribution of Link-State and TE 1445 Information using BGP", draft-gredler-idr-ls-distribution, 1446 work in progress. 1448 [PCE-AREA-AS] King, D., Meuric, J., Dugeon, O., Zhao, Q., Gonzalez de 1449 Dios, O., "Applicability of the Path Computation Element 1450 to Inter-Area and Inter-AS MPLS and GMPLS Traffic 1451 Engineering", draft-ietf-pce-inter-area-as-applicability, 1452 work in progress. 1454 [PCEP-MIB] Stephan, E., Koushik, K., Zhao, Q., King, D., "PCE 1455 Communication Protocol (PCEP) Management Information 1456 Base", work in progress. 1458 12. Authors' Addresses 1460 Daniel King 1461 Old Dog Consulting 1462 UK 1464 Email: daniel@olddog.co.uk 1466 Adrian Farrel 1467 Old Dog Consulting 1468 UK 1470 Email: adrian@olddog.co.uk 1472 Quintin Zhao 1473 Huawei Technology 1474 125 Nagog Technology Park 1475 Acton, MA 01719 1476 US 1478 Email: qzhao@huawei.com 1479 Fatai Zhang 1480 Huawei Technologies 1481 F3-5-B R&D Center, Huawei Base 1482 Bantian, Longgang District 1483 Shenzhen 518129 P.R.China 1485 Email: zhangfatai@huawei.com