idnits 2.17.1 draft-ietf-pce-architecture-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1242. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 684: '... A PCE SHOULD advertise its capabili...' RFC 2119 keyword, line 1185: '...y, but solutions MUST examine their ef...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2005) is 6850 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3667' is defined on line 1246, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 1249, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 1254, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1261, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 1267, but no explicit reference was found in the text == Unused Reference: 'RFC4105' is defined on line 1276, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) -- Obsolete informational reference (is this intentional?): RFC 3784 (ref. 'RFC3748') (Obsoleted by RFC 5305) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Adrian Farrel 2 IETF Internet Draft Old Dog Consulting 3 Proposed Status: Informational Jean-Philippe Vasseur 4 Expires: January 2006 Cisco Systems, Inc. 5 Jerry Ash 6 AT&T 8 July 2005 10 draft-ietf-pce-architecture-01.txt 12 Path Computation Element (PCE) Architecture 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be 34 accessed at http://www.ietf.org/shadow.html. 36 Abstract 38 Constraint-based path computation is a fundamental building block for 39 traffic engineering systems such as Multiprotocol Label Switching 40 (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) 41 networks. Path computation in large, multi-domain, multi-region or 42 multi-layer networks is highly complex and may require special 43 computational components and cooperation between the different 44 network domains. 46 This document specifies the architecture for a Path Computation 47 Element (PCE)-based model to address this problem space. This 48 document does not attempt to provide a detailed description of all 49 the architectural components, but rather it describes a set of 50 building blocks for the PCE architecture from which solutions may be 51 constructed. 53 Table of Contents 55 1. Introduction ................................................... 3 56 2. Terminology .................................................... 3 57 3. Definitions .................................................... 4 58 4. Motivation for a PCE-based Architecture ........................ 6 59 4.1. CPU-intensive Path Computation/Global Optimization ....... 6 60 4.2. Partial Visibility ....................................... 6 61 4.3. Absence of the TED or Use of Non-TE-Enabled IGP .......... 7 62 4.4. Node Outside the Routing Domain .......................... 7 63 4.5. Network Element Lacks Control Plane or Routing Capability 8 64 4.6. Backup Path Computation for Bandwidth Protection ......... 8 65 4.7. Multi-Layer Networks ..................................... 8 66 5. Overview of the PCE-Based Architecture ......................... 9 67 5.1. Composite PCE Node ....................................... 9 68 5.2. External PCE ............................................ 10 69 5.3. Multiple PCE Path Computation ........................... 11 70 5.4. Multiple PCE Path Computation with Inter-PCE Communication 71 .............................................. 12 72 5.5. Areas for Standardization ............................... 13 73 6. PCE Architectural Considerations .............................. 13 74 6.1. Centralized Computation Model ........................... 14 75 6.2. Distributed Computation Model ........................... 14 76 6.3. Synchronization ......................................... 14 77 6.4. PCE Discovery and Load Balancing ........................ 15 78 6.5. Detecting PCE Liveness .................................. 16 79 6.6. PCC-PCE & PCE-PCE Communication ......................... 16 80 6.7. PCE TED Synchronization ................................. 18 81 6.8. Stateful Versus Stateless PCEs .......................... 19 82 6.9. Monitoring .............................................. 21 83 6.10. Policy and Confidentiality ............................ 21 84 6.11. Unsolicited Interactions ............................... 21 85 7. Evaluation Metrics ............................................ 22 86 8. Manageability Considerations .................................. 23 87 8.1 Information and Data Models .............................. 23 88 8.2 Liveness Detection and Monitoring ........................ 24 89 8.3 Verifying Correct Operation .............................. 24 90 8.4 Requirements on Other Protocols and Functional Components 25 91 8.5 Impact on Network Operation .............................. 25 92 9. Security Considerations ....................................... 26 93 10. IANA Considerations .......................................... 26 94 11. Acknowledgements ............................................. 27 95 12. Intellectual Property Considerations ......................... 27 96 13. Normative References ......................................... 27 97 14. Informational References ..................................... 27 98 15. Authors' Addresses ........................................... 28 99 16. Full Copyright Statement ..................................... 29 101 1. Introduction 103 Constraint-based path computation is a fundamental building block for 104 traffic engineering in MPLS and GMPLS networks. Path computation in 105 large, multi-domain networks is highly complex and may require 106 special computational components and cooperation between the elements 107 in different domains. This document specifies the architecture for a 108 Path Computation Element (PCE)-based model to address this problem 109 space. 111 This document describes a set of building blocks for the PCE 112 architecture from which solutions may be constructed. For example, it 113 discusses PCE-based implementations including composite, external, 114 and multiple PCE path computation. Furthermore, it discusses 115 architectural considerations including centralized computation, 116 distributed computation, synchronization, PCE discovery and load 117 balancing, detection of PCE liveness, PCC-PCE and PCE-PCE 118 communication, TED synchronization, stateful and stateless PCEs, 119 monitoring, policy and confidentiality, and evaluation metrics. 121 2. Terminology 123 CSPF: Constraint-based Shortest Path First. 125 LER: Label Edge Router. 127 LSDB: Link State Database. 129 LSP: Label Switched Path. 131 LSR: Label Switching Router. 133 PCC: Path Computation Client : any client application requesting a 134 path computation to be performed by the Path Computation Element. 136 PCE: Path Computation Element: an entity (component, application or 137 network node) that is capable of computing a network path or route 138 based on a network graph and applying computational constraints (see 139 further description in Section 3). 141 TED: Traffic Engineering Database which contains the topology and 142 resource information of the domain. The TED may be fed by IGP 143 extensions or potentially by other means. 145 TE LSP: Traffic Engineering MPLS Label Switched Path. 147 3. Definitions 149 A Path Computation Element (PCE) is an entity that is capable of 150 computing a network path or route based on a network graph, and of 151 applying computational constraints during the computation. The PCE 152 entity is an application that can be located within a network node or 153 component, on an out-of-network server, etc. For example, a PCE would 154 be able to compute the path of a TE LSP by operating on the TED and 155 considering bandwidth and other constraints applicable to the TE LSP 156 service request. 158 A domain is any collection of network elements within a common sphere 159 of address management or path computation responsibility. Examples 160 of domains include IGP areas, Autonomous Systems (ASs), multiple ASs 161 within a service provider network, or multiple ASs across multiple 162 service provider networks. However, domains of path computation 163 responsibility may also exist as sub-domains of areas or ASs. 165 In order to fully characterize a PCE and clarify these definitions, 166 the following important considerations must also be examined: 168 1) Path computation is applicable in intra-domain, inter-domain, and 169 inter-layer contexts. 171 a. Inter-domain path computation may involve the correlation of 172 topology and routing information between domains. 174 b. Inter-layer path computation refers to the use of PCE where 175 multiple layers are involved and when the objective is to 176 perform path computation at one or multiple layers while taking 177 into account topology and resource information at these layers. 179 Overlapping domains are not within the scope of this document. In 180 the inter-domain case, the domains may belong to a single or 181 multiple Service Providers. 183 2) a. In "single PCE path computation," a single PCE is used to 184 compute a given path in a domain. There may be multiple PCEs in 185 a domain, but only one PCE per domain is involved in any single 186 path computation. 188 b. In "multiple PCE path computation," multiple PCEs are used to 189 compute a given path in a domain. 191 3) a. "Centralized computation model" refers to a model whereby all 192 paths in a domain are computed by a single, centralized PCE. 194 b. Conversely, "Distributed computation model" refers to the 195 computation of paths in a domain being shared among multiple 196 PCEs. 198 Paths that span multiple domains may be computed using the 199 distributed model with one or more PCEs responsible for each 200 domain, or the centralized model by defining a domain that 201 encompasses all of the other domains. 203 From these definitions, a centralized computation model inherently 204 uses single PCE path computation. However, a distributed 205 computation model could use either single PCE path computation or 206 multiple PCE path computations. There would be no such thing as a 207 centralized model which uses multiple PCEs. 209 4) The PCE may or may not be located at the head-end of the path. For 210 example, a conventional intra-domain solution is to have path 211 computation performed by the head-end LSR of an MPLS TE LSP; in 212 this case, the head-end LSR contains a PCE. But solutions also 213 exist where other nodes on the path must contribute to the path 214 computation (for example, loose hops) making them PCEs in their 215 own right. At the same time, the path computation may be made by 216 some other PCE physically distinct from the computed path. 218 5) The path computed by the PCE may be an "explicit PCE path" (that 219 is, the full explicit path from start to destination, made of a 220 list of strict hops) or a "strict/loose PCE path" (that is, a mix 221 of strict and loose hops comprising at least one loose hop 222 representing the destination), where a hop may be an abstract node 223 such as an AS. 225 6) A PCE-based path computation model does not mean to be exclusive 226 and can be used in conjunction with other path computation models. 227 For instance, the path of an inter-AS TE LSP may be computed using 228 a PCE-based path computation model in some IGP areas, whereas the 229 set of traversed ASs may be specified by other means (not 230 determined by a PCE). Furthermore, different path computation 231 models may be used for different TE LSPs. 233 7) This document does not make any assumptions about the nature or 234 implementation of a PCE. A PCE could be implemented on a router, 235 an LSR, a dedicated network server, etc. Moreover, the PCE 236 function is orthogonal to the forwarding capability of the node on 237 which it is implemented. 239 4. Motivation for a PCE-based Architecture 241 Several motivations for a PCE-based architecture (described in 242 Section 5) are listed below. This list is not meant to be exhaustive 243 and is provided for the sake of illustration. 245 It should be highlighted that the aim of this section is to provide 246 some application examples for which a PCE-based path may be suitable: 247 this also clearly states that such a model does not aim to replace 248 existing path computation models but would apply to specific existing 249 or future situations. 251 4.1. CPU-intensive Path Computation/Global Optimization 253 There are many situations where the computation of a path may be 254 highly CPU-intensive: examples of CPU-intensive path computations 255 include the resolution of problems such as: 257 - Global optimization in placing a set of TE LSPs within a domain so 258 as to optimize an objective function (for example, minimization of 259 the maximum link utilization) 261 - Multi-criteria path computation (for example, delay and link 262 utilization, inclusion of switching capabilities, adaptation 263 features, encoding types and optical constraints within a GMPLS 264 optical network) 266 - Computation of minimal cost Point to Multipoint trees (Steiner 267 trees). 269 In these situations, it may not be possible or desirable for a router 270 to perform path computation because of the constraints on its CPU, in 271 which case the path computation may be off-loaded to some other 272 PCE(s). 274 4.2. Partial Visibility 276 There are several scenarios where the node responsible for path 277 computation has limited visibility of the network topology to the 278 destination. This limitation may occur, for instance, when an ingress 279 router attempts to establish an LSP to a destination that lies in a 280 separate domain, since TE information is not exchanged across the 281 domain boundaries. In such cases, it is possible to use loose routes 282 to establish the LSP, relying on routers at the domain borders to 283 establish the next piece of the path, however, it is not possible to 284 guarantee that the optimal (shortest) path will be used, nor even 285 that a viable path will be discovered except, possibly, through 286 repeated trial and error using crankback or other signaling 287 extensions. 289 This problem of inter-domain path computation may most probably be 290 addressed through distributed computation with cooperation among PCEs 291 within each of the domains, or perhaps by using a central 292 "all-seeing" PCE that has access to the complete set of topology 293 information. In this latter case there are challenges of scalability 294 (both the size of the TED and the responsiveness of a single PCE 295 handling requests for many domains) and of preservation of 296 confidentiality when the domains belong to different Service 297 Providers. 299 Note that the issues described here can be further highlighted in the 300 context of LSP reoptimization, or the establishment of multiple 301 diverse LSPs for protection or load sharing. 303 4.3. Absence of the TED or use of Non-TE-Enabled IGP 305 The traffic engineering database (TED) may be a large drain on the 306 resources of a network node (such as an edge router or LER) both from 307 a memory perspective and because it may require non-negligible CPU 308 activity to maintain. The use of a distinct PCE may be appropriate in 309 such circumstances, and a separate node can be used to establish and 310 maintain the TED, and to make it available for path computation. 312 The IGPs run within some networks are not sufficient to build a full 313 TED. For example, a network may run OSPF/IS-IS without the 314 OSPF-TE/ISIS-TE extensions, or some routers in the network may not 315 support the TE extensions. In these cases, in order to successfully 316 compute paths through the network, the TED must be constructed or 317 supplemented through configuration action, and updated as network 318 resources are reserved or released. Such a TED could be distributed 319 to each router so that each router can perform path computation, or 320 held centrally (on a distinct node that supports PCE) for centralized 321 path computation. 323 4.4. Node Outside the Routing Domain 325 An LER might not be part of the routing domain for administrative 326 reasons (for example, a customer-edge (CE) router connected to the 327 provider-edge (PE) router in the context of MPLS VPN [RFC2547] and 328 for which it is desired to provide a CE to CE TE LSP path). 330 This scenario suggests a solution that does not involve doing 331 computation on the ingress router, and that does not rely on static 332 loose hops configuration in which case optimal shortest paths could 333 not be achieved. A distinct PCE-based solution can help here. Note 334 that the PCE in this case may, itself, provide a path that includes 335 loose hops. 337 4.5. Network Element Lacks Control Plane or Routing Capability 339 It is common in legacy optical networks for the network elements not 340 to have a control plane or routing capability. Such network elements 341 only have a data plane and a management plane, and all 342 cross-connections are made from the management plane. It is 343 desirable in this case to run the path computation on the PCE, and 344 send the cross-connection commands to each node on the computed path. 345 That is, the PCC would be an element of the management plane, perhaps 346 residing in the NMS or OSS. 348 This scenario is important for ASON-capable networks, and may also be 349 used for interworking between GMPLS-capable and GMPLS-incapable 350 networks. 352 4.6. Backup Path Computation for Bandwidth Protection 354 A PCE can be used to compute backup paths in the context of fast 355 reroute protection of TE-LSPs. In this model all backup TE-LSPs 356 protecting a given facility are computed in a coordinated manner by a 357 PCE. This allows complete bandwidth sharing between backup tunnels 358 protection independent elements, while avoiding any extensions to LSP 359 signaling. Both centralized and distributed computation models are 360 applicable. In the distributed case each LSR can be a PCE to compute 361 the paths of backup tunnels to protect against the failure of 362 adjacent network links or nodes. 364 4.7. Multi-Layer Networks 366 A server-layer network of one switching capability may support 367 multiple networks of another (more granular) switching capability. 368 For example, a TDM network may provide connectivity for client-layer 369 networks such as IP, MPLS or Layer 2 [MRN]. 371 The server-layer network is unlikely to provide the same connectivity 372 paradigm as the client networks so that bandwidth granularity in the 373 server-layer network may be much coarser than in the client-layer 374 network. Similarly, there is likely to be a management separation 375 between the two networks providing independent address spaces. 376 Further, where multiple client-layer networks make use of the same 377 server-layer network, those client-layer networks may have 378 independent policies, control parameters, address spaces and routing 379 preferences. 381 The different client and server layer networks may be considered as 382 distinct path computation regions within a PCE domain, and so the PCE 383 architecture is useful to allow path computation from one 384 client-layer network region, across the server-layer network to 385 another client-layer network region. 387 In this case, the PCEs are responsible for resolving address space 388 issues, handling differences in policy and control parameters, and 389 coordinating resources between the networks. Note that, because of 390 the differences in bandwidth granularity, connectivity across the 391 server-layer network may be provided through virtual TE links or 392 Forwarding Adjacencies: the PCE may offer a point of control 393 responsible for the decision to provision new TE links or Forwarding 394 Adjacencies across the server-layer network. 396 5. Overview of the PCE-Based Architecture 398 This section is gives an overview of the architecture of the PCE 399 model. It needs to be read in conjunction with the details provided 400 in the next section to provide a full view of the flexibility of the 401 model. 403 5.1. Composite PCE Node 405 Figure 1 below shows the components of a typical composite PCE node 406 (that is, a router that also implements the PCE functionality) that 407 utilizes path computation. The routing protocol is used to exchange 408 TE information from which the TED is constructed. Service requests to 409 provision TE LSPs are received by the node and converted into 410 signaling requests, but this conversion may require path computation 411 which is requested from a PCE. The PCE operates on the TED in order 412 to respond with the requested path. 414 --------------- 415 | --------- | Routing ---------- 416 | | | | Protocol | | 417 | | TED |<-+----------+-> | 418 | | | | | | 419 | --------- | | | 420 | | | | | 421 | | Input | | | 422 | v | | | 423 | --------- | | | 424 | | | | | Adjacent | 425 | | PCE | | | Node | 426 | | | | | | 427 | --------- | | | 428 | ^ | | | 429 | |Request | | | 430 | |Response| | | 431 | v | | | 432 | --------- | | | 433 Service | | | | Signaling| | 434 Request | |Signaling| | Protocol | | 435 ------+->| Engine |<-+----------+-> | 436 | | | | | | 437 | --------- | ---------- 438 --------------- 440 Figure 1. Composite PCE Node 442 Note that the routing adjacency between the composite PCE node and 443 any other router may be performed by means of direct connectivity or 444 any tunneling mechanism. 446 5.2. External PCE 448 Figure 2 shows a PCE that is external to the requesting network 449 element. A service request is received by the head-end node and 450 before it can initiate signaling to establish the service, it makes 451 a path computation request to the external PCE. The PCE uses the TED 452 as input to the computation and returns a response. 454 ---------- 455 | ----- | 456 | | TED |<-+------------> 457 | ----- | TED synchronization 458 | | | mechanism (for example, routing protocol) 459 | | | 460 | v | 461 | ----- | 462 | | PCE | | 463 | ----- | 464 ---------- 465 ^ 466 | Request/ 467 | Response 468 v 469 Service ---------- Signaling ---------- 470 Request| Head-End | Protocol | Adjacent | 471 ---->| Node |<---------->| Node | 472 ---------- ---------- 474 Figure 2. External PCE Node 476 Note that in this case, the node that supports the PCE function may 477 also be an LSR or router performing forwarding in its own right (i.e. 478 it may be a composit PCE node), but those functions are purely 479 orthogonal to the operation of the function in the instance being 480 considered here. 482 5.3. Multiple PCE Path Computation 484 Figure 3 illustrates how multiple PCE path computations may be 485 performed along the path of a signaled service. As in the previous 486 example, the head-end PCC makes a request to an external PCE, but the 487 path that is returned is such that the next network element finds it 488 necessary to perform further computation. This may be the case when 489 the path returned is a partial path that does not reach the intended 490 destination or when the computed path is loose. The downstream 491 network element consults another PCE to establish the next hop(s) in 492 the path. 494 Note that either or both PCEs in this case could be composite PCE 495 nodes as in Section 5.1. 497 ---------- ---------- 498 | | | | 499 | PCE | | PCE | 500 | | | | 501 | ----- | | ----- | 502 | | TED | | | | TED | | 503 | ----- | | ----- | 504 ---------- ---------- 505 ^ ^ 506 | Request/ | Request/ 507 | Response | Response 508 v v 509 Service -------- Signaling ------------ Signaling ------------ 510 Request|Head-End| Protocol |Intermediate| Protocol |Intermediate| 511 ---->| Node |<--------->| Node |<--------->| Node | 512 -------- ------------ ------------ 514 Figure 3. Multiple PCE Path Computation 516 5.4. Multiple PCE Path Computation with Inter-PCE Communication 518 The PCE in Section 5.3 was not able to supply a full path for the 519 requested service and this resulted in the adjacent node needing to 520 make its own computation request. As illustrated in Figure 4, the 521 same problem may be solved by introducing inter-PCE communication, 522 and cooperation between PCEs so that the PCE consulted by the 523 head-end network node makes a request of another PCE to help with the 524 computation. 526 ---------- ---------- 527 | | Inter-PCE Request/Response | | 528 | PCE |<--------------------------------->| PCE | 529 | | | | 530 | ----- | | ----- | 531 | | TED | | | | TED | | 532 | ----- | | ----- | 533 ---------- ---------- 534 ^ 535 | Request/ 536 | Response 537 v 538 Service ---------- Signaling ---------- Signaling ---------- 539 Request| Head-End | Protocol | Adjacent | Protocol | Adjacent | 540 ---->| Node |<---------->| Node |<---------->| Node | 541 ---------- ---------- ---------- 543 Figure 4. Multiple PCE Path Computation with Inter-PCE Communication 544 Multiple PCE path computation with inter-PCE communication involves 545 coordination between distributed PCEs such that the result of the 546 computation performed by one PCE depends on information supplied by 547 other PCEs. This model does not provide a distributed computaiton 548 algorithm, but allows distinct PCEs to be responsible for computation 549 of parts (segments) of the path. 551 PCE-PCE communication is discussed further in Section 6.6. 553 Note that a PCC might not see the difference between centralized 554 computation, and multiple PCE path computation with inter-PCE 555 communication. That is, the PCC network node or component that 556 requests the computation makes a single request and receives a full 557 or partial path in response, but the response is actually achieved 558 through the coordinated, cooperative efforts of more than one PCE. 560 5.5 Areas for Standardization 562 The following areas require standardization within the PCE 563 architecture. 565 - communication between PCCs and PCEs, and between cooperating PCEs 567 - requirements for extensions to existing routing and/or signaling 568 protocols in support of PCE discovery and signaling of inter-domain 569 paths 571 - definition of metrics to evaluate path quality, scalability, 572 responsiveness and robustness of path computation models. 574 6. PCE Architectural Considerations 576 This section provides a list of the PCE architectural components. 577 Specific realizations and implementation details (state machines or 578 algorithms, etc.) of PCE-based solutions are out of the scope of this 579 document. 581 Note also that PCE-based path computation does not affect in any way 582 the use of the computed paths. For example, the use of PCE does not 583 change the way in which Traffic Engineering LSPs are signaled, 584 maintained and torn down, but strictly relates to the path 585 computation aspects of such TE LSPs. 587 6.1. Centralized Computation Model 589 A "centralized computation model" considers that all path 590 computations for a given domain will be performed by a single, 591 centralized PCE. This may be a dedicated server (for example, an 592 external PCE node), or a designated router (for example, a composite 593 PCE node) in the network. In this model, all PCCs in the domain would 594 send their path computation requests to the central PCE. While a 595 domain in this context might be an IGP area or AS, it might also be a 596 sub-group of network nodes that is defined by its dependence on the 597 PCE. 599 This model has a single point of failure: the PCE. In order to avoid 600 this issue, the centralized computation model may designate a backup 601 PCE that can take over the computation responsibility in a controlled 602 manner in the event of a failure of the primary PCE. Note that at any 603 moment in time there is only one active PCE in any domain. 605 6.2. Distributed Computation Model 607 A "distributed computation model" refers to a domain or network that 608 may include multiple PCEs, and where computation of paths is shared 609 among the PCEs. A given path may in turn be computed by a single PCE 610 ("single PCE path computation") or multiple PCEs ("multiple PCE path 611 computation"). A PCC may be linked to a particular PCE, or may be 612 able to choose freely among several PCEs - the method of choice 613 between PCEs is out of scope of this document, but see Section 6.4 614 for a discussion of PCE discovery which impacts on this choice. It 615 will often be the case that the computation of an individual path is 616 performed entirely by a single PCE. For example, this is usually the 617 case in MPLS TE within a single IGP area where the ingress LSR / 618 composite PCE node is responsible for computing the path or for 619 contacting an external PCE. Conversely, multiple PCE path computation 620 implies that more than one PCE is involved in the computation of a 621 single path. An example of this is where loose hop expansion is 622 performed by transit LSRs / composite PCE nodes on an MPLS TE LSP. 623 Another example is the use of multiple cooperating PCEs to compute 624 the path of a single LSP. 626 6.3. Synchronization 628 It is often the case that multiple paths need to be computed to 629 support a single service (for example, for protection or load 630 sharing). A PCC that determines that it requires more than one path 631 to be computed may send a series of individual requests to the PCE. 632 In this case of non-synchronized path computation, the PCE will make 633 multiple individual path computations to generate the paths and the 634 PCC may send its individual requests to different PCEs. 636 Alternatively, the PCC may send a single request to a PCE asking for 637 a set of paths to be computed but specifying that non-synchronized 638 path computation is acceptable. The PCE may compute each path in turn 639 exactly as it would have done had the PCC made multiple requests, and 640 the PCE may devolve some computations to other PCEs if it chooses. 642 Conversely, the PCC may issue a single request to the PCE asking for 643 all of the paths to be computed in a synchronized manner. The PCE 644 will then perform simultaneous computation of the set of requested 645 path. Such synchronized computation can often provide more optimal 646 results. 648 The involvement of more than one PCE in the computation of a series 649 of paths is by its nature non-synchronized. However, a set of 650 cooperating PCEs may be synchronized under the control of a single 651 PCE. For example, a PCC may send a request to a PCE which invokes 652 domain specific computations by other PCEs before supplying a result 653 to the PCC. 655 It is desirable to add a parameter to the PCC-PCE protocol to request 656 that the PCE supplies a set of alternate paths for use by the PCC 657 should the establishment of the LSP using the principal path fail to 658 complete. While alternate paths may not always be successful if the 659 first path fails, including alternate paths in a PCE response could 660 have less overhead than having the PCC make separate requests for 661 subsequent path computations as the need arises. This technique is 662 used in some existing CSPF implementations. 664 6.4. PCE Discovery and Load Balancing 666 The PCE architecture requires that the PCC/PCE know the location of 667 one or more PCEs that it can use for the computation of a path. Such 668 knowledge may come through a discovery mechanism that simply relies 669 on local configuration, or can imply dynamic PCE discovery along with 670 various static (for example, Boolean capability) or dynamically 671 computed variables (for example, computing resources). Proxy PCE 672 advertisement whereby the existence of a PCE is advertised via a 673 proxy PCE is a viable alternative, should the PCE be incapable of 674 such advertisement itself. In this later case, it is a requirement 675 for the proxy to adequately advertise the PCE status and capability 676 in a timely and synchronized fashion. 678 In the event that multiple PCEs are available to serve a particular 679 path computation request, the PCC must select a PCE to satisfy the 680 request. The details of such a selection, in order for instance to 681 efficiently share the computation load across multiple PCEs, is local 682 to the PCC and out of the scope of this document. 684 A PCE SHOULD advertise its capabilities, such as: 686 - set of constraints that it can account for (diversity, SRLGs, 687 Optical impairments, wavelength continuity, etc.) 688 - number of switching capability layers (and which ones) 689 - number of path selection criteria (and which ones) 690 - whether it is a stateless PCE or it can send updates about 691 better paths that might be available in the future 692 - whether it can compute P2MP trees (and which types) 693 - whether it can ensure resource sharing between backup tunnels. 695 This information would help a PCC that dynamically learns about 696 PCEs available on the network to decide which of them to use. 697 Alternatively, a PCC might ask a PCE to perform a particular type 698 of service and receive a response that says that the PCE is unable to 699 perform the service, but specifying the things that the PCE can do. 700 Note that the parameters mentioned above are not meant to be 701 exhaustive and are listed for the sake of illustration. 703 6.5. Detecting PCE Liveness 705 The ability to detect a PCE's liveness is a mandatory piece of the 706 overall architecture and could be achieved by several means. If some 707 form of regular advertisement (such as through IGP extensions) is 708 used for PCE discovery, it is expected that the PCE liveness will be 709 determined by means of status advertisement (for example, IGP 710 LSA/LSPs). 712 The inability of a PCE to service a request (perhaps due to excessive 713 load) may be reported to the PCC through a failure message, but the 714 failure of a PCE or the communications mechanism while processing a 715 request cannot be reported in this way. Further, in the case of 716 excessive load, the PCE may not have sufficient resources to send a 717 failure message. Thus the PCC should employ other mechanisms such as 718 protocol timers to determine the liveness of the PCE. This is 719 particularly important in the case of inter-domain path computation 720 where the PCE liveness may not be detected by means of the IGP that 721 runs in the PCC's domain. 723 6.6. PCC-PCE & PCE-PCE Communication 725 Once the PCC has selected a PCE, and provided that the PCE is not 726 local to the PCC, a request/response protocol is required for the PCC 727 to communicate the path computation requests to the PCE and for the 728 PCE to return the path computation response. 730 The path computation request may include a significant set of 731 requirements including 733 - the source and destination of the path 734 - the bandwidth and other QoS parameters desired 735 - resources, resource affinities and shared risk link groups (SRLGs) 736 to use/avoid 737 - the number of disjoint paths required and if near-disjoint paths 738 are acceptable 739 - the level of robustness of the path resources 740 - and so on. 742 The level of robustness of the path resources covers a qualitative 743 assessment of the vulnerability of the resources that may be used. 744 For example, one might grade resources based on empirical evidence 745 (mean time between failures), on known risks (there is major building 746 work going on near this conduit), or on prejudice (vendor X's 747 software is always crashing). A PCC could request that only robust 748 resources be used, or allow any resource. 750 In case of a positive response from the PCE, one or more paths would 751 be returned to the requesting node. In the event of a failure to 752 compute the desired path(s), an error is returned together with as 753 much information as possible about the reasons for the failure(s), 754 and potentially with advice about which constraints might be relaxed 755 to be more likely to achieve a positive result in a future request. 757 Note that the resultant path(s) may be made up of a set of strict or 758 loose hops, or any combination of strict and loose hops. Moreover, a 759 hop may have the form of a non-explicit abstract node. 761 A request/response protocol is also required for a PCE to communicate 762 path computation requests to another PCE and for the PCE to return 763 the path computation response. The path computation request may 764 include a significant set of requirements including those defined 765 above. In case of a positive response from the PCE, one or more paths 766 would be returned to the requesting PCE. In the event of a failure to 767 compute the desired path(s), an error is returned together with as 768 much information as possible about the reasons for the failure, and 769 potentially advice about which constraints might be relaxed to be 770 more likely to achieve a positive result. Note that the resultant 771 path(s) may be made up of a set of strict or loose hops, or any 772 combination of strict and loose hops. Moreover, a hop may have the 773 form of a non-explicit abstract node. 775 An important feature of PCEs that are cooperating to compute a path 776 is that they apply compatible or identical computation algorithms. 777 This may require coordination through the communication between the 778 PCEs. 780 Note that when multiple PCEs cooperate to compute a path it is 781 important that they have a coordinated view of the meaning of 782 constraints such as resource affinities and class of service. This 783 is particularly significant where the PCEs are responsible for 784 different domains. It is assumed that this is a matter of policy 785 between domains and between PCEs, and is achieved through 786 configuration not through protocol communications. 788 No assumption is made in this architecture about whether the PCC-PCE 789 and PCE-PCE communication protocols are identical. 791 6.7. PCE TED Synchronization 793 As previously described, the PCE operates on a TED. Information on 794 network status to build the TED may be provided in the domain by 795 various means: 797 1) Participation in IGP distribution of TE information. The standard 798 method of distribution of TE information within an IGP area is 799 through the use of extensions to the IGP [RFC3630, RFC3748]. This 800 mechanism allows participating nodes to build a TED, and this is 801 the standard technique, for example, within a single area MPLS 802 network. A node that hosts the PCE function may collect TE 803 information in this way by maintaining at least one routing 804 adjacency with a router in the domain. The PCE node may be 805 adjacent or non-adjacent (via some tunneling techniques) to the 806 router. Such a technique provides a mechanism for ensuring that 807 the TED is efficiently synchronized with the network state and is 808 the normal case, for example, when the PCE is co-resident with the 809 LSRs in an MPLS network. 811 2) Out-of-band TED synchronization. It may not be convenient or 812 possible for a PCE to participate in the IGPs of one or more 813 domains (for example, when there are very many domains, when IGP 814 participation is not desired, or when some domains are not running 815 TE-aware IGPs). In this case some mechanism may need to be defined 816 to allow the PCE node to retrieve the TED from each domain. Such a 817 mechanism could be incremental (like the IGP in the previous 818 case), or could involve a bulk transfer of the complete TED. The 819 latter might significantly limit the capability to ensure TED 820 synchronization which might result in an increase in the failure 821 rate of computed paths. Consideration should also be given to the 822 impact of the TED distribution on the network and on the network 823 node within the domain that is asked to distribute the database. 824 This is particularly relevant in the case of frequent network 825 state changes. 827 3) Information in the TED can include information obtained from 828 sources other than the IGP. For example, information about link 829 usage policies can be configured by the operator. Path computation 830 can also act on a far wider set of information that includes data 831 about the LSPs provisioned within the network. This information 832 can include LSP routes, reserved bandwidth, and measured traffic 833 volume passing through the LSP. 835 Such LSP information can enhance LSP reoptimization to provide 836 "full network" reoptimization, and can allow traffic fluctuations 837 to be taken into account. Detailed LSP information may also 838 facilitate reconfiguration of the Virtual Network Topology (VNT) 839 [MRN], in which lower layer LSPs such as optical paths provide TE 840 links for use by the higher layer, since this reconfiguration is 841 also a "full network" problem. 843 Note that synchronization techniques may apply to both intra- and 844 inter-domain TEDs. Further, the techniques can be mixed for use in 845 different domains. The degree of synchronization between the PCE and 846 the network is subject to implementation and/or policy. However, 847 better synchronization generally leads to paths that are more likely 848 to succeed. 850 It must also be highlighted that the PCE may have access to only a 851 partial TED: for instance in the case of inter-domain path 852 computation where each such domain may be managed by different 853 entities. In such cases, each PCE may have access to a partial TED 854 and cooperative techniques between PCEs may be used to achieve 855 end-to-end path computation without any requirement for any PCE to 856 handle the complete TED related to the set of traversed domains by 857 the LSP path in question. 859 6.8. Stateful Versus Stateless PCEs 861 A PCE can be either stateful or stateless. In the former case, there 862 is a strict synchronization between the PCE and not only the network 863 states (in term of topology and resource information), but also the 864 set of computed paths and reserved resources in use in the network. 865 In other words, the PCE utilizes information from the TED as well as 866 information about existing paths (for example, TE LSPs) in the 867 network when processing new requests. Note that although this allows 868 for optimal path computation and increased path computation success, 869 stateful PCEs require reliable state synchronization mechanisms, with 870 potentially significant control plane overhead and the maintenance of 871 a large amount of data/states (for example, full mesh of TE LSPs). 873 For example, if there is only one PCE in the domain, all LSP 874 computation is done by this PCE, which can then track all the 875 existing LSPs and stay synchronized. However, this model could 876 require substantial control plane resources. If there are multiple 877 PCEs in the network, LSP computation and information is distributed 878 among PCEs and so the resources required to perform the computations 879 are also distributed. However, synchronization issues discussed in 880 Section 6.7 also come into play. 882 The maintenance of a stateful database can be non-trivial. However, 883 in a single centralized PCE environment, a stateful PCE is almost a 884 simple matter of remembering all of the LSPs the PCE has computed, 885 if it can also be known that the LSPs were actually set up, and when 886 they were torn down. Out-of-band TED synchronization can also be 887 complex with multiple PCE setup in a distributed PCE computation 888 model, and could be prone to race conditions, scalability concerns, 889 etc. Even if the PCE has detailed information on all paths, 890 priorities, and layers, taking such information into account for path 891 computation could be highly complex. PCEs might synchronize state by 892 communicating with each other, but when LSPs are set up using 893 distributed computation performed among several PCEs, the problem of 894 synchronization becomes larger and more complex. 896 There is benefit in knowing which LSPs exist, and their routing, to 897 support such applications as placing a high priority LSP in a crowded 898 network such that it preempts as few other LSPs as possible. Note 899 that preempting based on the minimum number of links might not result 900 in the smallest number of LSPs being disrupted. Another application 901 concerns the construction and maintenance of a Virtual Network 902 Topology [MRN]. It is also helpful to understand which other LSPs 903 exist in the network in order to decide how to manage the forward 904 adjacencies that exist or need to be set up. The cost-benefit of 905 stateful PCE computation would be helpful to determine if the benefit 906 in path computation is sufficient to offset the additional drain on 907 the network and computational resources. 909 Conversely, stateless PCEs do not have to remember any computed path 910 and each set of request(s) is processed independently of each other. 911 For example, stateless PCEs may compute paths based on current TED 912 information, which could be out of sync with actual network state 913 given other recent PCE-computed paths changes. Note that a PCC may 914 include a set of previously computed paths in its request, in order 915 to take them into account, for instance to avoid double bandwidth 916 accounting, or to try to minimize changes (minimum perturbation 917 problem). 919 It should be observed that the stateless PCE does operate on 920 information about network state. The TED contains link state and 921 bandwidth availability information as distributed by the IGPs or 922 collected through some other means. This information could be 923 further enhanced to provide increased granularity and more detail to 924 cover, for example, the current bandwidth usage on certain links 925 according to resource affinities or forwarding equivalence classes. 926 Such information is, however, not PCE state information and so a 927 model that uses it is still described as stateless in the PCE 928 context. 930 A limited form of statefulness might be applied within an otherwise 931 stateful PCE. The PCE may retain some context from paths it has 932 recently computed so that it avoid suggesting the use of the same 933 resources for other LSPs. 935 6.9. Monitoring 937 PCE Monitoring is undoubtedly of the utmost importance in any PCE 938 architecture. This must include the collection of variables related 939 to the PCE status and operation. For example, it will be necessary to 940 understand the way in which the TED is being kept synchronized, the 941 rate of arrival of new requests and the computation times, the range 942 of PCCs that are using the PCE, and the operation of any PCC-PCE 943 protocol. 945 6.10. Policy and Confidentiality 947 As stated in [INTER-AS], the case of inter-provider TE LSP path 948 computation requires the ability to compute a path while preserving 949 confidentiality across multiple Service Providers cores. Thus any PCE 950 architecture solution must support the ability to return partial 951 paths by means of loose hops (for example, where each loose hops 952 would for instance identify a boundary LSR). Confidentiality and 953 security of PCC-PCE and PCE-PCE messages must also be ensured. 955 The ability to compute a path at the request of the head end PCC, but 956 to supply the path in segments to the domain boundary PCCs may also 957 be desirable. 959 6.11. Unsolicited Interactions 961 It may be that the PCC-PCE communications (see section 6.6) can be 962 usefully extended beyond a simple request/response interaction. For 963 example, the PCE and PCC could exchange capabilities using this 964 protocol. Additionally, the protocol could be used to collect and 965 report information in support of a stateful PCE. 967 Further, it may be the case that a PCE is able to update a path that 968 it computed earlier (perhaps in reaction to a change in the network), 969 and in this case the PCE-PCC communication could support an 970 "unsolicited" path computation message to supply this new path to the 971 PCC. It should be noted, however, that this function would require 972 that the PCE retained a record of previous computations and had a 973 clear trigger for performing recomputations. The PCC would also need 974 to be able to identify the new path with the old path and determine 975 whether it should act on the new path. Note that the PCE-PCC 976 interaction is not a management interaction and the PCC is not 977 obliged to utilize any additional path supplied by the PCE. 979 These functions fit easily within the architecture described here 980 but are left for further discussion within separate requirements 981 documents. 983 7. Evaluation Metrics 985 Evaluation metrics that may be used to evaluate the efficiency and 986 applicability of any PCE-based solution are listed below. Note that 987 these metrics are not being used to determine paths, but are used to 988 evaluate potential solutions to the PCE architecture. 990 - Optimality: The ability to maximize network utilization and 991 minimize cost, considering QoS objectives, multiple regions and 992 network layers. Note that models that require the sequential 993 involvement of multiple PCEs (for example, the multiple PCE model 994 described in section 5.3) have an inherent risk of lower quality 995 paths and might create path loops unless careful policy is applied. 997 - Scalability: The implications of routing, LSP signaling and PCE 998 communication overhead such as the number of messages and the size 999 of messages (includes LSAs, crankbacks, queries, distribution 1000 mechanisms, etc.). 1002 - Load sharing: The ability to allow multiple PCEs to spread the path 1003 computation load by allowing multiple PCEs to each take 1004 responsibility for a subset of the total path computation requests. 1006 - Multi-path computation: The ability to compute multiple and 1007 potentially diverse paths to satisfy load-sharing of traffic and 1008 protection/restoration needs including end-to-end diversity and 1009 protection within individual domains. 1011 - Reoptimization: The ability to perform TE LSP path reoptimization. 1012 This also includes the ability to perform inter-layer correlation 1013 when considering the reoptimization at any specific layer. 1015 - Path computation time: The time to compute individual paths, 1016 multiple diverse paths, and to satisfy bulk path computation 1017 requests. (Note that such a metric can only be applied to problems 1018 that are not NP-complete.) 1020 - Network stability: The ability to minimize any perturbation on 1021 existing TE state resulting from the computation and establishment 1022 of new TE paths. 1024 - Ability to maintain accurate synchronization between TED and 1025 network topology and resource states. 1027 - Speed with which TED synchronization is achieved. 1029 - Impact of the synchronization process on the data flows in the 1030 network. 1032 Note that other metrics may also be considered. Such metrics should 1033 be used when evaluating a particular PCE-based architecture. It must 1034 also be highlighted that the potential tradeoffs of the optimization 1035 of such metrics should be evaluated (for instance, increasing the 1036 path optimality is likely to have consequences on the computation 1037 time). 1039 8. Manageability Considerations 1041 The PCE architecture introduces several elements that are subject to 1042 manageability. The PCE itself must be managed as must its 1043 communications with PCCs and other PCEs. The mechanism by which PCEs 1044 and PCCs discover each other are also subject to manageability. 1046 Many of the issues of manageability are already covered in other 1047 sections of this document. 1049 8.1 Information and Data Models 1051 It is expected that the operations of PCEs and PCCs will be modeled 1052 and controlled through appropriate MIB modules. These will be 1053 relatively simple constructs since the relationships between PCEs and 1054 PCCs are quite simple. The tables in the new MIB modules will need to 1055 reflect the relationships between entities and to control and report 1056 on configurable options. 1058 Statistics gathering will form an important part of the operation of 1059 PCEs. The operator must be able to determine the historical 1060 interactions of a PCC with its PCEs, the performance that it has 1061 seen, and success rate of its requests. Similarly, it is important 1062 for an operator to be able to inspect a PCE and determine its load 1063 and whether an individual PCC is responsible for a disproportionate 1064 amount of the load. It will also be important to be able to record 1065 and inspect statistics about the communications between the PCC and 1066 PCE, including issues such as malformed messages, unauthorized 1067 messages and messages discarded owing to congestion. In this respect 1068 there is clearly an overlap between manageability and security. 1070 Statistics for the PCE architecture can be made available through 1071 appropriate tables in the new MIB modules. 1073 The new MIB modules should also be used to provide notifications 1074 (formerly known as traps) when key thresholds are crossed or when 1075 important events occur. Great care must be exercised to ensure that 1076 the network is not flooded with SNMP notifications. Thus it might be 1077 inappropriate to issue a notification every time that a PCE receives 1078 a request to compute a path. In any case, full control must be 1079 provided through the MIB modules to allow notifications to be 1080 disabled. 1082 8.2 Liveness Detection and Monitoring 1084 Section 6.5 discusses the importance of a PCC being able to detect 1085 the liveness of a PCE. PCE-PCC communications techniques must enable 1086 a PCC to determine the liveness of a PCE both before it sends a 1087 request and in the period between sending a request and receiving a 1088 response. 1090 It is less important for a PCE to know about the liveness of PCCs, 1091 and within the simple request/response model, this is only helpful: 1093 - to gain a predictive view of the likely loading of a PCE in the 1094 future 1096 - to allow a PCE to abandon processing of a received request. 1098 8.3 Verifying Correct Operation 1100 Correct operation for the PCE architecture can be classified as 1101 determining the correct point-to-point connectivity between PCCs and 1102 PCEs, and assessing the validity of the computed paths. The former is 1103 a security issue that may be enhanced by authentication and monitored 1104 through event logging and records as described in Section 8.1. 1106 Verifying computed paths is more complex. The information to perform 1107 this function can, however, be made available to the operator through 1108 MIB tables provided full records are kept of the constraints passed 1109 on the request, the path computed and provided on the response, and 1110 any additional information supplied by the PCE such as the constraint 1111 relaxation policies applied. 1113 8.4 Requirements on Other Protocols and Functional Components 1115 At the architectural stage it is impossible to make definitive 1116 statements about the impact on other protocols and functional 1117 components since the solutions work has not been completed. However, 1118 it is possible to make some observations. 1120 - Dependence on underlying transport protocols 1122 PCE-PCC communications may choose to utilize underlying protocols 1123 to provide transport mechanisms. In this case some of the 1124 manageability considerations described in the previous sections may 1125 be devolved to those protocols. 1127 - Re-use of existing protocols for discovery 1129 Without prejudicing the requirements and solutions work for PCE 1130 discovery (see Section 6.4) it is possible that use will be made of 1131 existing protocols to facilitate this function. In this case some 1132 of the manageability considerations described in the previous 1133 sections may be devolved to those protocols. 1135 - Impact on LSRs and LSP signaling 1137 The primary example of a PCC identified in this architecture is an 1138 MPLS LSR. Consideration must therefore be given to the 1139 manageability of the LSRs and the additional manageability 1140 constraints applicable to the LSP signaling protocols. 1142 As well as allowing the PCC management described in the previous 1143 sections, an LSR must be configurable to determine whether it will 1144 use a remote PCE at all - the options being to use hop-by-hop 1145 routing or to supply the PCE function itself. It is likely to be 1146 important to be able to distinguish within an LSR whether the path 1147 used for an LSP was supplied in a signaling message, by an 1148 operator, or by a PCE, and in the case where it was supplied in a 1149 signaling message whether it was enhanced or expanded by a PCE. 1151 8.5 Impact on Network Operation 1153 This architecture may have two impacts on the operation of a network. 1154 It increases LSP setup times while requests are sent to and processed 1155 by a remote PCE, and it may cause congestion within the network if a 1156 significant number of computation requests are issued in a small 1157 period of time. These issues are most severe in busy networks and 1158 after network failures although the effect may be mitigated if the 1159 protection paths are precomputed. 1161 Issues of potential congestion during recovery from failures may be 1162 mitigated through the use of pre-established protection schemes such 1163 as fast reroute. 1165 It is important that network congestion be managed proactively 1166 because it may be impossible to manage it reactively once the network 1167 is congested. It should be possible for an operator to rate limit the 1168 requests that a PCC sends to a PCE, and a PCE should be able to 1169 report impending congestion (according to a configured threshold) 1170 both to the operator and to its PCCs. 1172 9. Security Considerations 1174 The impact of the use of a PCE-based architecture must be considered 1175 in the light of the impact that it has on the security of the 1176 existing routing and signaling protocols and techniques in use within 1177 the network. There is unlikely to be any impact on intra-domain 1178 security, but an increase in inter-domain information flows and the 1179 facilitation of inter-domain path establishment may increase the 1180 vulnerability to security attacks. 1182 Of particular relevance are the implications for confidentiality 1183 inherent in a PCE-based architecture for multi-domain networks. It is 1184 not necessarily the case that a multi-domain PCE solution will 1185 compromise security, but solutions MUST examine their effects in this 1186 area. 1188 Applicability statements for particular combinations of signaling, 1189 routing and path computation techniques are expected to contain 1190 detailed security sections. 1192 It should be observed that the use of a non-local PCE (that is, not 1193 co-resident with the PCC) does introduce additional security issues. 1194 Most notable amongst these are: 1196 - Interception of PCE requests or responses 1198 - Impersonation of PCE 1200 - Falsification of TE information 1202 - Denial of service attacks on PCE or PCE communication mechanisms. 1204 It is expected that PCE solutions will address these issues in detail 1205 using authentication and security techniques. 1207 10. IANA Considerations 1209 This informational document makes no requests for IANA action. 1211 11. Acknowledgements 1213 The authors would like to extend their warmest thanks to (in 1214 alphabetical order) Arthi Ayyangar, Zafar Ali, Mohamed Boucadair, 1215 Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella, 1216 Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou, 1217 Richard Rabbat, Takao Shimizu, and Raymond Zhang for their review and 1218 suggestions. 1220 12. Intellectual Property Considerations 1222 The IETF takes no position regarding the validity or scope of any 1223 Intellectual Property Rights or other rights that might be claimed to 1224 pertain to the implementation or use of the technology described in 1225 this document or the extent to which any license under such rights 1226 might or might not be available; nor does it represent that it has 1227 made any independent effort to identify any such rights. Information 1228 on the procedures with respect to rights in RFC documents can be 1229 found in BCP 78 and BCP 79. 1231 Copies of IPR disclosures made to the IETF Secretariat and any 1232 assurances of licenses to be made available, or the result of an 1233 attempt made to obtain a general license or permission for the use of 1234 such proprietary rights by implementers or users of this 1235 specification can be obtained from the IETF on-line IPR repository at 1236 http://www.ietf.org/ipr. 1238 The IETF invites any interested party to bring to its attention any 1239 copyrights, patents or patent applications, or other proprietary 1240 rights that may cover technology that may be required to implement 1241 this standard. Please address the information to the IETF at 1242 ietf-ipr@ietf.org. 1244 13. Normative References 1246 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 1247 RFC 3667, February 2004. 1249 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 1250 Technology", BCP 79, RFC 3668, February 2004. 1252 14. Informational References 1254 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and 1255 J. McManus, "Requirements for Traffic Engineering over 1256 MPLS", RFC 2702, September 1999. 1258 [RFC2547] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC2547, 1259 March 1999. 1261 [RFC3209] Awduche, D., et. all, "Extensions to RSVP for LSP 1262 Tunnels", RFC 3209, December 2001. 1264 [RFC3630] Katz et al., "Traffic Engineering (TE) Extensions to 1265 OSPF Version 2", RFC3630, September 2003. 1267 [RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label 1268 Switching (GMPLS) Signaling - Resource ReserVation 1269 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1270 RFC 3473, January 2003. 1272 [RFC3748] Smit, H. and Li, T., "Intermediate System to 1273 Intermediate System (IS-IS) - Extensions for Traffic 1274 Engineering (TE)", RFC3784, June 2004. 1276 [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for 1277 Support of Inter-Area and Inter-AS MPLS Traffic 1278 Engineering", RFC 4105, June 2005. 1280 [INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic 1281 Engineering requirements", 1282 draft-ietf-tewg-interas-mpls-te-req, work in progress. 1284 [MRN] Shiomoto, K., et. al., "Requirements for GMPLS-based 1285 multi-region and multi-layer networks", 1286 draft-shiomoto-ccamp-gmpls-mrn-reqs, work in progress. 1288 15. Authors' Addresses 1290 Adrian Farrel 1291 Old Dog Consulting 1292 EMail: adrian@olddog.co.uk 1294 Jean-Philippe Vasseur 1295 Cisco Systems, Inc. 1296 300 Beaver Brook Road 1297 Boxborough , MA - 01719 1298 USA 1299 Email: jpv@cisco.com 1301 Jerry Ash 1302 AT&T 1303 Room MT D5-2A01 1304 200 Laurel Avenue 1305 Middletown, NJ 07748, USA 1306 Phone: +1-(732)-420-4578 1307 Fax: +1-(732)-368-8659 1308 Email: gash@att.com 1310 16. Full Copyright Statement 1312 Copyright (C) The Internet Society (2005). This document is subject 1313 to the rights, licenses and restrictions contained in BCP 78, and 1314 except as set forth therein, the authors retain all their rights. 1316 This document and the information contained herein are provided on an 1317 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1318 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1319 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1320 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1321 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1322 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.