idnits 2.17.1 draft-farrkingel-pce-questions-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (28 April 2013) is 4013 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 Network Working Group A. Farrel 2 Internet Draft Juniper Networks 3 Category: Informational D. King 4 Expires: 28 October 2013 Old Dog Consulting 5 28 April 2013 7 Unanswered Questions in the Path Computation Element Architecture 8 draft-farrkingel-pce-questions-03.txt 10 Abstract 12 The Path Computation Element (PCE) architecture is set out in RFC 13 4655. The architecture is extended for multi-layer networking with 14 the introduction of the Virtual Network Topology Manager in RFC 15 5623, and generalized to Hierarchical PCE in RFC 6805. 17 These three architectural views of PCE deliberately leave some key 18 questions unanswered especially with respect to the interactions 19 between architectural components. This document draws out those 20 questions and discusses them in an architectural context with 21 reference to other architectural components, existing protocols, and 22 recent IETF work efforts. 24 This document does not update the architecture documents and does not 25 define how protocols or components must be used. It does, however, 26 suggest how the architectural components might be combined to provide 27 advanced PCE function. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that other 36 groups may also distribute working documents as Internet-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 Copyright Notice 51 Copyright (c) 2013 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction .................................................. 3 67 1.1. Terminology ................................................. 3 68 2. What Is Topology Information? ................................. 3 69 3. How Is Topology Information Gathered? ......................... 4 70 4. How Do I Find My PCE? ......................................... 5 71 5. How Do I Select Between PCEs? ................................. 6 72 6. How Do Redundant PCEs Synchronize TEDs? ....................... 7 73 7. Where Is the Destination? ..................................... 8 74 8. Who Runs Or Owns a Parent PCE? ................................ 9 75 9. How Do I Find My Parent PCE? ................................. 10 76 10. How Do I Find My Child PCEs? ................................ 10 77 11. How Is The Parent PCE Domain Topology Built? ................ 10 78 12. Does H-PCE Solve The Internet? .............................. 11 79 13. What are Sticky Resources? .................................. 11 80 14. What Is A Stateful PCE For? ................................. 12 81 15. How Does a Stateful PCE Learn LSP State From The Network? ... 13 82 16. How Do Redundant Stateful PCEs Synchronize State? ........... 14 83 17. What Is An Active PCE? What is a Passive PCE? ............... 15 84 18. What is LSP Delegation? ..................................... 15 85 19. Is An Active PCE with LSP Delegation Just a Fancy NMS? ..... 16 86 20. Comparison of Stateless and Stateful PCE .................... 16 87 21. How Does a PCE Work With A Virtual Network Topology? ........ 17 88 22. How Does PCE Communicate With VNTM .......................... 18 89 23. How Does Service Scheduling and Calendering Work? ........... 18 90 24. Where Does Policy Fit In? ................................... 19 91 25. Does PCE Play a Role in SDN? ................................ 20 92 26. What is a Path Computation Elephant? ........................ 21 93 27. Security Considerations ..................................... 21 94 28. IANA Considerations ......................................... 21 95 29. Acknowledgements ............................................ 21 96 30. References .................................................. 21 97 30.1. Normative References ...................................... 21 98 30.2. Informative References .................................... 22 99 Authors' Addresses ............................................... 25 101 1. Introduction 103 Over the years since the architecture for the Path Computation 104 Element (PCE) was documented in [RFC4655] many new people have 105 become involved in the work of the PCE working group and wish to use 106 or understand the PCE architecture. These people often missed out on 107 early discussions within the working group and are unfamiliar with 108 questions that were raised during the development of the 109 documentation. 111 Furthermore, the base architecture has been extended to handle other 112 situations and requirements. For example, the architecture was 113 extended for multi-layer networking with the introduction of the 114 Virtual Network Topology Manager [RFC5623] and was generalized to 115 include Hierarchical PCE (H-PCE) [RFC6805]. 117 These three architectural views of PCE deliberately leave some key 118 questions unanswered especially with respect to the interactions 119 between architectural components. This document draws out those 120 questions and discusses them in an architectural context with 121 reference to other architectural components, existing protocols, and 122 recent IETF work efforts. 124 This document does not update the architecture documents and does not 125 define how protocols or components must be used. It does, however, 126 suggest how the architectural components might be combined to provide 127 advanced PCE function. 129 1.1. Terminology 131 Readers are assumed to be thoroughly familiar with terminology 132 defined in defined in [RFC4655], [RFC4726], [RFC5440] and [RFC5623]. 134 Throughout this document the term "area" is used to refer equally to 135 an OSPF area and an IS-IS level. It is assumed that the reader is 136 able to map the small differences between these two use cases. 138 2. What Is Topology Information? 140 [RFC4655] defines that a PCE performs path computations based on a 141 view of the available network resources and network topology. This 142 information is collected into a Traffic Engineering Database (TED). 144 However, [RFC4655] does not provide a detailed description of what 145 information is present in the TED. It simply says that the TED 146 "contains the topology and resource information of the domain." 148 The precise information that needs to be held in a TED depends on the 149 type of network and nature of the computation that has to be 150 performed. As a basic minimum, the TED must contain the nodes and 151 links that form the domain, and must identify the connectivity in the 152 domain. 154 For most traffic engineering needs (for example, MPLS traffic 155 engineering - MPLS-TE) the TED would additionally contain a basic 156 metric for each link and knowledge of the available (unallocated) 157 resources on each link. 159 More advanced use cases might require that the TED contains 160 additional data that represents qualitative information such as: 162 - link delay 163 - link jitter 164 - node throughput capabilities 165 - optical impairments 166 - limited node cross-connect capabilities 168 Additionally, an important information element for computing paths, 169 especially for protected services, is the Shared Risk Group (SRG). 170 This is an indication of resources in the TED that have a common 171 risk of failure. That is, they have a shared risk of failure from a 172 single event. 174 In short, the TED needs to contain as much information as is needed 175 to satisfy the path computation requests subject to the objective 176 functions. This, in itself, may not be a trivial issue in some 177 network technologies. For example, in some optical networks, the 178 path computation for a new LSP may need to consider the impact that 179 turning up a new laser would have on the optical signals already 180 being carried by fibers. It may be possible to abstract this 181 information as parameters of the optical links and nodes in the TED, 182 but it may be easier to capture this information through a database 183 of existing LSPs (see Sections 14 and 15). 185 3. How Is Topology Information Gathered? 187 Clearly, the information in the TED discussed in Section 2 needs to 188 be gathered and maintained some how. [RFC4655] simple says "The TED 189 may be fed by Interior Gateway Protocol (IGP) extensions or 190 potentially by other means." In this context, "fed" means built and 191 maintained. 193 Thus, one way that the PCE may operate its TED is by participating in 194 the IGP running in the network. In an MPLS-TE network, this would 195 depend on OSPF-TE [RFC3630] and IS-IS-TE [RFC5305]. In a GMPLS 196 network it would utilize the GMPLS extensions to OSPF and IS-IS 198 [RFC4203] and [RFC5307]. 200 However, participating in an IGP, even as a passive receiver of IGP 201 information, can place a significant load on the PCE. The IGP can be 202 quite "chatty" when there are frequent updates to the use of the 203 network meaning that the PCE must dedicate significant processing to 204 parsing protocol messages and updating the TED. Furthermore, to be 205 truly useful, a PCE implementation would need to support OSPF and 206 IS-IS. 208 An alternative feed from the network to the PCE's TED is offered by 209 BGP-LS [I-D.ietf-idr-ls-distribution]. This approach offer the 210 alternative of leveraging an in-network BGP speaker (such as an ASBR 211 or a Route Reflector) that already has to participate in the IGP and 212 that is specifically designed to apply filters to IGP advertisements. 213 In this usage, the BGP speaker filters and aggregates topology 214 information according to configured policy before advertising it 215 "north-bound" to the PCE to update the TED. The PCE implementation 216 has to support just a simplified subset of BGP rather than two IGPs. 218 But BGP might not be convenient in all networks (for example, where 219 BGP is not run, such as in an optical network or a BGP-free core). 220 Furthermore, not all relevant information is made available through 221 standard TE extensions to the IGPs. In these cases, the TED must be 222 built or supplemented from other sources such as the NMS, inventory 223 management systems, and directly configured data. 225 It has also proposed that PCEP could be extended to serve as an 226 information collection protocol to supply information from network 227 devices to a PCE. The logic is that the network devices may already 228 speak PCEP and so the protocol could easily be used to report details 229 about the resources and state in the network, including the LSP state 230 discussed in Sections 14 and 15. 232 4. How Do I Find My PCE? 234 A Path Computation Client (PCC) needs to know the identity / location 235 of a PCE in order to be able to make computation requests. This is 236 because the Path Computation Element Communication Protocol (PCEP) is 237 a transaction-based protocol carried over TCP, and the 238 architectural decision made in Section 6.4 of RFC 4655 to required 239 targeted PCC-PCE communications. 241 As described in [RFC4655], a PCC could be configured with the 242 knowledge of the IP address of its PCE. This is a relatively light- 243 weight option considering all of the other configuration that a 244 router may require, but it is open to configuration errors, and does 245 not meet the need for minimal-configuration operation. Furthermore 246 configuration of multiple PCEs could become onerous, while handling 247 changes in PCE identities and coping with failure events would be an 248 issue for a configured system. 250 [RFC4655] offer the possibility that PCEs advertise themselves in the 251 IGP, and this requirement is developed in [RFC4674] and made possible 252 in OSPF and IS-IS through [RFC5088] and [RFC5089]. In general these 253 mechanisms should be sufficient for PCCs in a network where an IGP is 254 used and where the PCE participates in the IGP. 256 Note, however, that not all PCEs will participate in the IGP (see 257 Section 3). In these cases, assuming configuration is not 258 appropriate as a discovery mechanism, some other server 259 announcement/discovery function may be needed, such as DNS 260 [RFC4848] as used in the Application-Layer Traffic Optimization 261 (ALTO) discovery function [I-D.ietf-alto-server-discovery]. 263 5. How Do I Select Between PCEs? 265 When more then one PCE is discovered or configured, a PCC will need 266 to select which PCE to use. It may make this decision on any 267 arbitrary algorithm (for example, first-listed, or round-robin), but 268 it may also be the case that different PCEs have different 269 capabilities, in which case the PCC will want to select the PCE most 270 likely to be able to satisfy any one request. 272 PCE advertisement in OSPF or IS-IS per [RFC5088] and [RFC5089] allows 273 a PCE to announce its capabilities as required in [RFC4657]. A PCC 274 can select between PCEs based on the capabilities that they have 275 announced. However, these capabilities are expressed as flags in the 276 PCE advertisement so only the core capabilities are presented, and 277 there is not scope for including detailed information (such as 278 support for specific objective functions) in the advertisement. 280 Additional and more complex PCE capabilities, including the 281 capability to perform point-to-multipoint (P2MP) path computations 282 [RFC6006], may be announced by the PCE as optional PCEP 283 type-length-value (TLV) Type Indicators in the Open message described 284 in [RFC5440]. This mechanism is not limited to just a set of 285 flags, and detailed capability information may be presented in 286 sub-TLVs. 288 Note that this exchange of PCE capabilities is in the form of an 289 announcement, not a negotiation. That is, a PCC that wants specific 290 function from a PCE must examine the advertised capabilities and 291 select which PCE to use for a specific request. There is no scope 292 for a PCC to request a PCE to support features or functions that it 293 does not offer or announce. 295 A PCC may also vary which PCE it uses according to congestion 296 information reported by the PCEs [RFC5440] using the Notification 297 Object and Notification Type. Note that in a heavily overloaded PCE 298 system, reports from one PCE that it is overloaded may simply 299 result in all PCCs switching to another PCE which will, itself, 300 immediately become overloaded. Thus, PCCs should exercise a 301 certain amount of discretion and queueing theory before selecting 302 a PCE purely based on reported load. 304 Note that a PCC could send all requests to all PCEs that it knows 305 about. It can then elect between the results, perhaps choosing the 306 first result it receives, but this approach is very likely to 307 overload all the PCEs in the network considering that one of the 308 reasons for multiple PCEs is to share the load. 310 6. How Do Redundant PCEs Synchronize TEDs? 312 A network may have more than one PCE as discussed in the previous 313 sections. These PCEs may provide redundancy for load-sharing, 314 resilience, or partitioning of computation features. 316 In order to achieve some consistency between the results of different 317 PCEs, it is desirable that they operate on the same TE information. 319 The TED reflects the actual state of the network and does not a 320 resource reservation or booking scheme. Therefore, a PCE-based 321 system does not prevent competition for network resources during the 322 provisioning phase, although a process of "sticky resources" that are 323 temporarily reduced in the TED after a computation may be applied 324 purely as a local implementation issue. 326 One option for ensuring that multiple PCEs use the same TE 327 information is simply to have the PCEs driven from the same TED. 328 This could be achieved in an implementation by utilizing a shared 329 database, but it is unlikely to be efficient. 331 More likely is that each PCE is responsible for building its own TED 332 independently using the techniques described in Section 3. If the 333 PCEs participate in the IGP it is likely that they will attach at 334 different points in the network and so there may be minor and 335 temporary inconsistencies between their TEDs caused by IGP 336 convergence issues. If the PCEs gather TE information via BGP-LS 337 [I-D.ietf-idr-ls-distribution] from different sources, the same 338 inconsistencies may arise, but if the PCEs attach to the same BGP 339 speaker it may be possible to achieve consistency between TEDs modulo 340 the BGP-LS process itself. 342 A final option is to provide an explicit synchronization process 343 between the TED of a "master" PCE and the TEDs of other PCEs. Such a 344 process could be achieved using BGP-LS or a database synchronization 345 protocol (which would allow check-pointing and sequential updates). 346 This approach is fraught with issues around selection of the master 347 PCE and handling failures. It is, in fact, a mirrored database 348 scenario: a problem that is well known and the subject of plenty of 349 work. 351 Noting that the provisioning protocols handle contention for 352 resources, that the differences between TEDs are likely to be 353 relatively small with moderate arrival rates for new services, and 354 that contention in all but the most busy networks is relatively 355 unlikely, there may be no value in any attempt to synchronize TEDs. 357 However, see Section 16 for a discussion of synchronizing other state 358 between redundant PCEs. 360 7. Where Is the Destination? 362 Path computation provides an end-to-end path between a source and a 363 destination. If the destination lies in the source domain, then its 364 location will be known to the PCE and there are no issues to be 365 solved. However, in a multi--domain system a path must be found to 366 a remote domain that contains the destination, and that can only be 367 achieved by achieving some knowledge of the location of the 368 destination or at least knowing the next domain in the path toward 369 the domain that contains the destination. 371 The simplest solution here is achieved where a PCE has visibility 372 into multiple domains. Such may be the case in a multi-area 373 network where the PCE is aware of the contents of all of the IGP 374 areas. This approach is only likely to be appropriate where the 375 number of nodes is manageable, and is unlikely to extend over 376 administrative boundaries. 378 The per-domain path computation method for establishing inter-domain 379 traffic engineering LSPs [RFC5152] simply requires a PCE to compute a 380 path to the next domain toward the destination. As the LSP setup 381 (through signaling) progresses domain by domain, the label Switching 382 Router (LSR) at the entry point to each domain simply requests its 383 local PCE to compute the next segment of the path to the next domain 384 toward the destination. Thus, it is not necessary for any PCE 385 (except the last) to know in which domain the destination exists. 386 But, in this approach, each PCE must somehow determine the next 387 domain toward the destination, and it is not obvious how this is 388 achieved. 390 [RFC5152] suggests that in an IP/MPLS network it is good enough to 391 leverage the IP reachability information distributed by BGP and 392 assume that TE reachability can follow the same AS path. This 393 approach might not guarantee the optimal TE path and, of course, 394 might result in no path being found in degenerate cases. 395 Furthermore, in many network technologies (such as optical 396 networks operated by GMPLS) there may be limited or no 397 end-to-end IP connectivity. 399 The Backward Recursive PCE-based Computation (BRPC) procedure 400 [RFC5441] is able to achieve a more optimal end-to-end path than 401 the per-domain method, but depends on the knowledge of both the 402 domain in which the destination is located and the sequence of 403 domains toward the destination. This information is described in 404 [RFC5441] as being known a priori. Clearly, however, information is 405 not known a priori, and it may be hard for the PCE that serves the 406 source PCC to discover the necessary details. While there are 407 several approaches to solving the question of establishing the 408 domain sequence (for example, BRPC trial and error or Hierarchical 409 PCE [RFC6805]) none of them address the issue of determining 410 where the destination lies. 412 One argument that is often made is that an end-to-end connection 413 expressed as an LSP is a feature of a service agreement between 414 source and destination. If that is the case, it is argued, it 415 stands to reason that the location of the destination must be 416 known to the source node in the same way that the source has 417 determined the IP address of the destination. Presumably this 418 would be through a commercial process or an administrative 419 protocol. 421 [RFC4974] introduced the concept of Calls and Connections (LSPs). A 422 Call does not provide the actual connectivity for transmitting 423 user traffic, but builds a relationship that will allow subsequent 424 Connections to be made. A Call might be considered an agreement to 425 support an end-to-end LSP that is made between the endpoint nodes. 426 Call messages are sent and routed as normal IP messages, so the 427 sender does not need to know the location of the destination. 428 Furthermore, Call requests are responded, and the Call Response can 429 carry information (such as the identity of the domain containing the 430 destination) for use by Call initiator. Thus, the use of GMPLS Calls 431 might provide a mechanism to discover the location of the 432 destination. 434 8. Who Runs Or Owns a Parent PCE? 436 In the case of multi-domains (e.g., IGP areas or multiple ASes) 437 within a single service provider network, the management 438 responsibility for the parent PCE would most likely be handled by 439 the service provider. 441 In the case of multiple ASes within different service provider 442 networks, it may be necessary for a third party to manage the parent 443 PCEs according to commercial and policy agreements from each of the 444 participating service providers. Note that the H-PCE architecture 445 does not require disclosure of internals of a child domain to the 446 parent PCE. Thus, there is ample scope for a parent PCE to be run by 447 one of the connected service providers or by a third party without 448 compromising commercial issues. 450 9. How Do I Find My Parent PCE? 452 [RFC6805] specifies that a child PCE must be configured with the 453 address of its parent PCE in order for it to interact with its 454 parent PCE. There is no scope for parent PCEs to advertise their 455 presence, however there is potential for directory systems (such as 456 DNS [RFC4848] as used in the ALTO discovery function 457 [I-D.ietf-alto-server-discovery]) to be used as described in Section 458 4. 460 Note that according to [RFC6805] the child PCE must also be 461 authorized to peer with the parent PCE. This is discussed from the 462 viewpoint of the parent PCE in Section 10. The child PCE may need to 463 participate in a key distribution protocol in order to properly 464 authenticate its identity to the parent PCE. 466 10. How Do I Find My Child PCEs? 468 Within the hierarchical PCE framework [RFC6805] the parent PCE must 469 only accept path computation requests from authorized child PCEs. 470 If a parent PCE receives requests from an unauthorized child PCE, 471 the request should be dropped. 473 This would require a parent PCE to be configured with the 474 identities and security credentials of all of its child PCEs, or 475 there must be some form of shared secret that allows an unknown 476 child PCE to be authorized by the parent PCE. 478 11. How Is The Parent PCE Domain Topology Built? 480 The parent PCE maintains a domain topology map of the child domains 481 and their interconnectivity. Where inter-domain connectivity is 482 provided by TE links, the capabilities of those links may also be 483 known to the parent PCE. 485 The parent PCE maintains a TED for the parent domain in the same way 486 that any PCE does. The nodes in the parent domain will be 487 abstractions of the child domains (connected by real or virtual TE 488 links), but the parent domain may also include real nodes and links. 490 The mechanism for building the parent TED is likely to rely heavily 491 on administrative configuration and commercial issues because the 492 network was probably partitioned into domains specifically to address 493 these issues. However, note that in some configurations (for 494 example, collections of small optical domains) a separate instance of 495 a routing protocol (probably an IGP) may be run within the parent 496 domain to advertise the domain interconnectivity. Additionally, 497 since inter-domain TE links can be advertised by the IGPs operating 498 in the child domains, this information could be exported to the 499 parent PCE either by the child PCEs or using a north-bound export 500 mechanism such as BGP-LS [I-D.ietf-idr-ls-distribution]. 502 12. Does H-PCE Solve The Internet? 504 The model described in [RFC6805] introduced a hierarchical 505 relationship between domains. It is applicable to environments with 506 small groups of domains where visibility from the ingress LSRs is 507 limited. Applying the hierarchical PCE model to large groups of 508 domains such as the Internet, is not considered feasible or 509 desirable. 511 This does open up a harder question: how many domains can be handled 512 by an H-PCE system? In other words: what is a small group of 513 domains? The answer is not clear and might be "I know it when I see 514 it." At the moment, a rough guide might be around 20 domains as a 515 maximum. 517 An associated question would be: how many hierarchy levels can be 518 handled by H-PCE? Architecturally, the answer is that there is no 519 limit, but it is hard to construct practical examples where more than 520 two or possibly three layers are needed. 522 13. What are Sticky Resources? 524 When a PCE computes a path it has a reasonable idea that an LSP will 525 be set up and that resources will be allocated within the network. 526 If the arrival rate of computation requests is faster than the LSP 527 setup rate combined with the IGP convergence time, it is quite 528 possible that the PCE will perform its next computation before the 529 TED has been updated to reflect the setup of the previous LSP. This 530 can result in LSP setup failures are there is contention for 531 resources. The likelihood of this problem is particularly high 532 during recovery from network failures when a large number of LSPs 533 might need new paths. 535 A PCE may choose to make a provisional assignment of the resources 536 that would be needed for an LSP, and reduce the available resources 537 in its TED so that the problem is mitigated. Such resources are 538 informally known as "sticky resources". 540 Note that using sticky resources introduces a number of other 541 problems that can make managing the TED difficult. For example: 543 - When the TED is updated as a result of new information from the 544 IGP, how does the PCE know whether the reduction in available 545 resources is due to the successful setup of the LSP for which it 546 is holding sticky resources, or for some other network event (such 547 as the setup of another LSP)? This problem may be particularly 548 evident if there are multiple PCEs that do not synchronize their 549 sticky resources, or if not all LSPs utilize PCE computation. 551 - When LSP setup fails, how are the sticky resources? Since the PCE 552 doesn't know about the failure of the LSP setup, it needs some 553 other mechanism to release them. 555 - What happens if a path computation was made only to investigate the 556 potential for an LSP, but not to actually set one up? 558 - What if the path used by the LSP does not match that provided by 559 the PCE (for example, because the control plane routes around some 560 problem)? 562 Some of these issues can be mitigated by using a Stateful PCE (see 563 Section 14). 565 14. What Is A Stateful PCE For? 567 A Stateless PCE can perform path computations that take into account 568 the existence of other LSPs if the paths of those LSPs are supplied 569 on the computation request. This function can be particularly useful 570 when arranging protection paths so that a working and protection LSP 571 do not share any links or nodes. It can also be used when a group of 572 LSPs are to be reoptimized at the same time in the process known as 573 Global Concurrent Optimization (GCO) [RFC5557] 575 However, this mechanism can quite a burden on the protocol messages 576 especially when large numbers of LSP paths need to be reported. 578 A Stateful PCE maintains a database of LSPs (the LSP-DB) that are 579 active in the network, i.e., have been provisioned such that they use 580 network resources although they might or might not be carrying 581 traffic. This database allows a PCC to refer to an LSP using only 582 its identifier - all other details can be retrieved by the PCE from 583 the LSP-DB. 585 A Stateful PCE can use the LSP-DB for a many other functions, such as 586 balancing the distribution of LSPs in the network. Furthermore, the 587 PCE can correlate LSPs with network resource availability placing new 588 LSPs more cleverly. 590 A Stateful PCE that is also an Active PCE (see Section 17) can 591 respond to changes in network resource availability and predicted 592 demands to reroute LSPs that it knows about. 594 Section 20 offers a brief comparison of the different modes of PCE 595 with reference to stateful and stateless PCE. 597 15. How Does a Stateful PCE Learn LSP State From The Network? 599 The LSP-DB contains information about the LSPs that are active in the 600 network, as mentioned in Section 15. This state information can be 601 constructed by the PCE from information it receives from a number of 602 sources including from provisioning tools and from the network, but 603 however the information is gleaned, a Stateful PCE needs to 604 synchronize its LSP-DB with the state in the network. Just as 605 described in Section 13, the PCE cannot rely on knowledge about 606 previous computations it has made, but must find out the actual LSPs 607 in the network. 609 A simple solution is for all ingress LSRs to report all LSPs to the 610 PCE as they are set up, modified, or torn down. Since PCEP already 611 has the facility to fully describe LSP paths and resources in the 612 protocol messages, this is not a difficult problem, and the LSP State 613 Report (PCRpt) message has been defined for this purpose 614 [I-D.ietf-pce-stateful-pce]. 616 The situation can be more complex, however, if there are ingress LSRs 617 that do not support PCEP, support PCEP but not the PCRpt, or that are 618 unaware of the requirement to report LSPs to the PCE. This might 619 happen if the LSRs are able to compute paths themselves, or if they 620 receive LSP setup instructions with pre-computed paths from an NMS. 622 An alternative approach is to note that any LSR on the path of an LSP 623 can probably see the whole path (through the Record Route object in 624 RSVP-TE signaling [RFC3209]) and knows the bandwidth reserved for the 625 LSP. Thus, any LSR can report the LSP to the PCE, noting that it 626 will not hurt (beyond additional message processing and potential 627 overload of the PCE or the network) for the LSP to be reported 628 multiple times because it is clearly identified. In fact this would 629 also provide a cross-check mechanism. 631 Nevertheless, it is possible that some LSPs will traverse only LSRs 632 that are not aware of the PCE's need to learn LSP state and build an 633 LSP-DB. In these cases, the stateful PCE must either only have 634 limited knowledge of the LSPs in the network or must learn about LSPs 635 through some other mechanism (such as reading the MPLS and GMPLS MIB 636 modules [RFC3812] [RFC4802]. 638 Ultimately, there may be no substitute for all LSRs being aware of 639 Stateful PCEs and able to respond to requests to report all LSPs that 640 they know about. This will allow a Stateful PCE to build its LSP-DB 641 from scratch (which it may need to do at start of day) and to verify 642 its LSP-DB against the network (which may be important if the PCE has 643 suffered some form of outage). 645 16. How Do Redundant Stateful PCEs Synchronize State? 647 It is important that two PCEs operating in a network have similar 648 views of the available resources. That is, they should have the same 649 or substantially similar TEDs. This is easy to achieve either by 650 building the TEDs from the network in the same way, or by one PCE 651 synchronizing its TED to the other PCE using a TED export protocol 652 such as BGP-LS [I-D.ietf-idr-ls-distribution] or NETCONF [RFC6241]. 654 Synchronizing the LSP-DB can be a more complicated issue. As 655 described in Section 15, building the LSP-DB can be an involved 656 process, so it would be best to not have multiple PCEs each trying 657 to build an LSP-DB from the network. However, it is still important 658 that where multiple PCEs operate in the network (either as 659 distributed PCEs, or with one acting as a backup for the other) that 660 the LSP-DBs are kept synchronized. 662 Thus there is likely to be a need for a protocol mechanism for one 663 PCE to update its LSP-DB with that of another PCE. This is no 664 different from any other database synchronization problem and could 665 use existing mechanisms or a new protocol. Note, however, that in 666 the case of distributed PCEs that are also Active PCEs (see Section 667 17), each PCE will be creating entries in its own LSP-DB, so the 668 synchronization of databases must be incremental and bidirectional, 669 not just simply a database dump. 671 It may be helpful to clarify the word "redundant" in the context of 672 this question. One interpretation is that a redundant PCE exists 673 solely as a backup such that it only performs a function in the 674 network in the event of a failure of the primary PCE. This seems 675 like a shocking waste of expensive resources, and it would make more 676 sense for the redundant PCE to take its share of computation load all 677 the time. However, that scenario of two (or more) active PCEs 678 creates exactly the state synchronization issued described above. 680 Various options have been suggested where one PCE serves a set of 681 PCCs as the primary computation server, and only addresses requests 682 from other PCCs in the event of the failure of some other PCE, but 683 this mode of operation still draws questions about the need for 684 synchronized state even in non-failure scenarios if the LSPs that 685 will be computed by the different PCEs may traverse the same network 686 resources. 688 17. What Is An Active PCE? What is a Passive PCE? 690 A Passive PCE is one that only responds to path computation requests. 691 It takes no autonomous actions. A Passive PCE may be stateless or 692 stateful. 694 An Active PCE is one that issues provisioning "recommendations" to 695 the network. These recommendations may be new routes for existing 696 LSPs, or routes for new LSPs. An Active PCE may be stateless or 697 stateful, but in order that it can reroute existing LSPs effectively, 698 it is likely to hold state for at least those LSPs that it will 699 reroute. 701 Many people consider that the PCE, itself, cannot be Active. That 702 is, they hold that the PCE's function is purely to compute paths. In 703 that world-view, the "Active PCE" is actually the combination of a 704 normal, passive PCE and an additional architectural component 705 responsible for issuing commands or recommendations to the network. 706 In some configurations, the Virtual Network Topology Manager (VNTM) 707 discussed in Sections 21 and 22 provides this additional component. 709 Section 20 offers a brief comparison of the different modes of PCE 710 with reference to passive and active PCE. 712 18. What is LSP Delegation? 714 LSP delegation [I-D.ietf-pce-stateful-pce] is the process where a PCC 715 (usually an ingress LSR) passes responsibility for triggering 716 reoptimization or re-routing of an LSP to the PCE. In this case, the 717 PCE would need to be both Stateful and Active. 719 LSP delegation allows an LSP to be set up under the control of the 720 ingress LSR potentially using the services of a PCE. Once the LSP 721 has been set up, the LSR (a PCC) tells the PCE about the LSP by 722 providing details of the path and resources used. It delegates 723 responsibility for the LSP to the PCE so that the PCE can make 724 adjustments to the LSP as dictated by changes to the TED and the 725 policies in force at the PCE. The PCE makes the adjustments by 726 sending a new path to the LSR with the instruction/recommendation 727 that the LSP be re-signalled. 729 Section 20 offers a brief comparison of the different modes of PCE 730 with reference to LSP delegation. 732 19. Is An Active PCE with LSP Delegation Just a Fancy NMS? 734 In many ways the answer here is "yes". But the PCE architecture 735 forms part of a new way of looking at network operation and 736 management. In this new view, the network operation is more dynamic 737 and under the control of software applications without direct 738 intervention from operators. This is not to say that the operator 739 has no say in how their network runs, but it does mean that the 740 operator sets policies (see Section 24) and that new components (such 741 as an Active PCE) are responsible for acting on those policies to 742 dynamically control the network. 744 There is a subtle distinction between an NMS and an Active PCE with 745 LSP delegation. An NMS is in control of the LSPs in the network and 746 can request that they are set up, modified, or torn down. An Active 747 PCE can only make suggestions about LSPs that have been delegated to 748 the PCE by a PCC. 750 For more details, see the discussion of an architecture for 751 Application-Based Network Operation (ABNO) in 752 [I-D.farrkingel-pce-abno-architecture] 754 20. Comparison of Stateless and Stateful PCE 756 Table 1 shows a comparison of stateless and stateful PCEs to show 757 how they how might be instantiated as passive or active PCEs with 758 or without control of LSPs. The terms used relate to the concepts 759 introduced in the previous sections. 761 | Stateless | Stateful | 762 ------------------------+-----------+-----------+ 763 Passive | 1 | 2 | 764 Active delegated LSPs | 3 | 4 | 765 Active suggest new LSPs | 5 | 6 | 766 Active instantiate LSPs | 7 | 7 | 768 Notes: 769 1. Passive is the normal mode for stateless PCE. 770 2. Passive mode may have value for more complex environments and 771 for computing protected services. 772 3. Delegation of LSPs to a stateless PCE is relatively pointless, 773 but can add value at moment of delegation. 774 4. This is the normal mode for stateful PCE. 775 5. There is only marginal potential for a stateless PCE to 776 recommend new LSPs because without a view of existing LSPs, the 777 PCE cannot determine when new ones might be needed. 778 6. This mode has potential for recommending new LSPs. 779 7. These modes are out of scope for PCE as currently described. 781 Table 1 : Comparing Stateless and Stateful PCE 783 21. How Does a PCE Work With A Virtual Network Topology? 785 A Virtual Network Topology (VNT) is described in [RFC4397] as a set 786 of Hierarchical LSPs that is created (or could be created) in a 787 particular network layer to provide network flexibility (data links) 788 in other layers. Thus the TE topology of a network can be 789 constructed from TE links that are simply data links, from TE links 790 that are supported by LSPs in another layer or the network, or from 791 TE links that could be supported by LSPs ("potential LSPs") that 792 would be set up on demand in another network layer. This third type 793 of TE link is known as a Virtual TE Link in [RFC5212]. 795 [RFC5212] also gives a more detailed explanation of a VNT, and it 796 should be noted that the network topology in a packet network could 797 be supported by LSPs in a number of different lower-layer networks. 798 For example, the TE links in the packet network could be achieved by 799 connections (LSPs) in underlying SONET/SDH and photonic networks. 800 Furthermore, because of the hierarchical nature of MPLS, the TE links 801 in a packet network may be achieved by setting up packet LSPs in the 802 same packet network. 804 A PCE obviously works with the TED that contains information about 805 the TE links in the network. Those links may be already established 806 or may be virtual TE links. In a simple TED, there is no distinction 807 between the types of TE link, however, there may be advantages to 808 selecting TE links that are based on real data links over those based 809 on dynamic LSPs in lower layers because the data links may be more 810 stable. Conversely, the TE links based on dynamic LSPs may be able 811 to be repaired dynamically giving better resilience. Similarly, a 812 PCE may prefer to select a TE link that is supported by a data link 813 or existing LSP in preference to using a virtual TE link because the 814 latter may need to be set up (taking time) and the setup could 815 potentially fail. Thus, a PCE might want to employ additional 816 metrics or indicators to help it view the TED and select the right 817 path for LSPs. 819 If a PCE uses a virtual TE link, then some action will be needed to 820 establish the LSP that supports that link. Some models (such as that 821 in [RFC5212]) trigger the setup of the lower layer LSPs on-demand 822 during the signaling of the upper layer LSP (i.e., when the upper 823 layer comes to use the virtual TE link, the upper layer signaling is 824 paused and the lower layer LSP is established). Another view, 825 described in [RFC5623], is that when the PCE computes a path that 826 will use a virtual TE link, it should trigger the setup of the lower 827 layer LSP to properly create the TE link so that the path it returns 828 will be sure to be viable. This latter mode of operation can be 829 extended to allow the PCE to spot the need for additional TE links 830 and to trigger LSPs in lower layers in order to create those links. 832 Of course, such "interference" in a lower layer network by a PCE 833 responsible for a higher layer network depends heavily on policy. In 834 order to make a clean architectural separation and to facilitate 835 proper policy control, [RFC5623] introduces the Virtual Network 836 Topology Manager (VNTM) as a functional element that manages and 837 controls the VNT. [RFC5623] notes that the PCE and VNT Manager are 838 distinct functional elements that may or may not be collocated. 839 indeed, it should be noted that there will be a PCE for the upper 840 layer, and a PCE for each lower layer, and a VNTM responsible for 841 coordinating between the PCEs and for triggering LSP setup in the 842 lower layers. Therefore, the combination of all of the PCEs and the 843 VNTM produces functionally similar to an Active, multi-layer PCE. 845 22. How Does PCE Communicate With VNTM 847 The VNTM described in Section 21 and [RFC5623] has several interfaces 848 (see also [I-D.farrkingel-pce-abno-architecture]). 850 - The VNTM will need to learn about resource shortages and the need 851 for additional TE links from the upper layer PCE in order that it 852 can make policy-based decisions to determine whether and which LSPs 853 to set up to create new TE links. This interface is currently 854 undefined. 856 - The VNTM will need to coordinate with the PCEs in the lower layers, 857 but this is simply a normal use of PCEP. 859 - The VNTM will need to issue provisioning requests/commands to the 860 lower layer networks to cause LSPs to be set up to act as TE links 861 in the higher layer network. A number of potential protocols exist 862 for this function as described in [I-D.farrkingel-pce-abno- 863 architecture], but it should be noted that it makes a lot of sense 864 for this interface to be the same as that used by an Active PCE 865 when providing paths to the network. 867 23. How Does Service Scheduling and Calendering Work? 869 LSP scheduling or calendering is a process where LSPs are planned 870 ahead of time, and only set up when needed. The challenge here is to 871 ensure that the resources needed by LSP and that were available when 872 the LSP's path was computed are still available when the LSP needs to 873 be set up. This needs to be achieved using a mechanism that allows 874 those resources to be used in the mean time. 876 Previous discussion of this topic have suggested that LSPs should be 877 pre-signaled so that each LSR along the path could make a "temporal 878 reservation" of resources. But this approach can become very 879 complicated. 881 Conversely, a centralized database of resources and LSPs such as 882 maintained by a Stateful PCE can be enhanced with a time-based 883 booking system. If the PCE is also Active, then when the time comes 884 for the LSP to be set up (or later, when it is to be torn down) the 885 PCE can control the network. 887 It should be noted that in a busy network (and why would one bother 888 with a scheduling service in a network that is not busy?) the 889 computation algorithm can be quite complex. It may also be necessary 890 to reposition existing LSPs as new bookings arrive. Furthermore, the 891 booking database that contains both the scheduled LSPs and their 892 impact on the network resources can become quite large. A very 893 important factor in the size of the active database (depending on 894 implementation) may be the timeslices that are available in the 895 calendering process. 897 24. Where Does Policy Fit In? 899 Policy is critical to the operation of a network. In a PCE context 900 it provides control and management of how a PCE selects network 901 resources for use by different PCEs. 903 [RFC5394] introduced the concept of PCE-based policy-enabled path 904 computation. It is based on the Policy Core Information Model (PCIM) 905 [RFC3060] as extended by [RFC3460], and provides a framework for 906 supporting path computation policy. 908 Policy enters into all aspect of the use of a PCE starting from the 909 very decision to use a PCE to delegate computation function from the 910 LSRs. 912 - Each PCC must select which computations will be delegated to a PCE. 914 - Each PCC must select which PCEs it will use. 916 - Each PCE must determine which PCCs are allowed to use its services 917 and for what computations. 919 - The PCE must determine how to collect the information in its TED, 920 who to trust for that information, and how to refresh/update the 921 information. 923 - Each PCE must determine which objective functions and which 924 algorithms to apply. 926 - Inter-domain (and particularly H-PCE) computations will need to be 927 sensitive to commercial and reliability information about domains 928 and their interactions. 930 - Stateful PCEs must determine what state to hold, when to refresh 931 it, and which network elements to trust for the supply of the state 932 information. 934 - An Active PCE must have a policy relationship with its LSRs to 935 determine which LSPs can be modified or triggered, and what LSP 936 delegation is supported. 938 - Multi-layer interactions (especially those using virtual or dynamic 939 TE links) must provide policy control to stop server layer LSPs 940 (which are fat and expensive by definition) from being set up on a 941 whim to address micro-flows or speculative computations in higher 942 layers. 944 - A PCE may supply, along with a computed path, policy information 945 that should be signaled during LSP setup for use by the LSRs along 946 the path. 948 It may be seen, therefore, that a PCE is substantially a policy 949 engine that computes paths. It should also be noted that the work of 950 the PCE can be substantially controlled by configured policy in a way 951 that will reduce the options available to the PCC, but also 952 significantly reduce the need for the use of optional parameters in 953 the PCEP messages. 955 25. Does PCE Play a Role in SDN? 957 Software Defined Networking is the latest shiny thing in networking. 958 It refers to a separation between the control elements and the 959 forwarding components so that software running in a centralized 960 system called a controller, can act to program the devices in the 961 network to act in specific ways. 963 A required element in an SDN architecture is a component that plans 964 how the network resources will be used and how the devices will be 965 programmed. It is possible to view this component as performing 966 specific computations to place flows within the network given 967 knowledge of the availability of network resources, how other 968 forwarding devices are programmed, and the way that other flows are 969 routed. This, it may be concluded, is the same function that a PCE 970 might offer in a network operated using a dynamic control plane. 971 Thus, a PCE could form part of the infrastructure for an SDN. 973 A view of how PCE integrates into a wider network control system 974 including SDN is presented in [I-D.farrkingel-pce-abno-architecture]. 976 26. What is a Path Computation Elephant? 978 A Path Computation Elephant is an attribute of a long document on 979 the details of the PCE architecture. It serves two purposes: the 980 first being to check whether the reader is still awake; the second 981 being to remember things for the more relaxed reader because, as is 982 well known in pachyderm circles, Elephants are stateful and never 983 forget. 985 27. Security Considerations 987 This informational document does not define any new protocol elements 988 or mechanism. As such, it does not introduce any new security 989 issues. 991 It is worth noting that PCEP operates over TCP. An analysis of the 992 security issues for routing protocols that use TCP (including PCEP) 993 is provided in [I-D.ietf-karp-routing-tcp-analysis]. 995 28. IANA Considerations 997 This document makes no requests for IANA Action. 999 29. Acknowledgements 1001 Thanks for constructive comments go to Fatai Zhang, Oscar Gonzalez de 1002 Dios, Xian Zhang, Cyril Margaria, Denis Ovsienko, and Ina Minei. 1004 This work was supported in part by the FP-7 IDEALIST project under 1005 grant agreement number 317999. 1007 30. References 1009 30.1. Normative References 1011 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1012 Computation Element (PCE)-Based Architecture", RFC 1013 4655, August 2006. 1015 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 1016 Computation Element (PCE) Communication Protocol 1017 (PCEP)", RFC 5440, March 2009. 1019 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 1020 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 1021 Traffic Engineering", RFC 5623, September 2009. 1023 [RFC6805] King, D. and A. Farrel, "The Application of the Path 1024 Computation Element Architecture to the Determination of 1025 a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1026 November 2012. 1028 30.2. Informative References 1030 [I-D.farrkingel-pce-abno-architecture] 1031 King, D., and Farrel, A., "A PCE-based Architecture for 1032 Application-based Network Operations", 1033 draft-farrkingel-pce-abno-architecture, work in progress. 1035 [I-D.ietf-alto-server-discovery] 1036 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 1037 H. Song, "ALTO Server Discovery", 1038 draft-ietf-alto-server-discovery, work in progress. 1040 [I-D.ietf-idr-ls-distribution] 1041 Gredler, H., Medved, J., Previdi, S., Farrel, A., and 1042 Ray, S., "North-Bound Distribution of Link-State and TE 1043 Information using BGP", draft-ietf-idr-ls-distribution, 1044 work in progress. 1046 [I-D.ietf-karp-routing-tcp-analysis] 1047 Jethanandani, M., Patel, K., and Zheng, L., "Analysis of 1048 BGP, LDP, PCEP and MSDP Issues According to KARP Design 1049 Guide", draft-ietf-karp-routing-tcp-analysis, work in 1050 progress. 1052 [I-D.ietf-pce-stateful-pce] 1053 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 1054 Extensions for Stateful PCE", 1055 draft-ietf-pce-stateful-pce, work in progress. 1057 [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. 1058 Westerinen, "Policy Core Information Model -- Version 1 1059 Specification", RFC 3060, February 2001. 1061 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V, 1062 and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP 1063 Tunnels", RFC 3209, December 2001 1065 [RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) 1066 Extensions", RFC 3460, January 2003. 1068 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 1069 Engineering (TE) Extensions to OSPF Version 2", RFC 1070 3630, September 2003. 1072 [RFC3812] Srinivasan, C., Viswanathan, A., and Nadeau, T., 1073 "Multiprotocol Label Switching (MPLS) Traffic Engineering 1074 (TE) Management Information Base (MIB)", RFC 3812, June 1075 2004. 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 [RFC4397] Bryskin, I., and Farrel, A. "A Lexicography for the 1083 Interpretation of Generalized Multiprotocol Label 1084 Switching (GMPLS) Terminology within the Context of the 1085 ITU-T's Automatically Switched Optical Network (ASON) 1086 Architecture", RFC 4397, February 2006. 1088 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element 1089 (PCE) Communication Protocol Generic Requirements", 1090 RFC 4657, September 2006. 1092 [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation 1093 Element (PCE) Discovery", RFC 4674, October 2006. 1095 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework 1096 for Inter-Domain Multiprotocol Label Switching Traffic 1097 Engineering", RFC 4726, November 2006. 1099 [RFC4802] Nadeau, T., and Farrel, A., "Generalized Multiprotocol 1100 Label Switching (GMPLS) Traffic Engineering Management 1101 Information Base", RFC 4802, February 2007. 1103 [RFC4848] Daigle, L., "Domain-Based Application Service Location 1104 Using URIs and the Dynamic Delegation Discovery Service 1105 (DDDS)", RFC 4848, April 2007 1107 [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS 1108 (GMPLS) RSVP-TE Signaling Extensions in Support of 1109 Calls", RFC 4974, August 2007. 1111 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 1112 Per-Domain Path Computation Method for Establishing 1113 Inter-Domain Traffic Engineering (TE) Label Switched 1114 Paths (LSPs)", RFC 5152, February 2008. 1116 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1117 Zhang, "OSPF Protocol Extensions for Path Computation 1118 Element (PCE) Discovery", RFC 5088, January 2008. 1120 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1121 Zhang, "IS-IS Protocol Extensions for Path Computation 1122 Element (PCE) Discovery", RFC 5089, January 2008. 1124 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 1125 M., and Brungard, D., "Requirements for GMPLS-Based 1126 Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 1127 5212, July 2008. 1129 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1130 Engineering", RFC 5305, October 2008. 1132 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS 1133 Extensions in Support of Generalized Multi-Protocol 1134 Label Switching (GMPLS)", RFC 5307, 1135 October 2008. 1137 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 1138 "Policy-Enabled Path Computation Framework", RFC 5394, 1139 December 2008. 1141 [RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based 1142 Computation (BRPC) procedure to compute shortest inter- 1143 domain Traffic Engineering Label Switched Paths", RFC 1144 5441, April 2009. 1146 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 1147 Computation Element Communication Protocol (PCEP) 1148 Requirements and Protocol Extensions in Support of Global 1149 Concurrent Optimization", RFC 5557, July 2009. 1151 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, 1152 Z., and J. Meuric, "Extensions to the Path 1153 Computation Element Communication Protocol (PCEP) 1154 for Point-to-Multipoint Traffic Engineering Label 1155 Switched Paths", RFC 6006, September 2010. 1157 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and Bierman, 1158 A., "Network Configuration Protocol (NETCONF)", RFC 6241, 1159 June 2011. 1161 Authors' Addresses 1163 Adrian Farrel 1164 Juniper Networks 1165 EMail: adrian@olddog.co.uk 1167 Daniel King 1168 Old Dog Consulting 1169 EMail: daniel@olddog.co.uk