idnits 2.17.1 draft-king-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 == Line 491 has weird spacing: '...gularly updat...' -- The document date (October 11, 2010) is 4945 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) == Outdated reference: A later version (-07) exists of draft-zhao-pce-pcep-inter-domain-p2mp-procedures-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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: April 11, 2011 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 October 11, 2010 13 Applicability of the Path Computation Element to Inter-Area and 14 Inter-AS MPLS and GMPLS Traffic Engineering 16 draft-king-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 April 11, 2011. 51 Copyright Notice 53 Copyright (c) 2010 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 This Internet-Draft will expire on January 12, 2011. 68 Table of Contents 70 1. Introduction.................................................3 71 1.1. Domains....................................................4 72 1.2. Path Computation...........................................5 73 1.3. Traffic Engineering Aggregation and Abstraction............5 74 1.4. Traffic Engineered Label Switched Paths....................5 75 1.5. Inter-area and Inter AS Connectivity Discovery.............5 76 2. Terminology..................................................6 77 3. Issues and Considerations....................................6 78 3.1 Multi-homed domains......................................6 79 3.2 Domain meshes............................................6 80 3.3 Destination location.....................................6 81 4. Applicability of the PCE to Inter-area Traffic Engineering...7 82 4.1. Inter-area Routing......................................7 83 4.1.1. Area Inclusion and Exclusion..........................7 84 4.1.2. Strict Explicit Path and Loose Path...................7 85 4.1.3. Inter-Area Diverse Path Computation...................7 86 4.2. Control and Recording of Area Crossing..................7 87 4.3. Inter-Area Policies ....................................7 88 4.4. Loop Avoidance .........................................7 89 5. Applicability of the PCE to Inter-AS Traffic Engineering.....7 90 5.1. Inter-AS Routing........................................8 91 5.1.1. AS Inclusion and Exclusion............................8 92 5.1.2. Strict Explicit Path and Loose Path...................8 93 5.1.3. AS Inclusion and Exclusion............................8 94 5.2. Inter-AS Bandwidth Guarantees...........................8 95 5.3. Inter-AS Recovery.......................................9 96 5.4. Inter-AS PCE Peering Policies...........................9 97 6. Multi-Domain PCE Deployment..................................9 98 6.1 Overview of Techniques...................................10 99 6.2 Traffic Engineering Database.............................10 100 6.3 Provisioning Techniques..................................11 101 6.4 Pre-Planning and Management-Based Solutions..............11 102 6.5 Per-Domain Computation...................................11 103 6.6 Cooperative PCEs.........................................11 104 6.7 Hierarchical PCEs ......................................12 105 7. Domain Topologies............................................12 106 7.1 Selecting Domain Paths...................................12 107 7.2 Multi-Homed Domains......................................12 108 7.3 Domain Meshes............................................12 109 7.4 Route Diversity..........................................12 110 7.5 Synchronized Path Computations...........................12 111 8. Domain Confidentiality.......................................13 112 8.1 Loose Hops...............................................13 113 8.2 Confidential Path Segments and Path Keys.................13 114 9. Point-to-Multipoint..........................................13 115 10. Optical Domains.............................................13 116 10.1. PCE applied to the ASON Architecture......................14 117 11.1. Policy Control............................................14 118 11.1.1 Inter-AS PCE Peering Policy Controls.....................14 119 12. IANA Considerations.........................................15 120 13. References..................................................15 121 13.1. Normative References......................................15 122 13.2. Informative References....................................15 123 14. Acknowledgements............................................16 124 15. Author's Address............................................17 126 1. Introduction 128 Computing paths across large multi-domain environments may 129 require special computational components and cooperation between 130 entities in different domains capable of complex path computation. 131 The Path Computation Element (PCE) [RFC4655] provides an architecture 132 and a set of functional components to address this problem space. 134 Computing optimal routes for LSPs that cross domains in MPLS-TE and 135 GMPLS networks presents a problem because no single point of path 136 computation is aware of all of the links and resources in each 137 domain. A solution may be achieved using the PCE architecture 138 [RFC4655]. 140 A domain can be defined as a separate administrative, geographic, or 141 switching environment within the network. A domain may be further 142 defined as a zone of routing or computational ability. Under these 143 definitions a domain might be categorized as an Antonymous System 144 (AS) or an Interior Gateway Protocol (IGP) area ( as per [RFC4726] 145 and [RFC4655]). 147 A PCE may be used to compute end-to-end paths across multi-domain 148 environments using a per-domain path computation technique [RFC5152]. 149 The so called backward recursive path computation (BRPC) mechanism 150 [RFC5441] defines a PCE-based path computation procedure to compute 151 inter-domain constrained (G)MPLS TE LSPs. However, both per-domain 152 and BRPC techniques assume that the sequence of domains to be crossed 153 from source to destination is known, either fixed by the network 154 operator or obtained by other means. In more advanced deployments 155 (including multi-area and multi-AS environments) the sequence of 156 domains may not be known in advance and the choice of domains in the 157 end-to-end domain sequence might be critical to the determination of 158 an optimal end-to-end path 160 In this case the use of the Hierarchical PCE [H-PCE] architecture and 161 mechanisms may be used to discovery the intra-area path and select 162 the optimal end-to-end domain sequence. 164 This document examines the applicability and describes the processes 165 and procedures available when using the PCE architecture, protocols 166 and protocol extensions for computing inter-area and inter-AS MPLS 167 Traffic Engineered paths. 169 1.1 Domains 171 For the purposes of this document, a domain is considered to be a 172 collection of network elements within an area or AS that has a common 173 sphere of address management or path computational responsibility. 174 Wholly or partially overlapping domains are not within the scope of 175 this document. 177 In the context of GMPLS, a particularly important example of a domain 178 is the Automatically Switched Optical Network (ASON) subnetwork 179 [G-8080]. In this case, computation of an end-to-end path requires 180 the selection of nodes and links within a parent domain where some 181 nodes may, in fact, be subnetworks. Furthermore, a domain might be an 182 ASON routing area [G-7715]. A PCE may perform the path computation 183 function of an ASON routing controller as described in [G-7715-2]. 185 It is assumed that the PCE architecture should be applied to small 186 inter-domain topologies and not to solve route computation issues 187 across large groups of domains, I.E. the entire Internet. 189 1.2 Path Computation 191 For the purpose of this document it is assumed that the 192 path computation is the sole responsibility of the PCE as per the 193 architecture defined in [RFC4655]. When a path is required the Path 194 Computation Client (PCC) will send a request to the PCE. The PCE will 195 apply the required constraints and compute a path and return a 196 response to the PCC. In the context of this document it maybe 197 necessary for the PCE to co-operate with other PCEs in adjacent 198 domains (as per BRPC [RFC5441]) or cooperate with the Parent PCE 199 (as per [H-PCE]). 201 It is entirely feasible that an operator could compute a path across 202 multiple domains without the use of a PCE if the relevant domain 203 information is available to the network planner or network management 204 platform. The definition of what relevant information is required to 205 perform this network planning operation and how that information is 206 discovered and applied is outside the scope of this document. 208 1.3 Traffic Engineering Aggregation and Abstraction 210 Networks are often constructed from multiple areas or ASs that are 211 interconnected via multiple interconnect points. To maintain 212 network confidentiality and scalability TE properties of each area 213 and AS are not generally advertized outside each specific area or AS. 215 TE aggregation or abstraction provide mechanism to hide information 216 but may cause failed path setups or the selection of suboptimal 217 end-to-end paths [RFC4726]. The aggregation process may also have 218 significant scaling issues for networks with many possible routes 219 and multiple TE metrics. Flooding TE information breaks 220 confidentiality and does not scale in the routing protocol. 222 The PCE architecture and associated mechanisms provide a solution 223 to avoid the use of TE aggregation and abstraction. 225 1.4 Traffic Engineered Label Switched Paths 227 This document highlights the PCE techniques and mechanisms that exist 228 for establishing TE packet and optical LSPs across multiple areas 229 (inter-area TE LSP) and ASs (inter-AS TE LSP). In this context and 230 within the remainder of this document, we consider all LSPs to be 231 constraint-based and traffic engineered. 233 Three signaling options are defined for setting up an inter-area or 234 inter-AS LSP [RFC4726]: 236 - Contiguous LSP 237 - Stitched LSP 238 - Nested LSP 240 All three signaling methods are applicable to the architectures and 241 procedures discussed in this document. 243 1.5 Inter-area and Inter AS Connectivity Discovery 244 When using a PCE-based approach for inter-area and inter-AS path 245 computation, a PCE in one area or AS may need to learn information 246 related to inter-AS capable PCEs located in other ASs. The PCE 247 discovery mechanism defined in [RFC5088] and [RFC5089] allow 248 the discovery of PCEs and disclosure of information related to 249 inter-area and inter-AS capable PCEs across area and AS boundaries. 251 2. Terminology 253 Terminology used in this document. 255 ABR: IGP Area Border Router, a router that is attached to more than 256 one IGP area. 258 ASBR: Autonomous System Border Router, a router used to connect 259 together ASs of a different or the same Service Provider via one or 260 more inter-AS links. 262 Inter-area TE LSP: A TE LSP whose path transits through two or more 263 IGP areas. 265 Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or 266 more ASs or sub-ASs (BGP confederations 268 LSP: Traffic Engineered Label Switched Path. 270 LSR: Label Switching Router. 272 TED: Traffic Engineering Database, which contains the topology and 273 resource information of the domain. The TED may be fed by Interior 274 Gateway Protocol (IGP) extensions or potentially by other means. 276 This document also uses the terminology defined in [RFC4655] and 277 [RFC5440]. 279 3. Issues and Considerations 281 3.1 Multi-homed domains 283 3.2 Domain meshes 285 3.3 Destination location 287 4. Applicability of the PCE to Inter-area Traffic Engineering 288 As networks increase in size and complexity it may be required to 289 introduce scaling methods to reduce the amount information flooded 290 within the network and make the network more manageable. An IGP 291 hierarchy is designed to improve IGP scalability by dividing the 292 IGP domain into areas and limiting the flooding scope of topology 293 information to within area boundaries. This restricts visibility of 294 the area to routers in a single area. If a router needs to compute a 295 route to destination located in another area a method is required to 296 compute a path across area boundaries. 298 In order to support multiple vendors in a network, in cases where 299 data and/or control plane technologies cannot interoperate, it is 300 useful to divide the network in vendor domains. Each vendor domain is 301 an IGP area, and the flooding scope of the topology (as well as any 302 other relevant information) is limited to the area boundaries. 304 Per-domain path computation [RFC5152] exists to provide a method of 305 inter-area path computation. The per-domain solution is based on 306 loose hop routing with an Explicit Route Object (ERO) expansion on 307 each Area Border Router (ABR). This allows an LSP to be established 308 using a constrained path, however at least two issues exist: 310 - This method does not guarantee an optimal constrained path 312 - The method may require several crankback signaling messages 313 increasing signaling traffic and delaying the LSP setup 315 The PCE-based architecture [RFC4655] is designed to solve inter-area 316 path computation problems. The issue of limited topology visibility 317 is resolved by introducing path computation entities that are able to 318 cooperate in order to establish LSPs with source and destinations 319 located in different areas. 321 4.1. Inter-area Routing 323 4.1.1. Area Inclusion and Exclusion 325 4.1.2. Strict Explicit Path and Loose Path 327 4.1.3. Inter-Area Diverse Path Computation 329 4.2. Control and Recording of Area Crossing 331 4.3. Inter-Area Policies 333 4.4. Loop Avoidance 335 5. Applicability of the PCE to Inter-AS Traffic Engineering 336 As discussed in section 4 (Applicability of the PCE to Inter-area 337 Traffic Engineering) it is necessary to divide the network into 338 smaller administrative domains, or ASs. If an LSR within an AS needs 339 to compute a path across an AS boundary it must also use an inter-AS 340 computation technique. [RFC5152] defines mechanisms for the 341 computation of inter-domain TE LSPs using network elements along the 342 signaling paths to compute per-domain constrained path segments. 344 The PCE was designed to be capable of computing MPLS and GMPLS paths 345 across AS boundaries. This section outlines the features of a 346 PCE-enabled solution for computing inter-AS paths. 348 5.1 Inter-AS Routing 350 5.1.1. AS Inclusion and Exclusion 352 5.1.2. Strict Explicit Path and Loose Path 354 During path computation, the PCE architecture and BRPC algorithm 355 allow operators to specify if the resultant LSP must follow a strict 356 or a loose path. By explicitly specify the path, the operator 357 request a strict explicit path which must pass through one or many 358 LSR. If this behaviour is well define and appropriate for inter-area, 359 it implies some topology discovery for inter-AS. So, this feature 360 when the operator owns several ASs (and so, knows the topology of 361 its ASs) or restricts to the well-known ASBR to avoid topology 362 discovery between operators. The loose path, even if it does not 363 allow granular specification of the path, protects topology 364 disclosure as it not obligatory for the operator to disclose 365 information about its networks. 367 5.1.3. AS Inclusion and Exclusion 369 Like explicit and loose path, [RFC5441] allows to specify inclusion 370 or exclusion of respectively an AS or and ASBR. Using this method, 371 an operator might decide if an AS must be include or exclude from 372 the inter-AS path computation. Exclusion and/or inclusion could also 373 be specified at any step in the LSP path computation process by a PCE 374 (within the BRPC algorithm) but the best practice would be to specify 375 them at the edge. In opposition to the strict and loose path, AS 376 inclusion or exclusion doesn't impose topology disclosure as ASs are 377 public entity as well as their interconnection. 379 5.2 Inter-AS Bandwidth Guarantees 381 Many operators with multi-AS domains will have deployed MPLS-TE 382 Diffserv either across their entire network or at the domain 383 edges on CE-PE links. In situations where strict QOS bounds are 384 required, admission control inside the network may also be required. 386 When the propagation delay can be bounded, the performance targets, 387 such as maximum one-way transit delay may be guaranteed by providing 388 bandwidth guarantees along the Diffserv-enabled path. 390 One typical example of this requirement is to provide bandwidth 391 guarantees over an end-to-end path for VoIP traffic classified as EF 392 (Expedited Forwarding) class in a Diffserv-enabled 393 network. In the case where the EF path is extended across multiple 394 ASs, inter-AS bandwidth guarantee would be required. 396 Another case for inter-AS bandwidth guarantee is the requirement for 397 guaranteeing a certain amount of transit bandwidth across one or 398 multiple ASs. 400 5.3 Inter-AS Recovery 402 During path computation, a PCCReq may contains backup LSP 403 requirements in order to setup in the same time the primary and 404 backup LSPs. It is also possible to request a backup LSP for a group 405 of primary LSPs. [RFC4090] adds fast re-route protection to LSP. So, 406 the PCE could be used to trigger computation of backup tunnels in 407 order to protect Inter-AS connectivity. Inter-AS recovery 408 requirements needs not only PCE protection and redundancy but also 409 LSP tunnels protection through FRR mechanisms. Inter-AS PCE 410 computation must support the FRR mechanisms and the patch computation 411 for backup tunnels for protection and fast recovery. 413 5.4 Inter-AS PCE Peering Policies 415 Like BGP peering policies, inter-AS PCE peering policies is a 416 requirement for operator. In inter-AS BRPC process, PCE must 417 cooperate in order to compute the end-to-end LSP. So, the AS path 418 must not only follow technical constraints e.g. bandwidth 419 availability, but also policies define by the operator. 421 Typically PCE interconnections at an AS level must follow contract 422 obligations, also known as peering agreements. The PCE peering 423 policies are the result of the contract negotiation and govern 424 the relation between the different PCE. 426 6. Multi-domain PCE Deployment Options 428 The PCE provides the architecture and mechanisms to compute 429 inter-area and inter-AS LSPs. The objective of this document is not 430 to reprint the techniques and mechanisms available, but to highlight 431 their existence and reference the relevant documents that introduce 432 and describe the techniques and mechanisms necessary for computing 433 inter-area and inter-AS LSP based services. 435 An area or AS may contain multiple PCEs: 437 - The path computation load may be balanced among a set of PCEs to 438 improve scalability. 440 - For the purpose of redundancy, primary and backup PCEs may be used. 442 - PCEs may have distinct path computation capabilities (P2P or P2MP). 444 Discovery of PCEs and capabilities per area or AS is defined in 445 [RFC5088] and [RFC5089]. 447 Each PCE per domain can be deployed in a centralized or distributed 448 architecture, the latter model having local visibility and 449 collaborating in a distributed fashion to compute a path across the 450 domain. Each PCE may collect topology and TE information from the 451 same sources as the LSR, such as the IGP TED. 453 When the PCC sends a path computation request to the PCE, the PCE 454 will compute the path across a domain based on the required 455 constraints. The PCE will generate the full set of strict hops from 456 source to destination. This information, encoded as an ERO, is then 457 sent back to the PCC that requested the path. In the event that a 458 path request from a PCC contains source and destination nodes that 459 are located in different domains the PCE is required to co-operate 460 between multiple PCEs, each responsible for its own domain. 462 Techniques for inter-domain path computation are described in 463 [RFC5152] and [RFC5441], both techniques assume that the sequence of 464 domains to be crossed from source to destination is well known. In 465 the event that the sequence of domains is not well known, [H-PCE] 466 might be used. The sequence could also be retrieve locally from 467 information previously stored in the PCE database (preferably in 468 the TED) by OSS management or other protocols. 470 6.1 Overview of Techniques 472 6.2 Traffic Engineering Database 474 TEDs are automatically populated by the IGP-TE like IS-IS-TE or 475 OSPF-TE. However, no information related to AS path are provided 476 by such IGP-TE. It could be helpful for BRPC algorithm as AS path 477 helper, to populate a TED with suitable information regarding 478 inter-AS connectivity. Such information could be obtain from 479 various sources, such as BGP protocol, peering policies, OSS of the 480 operator or from neighbor PCE. In any case, no topology disclosure 481 must be impose in order to provide such information. 483 In particular, for both inter-area and inter-AS, the TED must be 484 populated with all boundary node information suitable to 485 establish PCEP protocol with the next PCE in the path. 487 6.3 Provisioning Techniques 489 As PCE algorithms rely on information contained in the TED, it 490 is possible to populate TED information by means of provisioning. In 491 this case, the operator must regularly update and store all suitable 492 information in the TED in order for the PCE to correctly compute LSP. 493 Such information range from policies (e.g. avoid this LSR, or use 494 this ASBR for a specific IP prefix) up to topology information (e.g. 495 AS X is reachable trough a 100 Mbit/s link on this ASBR and 30 Mbit/s 496 are reserved for EF traffic). Operators may choose the type and 497 amount of information they can use to manage their traffic engineered 498 network. 500 However, some LSPs might be provisioned to link ASs or areas. In this 501 case, these LSP must be announced by the IGP-TE in order to 502 automatically fulfill the TED. 504 6.4 Pre-Planning and Management-Based Solutions 506 Offline path computation is performed ahead of time, before the LSP 507 setup is requested. That means that it is requested by, or performed 508 as part of, a management application. This model can be seen in 509 Section 5.5 of [RFC4655]. 511 The offline model is particularly appropriate to long-lived LSPs 512 (such as those present in a transport network) or for planned 513 responses to network failures. In these scenarios, more planning is 514 normally a feature of LSP provisioning. 516 This model may also be used where the network operator wishes to 517 retain full manual control of the placement of LSPs, using the PCE 518 only as a computation tool to assist the operator, not as part of an 519 automated network. 521 The management based solutions could also be used in conjunction 522 with the BRPC algorithm. Operator just computes the AS-Path as 523 parameter for the inter-AS path computation request and let each 524 PCE along the AS path compute the LSP part on its own domain. 526 6.5 Per-Domain Computation 528 [RFC5152] define the mechanism to compute per-domain path and must be 529 used in that condition. Otherwise, BRPC [RFC5441] will be used. 531 6.6 Cooperative PCEs 533 When PCE cooperate to compute an inter-area or inter-AS LSP, both 534 [RFC5152] and [RFC5441] could be used. 536 6.7 Hierarchical PCEs 538 The [H-PCE] draft defines how a hierarchy of PCEs may be used. An 539 operator must define a parent PCE and each child PCE. A parent PCE 540 can be announced in the other areas or ASs in order for the parent 541 PCE to contact remote child PCEs. Reciprocally, childs PCEs are 542 announced in remote areas or ASs in order to be contacted by a 543 remote parent PCE. Parent and each child PCE could also be 544 provisioned in the TED if they are not announced. 546 7. Domain Topologies 548 7.1 Selecting Domain Paths 550 7.2 Multi-Homed Domains 552 7.3 Domain Meshes 554 Very frequently network domains are composed by dozens or hundreds of 555 network elements. These network elements are usually interconnected 556 between them in a partial-mesh fashion, to provide survivability 557 against dual failures, and to benefit from the traffic engineering 558 capabilities from MPLS and GMPLS protocols. A typical node degree 559 ranges from 3 to 10 (4-5 is quite common), being the node degree the 560 number of neighbors per node. 562 Networks are sometimes divided into domains. Some reasons for it 563 range from manageability to separation into vendor-specific domains. 564 The size of the domain will be usually limited by control plane, but 565 it can also be stated by arbitrary design constraints. 567 7.4 Route Diversity 569 Whenever an specific connectivity service is required to have 1+1 570 protection feature, two completely disjoint paths must be 571 established on an end to end fashion. In a multi-domain environment 572 without, this can be accomplished ither by selecting domain 573 diversity, or by ensuring divere connection within a domain. In order 574 to compute the route diversity, it could be helpful to have SRLG 575 information in the domains. 577 7.5 Synchronized Path Computations 579 In some scenarios, it would be beneficial for the operator to rely on 580 the capability of the PCE to perform synchronized path computation. 582 A non comprehensive list of such cases could be the following: 584 o Route diversity: computation of two disjoint paths from a source to 585 a destination (as drafted in the previous section). 587 o Synchronous restoration: joint computation of a set of alternative 588 paths for a set of affected LSPs as a consequence of a failure 589 event. Note that in this case, the requests will potentially 590 involve different source-destination pairs. In this scenario, the 591 different path computation requests may arrive at different time 592 stamps. 594 o Batch provisioning: It is common that the operator sends a set of 595 LSPs requests together, e.g in a daily of weekly basis, mainly in 596 case of long lived LSPs. In order to optimize the resource usage, 597 a synchronized path computation is needed. 599 o Network optimization: After some time of operation, the 600 distribution of the established LSP paths results in a non optimal 601 use of resources. Also, inter-domain policies/agreements may have 602 been changed. In such cases, a full (or partial) network planning 603 action regarding the interdomain connections will be triggered. 604 This will involve the request of potentially a big amount of 605 connections. 607 8. Domain Confidentiality 609 8.1 Loose Hops 611 8.2 Confidential Path Segments and Path Keys 613 9. Point-to-Multipoint 615 For the Point-to-Multipoint application scenarios for MPLS-TE LSP, 616 the complexity of domain sequences, domain policies, choice and 617 number of domain interconnects is magnified comparing to 618 P2P path computations. Also as the size of the network grows, 619 the number of leaves and branches increase and it in turn puts the 620 scalability of the path computation and optimization into a bigger 621 issue. A solution for the point-to-multipoint path computations may 622 be achieved using the PCEP protocol extension for P2MP 623 [RFC6006] and using the PCEP P2MP procedures defined in 624 [PCEP-P2MP-INTER-DOMAIN]. 626 10. Optical Domains 628 The International Telecommunications Union (ITU) defines the ASON 629 architecture in [G-8080]. [G-7715] defines the routing architecture 630 for ASON and introduces a hierarchical architecture. In this 631 architecture, the Routing Areas (RAs) have a hierarchical 632 relationship between different routing levels, which means a parent 633 (or higher level) RA can contain multiple child RAs. The 634 interconnectivity of the lower RAs is visible to the higher level RA. 636 10.1. PCE applied to the ASON Architecture 638 In the ASON framework, a path computation request is termed a Route 639 Query. This query is executed before signaling is used to establish 640 an LSP termed a Switched Connection (SC) or a Soft Permanent 641 Connection (SPC). [G-7715-2] defines the requirements and 642 architecture for the functions performed by Routing Controllers (RC) 643 during the operation of remote route queries - an RC is synonymous 644 with a PCE. 646 In the ASON routing environment, a RC responsible for an RA may 647 communicate with its neighbor RC to request the computation of an 648 end-to-end path across several RAs. The path computation components 649 and sequences are defined as follows: 651 o Remote route query. An operation where a routing controller 652 communicates with another routing controller, which does not have 653 the same set of layer resources, in order to compute a routing 654 path in a collaborative manner. 656 o Route query requester. The connection controller or RC that sends a 657 route query message to a routing controller requesting for one or 658 more routing path that satisfies a set of routing constraints. 660 o Route query responder. An RC that performs path computation upon 661 reception of a route query message from a routing controller or 662 connection controller, sending a response back at the end of 663 computation. 665 When computing an end-to-end connection, the route may be computed by 666 a single RC or multiple RCs in a collaborative manner and the two 667 scenarios can be considered a centralized remote route query model 668 and distributed remote route query model. RCs in an ASON environment 669 can also use the hierarchical PCE [H-PCE] model to fully match the 670 ASON hierarchical routing model. 672 11. Security 674 11.1. Policy Control 676 11.1.1 Inter-AS PCE Peering Policy Controls 677 Each PCE cooperating with another PCE in a neighboring AS will need 678 to request or enforce policies applicable to the sender of the 679 request. 681 Parameters that are subject to policy include bandwidth, 682 setup/holding priority, Fast Reroute request, Differentiated Services 683 Traffic Engineering (DS-TE) Class Type (CT), and others as specified 684 in Section 5.2.2.1 of [RFC4216]. 686 11.2. Confidentiality 688 11.3. Denial of Service Attacks 690 12. IANA Considerations 692 This document makes no requests for IANA action. 694 13. References 696 13.1. Normative References 698 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 699 Element (PCE)-Based Architecture", RFC 4655, August 2006. 701 [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, 702 A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, 703 "Path Computation Element (PCE) Communication Protocol 704 (PCEP)", RFC 5440, March 2009. 706 13.2. Informative References 708 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 709 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 710 2005. 712 [RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter- 713 Autonomous System (AS) Traffic Engineering (TE) 714 Requirements", RFC 4216, November 2005. 716 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework 717 for Inter-Domain Multiprotocol Label Switching Traffic 718 Engineering", RFC 4726, November 2006. 720 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 721 "OSPF Protocol Extensions for Path Computation Element 722 (PCE) Discovery", RFC 5088, January 2008. 724 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 725 Zhang, "IS-IS Protocol Extensions for Path Computation 726 Element (PCE) Discovery", RFC 5089, January 2008. 728 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 729 Path Computation Method for Establishing Inter-Domain 730 Traffic Engineering (TE) Label Switched Paths (LSPs)", 731 RFC 5152, February 2008. 733 [RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based 734 Computation (BRPC) procedure to compute shortest inter- 735 domain Traffic Engineering Label Switched Paths", 736 RFC5441, April 2009. 738 [G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for 739 the automatically switched optical network (ASON). 741 [G-7715] ITU-T Recommendation G.7715 (2002), Architecture 742 and Requirements for the Automatically Switched 743 Optical Network (ASON). 745 [G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing 746 architecture and requirements for remote route query. 748 [H-PCE] King, D. and A. Farrel, "The Application of the Path 749 Computation Element Architecture to the Determination 750 of a Sequence of Domains in MPLS & GMPLS", July 751 2010. 753 [RFC6006] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z., 754 Zhao, Q., King, D., "Extensions to the Path Computation 755 Element Communication Protocol (PCEP) for 756 Point-to-Multipoint Traffic Engineering Label Switched 757 Paths", RFC6006, September 2010. 759 [PCEP-P2MP-INTER-DOMAIN] Ali Z., Zhao, Q., King, D., "PCE-based 760 Computation Procedure To Compute Shortest Constrained P2MP 761 Inter-domain Traffic Engineering Label Switched Paths", 762 draft-zhao-pce-pcep-inter-domain-p2mp-procedures-05.txt, 763 work in progress, July, 2010. 765 11. Acknowledgements 767 The author would like to thank Adrian Farrel for his review and 768 Meral Shirazipour for his comments. 770 12. Author's Address 772 Daniel King 773 Old Dog Consulting 774 UK 775 Email: daniel@olddog.co.uk 777 Julien Meuric 778 France Telecom 779 2, avenue Pierre-Marzin 780 22307 Lannion Cedex 781 Email: julien.meuric@orange-ftgroup.com 783 Olivier Dugeon 784 France Telecom 785 2, avenue Pierre-Marzin 786 22307 Lannion Cedex 787 Email: olivier.dugeon@orange-ftgroup.com 789 Quintin Zhao 790 Huawei Technology 791 125 Nagog Technology Park 792 Acton, MA 01719 793 US 794 Email: qzhao@huawei.com 796 Oscar Gonzalez de Dios 797 Telefonica I+D 798 Emilio Vargas 6, Madrid 799 Spain 800 Email: ogondio@tid.es 802 Francisco Javier Jimenex Chico 803 Telefonica I+D 804 Emilio Vargas 6, Madrid 805 Spain 806 Email: fjjc@tid.es