idnits 2.17.1 draft-ietf-pce-inter-area-as-applicability-02.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 (January 16, 2012) is 4477 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6006 (Obsoleted by RFC 8306) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PCE Working Group D. King 2 Internet Draft Old Dog Consulting 3 Intended status: Informational J. Meuric 4 Expires: June 16, 2012 O. Dugeon 5 France Telecom 6 Q. Zhao 7 Huawei Technologies 8 Oscar Gonzalez de Dios 9 Francisco Javier Jimenex Chico 10 Telefonica I+D 11 January 16, 2012 13 Applicability of the Path Computation Element to Inter-Area and 14 Inter-AS MPLS and GMPLS Traffic Engineering 16 draft-ietf-pce-inter-area-as-applicability-02 18 Abstract 20 The Path Computation Element (PCE) may be used for computing services 21 that traverse multi-area and multi-AS Multiprotocol Label Switching 22 (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. 24 This document examines the applicability of the PCE architecture, 25 protocols, and protocol extensions for computing multi-area and 26 multi-AS paths in MPLS and GMPLS networks. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 This Internet-Draft will expire on October 18, 2012. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction.................................................3 69 1.1. Domains....................................................4 70 1.2. Path Computation...........................................4 71 1.2.1 PCE-based Path Computation Procedure......................5 72 1.3. Traffic Engineering Aggregation and Abstraction............5 73 1.4. Traffic Engineered Label Switched Paths....................6 74 1.5. Inter-area and Inter AS Connectivity Discovery.............6 75 2. Terminology..................................................6 76 3. Issues and Considerations....................................7 77 3.1 Multi-homing.............................................7 78 3.2 Domain Confidentiality ..................................7 79 3.3 Destination Location.....................................7 80 4. Domain Topologies............................................8 81 4.1 Selecting Domain Paths...................................8 82 4.2 Multi-Homed Domains......................................8 83 4.3 Domain Meshes............................................8 84 4.4 Domain Diversity.........................................8 85 4.5 Synchronized Path Computations...........................9 86 5. Applicability of the PCE to Inter-area Traffic Engineering...9 87 5.1. Inter-area Routing......................................10 88 5.1.1. Area Inclusion and Exclusion..........................10 89 5.1.2. Strict Explicit Path and Loose Path...................11 90 5.1.3. Inter-Area Diverse Path Computation...................11 91 5.2. Control and Recording of Area Crossing..................11 92 6. Applicability of the PCE to Inter-AS Traffic Engineering.....11 93 6.1. Inter-AS Routing........................................12 94 6.1.1. AS Inclusion and Exclusion............................12 95 6.1.2. Strict Explicit Path and Loose Path...................12 96 6.1.3. AS Inclusion and Exclusion............................12 97 6.2. Inter-AS Bandwidth Guarantees...........................12 98 6.3. Inter-AS Recovery.......................................13 99 6.4. Inter-AS PCE Peering Policies...........................13 101 7. Multi-Domain PCE Deployment..................................13 102 7.1 Traffic Engineering Database.............................14 103 7.2 Provisioning Techniques..................................15 104 7.3 Pre-Planning and Management-Based Solutions..............15 105 7.4 Per-Domain Computation...................................15 106 7.5 Cooperative PCEs.........................................15 107 7.6 Hierarchical PCEs ......................................16 108 8. Domain Confidentiality.......................................16 109 8.1 Loose Hops...............................................16 110 8.2 Confidential Path Segments and Path Keys.................16 111 9. Point-to-Multipoint..........................................17 112 10. Optical Domains.............................................17 113 10.1. PCE applied to the ASON Architecture......................17 114 11. Manageability Considerations................................18 115 12. Security Considerations.....................................18 116 13. IANA Considerations.........................................18 117 14. References..................................................18 118 14.1. Normative References......................................18 119 14.2. Informative References....................................18 120 15. Acknowledgements............................................20 121 16. Author's Address............................................20 123 1. Introduction 125 Computing paths across large multi-domain environments may 126 require special computational components and cooperation between 127 entities in different domains capable of complex path computation. 128 The Path Computation Element (PCE) [RFC4655] provides an architecture 129 and a set of functional components to address this problem space. 131 Computing optimal routes for LSPs that cross domains in MPLS-TE and 132 GMPLS networks presents a problem because no single point of path 133 computation is aware of all of the links and resources in each 134 domain. A solution may be achieved using the PCE architecture 135 [RFC4655]. 137 A domain can be defined as a separate administrative, geographic, or 138 switching environment within the network. A domain may be further 139 defined as a zone of routing or computational ability. Under these 140 definitions a domain might be categorized as an Antonymous System 141 (AS) or an Interior Gateway Protocol (IGP) area ( as per [RFC4726] 142 and [RFC4655]). 144 A PCE may be used to compute end-to-end paths across multi-domain 145 environments using a per-domain path computation technique [RFC5152]. 146 The so called backward recursive path computation (BRPC) mechanism 147 [RFC5441] defines a PCE-based path computation procedure to compute 148 inter-domain constrained (G)MPLS TE LSPs. However, both per-domain 149 and BRPC techniques assume that the sequence of domains to be crossed 150 from source to destination is known, either fixed by the network 151 operator or obtained by other means. In more advanced deployments 152 (including multi-area and multi-AS environments) the sequence of 153 domains may not be known in advance and the choice of domains in the 154 end-to-end domain sequence might be critical to the determination of 155 an optimal end-to-end path 157 In this case the use of the Hierarchical PCE [H-PCE] architecture and 158 mechanisms may be used to discovery the intra-area path and select 159 the optimal end-to-end domain sequence. 161 This document examines the applicability and describes the processes 162 and procedures available when using the PCE architecture, protocols 163 and protocol extensions for computing inter-area and inter-AS MPLS 164 Traffic Engineered paths. 166 1.1 Domains 168 For the purposes of this document, a domain is considered to be a 169 collection of network elements within an area or AS that has a common 170 sphere of address management or path computational responsibility. 171 Wholly or partially overlapping domains are not within the scope of 172 this document. 174 In the context of GMPLS, a particularly important example of a domain 175 is the Automatically Switched Optical Network (ASON) subnetwork 176 [G-8080]. In this case, computation of an end-to-end path requires 177 the selection of nodes and links within a parent domain where some 178 nodes may, in fact, be subnetworks. Furthermore, a domain might be an 179 ASON routing area [G-7715]. A PCE may perform the path computation 180 function of an ASON routing controller as described in [G-7715-2]. 182 It is assumed that the PCE architecture should be applied to small 183 inter-domain topologies and not to solve route computation issues 184 across large groups of domains, I.E. the entire Internet. 186 1.2 Path Computation 188 For the purpose of this document it is assumed that the 189 path computation is the sole responsibility of the PCE as per the 190 architecture defined in [RFC4655]. When a path is required the Path 191 Computation Client (PCC) will send a request to the PCE. The PCE will 192 apply the required constraints and compute a path and return a 193 response to the PCC. In the context of this document it maybe 194 necessary for the PCE to co-operate with other PCEs in adjacent 195 domains (as per BRPC [RFC5441]) or cooperate with the Parent PCE 196 (as per [H-PCE]). 198 It is entirely feasible that an operator could compute a path across 199 multiple domains without the use of a PCE if the relevant domain 200 information is available to the network planner or network management 201 platform. The definition of what relevant information is required to 202 perform this network planning operation and how that information is 203 discovered and applied is outside the scope of this document. 205 1.2.1 PCE-based Path Computation Procedure 207 As discussed, the PCE is an entity capable of computing an 208 inter-domain TE path upon receiving a request from a PCC. There could 209 be a single PCE per domain, or single PCE responsible for all 210 domains. A PCE may or may not reside on the same node as the 211 requesting PCC. A path may be computed by either a single PCE node 212 or a set of distributed PCE nodes that collaborate during path 213 computation. 215 [RFC4655] defines that a PCC should send a path computation request 216 to a particular PCE, using [RFC5440] (PCC-to-PCE communication). 217 This negates the need to broadcast a request to all the PCEs. Each 218 PCC can maintain information about the computation capabilities 219 of the PCEs it is aware of. The PCC-PCE capability awareness can 220 configured using static configuration or by listening to 221 the periodic advertisements generated by PCEs. 223 One a path computation request is received, the PCC will send a 224 request to the PCE. A PCE may compute the end-to-end path 225 if it is aware of the topology and TE information required to 226 compute the entire path. If the PCE is unable to compute the 227 entire path, the PCE architecture provides co-operative PCE 228 mechanisms for the resolution of path computation requests when an 229 individual PCE does not have sufficient TE visibility. 231 A PCE may cooperate with other PCEs to determine intermediate loose 232 hops. End-to-end path segments may be kept confidential through the 233 application of path keys, to protect partial or full path 234 information. A path key that is a token that replaces a path segment 235 in an explicit route. The path key mechanism is described in 236 [RFC5520] 238 1.3 Traffic Engineering Aggregation and Abstraction 240 Networks are often constructed from multiple areas or ASs that are 241 interconnected via multiple interconnect points. To maintain 242 network confidentiality and scalability TE properties of each area 243 and AS are not generally advertized outside each specific area or AS. 245 TE aggregation or abstraction provide mechanism to hide information 246 but may cause failed path setups or the selection of suboptimal 247 end-to-end paths [RFC4726]. The aggregation process may also have 248 significant scaling issues for networks with many possible routes 249 and multiple TE metrics. Flooding TE information breaks 250 confidentiality and does not scale in the routing protocol. 252 The PCE architecture and associated mechanisms provide a solution 253 to avoid the use of TE aggregation and abstraction. 255 1.4 Traffic Engineered Label Switched Paths 257 This document highlights the PCE techniques and mechanisms that exist 258 for establishing TE packet and optical LSPs across multiple areas 259 (inter-area TE LSP) and ASs (inter-AS TE LSP). In this context and 260 within the remainder of this document, we consider all LSPs to be 261 constraint-based and traffic engineered. 263 Three signaling options are defined for setting up an inter-area or 264 inter-AS LSP [RFC4726]: 266 - Contiguous LSP 267 - Stitched LSP 268 - Nested LSP 270 All three signaling methods are applicable to the architectures and 271 procedures discussed in this document. 273 1.5 Inter-area and Inter-AS Connectivity Discovery 275 When using a PCE-based approach for inter-area and inter-AS path 276 computation, a PCE in one area or AS may need to learn information 277 related to inter-AS capable PCEs located in other ASs. The PCE 278 discovery mechanism defined in [RFC5088] and [RFC5089] allow 279 the discovery of PCEs and disclosure of information related to 280 inter-area and inter-AS capable PCEs across area and AS boundaries. 282 2. Terminology 284 Terminology used in this document. 286 ABR: IGP Area Border Router, a router that is attached to more than 287 one IGP area. 289 ASBR: Autonomous System Border Router, a router used to connect 290 together ASs of a different or the same Service Provider via one or 291 more inter-AS links. 293 CSPF: Constrained Shortest Path First. 295 Inter-area TE LSP: A TE LSP whose path transits through two or more 296 IGP areas. 298 Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or 299 more ASs or sub-ASs (BGP confederations 301 SRLG: Shared Risk Link Group. 303 TED: Traffic Engineering Database, which contains the topology and 304 resource information of the domain. The TED may be fed by Interior 305 Gateway Protocol (IGP) extensions or potentially by other means. 307 This document also uses the terminology defined in [RFC4655] and 308 [RFC5440]. 310 3. Issues and Considerations 312 3.1 Multi-homing 314 Networks constructed from multi-areas or multi-AS environments 315 may have multiple interconnect points (multi-homing). End-to-end path 316 computations may need to use different interconnect points to avoid 317 single point failures disrupting primary and backup services. 319 Domain and path diversity may also be required when computing 320 end-to-end paths. Domain diversity should facilitate the selection 321 of paths that share ingress and egress domains, but do not share 322 transit domains. Therefore, there must be a method allowing the 323 inclusion or exclusion of specific domains when computing end-to-end 324 paths. 326 3.2 Domain Confidentiality 328 Where the end-to-end path crosses multiple domains, it may be 329 possible that each domain (AS or area) are administered by separate 330 Service Providers, it would break confidentiality rules for a PCE 331 to supply a path segment to a PCE in another domain, thus disclosing 332 AS-internal topology information. 334 If confidentiality is required between domains (ASes and areas) 335 belonging to different Service Providers. Then cooperating PCEs 336 cannot exchange path segments or else the receiving PCE PCC will be 337 able to see the individual hops through another domain. 339 3.3 Destination Location 341 The PCC asking for an inter-domain path computation is typically 342 aware of the identity of the destination node. Additionally, if the 343 PCC is aware of the destination domain, it can supply this 344 information as part of the path computation request. However, 345 if the PCC does not know the egress domain this information must 346 be determined by another method. 348 4. Domain Topologies 350 Constraint-based inter-domain path computation is a fundamental 351 requirement for operating traffic engineered MPLS [RFC3209] and 352 GMPLS [RFC3473] networks, in inter-area and inter-AS (multi-domain) 353 environments. Path computation across multi-domain networks is 354 complex and requires computational cooperational entities like the 355 PCE. 357 4.1 Selecting Domain Paths 359 Where the sequence of domains is known a priori, various techniques 360 can be employed to derive an optimal multi-domain path. If the 361 domains are simply-connected, or if the preferred points of 362 interconnection are also known, the Per-Domain Path Computation 363 [RFC5152] technique can be used. Where there are multiple connections 364 between domains and there is no preference for the choice of points 365 of interconnection, BRPC [RFC5441] can be used to derive an optimal 366 path. 368 When the sequence of domains is not known in advance, the optimum 369 end-to-end path can be derived through the use of a hierarchical 370 relationship between domains [H-PCE]. 372 4.2 Multi-Homed Domains 374 Networks constructed from multi-areas or multi-AS environments 375 may have multiple interconnect points (multi-homing). End-to-end path 376 computations may need to use different interconnect points to avoid 377 single point failures disrupting primary and backup services. 379 4.3 Domain Meshes 381 Very frequently network domains are composed by dozens or hundreds of 382 network elements. These network elements are usually interconnected 383 between them in a partial-mesh fashion, to provide survivability 384 against dual failures, and to benefit from the traffic engineering 385 capabilities from MPLS and GMPLS protocols. A typical node degree 386 ranges from 3 to 10 (4-5 is quite common), being the node degree the 387 number of neighbors per node. 389 Networks are sometimes divided into domains. Some reasons for it 390 range from manageability to separation into vendor-specific domains. 391 The size of the domain will be usually limited by control plane, but 392 it can also be stated by arbitrary design constraints. 394 4.4 Domain Diversity 396 Whenever an specific connectivity service is required to have 1+1 397 protection feature, two completely disjoint paths must be 398 established on an end to end fashion. In a multi-domain environment 399 without, this can be accomplished either by selecting domain 400 diversity, or by ensuring diverse connection within a domain. In 401 order to compute the route diversity, it could be helpful to have 402 SRLG information in the domains. 404 4.5 Synchronized Path Computations 406 In some scenarios, it would be beneficial for the operator to rely on 407 the capability of the PCE to perform synchronized path computation. 409 Synchronized path computations, known as Synchronization VECtors 410 (SVECs) are used for dependent path computations. [RFC6007] provides 411 an overview for the use of the PCE SVEC list for synchronized path 412 computations when computing dependent requests. 414 A non-comprehensive list of synchronized path computations include 415 the following examples: 417 o Route diversity: computation of two disjoint paths from a source to 418 a destination (as drafted in the previous section). 420 o Synchronous restoration: joint computation of a set of alternative 421 paths for a set of affected LSPs as a consequence of a failure 422 event. Note that in this case, the requests will potentially 423 involve different source-destination pairs. In this scenario, the 424 different path computation requests may arrive at different time 425 stamps. 427 o Batch provisioning: It is common that the operator sends a set of 428 LSPs requests together, e.g in a daily of weekly basis, mainly in 429 case of long lived LSPs. In order to optimize the resource usage, 430 a synchronized path computation is needed. 432 o Network optimization: After some time of operation, the 433 distribution of the established LSP paths results in a non optimal 434 use of resources. Also, inter-domain policies/agreements may have 435 been changed. In such cases, a full (or partial) network planning 436 action regarding the inter-domain connections will be triggered. 437 This will involve the request of potentially a big amount of 438 connections. 440 5. Applicability of the PCE to Inter-area Traffic Engineering 442 As networks increase in size and complexity it may be required to 443 introduce scaling methods to reduce the amount information flooded 444 within the network and make the network more manageable. An IGP 445 hierarchy is designed to improve IGP scalability by dividing the 446 IGP domain into areas and limiting the flooding scope of topology 447 information to within area boundaries. This restricts visibility of 448 the area to routers in a single area. If a router needs to compute a 449 route to destination located in another area a method is required to 450 compute a path across area boundaries. 452 In order to support multiple vendors in a network, in cases where 453 data and/or control plane technologies cannot interoperate, it is 454 useful to divide the network in vendor domains. Each vendor domain is 455 an IGP area, and the flooding scope of the topology (as well as any 456 other relevant information) is limited to the area boundaries. 458 Per-domain path computation [RFC5152] exists to provide a method of 459 inter-area path computation. The per-domain solution is based on 460 loose hop routing with an Explicit Route Object (ERO) expansion on 461 each Area Border Router (ABR). This allows an LSP to be established 462 using a constrained path, however at least two issues exist: 464 - This method does not guarantee an optimal constrained path. 466 - The method may require several crankback signaling messages 467 increasing signaling traffic and delaying the LSP setup. 469 The PCE-based architecture [RFC4655] is designed to solve inter-area 470 path computation problems. The issue of limited topology visibility 471 is resolved by introducing path computation entities that are able to 472 cooperate in order to establish LSPs with source and destinations 473 located in different areas. 475 5.1. Inter-area Routing 477 An inter-area TE-LSP is an LSP that transits through at least two 478 IGP areas. In a multi-area network, topology visibility remains 479 local to a given area, and a node in one area will not be able to 480 compute an end-to-end path across multiple areas without the use 481 of a PCE. 483 5.1.1. Area Inclusion and Exclusion 485 [RFC5152] provides the mechanisms to compute an inter-area 486 path. It uses loose hop routing with an ERO expansion on each ABR. 487 This allows the end-to-end path to be set up following a constrained 488 path, but faces two major limitations: 490 - The method does not guarantee the use of an optimal constrained 491 path. 493 - This may lead to several crankback signaling messages and hence 494 delay the path setup. 496 [RFC5441] provides a more optimal method to specify inclusion or 497 exclusion of an ABR. Using this method, an operator might decide if 498 an area must be include or exclude from the inter-area path 499 computation. 501 5.1.2. Strict Explicit Path and Loose Path 503 A strict explicit Path is defined as a set of strict hops, while a 504 loose path is defined as a set of at least one loose hop and zero, 505 one or more strict hops. It may be useful to indicate, during the 506 path computation request, if a strict explicit path is required or 507 not. An inter-area path may be strictly explicit or loose (e.g., a 508 list of ABRs as loose hops). 510 A PCC request to a PCE does allow the indication of if a strict 511 explicit path across specific areas is required or desired, or if 512 the path request is loose. 514 5.1.3. Inter-Area Diverse Path Computation 516 It may be neccessary (for protection or load-balancing) to compute 517 a path that is diverse, from a previously computed path. There are 518 various levels of diversity in the context of an inter-area network: 520 - Per-area diversity (intra-area path segments are link, node or 521 SRLG disjoint. 523 - Inter-area diversity (end-to-end inter-area paths are link, 524 node or SRLG disjoint). 526 Note that two paths may be disjoint in the backbone area but non- 527 disjoint in peripheral areas. Also two paths may be node disjoint 528 within areas but may share ABRs, in which case path segments within 529 an area are node disjoint but end-to-end paths are not node-disjoint. 531 Both Per-Domain [RFC5152] and BRPC [RFC5441] mechanisms support the 532 capability to compute diverse across multi-area topologies. 534 5.2. Control and Recording of Area Crossing 536 In some environments it be useful for the PCE to provide a PCC the 537 set of areas crossed by the end-to-end path. Additionally the PCE 538 can provide the path information and mark each segment so the PCC 539 has visibility of which piece of the path lies within which area. 540 Although by implementing Path-Key, the hop-by-hop (area topology) 541 information is kept confidential. 543 6. Applicability of the PCE to Inter-AS Traffic Engineering 544 As discussed in section 4 (Applicability of the PCE to Inter-area 545 Traffic Engineering) it is necessary to divide the network into 546 smaller administrative domains, or ASs. If an LSR within an AS needs 547 to compute a path across an AS boundary it must also use an inter-AS 548 computation technique. [RFC5152] defines mechanisms for the 549 computation of inter-domain TE LSPs using network elements along the 550 signaling paths to compute per-domain constrained path segments. 552 The PCE was designed to be capable of computing MPLS and GMPLS paths 553 across AS boundaries. This section outlines the features of a 554 PCE-enabled solution for computing inter-AS paths. 556 6.1 Inter-AS Routing 558 6.1.1. AS Inclusion and Exclusion 560 [RFC5441] a method to specify inclusion or exclusion of an ASBR. 561 Using this method, an operator might decide if an AS must be include 562 or exclude from the inter-AS path computation. 564 6.1.2. Strict Explicit Path and Loose Path 566 During path computation, the PCE architecture and BRPC algorithm 567 allow operators to specify if the resultant LSP must follow a strict 568 or a loose path. By explicitly specify the path, the operator 569 request a strict explicit path which must pass through one or many 570 LSR. If this behaviour is well define and appropriate for inter-area, 571 it implies some topology discovery for inter-AS. So, this feature 572 when the operator owns several ASs (and so, knows the topology of 573 its ASs) or restricts to the well-known ASBR to avoid topology 574 discovery between operators. The loose path, even if it does not 575 allow granular specification of the path, protects topology 576 disclosure as it not obligatory for the operator to disclose 577 information about its networks. 579 6.1.3. AS Inclusion and Exclusion 581 Like explicit and loose path, [RFC5441] allows to specify inclusion 582 or exclusion of respectively an AS or an ASBR. Using this method, 583 an operator might decide if an AS must be include or exclude from 584 the inter-AS path computation. Exclusion and/or inclusion could also 585 be specified at any step in the LSP path computation process by a PCE 586 (within the BRPC algorithm) but the best practice would be to specify 587 them at the edge. In opposition to the strict and loose path, AS 588 inclusion or exclusion doesn't impose topology disclosure as ASs are 589 public entity as well as their interconnection. 591 6.2 Inter-AS Bandwidth Guarantees 592 Many operators with multi-AS domains will have deployed MPLS-TE 593 DiffServ either across their entire network or at the domain 594 edges on CE-PE links. In situations where strict QOS bounds are 595 required, admission control inside the network may also be required. 597 When the propagation delay can be bounded, the performance targets, 598 such as maximum one-way transit delay may be guaranteed by providing 599 bandwidth guarantees along the DiffServ-enabled path. 601 One typical example of this requirement is to provide bandwidth 602 guarantees over an end-to-end path for VoIP traffic classified as EF 603 (Expedited Forwarding) class in a Diffserv-enabled 604 network. In the case where the EF path is extended across multiple 605 ASs, inter-AS bandwidth guarantee would be required. 607 Another case for inter-AS bandwidth guarantee is the requirement for 608 guaranteeing a certain amount of transit bandwidth across one or 609 multiple ASs. 611 6.3 Inter-AS Recovery 613 During path computation, a PCC request may contain backup LSP 614 requirements in order to setup in the same time the primary and 615 backup LSPs. It is also possible to request a backup LSP for a group 616 of primary LSPs. [RFC4090] adds fast re-route protection to LSP. So, 617 the PCE could be used to trigger computation of backup tunnels in 618 order to protect Inter-AS connectivity. Inter-AS recovery 619 requirements needs not only PCE protection and redundancy but also 620 LSP tunnels protection through FRR mechanisms. Inter-AS PCE 621 computation must support the FRR mechanisms and the patch computation 622 for backup tunnels for protection and fast recovery. 624 6.4 Inter-AS PCE Peering Policies 626 Like BGP peering policies, inter-AS PCE peering policies is a 627 requirement for operator. In inter-AS BRPC process, PCE must 628 cooperate in order to compute the end-to-end LSP. So, the AS path 629 must not only follow technical constraints e.g. bandwidth 630 availability, but also policies define by the operator. 632 Typically PCE interconnections at an AS level must follow contract 633 obligations, also known as peering agreements. The PCE peering 634 policies are the result of the contract negotiation and govern 635 the relation between the different PCE. 637 7. Multi-domain PCE Deployment Options 639 The PCE provides the architecture and mechanisms to compute 640 inter-area and inter-AS LSPs. The objective of this document is not 641 to reprint the techniques and mechanisms available, but to highlight 642 their existence and reference the relevant documents that introduce 643 and describe the techniques and mechanisms necessary for computing 644 inter-area and inter-AS LSP based services. 646 An area or AS may contain multiple PCEs: 648 - The path computation load may be balanced among a set of PCEs to 649 improve scalability. 651 - For the purpose of redundancy, primary and backup PCEs may be used. 653 - PCEs may have distinct path computation capabilities (P2P or P2MP). 655 Discovery of PCEs and capabilities per area or AS is defined in 656 [RFC5088] and [RFC5089]. 658 Each PCE per domain can be deployed in a centralized or distributed 659 architecture, the latter model having local visibility and 660 collaborating in a distributed fashion to compute a path across the 661 domain. Each PCE may collect topology and TE information from the 662 same sources as the LSR, such as the IGP TED. 664 When the PCC sends a path computation request to the PCE, the PCE 665 will compute the path across a domain based on the required 666 constraints. The PCE will generate the full set of strict hops from 667 source to destination. This information, encoded as an ERO, is then 668 sent back to the PCC that requested the path. In the event that a 669 path request from a PCC contains source and destination nodes that 670 are located in different domains the PCE is required to co-operate 671 between multiple PCEs, each responsible for its own domain. 673 Techniques for inter-domain path computation are described in 674 [RFC5152] and [RFC5441], both techniques assume that the sequence of 675 domains to be crossed from source to destination is well known. In 676 the event that the sequence of domains is not well known, [H-PCE] 677 might be used. The sequence could also be retrieve locally from 678 information previously stored in the PCE database (preferably in 679 the TED) by OSS management or other protocols. 681 7.1 Traffic Engineering Database 683 TEDs are automatically populated by the IGP-TE like IS-IS-TE or 684 OSPF-TE. However, no information related to AS path are provided 685 by such IGP-TE. It could be helpful for BRPC algorithm as AS path 686 helper, to populate a TED with suitable information regarding 687 inter-AS connectivity. Such information could be obtain from 688 various sources, such as BGP protocol, peering policies, OSS of the 689 operator or from neighbor PCE. In any case, no topology disclosure 690 must be impose in order to provide such information. 692 In particular, for both inter-area and inter-AS, the TED must be 693 populated with all boundary node information suitable to 694 establish PCEP protocol with the next PCE in the path. 696 7.2 Provisioning Techniques 698 As PCE algorithms rely on information contained in the TED, it 699 is possible to populate TED information by means of provisioning. In 700 this case, the operator must regularly update and store all suitable 701 information in the TED in order for the PCE to correctly compute LSP. 702 Such information range from policies (e.g. avoid this LSR, or use 703 this ASBR for a specific IP prefix) up to topology information (e.g. 704 AS X is reachable trough a 100 Mbit/s link on this ASBR and 30 Mbit/s 705 are reserved for EF traffic). Operators may choose the type and 706 amount of information they can use to manage their traffic engineered 707 network. 709 However, some LSPs might be provisioned to link ASs or areas. In this 710 case, these LSP must be announced by the IGP-TE in order to 711 automatically populate the TED. 713 7.3 Pre-Planning and Management-Based Solutions 715 Offline path computation is performed ahead of time, before the LSP 716 setup is requested. That means that it is requested by, or performed 717 as part of, a management application. This model can be seen in 718 Section 5.5 of [RFC4655]. 720 The offline model is particularly appropriate to long-lived LSPs 721 (such as those present in a transport network) or for planned 722 responses to network failures. In these scenarios, more planning is 723 normally a feature of LSP provisioning. 725 This model may also be used where the network operator wishes to 726 retain full manual control of the placement of LSPs, using the PCE 727 only as a computation tool to assist the operator, not as part of an 728 automated network. 730 The management based solutions could also be used in conjunction 731 with the BRPC algorithm. Operator just computes the AS-Path as 732 parameter for the inter-AS path computation request and let each 733 PCE along the AS path compute the LSP part on its own domain. 735 7.4 Per-Domain Computation 737 [RFC5152] defines the mechanism to compute per-domain path and must 738 be used in that condition. Otherwise, BRPC [RFC5441] will be used. 740 7.5 Cooperative PCEs 741 When PCE cooperate to compute an inter-area or inter-AS LSP, both 742 [RFC5152] and [RFC5441] could be used. 744 7.6 Hierarchical PCEs 746 The [H-PCE] draft defines how a hierarchy of PCEs may be used. An 747 operator must define a parent PCE and each child PCE. A parent PCE 748 can be announced in the other areas or ASs in order for the parent 749 PCE to contact remote child PCEs. Reciprocally, child PCEs are 750 announced in remote areas or ASs in order to be contacted by a 751 remote parent PCE. Parent and each child PCE could also be 752 provisioned in the TED if they are not announced. 754 8. Domain Confidentiality 756 Confidentiality typically applies to inter-provider (inter-AS) PCE 757 communication. Where the TE LSP crosses multiple domains (ASes or 758 areas), the path may be computed by multiple PCEs that cooperate 759 together. With each local PCE responsible for computing a segment 760 of the path. However, in some cases (e.g., when ASes are 761 administered by separate Service Providers), it would break 762 confidentiality rules for a PCE to supply a path segment to a 763 PCE in another domain, thus disclosing AS-internal or area 764 topology information. 766 8.1 Loose Hops 768 A method for preserving the confidentiality of the path segment is 769 for the PCE to return a path containing a loose hop in place of the 770 segment that must be kept confidential. The concept of loose and 771 strict hops for the route of a TE LSP is described in [RFC3209]. 773 [RFC5440] supports the use of paths with loose hops, and it is a 774 local policy decision at a PCE whether it returns a full explicit 775 path with strict hops or uses loose hops. A path computation 776 request may request an explicit path with strict hops, or 777 may allow loose hops as detailed in [RFC5440]. 779 8.2 Confidential Path Segments and Path Keys 781 [RFC5520] defines the concept and mechanism of Path-Key. A Path-Key 782 is a token that replaces the path segment information in an explicit 783 route. The Path-Key allows the explicit route enformation to be 784 encoded and in the PCEP ([RFC5440]) messages exchanged between the 785 PCE and PCC. 787 This Path-Key technique allows explicit route information to used 788 for end-to-end path computation, without disclosing internal topology 789 information between domains. 791 9. Point-to-Multipoint 793 For the Point-to-Multipoint application scenarios for MPLS-TE LSP, 794 the complexity of domain sequences, domain policies, choice and 795 number of domain interconnects is magnified comparing to 796 P2P path computations. Also as the size of the network grows, 797 the number of leaves and branches increase and it in turn puts the 798 scalability of the path computation and optimization into a bigger 799 issue. A solution for the point-to-multipoint path computations may 800 be achieved using the PCEP protocol extension for P2MP 801 [RFC6006] and using the PCEP P2MP procedures defined in 802 [PCEP-P2MP-INTER-DOMAIN]. 804 10. Optical Domains 806 The International Telecommunications Union (ITU) defines the ASON 807 architecture in [G-8080]. [G-7715] defines the routing architecture 808 for ASON and introduces a hierarchical architecture. In this 809 architecture, the Routing Areas (RAs) have a hierarchical 810 relationship between different routing levels, which means a parent 811 (or higher level) RA can contain multiple child RAs. The 812 interconnectivity of the lower RAs is visible to the higher level RA. 814 10.1. PCE applied to the ASON Architecture 816 In the ASON framework, a path computation request is termed a Route 817 Query. This query is executed before signaling is used to establish 818 an LSP termed a Switched Connection (SC) or a Soft Permanent 819 Connection (SPC). [G-7715-2] defines the requirements and 820 architecture for the functions performed by Routing Controllers (RC) 821 during the operation of remote route queries - an RC is synonymous 822 with a PCE. 824 In the ASON routing environment, a RC responsible for an RA may 825 communicate with its neighbor RC to request the computation of an 826 end-to-end path across several RAs. The path computation components 827 and sequences are defined as follows: 829 o Remote route query. An operation where a routing controller 830 communicates with another routing controller, which does not have 831 the same set of layer resources, in order to compute a routing 832 path in a collaborative manner. 834 o Route query requester. The connection controller or RC that sends a 835 route query message to a routing controller requesting for one or 836 more routing path that satisfies a set of routing constraints. 838 o Route query responder. An RC that performs path computation upon 839 reception of a route query message from a routing controller or 840 connection controller, sending a response back at the end of 841 computation. 843 When computing an end-to-end connection, the route may be computed by 844 a single RC or multiple RCs in a collaborative manner and the two 845 scenarios can be considered a centralized remote route query model 846 and distributed remote route query model. RCs in an ASON environment 847 can also use the hierarchical PCE [H-PCE] model to fully match the 848 ASON hierarchical routing model. 850 11. Manageability Considerations 852 This document does not describe any specific protocol, 853 protocol extensions, or protocol usage, therefore no manageability 854 considerations need to be discussed here. 856 12. Security Considerations 858 This document is informational and does not describe any new 859 specific protocol, protocol extensions, or protocol usage. As such, 860 it introduces no new security concerns. 862 13. IANA Considerations 864 This document makes no requests for IANA action. 866 13. References 868 14.1. Normative References 870 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 871 Element (PCE)-Based Architecture", RFC 4655, August 2006. 873 [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, 874 A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, 875 "Path Computation Element (PCE) Communication Protocol 876 (PCEP)", RFC 5440, March 2009. 878 14.2. Informative References 880 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 881 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 882 Tunnels", RFC 3209, December 2001. 884 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 885 Switching (GMPLS) Signaling Resource ReserVation 886 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 887 3473, January 2003. 889 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 890 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 891 2005. 893 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework 894 for Inter-Domain Multiprotocol Label Switching Traffic 895 Engineering", RFC 4726, November 2006. 897 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 898 "OSPF Protocol Extensions for Path Computation Element 899 (PCE) Discovery", RFC 5088, January 2008. 901 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 902 Zhang, "IS-IS Protocol Extensions for Path Computation 903 Element (PCE) Discovery", RFC 5089, January 2008. 905 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 906 Path Computation Method for Establishing Inter-Domain 907 Traffic Engineering (TE) Label Switched Paths (LSPs)", 908 RFC 5152, February 2008. 910 [RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based 911 Computation (BRPC) procedure to compute shortest inter- 912 domain Traffic Engineering Label Switched Paths", 913 RFC5441, April 2009. 915 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 916 "Preserving Topology Confidentiality in Inter-Domain Path 917 Computation Using a Path-Key-Based Mechanism", RFC 5520, 918 April 2009. 920 [RFC6006] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z., 921 Zhao, Q., King, D., "Extensions to the Path Computation 922 Element Communication Protocol (PCEP) for 923 Point-to-Multipoint Traffic Engineering Label Switched 924 Paths", RFC6006, September 2010. 926 [RFC6007] Nishioka, I., King, D., "Use of the Synchronization 927 VECtor (SVEC) List for Synchronized Dependent Path 928 Computations", RFC6007, September 2010. 930 [G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for 931 the automatically switched optical network (ASON). 933 [G-7715] ITU-T Recommendation G.7715 (2002), Architecture 934 and Requirements for the Automatically Switched 935 Optical Network (ASON). 937 [G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing 938 architecture and requirements for remote route query. 940 [PCEP-P2MP-INTER-DOMAIN] Ali Z., Zhao, Q., King, D., "PCE-based 941 Computation Procedure To Compute Shortest Constrained 942 P2MP Inter-domain Traffic Engineering Label Switched 943 Paths", 944 draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07.txt, 945 work in progress, Januaury, 2011. 947 [H-PCE] King, D. and A. Farrel, "The Application of the Path 948 Computation Element Architecture to the Determination 949 of a Sequence of Domains in MPLS & GMPLS", July 950 2010. 952 15. Acknowledgements 954 The author would like to thank Adrian Farrel for his review and 955 Meral Shirazipour for his comments. 957 16. Author's Address 959 Daniel King 960 Old Dog Consulting 961 UK 962 Email: daniel@olddog.co.uk 964 Julien Meuric 965 France Telecom 966 2, avenue Pierre-Marzin 967 22307 Lannion Cedex 968 Email: julien.meuric@orange-ftgroup.com 970 Olivier Dugeon 971 France Telecom 972 2, avenue Pierre-Marzin 973 22307 Lannion Cedex 974 Email: olivier.dugeon@orange-ftgroup.com 976 Quintin Zhao 977 Huawei Technology 978 125 Nagog Technology Park 979 Acton, MA 01719 980 US 981 Email: qzhao@huawei.com 983 Oscar Gonzalez de Dios 984 Telefonica I+D 985 Emilio Vargas 6, Madrid 986 Spain 987 Email: ogondio@tid.es 988 Francisco Javier Jimenex Chico 989 Telefonica I+D 990 Emilio Vargas 6, Madrid 991 Spain 992 Email: fjjc@tid.es