idnits 2.17.1 draft-ietf-pce-inter-area-as-applicability-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 3, 2014) is 3587 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: December 3, 2014 O. Dugeon 5 France Telecom 6 Q. Zhao 7 Huawei Technologies 8 Oscar Gonzalez de Dios 9 Telefonica I+D 10 June 3, 2014 12 Applicability of the Path Computation Element to Inter-Area and 13 Inter-AS MPLS and GMPLS Traffic Engineering 15 draft-ietf-pce-inter-area-as-applicability-04 17 Abstract 19 The Path Computation Element (PCE) may be used for computing services 20 that traverse multi-area and multi-AS Multiprotocol Label Switching 21 (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. 23 This document examines the applicability of the PCE architecture, 24 protocols, and protocol extensions for computing multi-area and 25 multi-AS paths in MPLS and GMPLS networks. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on December, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction.................................................3 68 1.1. Domains.................................................4 69 1.2. Path Computation........................................4 70 1.2.1 PCE-based Path Computation Procedure.................5 71 1.3. Traffic Engineering Aggregation and Abstraction.........5 72 1.4. Traffic Engineered Label Switched Paths.................6 73 1.5. Inter-area and Inter-AS Connectivity Discovery..........6 74 1.6. Objective Functions.....................................6 75 2. Terminology..................................................7 76 3. Issues and Considerations....................................7 77 3.1 Multi-homing.............................................7 78 3.2 Domain Confidentiality ..................................8 79 3.3 Destination Location.....................................8 80 4. Domain Topologies............................................8 81 4.1 Selecting Domain Paths...................................9 82 4.2 Multi-Homed Domains......................................9 83 4.3 Domain Meshes............................................9 84 4.4 Domain Diversity.........................................9 85 4.5 Synchronized Path Computations...........................9 86 4.6 Domain Inclusion or Exclusion............................10 87 5. Applicability of the PCE to Inter-area Traffic Engineering...10 88 5.1. Inter-area Routing......................................11 89 5.1.1. Area Inclusion and Exclusion..........................11 90 5.1.2. Strict Explicit Path and Loose Path...................11 91 5.1.3. Inter-Area Diverse Path Computation...................12 92 5.2. Control and Recording of Area Crossing..................12 93 6. Applicability of the PCE to Inter-AS Traffic Engineering.....12 94 6.1. Inter-AS Routing........................................13 95 6.1.1. AS Inclusion and Exclusion............................13 96 6.1.2. Strict Explicit Path and Loose Path...................13 97 6.1.3. AS Inclusion and Exclusion............................13 98 6.2. Inter-AS Bandwidth Guarantees...........................13 99 6.3. Inter-AS Recovery.......................................14 100 6.4. Inter-AS PCE Peering Policies...........................14 101 7. Multi-Domain PCE Deployment..................................14 102 7.1 Traffic Engineering Database.............................14 103 7.2 Provisioning Techniques..................................14 104 7.3 Pre-Planning and Management-Based Solutions..............16 105 7.4 Per-Domain Computation...................................16 106 7.5 Cooperative PCEs.........................................16 107 7.6 Hierarchical PCEs ......................................16 108 8. Domain Confidentiality.......................................17 109 8.1 Loose Hops...............................................17 110 8.2 Confidential Path Segments and Path Keys.................17 111 9. Point-to-Multipoint..........................................17 112 10. Optical Domains.............................................18 113 10.1. PCE applied to the ASON Architecture....................18 114 11. Policy......................................................19 115 12. TED Topology and Synchronization............................19 116 12.1. Applicability of BGP-LS to PCE..........................20 117 13. Manageability Considerations................................20 118 13.1 Control of Function and Policy...........................20 119 13.2 Information and Data Models..............................21 120 13.3 Liveness Detection and Monitoring........................21 121 13.4 Verifying Correct Operation..............................21 122 13.5 Impact on Network Operation..............................21 123 14. Security Considerations.....................................21 124 15. IANA Considerations.........................................22 125 16. Acknowledgements............................................22 126 17. References..................................................22 127 17.1. Normative References....................................22 128 17.2. Informative References..................................22 129 18. Author's Addresses..........................................25 131 1. Introduction 133 Computing paths across large multi-domain environments may 134 require special computational components and cooperation between 135 entities in different domains capable of complex path computation. 136 The Path Computation Element (PCE) [RFC4655] provides an architecture 137 and a set of functional components to address this problem space. 139 A PCE may be used to compute end-to-end paths across multi-domain 140 environments using a per-domain path computation technique [RFC5152]. 141 The so called backward recursive path computation (BRPC) mechanism 142 [RFC5441] defines a PCE-based path computation procedure to compute 143 inter-domain constrained Multiprotocol Label Switching (MPLS) and 144 Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. However, 145 both per-domain and BRPC techniques assume that the sequence of 146 domains to be crossed from source to destination is known, either 147 fixed by the network operator or obtained by other means. 149 In more advanced deployments (including multi-area and multi-AS 150 environments) the sequence of domains may not be known in advance 151 and the choice of domains in the end-to-end domain sequence might 152 be critical to the determination of an optimal end-to-end path. In 153 this case the use of the Hierarchical PCE [RFC6805] architecture and 154 mechanisms may be used to discovery the intra-area path and select 155 the optimal end-to-end domain sequence. 157 This document describes the processes and procedures available when 158 using the PCE architecture, protocols and protocol extensions for 159 computing inter-area and inter-AS MPLS and GMPLS Traffic TE paths. 161 1.1 Domains 163 A domain can be defined as a separate administrative, geographic, or 164 switching environment within the network. A domain may be further 165 defined as a zone of routing or computational ability. Under these 166 definitions a domain might be categorized as an Antonymous System 167 (AS) or an Interior Gateway Protocol (IGP) area ( as per [RFC4726] 168 and [RFC4655]). 170 For the purposes of this document, a domain is considered to be a 171 collection of network elements within an area or AS that has a common 172 sphere of address management or path computational responsibility. 173 Wholly or partially overlapping domains are not within the scope of 174 this document. 176 In the context of GMPLS, a particularly important example of a domain 177 is the Automatically Switched Optical Network (ASON) subnetwork 178 [G-8080]. In this case, computation of an end-to-end path requires 179 the selection of nodes and links within a parent domain where some 180 nodes may, in fact, be subnetworks. Furthermore, a domain might be an 181 ASON routing area [G-7715]. A PCE may perform the path computation 182 function of an ASON routing controller as described in [G-7715-2]. 184 It is assumed that the PCE architecture should only be applied to 185 small inter-domain topologies and not to solve route computation 186 issues across large groups of domains, i.e. the entire Internet. 188 1.2 Path Computation 190 For the purpose of this document it is assumed that the 191 path computation is the sole responsibility of the PCE as per the 192 architecture defined in [RFC4655]. When a path is required the Path 193 Computation Client (PCC) will send a request to the PCE. The PCE will 194 apply the required constraints and compute a path and return a 195 response to the PCC. In the context of this document it maybe 196 necessary for the PCE to co-operate with other PCEs in adjacent 197 domains (as per BRPC [RFC5441]) or cooperate with a Parent PCE 198 (as per [RFC6805]). 200 It is entirely feasible that an operator could compute a path across 201 multiple domains without the use of a PCE if the relevant domain 202 information is available to the network planner or network management 203 platform. The definition of what relevant information is required to 204 perform this network planning operation and how that information is 205 discovered and applied is outside the scope of this document. 207 1.2.1 PCE-based Path Computation Procedure 209 As highlighted, the PCE is an entity capable of computing an 210 inter-domain TE path upon receiving a request from a PCC. There could 211 be a single PCE per domain, or single PCE responsible for all 212 domains. A PCE may or may not reside on the same node as the 213 requesting PCC. A path may be computed by either a single PCE node 214 or a set of distributed PCE nodes that collaborate during path 215 computation. 217 [RFC4655] defines that a PCC should send a path computation request 218 to a particular PCE, using [RFC5440] (PCC-to-PCE communication). 219 This negates the need to broadcast a request to all the PCEs. Each 220 PCC can maintain information about the computation capabilities 221 of the PCEs it is aware of. The PCC-PCE capability awareness can 222 configured using static configuration or by listening to the 223 periodic advertisements generated by PCEs. 225 Once a path computation request is received, the PCC will send a 226 request to the PCE. A PCE may compute the end-to-end path 227 if it is aware of the topology and TE information required to 228 compute the entire path. If the PCE is unable to compute the 229 entire path, the PCE architecture provides co-operative PCE 230 mechanisms for the resolution of path computation requests when an 231 individual PCE does not have sufficient TE visibility. 233 A PCE may cooperate with other PCEs to determine intermediate loose 234 hops. End-to-end path segments may be kept confidential through the 235 application of path keys, to protect partial or full path 236 information. A path key that is a token that replaces a path segment 237 in an explicit route. The path key mechanism is described in 238 [RFC5520] 240 1.3 Traffic Engineering Aggregation and Abstraction 242 Networks are often constructed from multiple areas or ASes that are 243 interconnected via multiple interconnect points. To maintain 244 network confidentiality and scalability TE properties of each area 245 and AS are not generally advertized outside each specific area or AS. 247 TE aggregation or abstraction provide mechanism to hide information 248 but may cause failed path setups or the selection of suboptimal 249 end-to-end paths [RFC4726]. The aggregation process may also have 250 significant scaling issues for networks with many possible routes 251 and multiple TE metrics. Flooding TE information breaks 252 confidentiality and does not scale in the routing protocol. 254 The PCE architecture and associated mechanisms provide a solution 255 to avoid the use of TE aggregation and abstraction. 257 1.4 Traffic Engineered Label Switched Paths 259 This document highlights the PCE techniques and mechanisms that exist 260 for establishing TE packet and optical LSPs across multiple areas 261 (inter-area TE LSP) and ASes (inter-AS TE LSP). In this context and 262 within the remainder of this document, we consider all LSPs to be 263 constraint-based and traffic engineered. 265 Three signaling options are defined for setting up an inter-area or 266 inter-AS LSP [RFC4726]: 268 - Contiguous LSP 269 - Stitched LSP 270 - Nested LSP 272 All three signaling methods are applicable to the architectures and 273 procedures discussed in this document. 275 1.5 Inter-area and Inter-AS Connectivity Discovery 277 When using a PCE-based approach for inter-area and inter-AS path 278 computation, a PCE in one area or AS may need to learn information 279 related to inter-AS capable PCEs located in other ASes. The PCE 280 discovery mechanism defined in [RFC5088] and [RFC5089] allow 281 the discovery of PCEs and disclosure of information related to 282 inter-area and inter-AS capable PCEs across area and AS boundaries. 284 1.6 Objective Functions 286 An Objective Function (OF) [RFC5541], or set of OFs, specify the 287 intentions of the path computation and so define the "optimality" 288 in the context of that computation request. 290 An OF specifies the desired outcome of a computation. An OF does not 291 describe or specify the algorithm to use, and an implementation may 292 apply any algorithm or set of algorithms to achieve the result 293 indicated by the OF. [RFC5541] provides the following OFs when 294 computing inter-domain paths: 296 o Minimum Cost Path (MCP); 297 o Minimum Load Path (MLP); 298 o Maximum residual Bandwidth Path (MBP); 299 o Minimize aggregate Bandwidth Consumption (MBC); 300 o Minimize the Load of the most loaded Link (MLL); 301 o Minimize the Cumulative Cost of a set of paths (MCC). 303 OFs can be included in the PCE computation requests to satisfy the 304 policies encoded or configured at the PCC, and a PCE may be 305 subject to policy in determining whether it meets the OFs included 306 in the computation request, or applies its own OFs. 308 During inter-domain path computation, the selection of a domain 309 sequence, the computation of each (per-domain) path fragment, and 310 the determination of the end-to-end path may each be subject to 311 different OFs and policy. 313 2. Terminology 315 This document also uses the terminology defined in [RFC4655] and 316 [RFC5440]. Additional terminology is defined below: 318 ABR: IGP Area Border Router, a router that is attached to more than 319 one IGP area. 321 ASBR: Autonomous System Border Router, a router used to connect 322 together ASes of a different or the same Service Provider via one or 323 more inter-AS links. 325 CSPF: Constrained Shortest Path First. 327 Inter-area TE LSP: A TE LSP whose path transits through two or more 328 IGP areas. 330 Inter-AS MPLS TE LSP: A TE LSP whose path transits through two or 331 more ASes or sub-ASes (BGP confederations 333 SRLG: Shared Risk Link Group. 335 TED: Traffic Engineering Database, which contains the topology and 336 resource information of the domain. The TED may be fed by Interior 337 Gateway Protocol (IGP) extensions or potentially by other means. 339 3. Issues and Considerations 341 3.1 Multi-homing 343 Networks constructed from multi-areas or multi-AS environments 344 may have multiple interconnect points (multi-homing). End-to-end path 345 computations may need to use different interconnect points to avoid 346 single point failures disrupting primary and backup services. 348 Domain and path diversity may also be required when computing 349 end-to-end paths. Domain diversity should facilitate the selection 350 of paths that share ingress and egress domains, but do not share 351 transit domains. Therefore, there must be a method allowing the 352 inclusion or exclusion of specific domains when computing end-to-end 353 paths. 355 3.2 Domain Confidentiality 357 Where the end-to-end path crosses multiple domains, it may be 358 possible that each domain (AS or area) are administered by separate 359 Service Providers, it would break confidentiality rules for a PCE 360 to supply a path segment to a PCE in another domain, thus disclosing 361 AS-internal topology information. 363 If confidentiality is required between domains (ASes and areas) 364 belonging to different Service Providers. Then cooperating PCEs 365 cannot exchange path segments or else the receiving PCE PCC will be 366 able to see the individual hops through another domain. 368 3.3 Destination Location 370 The PCC asking for an inter-domain path computation is typically 371 aware of the identity of the destination node. Additionally, if the 372 PCC is aware of the destination domain, it can supply this 373 information as part of the path computation request. However, 374 if the PCC does not know the egress domain this information must 375 be determined by another method. 377 4. Domain Topologies 379 Constraint-based inter-domain path computation is a fundamental 380 requirement for operating traffic engineered MPLS [RFC3209] and 381 GMPLS [RFC3473] networks, in inter-area and inter-AS (multi-domain) 382 environments. Path computation across multi-domain networks is 383 complex and requires computational co-operational entities like the 384 PCE. 386 4.1 Selecting Domain Paths 388 Where the sequence of domains is known a priori, various techniques 389 can be employed to derive an optimal multi-domain path. If the 390 domains are simply-connected, or if the preferred points of 391 interconnection are also known, the Per-Domain Path Computation 392 [RFC5152] technique can be used. Where there are multiple connections 393 between domains and there is no preference for the choice of points 394 of interconnection, BRPC [RFC5441] can be used to derive an optimal 395 path. 397 When the sequence of domains is not known in advance, the optimum 398 end-to-end path can be derived through the use of a hierarchical 399 relationship between domains [RFC6805]. 401 4.2 Multi-Homed Domains 403 Networks constructed from multi-areas or multi-AS environments 404 may have multiple interconnect points (multi-homing). End-to-end path 405 computations may need to use different interconnect points to avoid 406 single point failures disrupting primary and backup services. 408 4.3 Domain Meshes 410 Very frequently network domains are composed by dozens or hundreds of 411 network elements. These network elements are usually interconnected 412 between them in a partial-mesh fashion, to provide survivability 413 against dual failures, and to benefit from the traffic engineering 414 capabilities from MPLS and GMPLS protocols. A typical node degree 415 ranges from 3 to 10 (4-5 is quite common), being the node degree the 416 number of neighbors per node. 418 Networks are sometimes divided into domains. Some reasons for it 419 range from manageability to separation into vendor-specific domains. 420 The size of the domain will be usually limited by control plane, but 421 it can also be stated by arbitrary design constraints. 423 4.4 Domain Diversity 425 Whenever an specific connectivity service is required to have 1+1 426 protection feature, two completely disjoint paths must be 427 established on an end to end fashion. In a multi-domain environment 428 without, this can be accomplished either by selecting domain 429 diversity, or by ensuring diverse connection within a domain. In 430 order to compute the route diversity, it could be helpful to have 431 SRLG information in the domains. 433 4.5 Synchronized Path Computations 435 In some scenarios, it would be beneficial for the operator to rely on 436 the capability of the PCE to perform synchronized path computation. 438 Synchronized path computations, known as Synchronization VECtors 439 (SVECs) are used for dependent path computations. SVECs are 440 defined in [RFC5440] and [RFC6007] provides an overview for the 441 use of the PCE SVEC list for synchronized path computations when 442 computing dependent requests. 444 A non-comprehensive list of synchronized path computations include 445 the following examples: 447 o Route diversity: computation of two disjoint paths from a source to 448 a destination (as drafted in the previous section). 450 o Synchronous restoration: joint computation of a set of alternative 451 paths for a set of affected LSPs as a consequence of a failure 452 event. Note that in this case, the requests will potentially 453 involve different source-destination pairs. In this scenario, the 454 different path computation requests may arrive at different time 455 stamps. 457 o Batch provisioning: It is common that the operator sends a set of 458 LSPs requests together, e.g in a daily of weekly basis, mainly in 459 case of long lived LSPs. In order to optimize the resource usage, 460 a synchronized path computation is needed. 462 o Network optimization: After some time of operation, the 463 distribution of the established LSP paths results in a non optimal 464 use of resources. Also, inter-domain policies/agreements may have 465 been changed. In such cases, a full (or partial) network planning 466 action regarding the inter-domain connections will be triggered. 467 This will involve the request of potentially a big amount of 468 connections. 470 4.6 Domain Inclusion or Exclusion 472 A domain sequence is an ordered sequence of domains traversed to 473 reach the destination domain, a domain sequence may be supplied 474 during path computation to guide the PCEs or derived via use of 475 Hierarchical PCE (H-PCE). 477 During multi-domain path computation, a PCC may request 478 specific domains to be included or excluded in the domain sequence 479 using the Include Route Object (IRO) [RFC5440] and Exclude Route 480 Object (XRO) [RFC5521]. The use of Autonomous Number (AS) as an 481 abstract node representing a domain is defined in [RFC3209], 482 [DOMAIN-SEQ] specifies new sub-objects to include or exclude domains 483 such as an IGP area or an Autonomous Systems. 485 5. Applicability of the PCE to Inter-area Traffic Engineering 487 As networks increase in size and complexity it may be required to 488 introduce scaling methods to reduce the amount information flooded 489 within the network and make the network more manageable. An IGP 490 hierarchy is designed to improve IGP scalability by dividing the 491 IGP domain into areas and limiting the flooding scope of topology 492 information to within area boundaries. This restricts visibility of 493 the area to routers in a single area. If a router needs to compute a 494 route to destination located in another area a method is required to 495 compute a path across area boundaries. 497 In order to support multiple vendors in a network, in cases where 498 data and/or control plane technologies cannot interoperate, it is 499 useful to divide the network in vendor domains. Each vendor domain is 500 an IGP area, and the flooding scope of the topology (as well as any 501 other relevant information) is limited to the area boundaries. 503 Per-domain path computation [RFC5152] exists to provide a method of 504 inter-area path computation. The per-domain solution is based on 505 loose hop routing with an Explicit Route Object (ERO) expansion on 506 each Area Border Router (ABR). This allows an LSP to be established 507 using a constrained path, however at least two issues exist: 509 - This method does not guarantee an optimal constrained path. 511 - The method may require several crankback signaling messages 512 increasing signaling traffic and delaying the LSP setup. 514 The PCE-based architecture [RFC4655] is designed to solve inter-area 515 path computation problems. The issue of limited topology visibility 516 is resolved by introducing path computation entities that are able to 517 cooperate in order to establish LSPs with source and destinations 518 located in different areas. 520 5.1. Inter-area Routing 522 An inter-area TE-LSP is an LSP that transits through at least two 523 IGP areas. In a multi-area network, topology visibility remains 524 local to a given area, and a node in one area will not be able to 525 compute an end-to-end path across multiple areas without the use 526 of a PCE. 528 5.1.1. Area Inclusion and Exclusion 530 [RFC5152] provides the mechanisms to compute an inter-area 531 path. It uses loose hop routing with an ERO expansion on each ABR. 532 This allows the end-to-end path to be set up following a constrained 533 path, but faces two major limitations: 535 - The method does not guarantee the use of an optimal constrained 536 path. 538 - This may lead to several crankback signaling messages and hence 539 delay the path setup. 541 [RFC5441] provides a more optimal method to specify inclusion or 542 exclusion of an ABR. Using this method, an operator might decide if 543 an area must be include or exclude from the inter-area path 544 computation. 546 5.1.2. Strict Explicit Path and Loose Path 547 A strict explicit Path is defined as a set of strict hops, while a 548 loose path is defined as a set of at least one loose hop and zero, 549 one or more strict hops. It may be useful to indicate, during the 550 path computation request, if a strict explicit path is required or 551 not. An inter-area path may be strictly explicit or loose (e.g., a 552 list of ABRs as loose hops). 554 A PCC request to a PCE does allow the indication of if a strict 555 explicit path across specific areas is required or desired, or if 556 the path request is loose. 558 5.1.3. Inter-Area Diverse Path Computation 560 It may be necessary (for protection or load-balancing) to compute 561 a path that is diverse, from a previously computed path. There are 562 various levels of diversity in the context of an inter-area network: 564 - Per-area diversity (intra-area path segments are link, node or 565 SRLG disjoint. 567 - Inter-area diversity (end-to-end inter-area paths are link, 568 node or SRLG disjoint). 570 Note that two paths may be disjoint in the backbone area but non- 571 disjoint in peripheral areas. Also two paths may be node disjoint 572 within areas but may share ABRs, in which case path segments within 573 an area are node disjoint but end-to-end paths are not node-disjoint. 575 Both Per-Domain [RFC5152] and BRPC [RFC5441] mechanisms support the 576 capability to compute diverse across multi-area topologies. 578 5.2. Control and Recording of Area Crossing 580 In some environments it be useful for the PCE to provide a PCC the 581 set of areas crossed by the end-to-end path. Additionally the PCE 582 can provide the path information and mark each segment so the PCC 583 has visibility of which piece of the path lies within which area. 584 Although by implementing Path-Key, the hop-by-hop (area topology) 585 information is kept confidential. 587 6. Applicability of the PCE to Inter-AS Traffic Engineering 589 As discussed in section 4 (Applicability of the PCE to Inter-area 590 Traffic Engineering) it is necessary to divide the network into 591 smaller administrative domains, or ASes. If an LSR within an AS needs 592 to compute a path across an AS boundary it must also use an inter-AS 593 computation technique. [RFC5152] defines mechanisms for the 594 computation of inter-domain TE LSPs using network elements along the 595 signaling paths to compute per-domain constrained path segments. 597 The PCE was designed to be capable of computing MPLS and GMPLS paths 598 across AS boundaries. This section outlines the features of a 599 PCE-enabled solution for computing inter-AS paths. 601 6.1 Inter-AS Routing 603 6.1.1. AS Inclusion and Exclusion 605 [RFC5441] a method to specify inclusion or exclusion of an ASBR. 606 Using this method, an operator might decide if an AS must be include 607 or exclude from the inter-AS path computation. 609 6.1.2. Strict Explicit Path and Loose Path 611 During path computation, the PCE architecture and BRPC algorithm 612 allow operators to specify if the resultant LSP must follow a strict 613 or a loose path. By explicitly specify the path, the operator 614 request a strict explicit path which must pass through one or many 615 LSR. If this behaviour is well define and appropriate for inter-area, 616 it implies some topology discovery for inter-AS. So, this feature 617 when the operator owns several ASes (and so, knows the topology of 618 its ASes) or restricts to the well-known ASBR to avoid topology 619 discovery between operators. The loose path, even if it does not 620 allow granular specification of the path, protects topology 621 disclosure as it not obligatory for the operator to disclose 622 information about its networks. 624 6.1.3. AS Inclusion and Exclusion 626 Like explicit and loose path, [RFC5441] allows to specify inclusion 627 or exclusion of respectively an AS or an ASBR. Using this method, 628 an operator might decide if an AS must be include or exclude from 629 the inter-AS path computation. Exclusion and/or inclusion could also 630 be specified at any step in the LSP path computation process by a PCE 631 (within the BRPC algorithm) but the best practice would be to specify 632 them at the edge. In opposition to the strict and loose path, AS 633 inclusion or exclusion doesn't impose topology disclosure as ASes are 634 public entity as well as their interconnection. 636 6.2 Inter-AS Bandwidth Guarantees 638 Many operators with multi-AS domains will have deployed MPLS-TE 639 DiffServ either across their entire network or at the domain edges 640 on CE-PE links. In situations where strict QOS bounds are required, 641 admission control inside the network may also be required. 643 When the propagation delay can be bounded, the performance targets, 644 such as maximum one-way transit delay may be guaranteed by providing 645 bandwidth guarantees along the DiffServ-enabled path. 647 One typical example of this requirement is to provide bandwidth 648 guarantees over an end-to-end path for VoIP traffic classified as EF 649 (Expedited Forwarding) class in a DiffServ-enabled 650 network. In the case where the EF path is extended across multiple 651 ASes, inter-AS bandwidth guarantee would be required. 653 Another case for inter-AS bandwidth guarantee is the requirement for 654 guaranteeing a certain amount of transit bandwidth across one or 655 multiple ASes. 657 6.3 Inter-AS Recovery 659 During path computation, a PCC request may contain backup LSP 660 requirements in order to setup in the same time the primary and 661 backup LSPs. It is also possible to request a backup LSP for a group 662 of primary LSPs. [RFC4090] adds fast re-route protection to LSP. So, 663 the PCE could be used to trigger computation of backup tunnels in 664 order to protect Inter-AS connectivity. Inter-AS recovery 665 requirements needs not only PCE protection and redundancy but also 666 LSP tunnels protection through FRR mechanisms. Inter-AS PCE 667 computation must support the FRR mechanisms and the patch computation 668 for backup tunnels for protection and fast recovery. 670 6.4 Inter-AS PCE Peering Policies 672 Like BGP peering policies, inter-AS PCE peering policies is a 673 requirement for operator. In inter-AS BRPC process, PCE must 674 cooperate in order to compute the end-to-end LSP. So, the AS path 675 must not only follow technical constraints e.g. bandwidth 676 availability, but also policies define by the operator. 678 Typically PCE interconnections at an AS level must follow contract 679 obligations, also known as peering agreements. The PCE peering 680 policies are the result of the contract negotiation and govern 681 the relation between the different PCE. 683 7. Multi-domain PCE Deployment Options 685 The PCE provides the architecture and mechanisms to compute 686 inter-area and inter-AS LSPs. The objective of this document is not 687 to reprint the techniques and mechanisms available, but to highlight 688 their existence and reference the relevant documents that introduce 689 and describe the techniques and mechanisms necessary for computing 690 inter-area and inter-AS LSP based services. 692 An area or AS may contain multiple PCEs: 694 - The path computation load may be balanced among a set of PCEs to 695 improve scalability. 697 - For the purpose of redundancy, primary and backup PCEs may be used. 699 - PCEs may have distinct path computation capabilities (P2P or P2MP). 701 Discovery of PCEs and capabilities per area or AS is defined in 702 [RFC5088] and [RFC5089]. 704 Each PCE per domain can be deployed in a centralized or distributed 705 architecture, the latter model having local visibility and 706 collaborating in a distributed fashion to compute a path across the 707 domain. Each PCE may collect topology and TE information from the 708 same sources as the LSR, such as the IGP TED. 710 When the PCC sends a path computation request to the PCE, the PCE 711 will compute the path across a domain based on the required 712 constraints. The PCE will generate the full set of strict hops from 713 source to destination. This information, encoded as an ERO, is then 714 sent back to the PCC that requested the path. In the event that a 715 path request from a PCC contains source and destination nodes that 716 are located in different domains the PCE is required to co-operate 717 between multiple PCEs, each responsible for its own domain. 719 Techniques for inter-domain path computation are described in 720 [RFC5152] and [RFC5441], both techniques assume that the sequence of 721 domains to be crossed from source to destination is well known. In 722 the event that the sequence of domains is not well known, [RFC6805] 723 might be used. The sequence could also be retrieve locally from 724 information previously stored in the PCE database (preferably in 725 the TED) by OSS management or other protocols. 727 7.1 Traffic Engineering Database 729 TEDs are automatically populated by the IGP-TE like IS-IS-TE or 730 OSPF-TE. However, no information related to AS path are provided 731 by such IGP-TE. It could be helpful for BRPC algorithm as AS path 732 helper, to populate a TED with suitable information regarding 733 inter-AS connectivity. Such information could be obtain from 734 various sources, such as BGP protocol, peering policies, OSS of the 735 operator or from neighbor PCE. In any case, no topology disclosure 736 must be impose in order to provide such information. 738 In particular, for both inter-area and inter-AS, the TED must be 739 populated with all boundary node information suitable to 740 establish PCEP protocol with the next PCE in the path. 742 7.2 Provisioning Techniques 744 As PCE algorithms rely on information contained in the TED, it 745 is possible to populate TED information by means of provisioning. In 746 this case, the operator must regularly update and store all suitable 747 information in the TED in order for the PCE to correctly compute LSP. 748 Such information range from policies (e.g. avoid this LSR, or use 749 this ASBR for a specific IP prefix) up to topology information (e.g. 750 AS X is reachable trough a 100 Mbit/s link on this ASBR and 30 Mbit/s 751 are reserved for EF traffic). Operators may choose the type and 752 amount of information they can use to manage their traffic engineered 753 network. 755 However, some LSPs might be provisioned to link ASes or areas. In 756 this case, these LSP must be announced by the IGP-TE in order to 757 automatically populate the TED. 759 7.3 Pre-Planning and Management-Based Solutions 761 Offline path computation is performed ahead of time, before the LSP 762 setup is requested. That means that it is requested by, or performed 763 as part of, a management application. This model can be seen in 764 Section 5.5 of [RFC4655]. 766 The offline model is particularly appropriate to long-lived LSPs 767 (such as those present in a transport network) or for planned 768 responses to network failures. In these scenarios, more planning is 769 normally a feature of LSP provisioning. 771 This model may also be used where the network operator wishes to 772 retain full manual control of the placement of LSPs, using the PCE 773 only as a computation tool to assist the operator, not as part of an 774 automated network. 776 The management based solutions could also be used in conjunction 777 with the BRPC algorithm. Operator just computes the AS-Path as 778 parameter for the inter-AS path computation request and let each 779 PCE along the AS path compute the LSP part on its own domain. 781 7.4 Per-Domain Computation 783 [RFC5152] defines the mechanism to compute per-domain path and must 784 be used in that condition. Otherwise, BRPC [RFC5441] will be used. 786 7.5 Cooperative PCEs 788 When PCE cooperate to compute an inter-area or inter-AS LSP, both 789 [RFC5152] and [RFC5441] could be used. 791 7.6 Hierarchical PCEs 793 The [RFC6805] draft defines how a hierarchy of PCEs may be used. An 794 operator must define a parent PCE and each child PCE. A parent PCE 795 can be announced in the other areas or ASes in order for the parent 796 PCE to contact remote child PCEs. Reciprocally, child PCEs are 797 announced in remote areas or ASes in order to be contacted by a 798 remote parent PCE. Parent and each child PCE could also be 799 provisioned in the TED if they are not announced. 801 8. Domain Confidentiality 803 Confidentiality typically applies to inter-provider (inter-AS) PCE 804 communication. Where the TE LSP crosses multiple domains (ASes or 805 areas), the path may be computed by multiple PCEs that cooperate 806 together. With each local PCE responsible for computing a segment 807 of the path. However, in some cases (e.g., when ASes are 808 administered by separate Service Providers), it would break 809 confidentiality rules for a PCE to supply a path segment to a 810 PCE in another domain, thus disclosing AS-internal or area 811 topology information. 813 8.1 Loose Hops 815 A method for preserving the confidentiality of the path segment is 816 for the PCE to return a path containing a loose hop in place of the 817 segment that must be kept confidential. The concept of loose and 818 strict hops for the route of a TE LSP is described in [RFC3209]. 820 [RFC5440] supports the use of paths with loose hops, and it is a 821 local policy decision at a PCE whether it returns a full explicit 822 path with strict hops or uses loose hops. A path computation 823 request may request an explicit path with strict hops, or 824 may allow loose hops as detailed in [RFC5440]. 826 8.2 Confidential Path Segments and Path Keys 828 [RFC5520] defines the concept and mechanism of Path-Key. A Path-Key 829 is a token that replaces the path segment information in an explicit 830 route. The Path-Key allows the explicit route information to be 831 encoded and in the PCEP ([RFC5440]) messages exchanged between the 832 PCE and PCC. 834 This Path-Key technique allows explicit route information to used 835 for end-to-end path computation, without disclosing internal topology 836 information between domains. 838 9. Point-to-Multipoint 840 For the Point-to-Multipoint application scenarios for MPLS-TE LSP, 841 the complexity of domain sequences, domain policies, choice and 842 number of domain interconnects is magnified comparing to P2P path 843 computations. Also as the size of the network grows, the number of 844 leaves and branches increase and it in turn puts the scalability of 845 the path computation and optimization into a bigger issue. A 846 solution for the point-to-multipoint path computations may be 847 achieved using the PCEP protocol extension for P2MP [RFC6006] and 848 using the PCEP P2MP procedures defined in [PCEP-P2MP-INTER-DOMAIN]. 850 10. Optical Domains 852 The International Telecommunications Union (ITU) defines the ASON 853 architecture in [G-8080]. [G-7715] defines the routing architecture 854 for ASON and introduces a hierarchical architecture. In this 855 architecture, the Routing Areas (RAs) have a hierarchical 856 relationship between different routing levels, which means a parent 857 (or higher level) RA can contain multiple child RAs. The 858 interconnectivity of the lower RAs is visible to the higher level RA. 860 10.1. PCE applied to the ASON Architecture 862 In the ASON framework, a path computation request is termed a Route 863 Query. This query is executed before signaling is used to establish 864 an LSP termed a Switched Connection (SC) or a Soft Permanent 865 Connection (SPC). [G-7715-2] defines the requirements and 866 architecture for the functions performed by Routing Controllers (RC) 867 during the operation of remote route queries - an RC is synonymous 868 with a PCE. 870 In the ASON routing environment, a RC responsible for an RA may 871 communicate with its neighbor RC to request the computation of an 872 end-to-end path across several RAs. The path computation components 873 and sequences are defined as follows: 875 o Remote route query. An operation where a routing controller 876 communicates with another routing controller, which does not have 877 the same set of layer resources, in order to compute a routing 878 path in a collaborative manner. 880 o Route query requester. The connection controller or RC that sends a 881 route query message to a routing controller requesting for one or 882 more routing path that satisfies a set of routing constraints. 884 o Route query responder. An RC that performs path computation upon 885 reception of a route query message from a routing controller or 886 connection controller, sending a response back at the end of 887 computation. 889 When computing an end-to-end connection, the route may be computed by 890 a single RC or multiple RCs in a collaborative manner and the two 891 scenarios can be considered a centralized remote route query model 892 and distributed remote route query model. RCs in an ASON environment 893 can also use the hierarchical PCE [RFC6805] model to fully match the 894 ASON hierarchical routing model. 896 11. Policy 898 Policy is important in the deployment of new services and the 899 operation of the network. [RFC5394] provides a framework for PCE- 900 based policy-enabled path computation. This framework is based on 901 the Policy Core Information Model (PCIM) as defined in [RFC3060] and 902 further extended by [RFC3460]. 904 When using a PCE to compute inter-domain paths, policy may be 905 invoked by specifying: 907 - Each PCC must select which computations will be delegated to a PCE; 909 - Each PCC must select which PCEs it will use; 911 - Each PCE must determine which PCCs are allowed to use its services 912 and for what computations; 914 - The PCE must determine how to collect the information in its TED, 915 who to trust for that information, and how to refresh/update the 916 information; 918 - Each PCE must determine which objective functions and which 919 algorithms to apply. 921 Finally, due to the nature of inter-domain (and particularly using 922 H-PCE based) path computations, deployment of policy should also 923 consider the need to be sensitive to commercial and reliability 924 information about domains and the interactions of services crossing 925 domains. 927 12. TED Topology and Synchronization 929 The PCE operates on a view of the network topology as presented by a 930 Traffic Engineering Database. As discussed in [RFC4655] the TED 931 used by a PCE may be learnt by the relevant IGP extensions. 933 Thus, the PCE may operate its TED is by participating 934 in the IGP running in the network. In an MPLS-TE network, this 935 would require OSPF-TE [RFC3630] or ISIS-TE [RFC5305]. In a GMPLS 936 network it would utilize the GMPLS extensions to OSPF and IS-IS 937 defined in [RFC4203] and [RFC5307]. 939 An alternative method to provide network topology and resource 940 information is offered by [BGP-LS], which is described in the 941 following section. 943 12.1 Applicability of BGP-LS to PCE 945 The concept of exchange of TE information between Autonomous Systems 946 (ASes) is discussed in [BGP-LS]. The information exchanged in this 947 way could be the full TE information from the AS, an aggregation of 948 that information, or a representation of the potential connectivity 949 across the AS. Furthermore, that information could be updated 950 frequently (for example, for every new LSP that is set up across the 951 AS) or only at threshold-crossing events. 953 There are a number of discussion points associated with the use of 954 [BGP-LS] concerning the volume of information, the rate of churn of 955 information, the confidentiality of information, the accuracy of 956 aggregated or potential-connectivity information, and the processing 957 required to generate aggregated information. The PCE architecture and 958 the architecture enabled by [BGP-LS] make different assumptions about 959 the operational objectives of the networks, and this document does 960 not attempt to make one of the approaches "right" and the other 961 "wrong". Instead, this work assumes that a decision has been made to 962 utilize the PCE architecture. 964 Indeed, [BGP-LS] may have some uses within the PCE model. For 965 example, [BGP-LS] could be used as a "northbound" TE advertisement 966 such that a PCE does not need to listen to an IGP in its domain, but 967 has its TED populated by messages received (for example) from a 968 Route Reflector. Furthermore, the inter-domain connectivity and 969 connectivity capabilities that is required optional information for 970 a parent PCE could be obtained as a filtered subset of the 971 information available in [BGP-LS]. 973 13. Manageability Considerations 975 General PCE management considerations are discussed in [RFC4655]. 976 In the case of multi-domains within a single service provider 977 network, the management responsibility for each PCE would most 978 likely be handled by the same service provider. In the case of 979 multiple ASes within different service provider networks, it will 980 likely be necessary for each PCE to be configured and managed 981 separately by each participating service provider, with policy 982 being implemented based on an a previously agreed set of principles. 984 13.1 Control of Function and Policy 986 As per PCEP [RFC5440] implementation allow the user to configure 987 a number of PCEP session parameters. These are detailed in section 988 8.1 of [RFC5440] and will not be repeated here. 990 13.2 Information and Data Models 992 A PCEP MIB module is defined in [PCEP-MIB] that describes managed 993 objects for modeling of PCEP communication including: 995 o PCEP client configuration and status, 997 o PCEP peer configuration and information, 999 o PCEP session configuration and information, 1001 o Notifications to indicate PCEP session changes. 1003 13.3 Liveness Detection and Monitoring 1005 PCEP includes a keepalive mechanism to check the liveliness of a PCEP 1006 peer and a notification procedure allowing a PCE to advertise its 1007 overloaded state to a PCC. In a multi-domain environment [RFC5886] 1008 provides the procedures necessary to monitor the liveliness and 1009 performances of a given PCE chain. 1011 13.4 Verifying Correct Operation 1013 In order to verify the correct operation of PCEP, [RFC5440] specifies 1014 the monitoring of key parameters. These parameters are detailed in 1015 section 8.4 of [RFC5440] and will not be repeated here. 1017 13.5 Impact on Network Operation 1019 [RFC5440] states that in order to avoid any unacceptable impact on 1020 network operations, a PCEP implementation should allow a limit to be 1021 placed on the number of sessions that can be set up on a PCEP 1022 speaker, it may also be practical to place a limit on the rate 1023 of messages sent by a PCC and received my the PCE. 1025 14. Security Considerations 1027 PCEP security is defined [RFC5440]. Any multi-domain operation 1028 necessarily involves the exchange of information across domain 1029 boundaries. This does represent a significant security and 1030 confidentiality risk. PCEP allows individual PCEs to maintain 1031 confidentiality of their domain path information using path-keys 1032 [RFC5520]. 1034 For further considerations of the security issues related to inter- 1035 domain path computation, see [RFC5376]. 1037 15. IANA Considerations 1039 This document makes no requests for IANA action. 1041 16. Acknowledgements 1043 The author would like to thank Adrian Farrel for his review, and 1044 Meral Shirazipour and Francisco Javier Jimenex Chico for their 1045 comments. 1047 17. References 1049 17.1. Normative References 1051 17.2. Informative References 1053 [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. 1054 Westerinen, "Policy Core Information Model -- Version 1 1055 Specification", RFC 3060, February 2001. 1057 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1058 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1059 Tunnels", RFC 3209, December 2001. 1061 [RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) 1062 Extensions", RFC 3460, January 2003. 1064 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 1065 Switching (GMPLS) Signaling Resource ReserVation 1066 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 1067 3473, January 2003. 1069 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 1070 Engineering (TE) Extensions to OSPF Version 2", RFC 1071 3630, September 2003. 1073 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 1074 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 1075 2005. 1077 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF 1078 Extensions in Support of Generalized Multi- 1079 Protocol Label Switching (GMPLS)", RFC 1080 4203, October 2005. 1082 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1083 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1085 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework 1086 for Inter-Domain Multiprotocol Label Switching Traffic 1087 Engineering", RFC 4726, November 2006. 1089 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 1090 "OSPF Protocol Extensions for Path Computation Element 1091 (PCE) Discovery", RFC 5088, January 2008. 1093 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1094 Zhang, "IS-IS Protocol Extensions for Path Computation 1095 Element (PCE) Discovery", RFC 5089, January 2008. 1097 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 1098 Path Computation Method for Establishing Inter-Domain 1099 Traffic Engineering (TE) Label Switched Paths (LSPs)", 1100 RFC 5152, February 2008. 1102 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1103 Engineering", RFC 5305, October 2008. 1105 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS 1106 Extensions in Support of Generalized Multi-Protocol 1107 Label Switching (GMPLS)", RFC 5307, 1108 October 2008. 1110 [RFC5376] Bitar, N., et al., "Inter-AS Requirements for the Path 1111 Computation Element Communication Protocol (PCECP)", RFC 1112 5376, November 2008. 1114 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 1115 "Policy-Enabled Path Computation Framework", RFC 5394, 1116 December 2008. 1118 [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, 1119 A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, 1120 "Path Computation Element (PCE) Communication Protocol 1121 (PCEP)", RFC 5440, March 2009. 1123 [RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based 1124 Computation (BRPC) procedure to compute shortest inter- 1125 domain Traffic Engineering Label Switched Paths", 1126 RFC5441, April 2009. 1128 [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, 1129 "Preserving Topology Confidentiality in Inter-Domain Path 1130 Computation Using a Path-Key-Based Mechanism", RFC 5520, 1131 April 2009. 1133 [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the 1134 Path Computation Element Communication Protocol (PCEP) 1135 for Route Exclusions", RFC 5521, April 2009. 1137 [RFC5541] Le Roux, J., Vasseur, J., Lee, Y., "Encoding 1138 of Objective Functions in the Path Computation Element 1139 Communication Protocol (PCEP)", RFC5541, December 2008. 1141 [RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of 1142 Monitoring Tools for Path ComputationElement (PCE)-Based 1143 Architecture", RFC 5886, June 2010. 1145 [RFC6006] Takeda, T., Chaitou M., Le Roux, J.L., Ali Z., 1146 Zhao, Q., King, D., "Extensions to the Path Computation 1147 Element Communication Protocol (PCEP) for 1148 Point-to-Multipoint Traffic Engineering Label Switched 1149 Paths", RFC6006, September 2010. 1151 [RFC6007] Nishioka, I., King, D., "Use of the Synchronization 1152 VECtor (SVEC) List for Synchronized Dependent Path 1153 Computations", RFC6007, September 2010. 1155 [G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for 1156 the automatically switched optical network (ASON). 1158 [G-7715] ITU-T Recommendation G.7715 (2002), Architecture 1159 and Requirements for the Automatically Switched 1160 Optical Network (ASON). 1162 [G-7715-2] ITU-T Recommendation G.7715.2 (2007), ASON routing 1163 architecture and requirements for remote route query. 1165 [RFC6805] King, D. and A. Farrel, "The Application of the Path 1166 Computation Element Architecture to the Determination 1167 of a Sequence of Domains in MPLS & GMPLS", RFC6805, July 1168 2010. 1170 [PCEP-P2MP-INTER-DOMAIN] Zhao, Q., Dhody, D., Ali Z., King, D., 1171 Casellas, R., "PCE-based Computation 1172 Procedure To Compute Shortest Constrained 1173 P2MP Inter-domain Traffic Engineering Label Switched 1174 Paths", work in progress. 1176 [BGP-LS] Gredler, H., Medved, J., Previdi, S., Farrel, A., and 1177 S. Ray, "North-Bound Distribution of Link-State and TE 1178 Information using BGP", work in progress. 1180 [PCEP-MIB] Stephan, E., Koushik, K., Zhao, Q., King, D., "PCE 1181 Communication Protocol (PCEP) Management Information 1182 Base", work in progress. 1184 [DOMAIN-SEQ] Dhody, D., Palle, U., and R. Casellas, "Standard 1185 Representation Of Domain Sequence", work in progress. 1187 18. Author's Addresses 1189 Daniel King 1190 Old Dog Consulting 1191 UK 1193 EMail: daniel@olddog.co.uk 1195 Julien Meuric 1196 France Telecom 1197 2, avenue Pierre-Marzin 1198 22307 Lannion Cedex 1200 EMail: julien.meuric@orange-ftgroup.com 1202 Olivier Dugeon 1203 France Telecom 1204 2, avenue Pierre-Marzin 1205 22307 Lannion Cedex 1207 EMail: olivier.dugeon@orange-ftgroup.com 1209 Quintin Zhao 1210 Huawei Technology 1211 125 Nagog Technology Park 1212 Acton, MA 01719 1213 US 1215 EMail: qzhao@huawei.com 1217 Oscar Gonzalez de Dios 1218 Telefonica I+D 1219 Emilio Vargas 6, Madrid 1220 Spain 1222 EMail: ogondio@tid.es