idnits 2.17.1 draft-ietf-pce-questions-08.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 (6 October 2014) is 3491 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 A. Farrel 2 Internet Draft Juniper Networks 3 Category: Informational D. King 4 Expires: 6 April 2015 Old Dog Consulting 5 6 October 2014 7 Unanswered Questions in the Path Computation Element Architecture 8 draft-ietf-pce-questions-08.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 (VNTM) in 15 RFC 5623, and generalized to Hierarchical PCE (H-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) 2014 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? ............................... 10 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? ................ 11 78 12. Does H-PCE Solve The Internet? .............................. 11 79 13. What are Sticky Resources? .................................. 12 80 14. What Is A Stateful PCE For? ................................. 13 81 15. How Is the LSP-DB Built? .................................... 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? ..................................... 16 85 19. Is An Active PCE with LSP Delegation Just a Fancy NMS? ..... 16 86 20. Comparison of Stateless and Stateful PCE .................... 17 87 21. How Does a PCE Work With A Virtual Network Topology? ........ 18 88 22. How Does PCE Communicate With VNTM .......................... 19 89 23. How Does Service Scheduling and Calendering Work? ........... 19 90 24. Where Does Policy Fit In? ................................... 20 91 25. Does PCE Play a Role in SDN? ................................ 21 92 26. Security Considerations ..................................... 22 93 27. IANA Considerations ......................................... 23 94 28. Acknowledgements ............................................ 23 95 29. References .................................................. 23 96 29.1. Normative References ...................................... 23 97 29.2. Informative References .................................... 24 98 Authors' Addresses ............................................... 27 100 1. Introduction 102 Over the years since the architecture for the Path Computation 103 Element (PCE) was documented in [RFC4655] many new people have 104 become involved in the work of the PCE working group and wish to use 105 or understand the PCE architecture. These people often missed out on 106 early discussions within the working group and are unfamiliar with 107 questions that were raised during the development of the 108 documentation. 110 Furthermore, the base architecture has been extended to handle other 111 situations and requirements: the architecture was extended for multi- 112 layer networking with the introduction of the Virtual Network 113 Topology Manager (VNTM) [RFC5623] and was generalized to include 114 Hierarchical PCE (H-PCE) [RFC6805]. 116 These three architectural views of PCE deliberately leave some key 117 questions unanswered especially with respect to the interactions 118 between architectural components. This document draws out those 119 questions and discusses them in an architectural context with 120 reference to other architectural components, existing protocols, and 121 recent IETF work efforts. 123 This document does not update the architecture documents and does not 124 define how protocols or components must be used. It does, however, 125 suggest how the architectural components might be combined to provide 126 advanced PCE function. 128 1.1. Terminology 130 Readers are assumed to be thoroughly familiar with terminology 131 defined in [RFC4655], [RFC4726], [RFC5440], [RFC5623], and 132 [RFC6805]. More information about terms related to stateful PCE 133 can be found in [I-D.ietf-pce-stateful-pce]. 135 Throughout this document the term "area" is used to refer equally to 136 an OSPF area and an IS-IS level. It is assumed that the reader is 137 able to map the small differences between these two use cases. 139 2. What Is Topology Information? 141 [RFC4655] defines that a PCE performs path computations based on a 142 view of the available network resources and network topology. This 143 information is collected into a Traffic Engineering Database (TED). 145 However, [RFC4655] does not provide a detailed description of what 146 information is present in the TED. It simply says that the TED 147 "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 - switching capabilities 167 - limited node cross-connect capabilities 169 Additionally, an important information element for computing paths, 170 especially for protected services, is the Shared Risk Group (SRG). 171 This is an indication of resources in the TED that have a common 172 risk of failure. That is, they have a shared risk of failure from a 173 single event. 175 In short, the TED needs to contain as much information as is needed 176 to satisfy the path computation requests subject to the objective 177 functions (OFs). This, in itself, may not be a trivial issue in some 178 network technologies. For example, in some optical networks, the 179 path computation for a new Label Switched Path (LSP) may need to 180 consider the impact that turning up a new laser would have on the 181 optical signals already being carried by fibers. It may be possible 182 to abstract this information as parameters of the optical links and 183 nodes in the TED, but it may be easier to capture this information 184 through a database of existing LSPs (see Sections 14 and 15). 186 3. How Is Topology Information Gathered? 188 Clearly, the information in the TED discussed in Section 2 needs to 189 be gathered and maintained somehow. [RFC4655] simply says "The TED 190 may be fed by Interior Gateway Protocol (IGP) extensions or 191 potentially by other means." In this context, "fed" means built and 192 maintained. 194 Thus, one way that the PCE may construct its TED is by participating 195 in the IGP running in the network. In an MPLS-TE network, this would 196 depend on OSPF-TE [RFC3630] and IS-IS-TE [RFC5305]. In a GMPLS 197 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 offers the 210 alternative of leveraging an in-network BGP speaker (such as an 211 Autonomous System Border Router or a Route Reflector) that already 212 has to participate in the IGP and that is specifically designed to 213 apply filters to IGP advertisements. In this usage, the BGP speaker 214 filters and aggregates topology information according to configured 215 policy before advertising it "north-bound" to the PCE to update the 216 TED. The PCE implementation has to support just a simplified subset 217 of BGP rather than two full IGPs. 219 But BGP might not be convenient in all networks (for example, where 220 BGP is not run, such as in an optical network or a BGP-free core). 221 Furthermore, not all relevant information is made available through 222 standard TE extensions to the IGPs. In these cases, the TED must be 223 built or supplemented from other sources such as the Network 224 Management System (NMS), inventory management systems, and directly 225 configured data. 227 It has also been proposed that the PCE Communication Protocol (PCEP) 228 [RFC5440] could be extended to serve as an information collection 229 protocol to supply information from network devices to a PCE. The 230 logic is that the network devices may already speak PCEP and so the 231 protocol could easily be used to report details about the resources 232 and state in the network, including the LSP state discussed in 233 Sections 14 and 15. 235 Note that a PCE that is responsible for more than one domain must, of 236 course, collect TE information from each domain to build its TED or 237 TEDs. 239 4. How Do I Find My PCE? 241 A Path Computation Client (PCC) needs to know the identity / location 242 of a PCE in order to be able to make computation requests. This is 243 because PCEP is a transaction-based protocol carried over TCP, and 244 the architectural decision made in Section 6.4 of RFC 4655 required 245 targeted PCC-PCE communications. 247 As described in [RFC4655], a PCC could be configured with the 248 knowledge of the IP address of its PCE. This is a relatively light- 249 weight option considering all of the other configuration that a 250 router may require, but it is open to configuration errors, and does 251 not meet the need for minimal-configuration operation. Furthermore 252 configuration communication with multiple PCEs could become onerous, 253 while handling changes in PCE identities and coping with failure 254 events would be an issue for a configured system. 256 [RFC4655] offer the possibility that PCEs advertise themselves in the 257 IGP, and this requirement is developed in [RFC4674] and made possible 258 in OSPF and IS-IS through [RFC5088] and [RFC5089]. In general these 259 mechanisms should be sufficient for PCCs in a network where an IGP is 260 used and where the PCE participates in the IGP. 262 Note, however, that not all PCEs will participate in the IGP (see 263 Section 3). In these cases, assuming configuration is not 264 appropriate as a discovery mechanism, some other server 265 announcement/discovery function may be needed, such as DNS [RFC4848] 266 as used for discovery of the Local Location Information Server (LIS) 267 [RFC5986] and in the Application-Layer Traffic Optimization (ALTO) 268 discovery function [I-D.ietf-alto-server-discovery]. 270 5. How Do I Select Between PCEs? 272 When more than one PCE is discovered or configured, a PCC will need 273 to select which PCE to use. It may make this decision on any 274 arbitrary algorithm (for example, first-listed, or round-robin), but 275 it may also be the case that different PCEs have different 276 capabilities and path computation scope, in which case the PCC will 277 want to select the PCE most likely to be able to satisfy any one 278 request. The first requirement, of course, is that the PCE can 279 compute paths for the relevant domain. 281 PCE advertisement in OSPF or IS-IS per [RFC5088] and [RFC5089] allows 282 a PCE to announce its capabilities as required in [RFC4657]. A PCC 283 can select between PCEs based on the capabilities that they have 284 announced. However, these capabilities are expressed as flags in the 285 PCE advertisement so only the core capabilities are presented, and 286 there is not scope for including detailed information (such as 287 support for specific objective functions) in the advertisement. 289 Additional and more complex PCE capabilities, including the 290 capability to perform point-to-multipoint (P2MP) path computations 291 [RFC6006], may be announced by the PCE as optional PCEP 292 type-length-value (TLV) Type Indicators in the Open message described 293 in [RFC5440]. This mechanism is not limited to just a set of 294 flags, and detailed capability information may be presented in 295 sub-TLVs. 297 Note that this exchange of PCE capabilities is in the form of an 298 announcement, not a negotiation. That is, a PCC that wants specific 299 function from a PCE must examine the advertised capabilities and 300 select which PCE to use for a specific request. There is no scope 301 for a PCC to request a PCE to support features or functions that it 302 does not offer or announce. 304 A PCC may also vary which PCE it uses according to congestion 305 information reported by the PCEs using the Notification Object and 306 Notification Type [RFC5440] . Note that in a heavily overloaded PCE 307 system, reports from one PCE that it is overloaded may simply 308 result in all PCCs switching to another PCE which will, itself, 309 immediately become overloaded. Thus, PCCs should exercise a 310 certain amount of discretion and queueing theory before selecting 311 a PCE purely based on reported load. 313 Note that a PCC could send all requests to all PCEs that it knows 314 about. It can then select between the results, perhaps choosing the 315 first result it receives, but this approach is very likely to 316 overload all the PCEs in the network considering that one of the 317 reasons for multiple PCEs is to share the load. 319 6. How Do Redundant PCEs Synchronize TEDs? 321 A network may have more than one PCE as discussed in the previous 322 sections. These PCEs may provide redundancy for load-sharing, 323 resilience, or partitioning of computation features. 325 In order to achieve some consistency between the results of different 326 PCEs, it is desirable that they operate on the same TE information. 328 The TED reflects the actual state of the network and is not a 329 resource reservation or booking scheme. Therefore, a PCE-based 330 system does not prevent competition for network resources during the 331 provisioning phase, although a process of "sticky resources" that are 332 temporarily reduced in the TED after a computation may be applied 333 purely as a local implementation feature. 335 One option for ensuring that multiple PCEs use the same TE 336 information is simply to have the PCEs driven from the same TED. 337 This could be achieved in implementations by utilizing a shared 338 database, but it is unlikely to be efficient. 340 More likely is that each PCE is responsible for building its own TED 341 independently using the techniques described in Section 3. If the 342 PCEs participate in the IGP it is likely that they will attach at 343 different points in the network and so there may be minor and 344 temporary inconsistencies between their TEDs caused by IGP 345 convergence issues. If the PCEs gather TE information via BGP-LS 346 [I-D.ietf-idr-ls-distribution] from different sources, the same 347 inconsistencies may arise, but if the PCEs attach to the same BGP 348 speaker it may be possible to achieve consistency between TEDs modulo 349 the BGP-LS process itself. 351 A final option is to provide an explicit synchronization process 352 between the TED of a "master" PCE and the TEDs of other PCEs. Such a 353 process could be achieved using BGP-LS or a database synchronization 354 protocol (which would allow check-pointing and sequential updates). 355 This approach is fraught with issues around selection of the master 356 PCE and handling failures. It is, in fact, a mirrored database 357 scenario: a problem that is well known and the subject of plenty of 358 work. 360 Noting that the provisioning protocols such as RSVP-TE [RFC3209] 361 already handle contention for resources, that the differences between 362 TEDs are likely to be relatively small with moderate arrival rates 363 for new services, and that contention in all but the most busy 364 networks is relatively unlikely, there may be no value in any attempt 365 to synchronize TEDs between PCEs. 367 However, see Section 16 for a discussion of synchronizing other state 368 between redundant PCEs. 370 7. Where Is the Destination? 372 Path computation provides an end-to-end path between a source and a 373 destination. If the destination lies in the source domain, then its 374 location will be known to the PCE and there are no issues to be 375 solved. However, in a multi-domain system a path must be found to a 376 remote domain that contains the destination, and that can only be 377 achieved by knowledge of the location of the destination or at least 378 knowing the next domain in the path toward the domain that contains 379 the destination. 381 The simplest solution here is achieved when a PCE has visibility into 382 multiple domains. Such may be the case in a multi-area network where 383 the PCE is aware of the contents of all of the IGP areas. This 384 approach is only likely to be appropriate where the number of nodes 385 is manageable, and is unlikely to extend over administrative 386 boundaries. 388 The per-domain path computation method for establishing inter-domain 389 traffic engineering LSPs [RFC5152] simply requires a PCE to compute a 390 path to the next domain toward the destination. As the LSP setup 391 (through signaling) progresses domain by domain, the Label Switching 392 Router (LSR) at the entry point to each domain requests its local PCE 393 to compute the next segment of the path, that is from that LSR to the 394 next domain in the sequence toward the destination. Thus, it is not 395 necessary for any PCE (except the last) to know in which domain the 396 destination exists. But, in this approach, each PCE must somehow 397 determine the next domain toward the destination, and it is not 398 obvious how this is achieved. 400 [RFC5152] suggests that in an IP/MPLS network it is good enough to 401 leverage the IP reachability information distributed by BGP and 402 assume that TE reachability can follow the same Autonomous System 403 (AS) path. This approach might not guarantee the optimal TE path 404 and, of course, might result in no path being found in degenerate 405 cases. Furthermore, in many network technologies (such as optical 406 networks operated by GMPLS) there may be limited or no end-to-end IP 407 connectivity. 409 The Backward Recursive PCE-based Computation (BRPC) procedure 410 [RFC5441] is able to achieve a more optimal end-to-end path than 411 the per-domain method, but depends on the knowledge of both the 412 domain in which the destination is located and the sequence of 413 domains toward the destination. This information is described in 414 [RFC5441] as being known a priori. Clearly, however, information is 415 not always known a priori, and it may be hard for the PCE that serves 416 the source PCC to discover the necessary details. While there are 417 several approaches to solving the question of establishing the domain 418 sequence (for example, BRPC trial and error or Hierarchical PCE 419 [RFC6805]) none of them addresses the issue of determining where the 420 destination lies. 422 One argument that is often made is that an end-to-end connection 423 expressed as an LSP is a feature of a service agreement between 424 source and destination. If that is the case, it is argued, it stands 425 to reason that the location of the destination must be known to the 426 source node in the same way that the source has determined the IP 427 address of the destination. Presumably this would be through a 428 commercial process or an administrative protocol. 430 [RFC4974] introduced the concept of Calls and Connections for LSPs. A 431 Call does not provide the actual connectivity for transmitting user 432 traffic, but builds a relationship that will allow subsequent 433 Connections to be made. A Call might be considered an agreement to 434 support an end-to-end LSP that is made between the endpoint nodes. 435 Call messages are sent and routed as normal IP messages, so the 436 sender does not need to know the location of the destination. 438 Furthermore, Call requests are responded, and the Call Response can 439 carry information (such as the identity of the domain containing the 440 destination) for use by Call initiator. Thus, the use of GMPLS Calls 441 might provide a mechanism to discover destination's location. 443 8. Who Runs Or Owns a Parent PCE? 445 A Parent PCE [RFC6805] is responsible for selecting inter-domain path 446 by coordinating with child PCEs and maintaining a domain topology 447 map. 449 In the case of multi-domains (e.g., IGP areas or multiple ASes) 450 within a single service provider network, the management 451 responsibility for the parent PCE would most likely be handled by 452 the service provider. 454 In the case of multiple ASes within different service provider 455 networks, it may be necessary for a third party to manage the parent 456 PCEs according to commercial and policy agreements from each of the 457 participating service providers. Note that the H-PCE architecture 458 does not require disclosure of internals of a child domain to the 459 parent PCE. Thus, there is ample scope for a parent PCE to be run by 460 one of the connected service providers or by a third party without 461 compromising commercial issues. In fact, each service provider could 462 run its own parent PCE while allowing its child PCEs to be contacted 463 by outsider parent PCEs according to configured policy and security. 465 9. How Do I Find My Parent PCE? 467 [RFC6805] specifies that a child PCE must be configured with the 468 address of its parent PCE in order for it to interact with its 469 parent PCE. There is no scope for parent PCEs to advertise their 470 presence, however there is potential for directory systems (such as 471 DNS [RFC4848] as used in the ALTO discovery function 472 [I-D.ietf-alto-server-discovery]) to be used as described in Section 473 4. 475 Note that according to [RFC6805] the child PCE must also be 476 authorized to peer with the parent PCE. This is discussed from the 477 viewpoint of the parent PCE in Section 10. The child PCE may need to 478 participate in a key distribution protocol in order to properly 479 authenticate its identity to the parent PCE. 481 10. How Do I Find My Child PCEs? 483 Within the hierarchical PCE framework [RFC6805] the parent PCE must 484 only accept path computation requests from authorized child PCEs. 485 If a parent PCE receives a request from an unauthorized child PCE, 486 the request should be dropped. 488 This requires a parent PCE to be configured with the identities and 489 security credentials of all of its child PCEs, or there must be some 490 form of shared secret that allows an unknown child PCE to be 491 authorized by the parent PCE. 493 11. How Is The Parent PCE Domain Topology Built? 495 The parent PCE maintains a domain topology map of the child domains 496 and their interconnectivity. This map does not include any 497 visibility into the child domains. Where inter-domain connectivity 498 is provided by TE links, the capabilities of those links may also be 499 known to the parent PCE. 501 The parent PCE maintains a TED for the parent domain in the same way 502 that any PCE does. The nodes in the parent domain will be 503 abstractions of the child domains (connected by real or virtual TE 504 links), but the parent domain may also include real nodes and links. 506 The mechanism for building the parent TED is likely to rely heavily 507 on administrative configuration and commercial issues because the 508 network was probably partitioned into domains specifically to address 509 these issues. However, note that in some configurations (for 510 example, collections of small optical domains) a separate instance of 511 a routing protocol (probably an IGP) may be run within the parent 512 domain to advertise the domain interconnectivity. Additionally, 513 since inter-domain TE links can be advertised by the IGPs operating 514 in the child domains, this information could be exported to the 515 parent PCE either by the child PCEs or using a north-bound export 516 mechanism such as BGP-LS [I-D.ietf-idr-ls-distribution]. 518 12. Does H-PCE Solve The Internet? 520 The model described in [RFC6805] introduced a hierarchical 521 relationship between domains. It is applicable to environments with 522 small groups of domains where visibility from the ingress LSRs is 523 limited. Applying the hierarchical PCE model to large groups of 524 domains such as the Internet, is not considered feasible or 525 desirable. 527 This does open up a harder question: how many domains can be handled 528 by an H-PCE system? In other words: what is a small group of 529 domains? The answer is not clear and might be "I know it when I see 530 it." At the moment, a rough guide might be around 20 domains as a 531 maximum. 533 An associated question would be: how many hierarchy levels can be 534 handled by H-PCE? Architecturally, the answer is that there is no 535 limit, but it is hard to construct practical examples where more than 536 two or possibly three levels are needed. 538 13. What are Sticky Resources? 540 When a PCE computes a path it has a reasonable idea that an LSP will 541 be set up and that resources will be allocated within the network. 542 If the arrival rate of computation requests is faster than the LSP 543 setup rate combined with the IGP convergence time, it is quite 544 possible that the PCE will perform its next computation before the 545 TED has been updated to reflect the setup of the previous LSP. This 546 can result in LSP setup failures if there is contention for 547 resources. The likelihood of this problem is particularly high 548 during recovery from network failures when a large number of LSPs 549 might need new paths. 551 A PCE may choose to make a provisional assignment of the resources 552 that would be needed for an LSP, and reduce the available resources 553 in its TED so that the problem is mitigated. Such resources are 554 informally known as "sticky resources". 556 Note that using sticky resources introduces a number of other 557 problems that can make managing the TED difficult. For example: 559 - When the TED is updated as a result of new information from the 560 IGP, how does the PCE know whether the reduction in available 561 resources is due to the successful setup of the LSP for which it 562 is holding sticky resources, or for some other network event (such 563 as the setup of another LSP)? This problem may be particularly 564 evident if there are multiple PCEs that do not synchronize their 565 sticky resources, or if not all LSPs utilize PCE computation. 567 - When LSP setup fails, how are the sticky resources released? Since 568 the PCE doesn't know about the failure of the LSP setup, it needs 569 some other mechanism to release them. 571 - What happens if a path computation was made only to investigate the 572 potential for an LSP, but not to actually set one up? 574 - What if the path used by the LSP does not match that provided by 575 the PCE (for example, because the control plane routes around some 576 problem)? 578 Some of these issues can be mitigated by using a Stateful PCE (see 579 Section 14) or by timers. 581 14. What Is A Stateful PCE For? 583 A Stateless PCE can perform path computations that take into account 584 the existence of other LSPs if the paths of those LSPs are supplied 585 on the computation request. This function can be particularly useful 586 when arranging protection paths so that a working and protection LSP 587 do not share any links or nodes. It can also be used when a group of 588 LSPs are to be reoptimized at the same time in the process known as 589 Global Concurrent Optimization (GCO) [RFC5557] 591 However, this mechanism can be quite a burden on the protocol 592 messages especially when large numbers of LSP paths need to be 593 reported. 595 A Stateful PCE [I-D.ietf-pce-stateful-pce] maintains a database of 596 LSPs (the LSP-DB) that are active in the network, i.e., have been 597 provisioned such that they use network resources although they might 598 or might not be carrying traffic. This database allows a PCC to 599 refer to an LSP using only its identifier - all other details can be 600 retrieved by the PCE from the LSP-DB. 602 A Stateful PCE can use the LSP-DB for many other functions, such as 603 balancing the distribution of LSPs in the network. Furthermore, the 604 PCE can correlate LSPs with network resource availability placing new 605 LSPs more cleverly. 607 A Stateful PCE that is also an Active PCE (see Section 17) can 608 respond to changes in network resource availability and predicted 609 demands to reroute LSPs that it knows about. 611 Section 20 offers a brief comparison of the different modes of PCE 612 with reference to stateful and stateless PCE. 614 15. How Is the LSP-DB Built? 616 The LSP-DB contains information about the LSPs that are active in the 617 network, as mentioned in Section 14. This state information can be 618 constructed by the PCE from information it receives from a number of 619 sources including from provisioning tools and from the network, but 620 however the information is gleaned, a Stateful PCE needs to 621 synchronize its LSP-DB with the state in the network. Just as 622 described in Section 13, the PCE cannot rely on knowledge about 623 previous computations it has made, but must find out the actual LSPs 624 in the network. 626 A simple solution is for all ingress LSRs to report all LSPs to the 627 PCE as they are set up, modified, or torn down. Since PCEP already 628 has the facility to fully describe LSP routes and resources in the 629 protocol messages, this is not a difficult problem, and the LSP State 630 Report (PCRpt) message has been defined for this purpose 631 [I-D.ietf-pce-stateful-pce]. 633 The situation can be more complex, however, if there are ingress LSRs 634 that do not support PCEP, support PCEP but not the PCRpt, or that are 635 unaware of the requirement to report LSPs to the PCE. This might 636 happen if the LSRs are able to compute paths themselves, or if they 637 receive LSP setup instructions with pre-computed paths from an NMS. 639 An alternative approach is to note that any LSR on the path of an LSP 640 can probably see the whole path (through the Record Route object in 641 RSVP-TE signaling [RFC3209]) and knows the bandwidth reserved for the 642 LSP. Thus, any LSR could report the LSP to the PCE, noting that it 643 will not hurt (beyond additional message processing and potential 644 overload of the PCE or the network) for the LSP to be reported 645 multiple times because it is clearly identified. In fact this would 646 also provide a cross-check mechanism. 648 Nevertheless, it is possible that some LSPs will traverse only LSRs 649 that are not aware of the PCE's need to learn LSP state and build an 650 LSP-DB. In these cases, the stateful PCE must either only have 651 limited knowledge of the LSPs in the network or must learn about LSPs 652 through some other mechanism (such as reading the MPLS and GMPLS MIB 653 modules [RFC3812] [RFC4802]). 655 Ultimately, there may be no substitute for all LSRs being aware of 656 Stateful PCEs and able to respond to requests for reports on all LSPs 657 that they know about. This will allow a Stateful PCE to build its 658 LSP-DB from scratch (which it may need to do at start of day) and to 659 verify its LSP-DB against the network (which may be important if the 660 PCE has suffered some form of outage). 662 16. How Do Redundant Stateful PCEs Synchronize State? 664 It is important that two PCEs operating in a network have similar 665 views of the available resources. That is, they should have the same 666 or substantially similar TEDs. This is easy to achieve either by 667 building the TEDs from the network in the same way, or by one PCE 668 synchronizing its TED to the other PCE using a TED export protocol 669 such as BGP-LS [I-D.ietf-idr-ls-distribution] or the Network 670 Configuration Protocol (NETCONF) [RFC6241] (see Section 6). 672 Synchronizing the LSP-DB can be a more complicated issue. As 673 described in Section 15, building the LSP-DB can be an involved 674 process, so it would be best to not have multiple PCEs each trying 675 to build an LSP-DB from the network. However, it is still important 676 that where multiple PCEs operate in the network (either as 677 distributed PCEs, or with one acting as a backup for the other) their 678 LSP-DBs are kept synchronized. 680 Thus, there is likely to be a need for a protocol mechanism for one 681 PCE to update its LSP-DB with that of another PCE. This is no 682 different from any other database synchronization problem and could 683 use existing mechanisms or a new protocol. Note, however, that in 684 the case of distributed PCEs that are also Active PCEs (see Section 685 17), each PCE will be creating entries in its own LSP-DB, so the 686 synchronization of databases must be incremental and bidirectional, 687 not just simply a database dump. 689 It may be helpful to clarify the word "redundant" in the context of 690 this question. One interpretation is that a redundant PCE exists 691 solely as a backup such that it only performs a function in the 692 network in the event of a failure of the primary PCE. This seems 693 like a waste of expensive resources, and it would make more sense for 694 the redundant PCE to take its share of computation load all the time. 695 However, that scenario of two (or more) active PCEs creates exactly 696 the state synchronization issue described above. 698 Various deployment options have been suggested where one PCE serves a 699 set of PCCs as the primary computation server, and only addresses 700 requests from other PCCs in the event of the failure of some other 701 PCE, but this mode of operation still raises questions about the need 702 for synchronized state even in non-failure scenarios if the LSPs that 703 will be computed by the different PCEs may traverse the same network 704 resources. 706 17. What Is An Active PCE? What is a Passive PCE? 708 A Passive PCE is one that only responds to path computation requests. 709 It takes no autonomous actions. A Passive PCE may be stateless or 710 stateful. 712 An Active PCE is one that issues provisioning "recommendations" to 713 the network. These recommendations may be new routes for existing 714 LSPs, or routes for new LSPs (that is, an Active PCE may recommend 715 the instantiation of new LSPs). An Active PCE may be stateless or 716 stateful, but in order that it can reroute existing LSPs effectively, 717 it is likely to hold state for at least those LSPs that it will 718 reroute. 720 Many people consider that the PCE, itself, cannot be Active. That 721 is, they hold that the PCE's function is purely to compute paths. In 722 that world-view, the "Active PCE" is actually the combination of a 723 normal, passive PCE and an additional architectural component 724 responsible for issuing commands or recommendations to the network. 726 In some configurations, the VNTM discussed in Sections 21 and 22 727 provides this additional component. 729 Section 20 offers a brief comparison of the different modes of PCE 730 with reference to passive and active PCE. 732 18. What is LSP Delegation? 734 LSP delegation [I-D.ietf-pce-stateful-pce] is the process where a PCC 735 (usually an ingress LSR) passes responsibility for triggering updates 736 to the attributes of an LSP (such as bandwidth or path) to the PCE. 737 In this case, the PCE would need to be both Stateful and Active. 739 LSP delegation allows an LSP to be set up under the control of the 740 ingress LSR potentially using the services of a PCE. Once the LSP 741 has been set up, the LSR (a PCC) tells the PCE about the LSP by 742 providing details of the path and resources used. It delegates 743 responsibility for the LSP to the PCE so that the PCE can make 744 adjustments to the LSP as dictated by changes to the TED and the 745 policies in force at the PCE. The PCE makes the adjustments by 746 sending a new path to the LSR with the instruction/recommendation 747 that the LSP be re-signalled. 749 There may be some debate over whether the PCE "owns" the LSP after 750 delegation. That is, if the PCE supplies a new path, is the ingress 751 LSR required to act or can it take the information "under 752 advisement"? It may be too soon to answer this question 753 definitively, however there is certainly an expectation that the LSR 754 will act on the advice it receives. A comparison may be drawn with 755 a visit to the doctor: the doctor has an expectation that the patient 756 will take the medicine, but the patient has free will. 758 It is important, however, to distinguish between an LSP established 759 within the network and subsequently delegated to a PCE, and an LSP 760 that was established as the result of an Active PCE's recommendation 761 for LSP instantiation. 763 Section 20 offers a brief comparison of the different modes of PCE 764 with reference to LSP delegation. 766 19. Is An Active PCE with LSP Delegation Just a Fancy NMS? 768 In many ways the answer here is "yes". But the PCE architecture 769 forms part of a new way of looking at network operation and 770 management. In this new view, the network operation is more dynamic 771 and under the control of software applications without direct 772 intervention from operators. This is not to say that the operator 773 has no say in how their network runs, but it does mean that the 774 operator sets policies (see Section 24) and that new components (such 775 as an Active PCE) are responsible for acting on those policies to 776 dynamically control the network. 778 There is a subtle distinction between an NMS and an Active PCE with 779 LSP delegation. An NMS is in control of the LSPs in the network and 780 can command that they are set up, modified, or torn down. An Active 781 PCE can only make suggestions about LSPs that have been delegated to 782 the PCE by a PCC, or make recommendations for the instantiation of 783 new LSPs. 785 For more details, see the discussion of an architecture for 786 Application-Based Network Operation (ABNO) in 787 [I-D.farrkingel-pce-abno-architecture] 789 20. Comparison of Stateless and Stateful PCE 791 Table 1 shows a comparison of stateless and stateful PCEs to show 792 how they how might be instantiated as passive or active PCEs with 793 or without control of LSPs. The terms used relate to the concepts 794 introduced in the previous sections. The entries in the table 795 refer to the notes that follow. 797 | Stateless | Stateful | 798 ------------------------+-----------+-----------+ 799 Passive | 1 | 2 | 800 Active delegated LSPs | 3 | 4 | 801 Active suggest new LSPs | 5 | 6 | 802 Active instantiate LSPs | 7 | 7 | 804 Notes: 805 1. Passive is the normal mode for a stateless PCE. 806 2. A passive mode stateful PCE may have value for more complex 807 environments and for computing protected services. 808 3. Delegation of LSPs to a stateless PCE is relatively pointless, 809 but could add value at moment of delegation. 810 4. This is the normal mode for a stateful PCE. 811 5. There is only marginal potential for a stateless PCE to 812 recommend new LSPs because without a view of existing LSPs, the 813 PCE cannot determine when new ones might be needed. 814 6. This mode has potential for recommending the instantiation of 815 new LSPs. 816 7. These modes are out of scope for PCE as currently described. 817 That is, the PCE can recommend instantiation, but cannot 818 actually instantiate the LSPs. 820 Table 1 : Comparing Stateless and Stateful PCE 822 21. How Does a PCE Work With A Virtual Network Topology? 824 A Virtual Network Topology (VNT) is described in [RFC4397] as a set 825 of Hierarchical LSPs that is created (or could be created) in a 826 particular network layer to provide network flexibility (data links) 827 in other layers. Thus the TE topology of a network can be 828 constructed from TE links that are simply data links, from TE links 829 that are supported by LSPs in another layer of the network, or from 830 TE links that could be supported by LSPs ("potential LSPs") that 831 would be set up on demand in another network layer. This third type 832 of TE link is known as a Virtual TE Link in [RFC5212]. 834 [RFC5212] also gives a more detailed explanation of a VNT, and it 835 should be noted that the network topology in a packet network could 836 be supported by LSPs in a number of different lower-layer networks. 837 For example, the TE links in the packet network could be achieved by 838 connections (LSPs) in underlying Synchronous Optical Network or 839 Synchronous Digital Hierarchy (SONET/SDH) and photonic networks. 840 Furthermore, because of the hierarchical nature of MPLS, the TE links 841 in a packet network may be achieved by setting up packet LSPs in the 842 same packet network. 844 A PCE obviously works with the TED that contains information about 845 the TE links in the network. Those links may be already established 846 or may be virtual TE links. In a simple TED, there is no distinction 847 between the types of TE link, however, there may be advantages to 848 selecting TE links that are based on real data links over those based 849 on dynamic LSPs in lower layers because the data links may be more 850 stable. Conversely, the TE links based on dynamic LSPs may be able 851 to be repaired dynamically giving better resilience. Similarly, a 852 PCE may prefer to select a TE link that is supported by a data link 853 or existing LSP in preference to using a virtual TE link because the 854 latter may need to be set up (taking time) and the setup could 855 potentially fail. Thus, a PCE might want to employ additional 856 metrics or indicators to help it view the TED and select the right 857 path for LSPs. 859 If a PCE uses a virtual TE link, then some action will be needed to 860 establish the LSP that supports that link. Some models (such as that 861 in [RFC5212]) trigger the setup of the lower layer LSPs on-demand 862 during the signaling of the upper layer LSP (i.e., when the upper 863 layer comes to use the virtual TE link, the upper layer signaling is 864 paused and the lower layer LSP is established). Another view, 865 described in [RFC5623], is that when the PCE computes a path that 866 will use a virtual TE link, it should trigger the setup of the lower 867 layer LSP to properly create the TE link so that the path it returns 868 will be sure to be viable. This latter mode of operation can be 869 extended to allow the PCE to spot the need for additional TE links 870 and to trigger LSPs in lower layers in order to create those links. 872 Of course, such "interference" in a lower layer network by a PCE 873 responsible for a higher layer network depends heavily on policy. In 874 order to make a clean architectural separation and to facilitate 875 proper policy control, [RFC5623] introduces the Virtual Network 876 Topology Manager (VNTM) as a functional element that manages and 877 controls the VNT. [RFC5623] notes that the PCE and VNT Manager are 878 distinct functional elements that may or may not be collocated. 879 indeed, it should be noted that there will be a PCE for the upper 880 layer, and a PCE for each lower layer, and a VNTM responsible for 881 coordinating between the PCEs and for triggering LSP setup in the 882 lower layers. Therefore, the combination of all of the PCEs and the 883 VNTM produces functionally similar to an Active, multi-layer PCE. 885 See [I-D.farrel-interconnected-te-info-exchange] for additional 886 discussion of the construction of networks using virtual and 887 potential links. 889 22. How Does PCE Communicate With VNTM 891 The VNTM described in Section 21 and [RFC5623] has several interfaces 892 (see also [I-D.farrkingel-pce-abno-architecture]). 894 - The VNTM will need to learn about resource shortages and the need 895 for additional TE links from the upper layer PCE in order that it 896 can make policy-based decisions to determine whether and which LSPs 897 to set up to create new TE links. This interface is currently 898 undefined. 900 - The VNTM will need to coordinate with the PCEs in the lower layers, 901 but this is simply a normal use of PCEP. 903 - The VNTM will need to issue provisioning requests/commands (via the 904 Provisioning Manager described in [I-D.farrkingel-pce-abno- 905 architecture]) to the lower layer networks to cause LSPs to be set 906 up to act as TE links in the higher layer network. A number of 907 potential protocols exist for this function as described in [I-D. 908 farrkingel-pce-abno-architecture], but it should be noted that it 909 makes a lot of sense for this interface to be the same as that used 910 by an Active PCE when providing paths to the network. 912 23. How Does Service Scheduling and Calendering Work? 914 LSP scheduling or calendaring is a process where LSPs are planned 915 ahead of time, and only set up when needed. The challenge here is to 916 ensure that the resources needed by an LSP and that were available 917 when the LSP's path was computed are still available when the LSP 918 needs to be set up. This needs to be achieved using a mechanism that 919 allows those resources to be used in the mean time. 921 Previous discussion of this topic has suggested that LSPs should be 922 pre-signaled so that each LSR along the path could make a "temporal 923 reservation" of resources. But this approach can become very 924 complicated requiring each network node to store multi-dimensional 925 state. 927 Conversely, a centralized database of resources and LSPs (such as the 928 database maintained by a Stateful PCE) can be enhanced with a time- 929 based booking system. If the PCE is also Active, then when the time 930 comes for the LSP to be set up (or later, when it is to be torn down) 931 the PCE can issue recommendations to the network. 933 It should be noted that in a busy network (and why would one bother 934 with a scheduling service in a network that is not busy?) the 935 computation algorithm can be quite complex. It may also be necessary 936 to reposition existing or planned LSPs as new bookings arrive. 937 Furthermore, the booking database that contains both the scheduled 938 LSPs and their impact on the network resources can become quite 939 large. A very important factor in the size of the active database 940 (depending on implementation) may be the timeslices that are 941 available in the calendering process. 943 24. Where Does Policy Fit In? 945 Policy is critical to the operation of a network. In a PCE context 946 it provides control and management of how a PCE selects network 947 resources for use by different PCEs. 949 [RFC5394] introduced the concept of PCE-based policy-enabled path 950 computation. It is based on the Policy Core Information Model (PCIM) 951 [RFC3060] as extended by [RFC3460], and provides a framework for 952 supporting path computation policy. 954 Policy enters into all aspect of the use of a PCE starting from the 955 very decision to use a PCE to off-load computation function from the 956 LSRs. 958 - Each PCC must select which computations will be delegated to a PCE. 960 - Each PCC must select which PCEs it will use. 962 - Each PCE must determine which PCCs are allowed to use its services 963 and for what computations. 965 - The PCE must determine how to collect the information in its TED, 966 who to trust for that information, and how to refresh/update the 967 information. 969 - Each PCE must determine which objective functions and which 970 algorithms to apply. 972 - Inter-domain (and particularly H-PCE) computations will need to be 973 sensitive to commercial and reliability information about domains 974 and their interactions. 976 - Stateful PCEs must determine what state to hold, when to refresh 977 it, and which network elements to trust for the supply of the state 978 information. 980 - An Active PCE must have a policy relationship with its LSRs to 981 determine which LSPs can be modified or triggered, and what LSP 982 delegation is supported. 984 - Multi-layer interactions (especially those using virtual or dynamic 985 TE links) must provide policy control to stop server layer LSPs 986 (which are fat and expensive by definition) from being set up on a 987 whim to address micro-flows or speculative computations in higher 988 layers. 990 - A PCE may supply, along with a computed path, policy information 991 that should be signaled during LSP setup for use by the LSRs along 992 the path. 994 It may be seen, therefore, that a PCE is substantially a policy 995 engine that computes paths. It should also be noted that the work of 996 the PCE can be substantially controlled by configured policy in a way 997 that will reduce the options available to the PCC, but also 998 significantly reduce the need for the use of optional parameters in 999 the PCEP messages. 1001 25. Does PCE Play a Role in SDN? 1003 Software Defined Networking (SDN) is the latest shiny thing in 1004 networking. It refers to a separation between the control elements 1005 and the forwarding components so that software running in a 1006 centralized system called a controller, can act to program the 1007 devices in the network to behave in specific ways. 1009 A required element in an SDN architecture is a component that plans 1010 how the network resources will be used and how the devices will be 1011 programmed. It is possible to view this component as performing 1012 specific computations to place flows within the network given 1013 knowledge of the availability of network resources, how other 1014 forwarding devices are programmed, and the way that other flows are 1015 routed. This, it may be concluded, is the same function that a PCE 1016 might offer in a network operated using a dynamic control plane. 1017 Thus, a PCE could form part of the infrastructure for an SDN. 1019 A view of how PCE integrates into a wider network control system 1020 including SDN is presented in [I-D.farrkingel-pce-abno-architecture]. 1022 26. Security Considerations 1024 The use of a PCE-based architectures and subsequent impact on network 1025 security must, itself, be considered in the context of existing 1026 routing and signaling protocols and techniques. The nature of multi- 1027 domain network scenarios and establishment of relationships between 1028 PCCs and PCEs may increase the vulnerability of the network to 1029 security attacks. However, this informational document does not 1030 define any new protocol elements or mechanism. As such, it does not 1031 introduce any new security issues and security is deemed to be a 1032 "previously answered question" even if the answers previously 1033 supplied are not perfect. Previous PCE RFCs have given some 1034 attention to security concerns in the use of PCE (RFC 4655), PCE 1035 discovery (RFC 4674, RFC 5088. RFC 5089), and PCEP (RFC 4657 and RFC 1036 5440). 1038 It is worth noting that PCEP operates over TCP. An analysis of the 1039 security issues for routing protocols that use TCP (including PCEP) 1040 is provided in [RFC6952] while [I-D.ietf-pce-pceps] discusses an 1041 experimental approach to provide secure transport for PCEP. 1043 A number of the questions raised and answered in this document should 1044 be given consideration in the light of security requirements. Some 1045 of these are called out explicitly (Sections 8 and 10), but attention 1046 should also be paid to security in all aspects of the use of PCE. For 1047 example: 1049 - Topology and other information about the network needs to be kept 1050 private and protected from modification or forgery. That means 1051 that access to the TED, LSP-DB, etc. needs to be secured and that 1052 mechanisms used to gather topology and other information (Sections 1053 2, 11, 14, and 15) need to include security. 1055 - PCE discovery (Sections 4, 5, 9, and 10) needs to protect against 1056 impersonation or or misconfiguration so that PCCs know that they 1057 are getting correct paths and so that PCEs know that they are only 1058 serving legitimate computation requests. 1060 - Synchonization of information and state between PCEs (Sections 6 1061 and 16) is subject to the same security requirements in that the 1062 information exchanged is sensitive and needs to be protected 1063 against interception and modification. 1065 - PCE computes paths for components that may provision the network. 1066 Those component are responsible for the security of the 1067 provisioning mechanisms, however, if PCE operates as a provisioning 1068 protocol (Sections 17, 18, 19, and 25). 1070 - A PCE may also need to interface with other network components 1071 (Sections 19, 21, 22, and 25). Those communications, if external 1072 to an implementation, also need to be secure. 1074 27. IANA Considerations 1076 This document makes no requests for IANA Action. 1078 28. Acknowledgements 1080 Thanks for constructive comments go to Fatai Zhang, Oscar Gonzalez de 1081 Dios, Xian Zhang, Cyril Margaria, Denis Ovsienko, Ina Minei, Dhruv 1082 Dhody, and Qin Wu. 1084 This work was supported in part by the FP-7 IDEALIST project under 1085 grant agreement number 317999. 1087 This work received funding from the European Union's Seventh 1088 Framework Programme for research, technological development and 1089 demonstration through the PACE project under grant agreement 1090 no. 619712. 1092 29. References 1094 29.1. Normative References 1096 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1097 Computation Element (PCE)-Based Architecture", RFC 1098 4655, August 2006. 1100 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 1101 Computation Element (PCE) Communication Protocol 1102 (PCEP)", RFC 5440, March 2009. 1104 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 1105 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 1106 Traffic Engineering", RFC 5623, September 2009. 1108 [RFC6805] King, D. and A. Farrel, "The Application of the Path 1109 Computation Element Architecture to the Determination of 1110 a Sequence of Domains in MPLS and GMPLS", RFC 6805, 1111 November 2012. 1113 29.2. Informative References 1115 [I-D.farrkingel-pce-abno-architecture] 1116 King, D., and Farrel, A., "A PCE-based Architecture for 1117 Application-based Network Operations", 1118 draft-farrkingel-pce-abno-architecture, work in progress. 1120 [I-D.farrel-interconnected-te-info-exchange] 1121 Farrel, A., Drake, J., Bitar, N., Swallow, G., and D. 1122 Ceccarelli, "Problem Statement and Architecture for 1123 Information Exchange Between Interconnected Traffic 1124 Engineered Networks", 1125 draft-farrel-interconnected-te-info-exchange, work in 1126 progress. 1128 [I-D.ietf-alto-server-discovery] 1129 Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and 1130 H. Song, "ALTO Server Discovery", 1131 draft-ietf-alto-server-discovery, work in progress. 1133 [I-D.ietf-idr-ls-distribution] 1134 Gredler, H., Medved, J., Previdi, S., Farrel, A., and 1135 Ray, S., "North-Bound Distribution of Link-State and TE 1136 Information using BGP", draft-ietf-idr-ls-distribution, 1137 work in progress. 1139 [I-D.ietf-pce-pceps] 1140 Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1141 "Secure Transport for PCEP", draft-ietf-pce-pceps, work 1142 in progress. 1144 [I-D.ietf-pce-stateful-pce] 1145 Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP 1146 Extensions for Stateful PCE", 1147 draft-ietf-pce-stateful-pce, work in progress. 1149 [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. 1150 Westerinen, "Policy Core Information Model -- Version 1 1151 Specification", RFC 3060, February 2001. 1153 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V, 1154 and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP 1155 Tunnels", RFC 3209, December 2001 1157 [RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) 1158 Extensions", RFC 3460, January 2003. 1160 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic 1161 Engineering (TE) Extensions to OSPF Version 2", RFC 1162 3630, September 2003. 1164 [RFC3812] Srinivasan, C., Viswanathan, A., and Nadeau, T., 1165 "Multiprotocol Label Switching (MPLS) Traffic Engineering 1166 (TE) Management Information Base (MIB)", RFC 3812, June 1167 2004. 1169 [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF 1170 Extensions in Support of Generalized Multi- 1171 Protocol Label Switching (GMPLS)", RFC 1172 4203, October 2005. 1174 [RFC4397] Bryskin, I., and Farrel, A. "A Lexicography for the 1175 Interpretation of Generalized Multiprotocol Label 1176 Switching (GMPLS) Terminology within the Context of the 1177 ITU-T's Automatically Switched Optical Network (ASON) 1178 Architecture", RFC 4397, February 2006. 1180 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element 1181 (PCE) Communication Protocol Generic Requirements", 1182 RFC 4657, September 2006. 1184 [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation 1185 Element (PCE) Discovery", RFC 4674, October 2006. 1187 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework 1188 for Inter-Domain Multiprotocol Label Switching Traffic 1189 Engineering", RFC 4726, November 2006. 1191 [RFC4802] Nadeau, T., and Farrel, A., "Generalized Multiprotocol 1192 Label Switching (GMPLS) Traffic Engineering Management 1193 Information Base", RFC 4802, February 2007. 1195 [RFC4848] Daigle, L., "Domain-Based Application Service Location 1196 Using URIs and the Dynamic Delegation Discovery Service 1197 (DDDS)", RFC 4848, April 2007 1199 [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS 1200 (GMPLS) RSVP-TE Signaling Extensions in Support of 1201 Calls", RFC 4974, August 2007. 1203 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 1204 Per-Domain Path Computation Method for Establishing 1205 Inter-Domain Traffic Engineering (TE) Label Switched 1206 Paths (LSPs)", RFC 5152, February 2008. 1208 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1209 Zhang, "OSPF Protocol Extensions for Path Computation 1210 Element (PCE) Discovery", RFC 5088, January 2008. 1212 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 1213 Zhang, "IS-IS Protocol Extensions for Path Computation 1214 Element (PCE) Discovery", RFC 5089, January 2008. 1216 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 1217 M., and Brungard, D., "Requirements for GMPLS-Based 1218 Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 1219 5212, July 2008. 1221 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1222 Engineering", RFC 5305, October 2008. 1224 [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS 1225 Extensions in Support of Generalized Multi-Protocol 1226 Label Switching (GMPLS)", RFC 5307, 1227 October 2008. 1229 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 1230 "Policy-Enabled Path Computation Framework", RFC 5394, 1231 December 2008. 1233 [RFC5441] Vasseur, J.P., Ed., "A Backward Recursive PCE-based 1234 Computation (BRPC) procedure to compute shortest inter- 1235 domain Traffic Engineering Label Switched Paths", RFC 1236 5441, April 2009. 1238 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 1239 Computation Element Communication Protocol (PCEP) 1240 Requirements and Protocol Extensions in Support of Global 1241 Concurrent Optimization", RFC 5557, July 2009. 1243 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 1244 Location Information Server (LIS)", RFC 5986, September 1245 2010. 1247 [RFC6006] Zhao, Q., King, D., Verhaeghe, F., Takeda, T., Ali, 1248 Z., and J. Meuric, "Extensions to the Path 1249 Computation Element Communication Protocol (PCEP) 1250 for Point-to-Multipoint Traffic Engineering Label 1251 Switched Paths", RFC 6006, September 2010. 1253 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and Bierman, 1254 A., "Network Configuration Protocol (NETCONF)", RFC 6241, 1255 June 2011. 1257 [RFC6952] Jethanandani, M., Patel, K., and Zheng, L., "Analysis of 1258 BGP, LDP, PCEP, and MSDP Issues According to the 1259 Keying and Authentication for Routing Protocols (KARP) 1260 Design Guide", RFC 6952, May 2013. 1262 Authors' Addresses 1264 Adrian Farrel 1265 Juniper Networks 1266 EMail: adrian@olddog.co.uk 1268 Daniel King 1269 Old Dog Consulting 1270 EMail: daniel@olddog.co.uk