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