idnits 2.17.1 draft-ietf-pce-architecture-02.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 1569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1485. ** 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 780: '... A PCE SHOULD advertise its capabili...' RFC 2119 keyword, line 1429: '...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 (September 2005) is 6796 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 1489, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 1492, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 1497, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1504, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 1510, but no explicit reference was found in the text == Unused Reference: 'RFC4105' is defined on line 1524, 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: March 2006 Cisco Systems, Inc. 5 Jerry Ash 6 AT&T 8 September 2005 10 draft-ietf-pce-architecture-02.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 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 1. Introduction ................................................... 3 54 2. Terminology .................................................... 3 55 3. Definitions .................................................... 4 56 4. Motivation for a PCE-based Architecture ........................ 6 57 4.1. CPU-intensive Path Computation ............................. 6 58 4.2. Partial Visibility ......................................... 7 59 4.3. Absence of the TED or Use of Non-TE-Enabled IGP ............ 7 60 4.4. Node Outside the Routing Domain ............................ 8 61 4.5. Network Element Lacks Control Plane or Routing Capability .. 8 62 4.6. Backup Path Computation for Bandwidth Protection ........... 8 63 4.7. Multi-Layer Networks ....................................... 8 64 4.8. Non-Motivations ............................................ 9 65 4.8.1. The Whole Internet .................................... 9 66 4.8.2. Guaranteed TE LSP Establishment ....................... 9 67 5. Overview of the PCE-Based Architecture ........................ 10 68 5.1. Composite PCE Node ........................................ 10 69 5.2. External PCE .............................................. 11 70 5.3. Multiple PCE Path Computation ............................. 11 71 5.4. Multiple PCE Path Computation with Inter-PCE Communication 12 72 5.5. Management-Based PCE Usage ................................ 13 73 5.6. Areas for Standardization ................................. 14 74 6. PCE Architectural Considerations .............................. 14 75 6.1. Centralized Computation Model ............................. 14 76 6.2. Distributed Computation Model ............................. 15 77 6.3. Synchronization ........................................... 15 78 6.4. PCE Discovery and Load Balancing .......................... 16 79 6.5. Detecting PCE Liveness .................................... 17 80 6.6. PCC-PCE & PCE-PCE Communication ........................... 17 81 6.7. PCE TED Synchronization ................................... 18 82 6.8. Stateful Versus Stateless PCEs ............................ 20 83 6.9. Monitoring ................................................ 21 84 6.10. Policy and Confidentiality .............................. 22 85 6.11. Unsolicited Interactions ................................. 23 86 6.12. Relationship with Crankback .............................. 23 87 7. The View from the Path Computation Client ..................... 24 88 8. Evaluation Metrics ............................................ 25 89 9. Manageability Considerations .................................. 26 90 9.1. Control of Function and Policy ............................ 26 91 9.2. Information and Data Models ............................... 26 92 9.3. Liveness Detection and Monitoring ......................... 27 93 9.5. Verifying Correct Operation ............................... 27 94 9.5. Requirements on Other Protocols and Functional Components . 28 95 9.6. Impact on Network Operation ............................... 29 96 10. Security Considerations ...................................... 29 97 11. IANA Considerations .......................................... 30 98 12. Acknowledgements ............................................. 30 99 13. Intellectual Property Considerations ......................... 30 100 14. Normative References ......................................... 30 101 15. Informational References ..................................... 31 102 16. Contact Information .......................................... 31 103 17. Full Copyright Statement ..................................... 32 105 1. Introduction 107 Constraint-based path computation is a fundamental building block for 108 traffic engineering in MPLS and GMPLS networks. Path computation in 109 large, multi-domain networks is complex and may require 110 special computational components and cooperation between the elements 111 in different domains. This document specifies the architecture for a 112 Path Computation Element (PCE)-based model to address this problem 113 space. 115 This document describes a set of building blocks for the PCE 116 architecture from which solutions may be constructed. For example, it 117 discusses PCE-based implementations including composite, external, 118 and multiple PCE path computation. Furthermore, it discusses 119 architectural considerations including centralized computation, 120 distributed computation, synchronization, PCE discovery and load 121 balancing, detection of PCE liveness, PCC-PCE and PCE-PCE 122 communication, TED synchronization, stateful and stateless PCEs, 123 monitoring, policy and confidentiality, and evaluation metrics. 125 The model of the Internet is to distribute network functionality 126 (e.g., routing) within the network. PCE functionality is not intended 127 to contradict this model, and can be used to exactly match the model, 128 for example, when the PCE functionality co-exists with each LSR in 129 the network. PCE is also able to augment functionality in the network 130 where the Internet model cannot supply adequate solutions, for 131 example, where traffic engineering information is not exchanged 132 between network domains. 134 2. Terminology 136 CSPF: Constraint-based Shortest Path First. 138 LER: Label Edge Router. 140 LSDB: Link State Database. 142 LSP: Label Switched Path. 144 LSR: Label Switching Router. 146 PCC: Path Computation Client : any client application requesting a 147 path computation to be performed by the Path Computation Element. 149 PCE: Path Computation Element: an entity (component, application or 150 network node) that is capable of computing a network path or route 151 based on a network graph and applying computational constraints (see 152 further description in Section 3). 154 TED: Traffic Engineering Database which contains the topology and 155 resource information of the domain. The TED may be fed by IGP 156 extensions or potentially by other means. 158 TE LSP: Traffic Engineering MPLS Label Switched Path. 160 3. Definitions 162 A Path Computation Element (PCE) is an entity that is capable of 163 computing a network path or route based on a network graph, and of 164 applying computational constraints during the computation. The PCE 165 entity is an application that can be located within a network node or 166 component, on an out-of-network server, etc. For example, a PCE would 167 be able to compute the path of a TE LSP by operating on the TED and 168 considering bandwidth and other constraints applicable to the TE LSP 169 service request. 171 A domain is any collection of network elements within a common sphere 172 of address management or path computation responsibility. Examples of 173 domains include IGP areas, Autonomous Systems (ASs), and multiple ASs 174 within a Service Provider network. However, domains of path 175 computation responsibility may also exist as sub-domains of areas or 176 ASs. 178 In order to fully characterize a PCE and clarify these definitions, 179 the following important considerations must also be examined: 181 1) Path computation is applicable in intra-domain, inter-domain, and 182 inter-layer contexts. 184 a. Inter-domain path computation may involve the correlation of 185 topology and routing information between domains. 187 b. Inter-layer path computation refers to the use of PCE where 188 multiple layers are involved and when the objective is to 189 perform path computation at one or multiple layers while taking 190 into account topology and resource information at these layers. 192 Overlapping domains are not within the scope of this document. In 193 the inter-domain case, the domains may belong to a single or 194 multiple Service Providers. 196 2) a. In "single PCE path computation," a single PCE is used to 197 compute a given path in a domain. There may be multiple PCEs in 198 a domain, but only one PCE per domain is involved in any single 199 path computation. 201 b. In "multiple PCE path computation," multiple PCEs are used to 202 compute a given path in a domain. 204 3) a. "Centralized computation model" refers to a model whereby all 205 paths in a domain are computed by a single, centralized PCE. 207 b. Conversely, "Distributed computation model" refers to the 208 computation of paths in a domain being shared among multiple 209 PCEs. 211 Paths that span multiple domains may be computed using the 212 distributed model with one or more PCEs responsible for each 213 domain, or the centralized model by defining a domain that 214 encompasses all of the other domains. 216 From these definitions, a centralized computation model inherently 217 uses single PCE path computation. However, a distributed 218 computation model could use either single PCE path computation or 219 multiple PCE path computations. There would be no such thing as a 220 centralized model which uses multiple PCEs. 222 4) The PCE may or may not be located at the head-end of the path. For 223 example, a conventional intra-domain solution is to have path 224 computation performed by the head-end LSR of an MPLS TE LSP; in 225 this case, the head-end LSR contains a PCE. But solutions also 226 exist where other nodes on the path must contribute to the path 227 computation (for example, loose hops) making them PCEs in their 228 own right. At the same time, the path computation may be made by 229 some other PCE physically distinct from the computed path. 231 5) The path computed by the PCE may be an "explicit path" (that 232 is, the full explicit path from start to destination, made of a 233 list of strict hops) or a "strict/loose path" (that is, a mix 234 of strict and loose hops comprising at least one loose hop 235 representing the destination), where a hop may be an abstract node 236 such as an AS. 238 6) A PCE-based path computation model does not mean to be exclusive 239 and can be used in conjunction with other path computation models. 240 For instance, the path of an inter-AS TE LSP may be computed using 241 a PCE-based path computation model in some ASs, whereas the 242 set of traversed ASs may be specified by other means (not 243 determined by a PCE). Furthermore, different path computation 244 models may be used for different TE LSPs. 246 7) This document does not make any assumptions about the nature or 247 implementation of a PCE. A PCE could be implemented on a router, 248 an LSR, a dedicated network server, etc. Moreover, the PCE 249 function is orthogonal to the forwarding capability of the node on 250 which it is implemented. 252 4. Motivation for a PCE-based Architecture 254 Several motivations for a PCE-based architecture (described in 255 Section 5) are listed below. This list is not meant to be exhaustive 256 and is provided for the sake of illustration. 258 It should be highlighted that the aim of this section is to provide 259 some application examples for which a PCE-based path may be suitable: 260 this also clearly states that such a model does not aim to replace 261 existing path computation models but would apply to specific existing 262 or future situations. 264 As can be seen from these examples, PCE does not replace the existing 265 Internet model where intelligence is distributed within the network. 266 Instead, it builds on this model and makes use of distributed centers 267 of information or computational ability. PCE should not, therefore, 268 necessarily be seen as a centralized, "all-seeing oracle in the sky", 269 but as the cooperative operation of distributed functionality used to 270 address specific challenges such as the computation of a shortest 271 inter-domain constrained path. 273 4.1. CPU-intensive Path Computation 275 There are many situations where the computation of a path may be 276 highly CPU-intensive: examples of CPU-intensive path computations 277 include the resolution of problems such as: 279 - Placing a set of TE LSPs within a domain so 280 as to optimize an objective function (for example, minimization of 281 the maximum link utilization) 283 - Multi-criteria path computation (for example, delay and link 284 utilization, inclusion of switching capabilities, adaptation 285 features, encoding types and optical constraints within a GMPLS 286 optical network) 288 - Computation of minimal cost Point to Multipoint trees (Steiner 289 trees). 291 In these situations, it may not be possible or desirable for some 292 routers to perform path computation because of the constraints on 293 their CPUs, in which case the path computations may be off-loaded to 294 some other PCE(s) which may, themselves, be routers or may be 295 dedicated PCE servers. 297 4.2. Partial Visibility 299 There are several scenarios where the node responsible for path 300 computation has limited visibility of the network topology to the 301 destination. This limitation may occur, for instance, when an ingress 302 router attempts to establish a TE LSP to a destination that lies in a 303 separate domain, since TE information is not exchanged across the 304 domain boundaries. In such cases, it is possible to use loose routes 305 to establish the TE LSP, relying on routers at the domain borders to 306 establish the next piece of the path, however, it is not possible to 307 guarantee that the optimal (shortest) path will be used, nor even 308 that a viable path will be discovered except, possibly, through 309 repeated trial and error using crankback or other signaling 310 extensions. 312 This problem of inter-domain path computation may most probably be 313 addressed through distributed computation with cooperation among PCEs 314 within each of the domains, and potentially using crankback between 315 the domains to dynamically resolve provisioning issues. 316 Alternatively, a central "all-seeing" PCE that has access to the 317 complete set of topology information may be used, but in this case 318 there are challenges of scalability(both the size of the TED and the 319 responsiveness of a single PCE handling requests for many domains) 320 and of preservation of confidentiality when the domains belong to 321 different Service Providers. 323 Note that the issues described here can be further highlighted in the 324 context of TE LSP reoptimization, or the establishment of multiple 325 diverse TE LSPs for protection or load sharing. 327 4.3. Absence of the TED or use of Non-TE-Enabled IGP 329 The traffic engineering database (TED) may be a large drain on the 330 resources of a network node (such as an edge router or LER) both from 331 a memory perspective and because it may require non-negligible CPU 332 activity to maintain. The use of a distinct PCE may be appropriate in 333 such circumstances, and a separate node can be used to establish and 334 maintain the TED, and to make it available for path computation. 336 The IGPs run within some networks are not sufficient to build a full 337 TED. For example, a network may run OSPF/IS-IS without the 338 OSPF-TE/ISIS-TE extensions, or some routers in the network may not 339 support the TE extensions. In these cases, in order to successfully 340 compute paths through the network, the TED must be constructed or 341 supplemented through configuration action, and updated as network 342 resources are reserved or released. Such a TED could be distributed 343 to the routers that need to perform path computation, or held 344 centrally (on a distinct node that supports PCE) for centralized 345 computation. 347 4.4. Node Outside the Routing Domain 349 An LER might not be part of the routing domain for administrative 350 reasons (for example, a customer-edge (CE) router connected to the 351 provider-edge (PE) router in the context of MPLS VPN [RFC2547] and 352 for which it is desired to provide a CE to CE TE LSP path). 354 This scenario suggests a solution that does not involve doing 355 computation on the ingress (TE LSP head-end) router, and that does 356 not rely on static loose hops configuration in which case optimal 357 shortest paths could not be achieved. A distinct PCE-based solution 358 can help here. Note that the PCE in this case may, itself, provide a 359 path that includes loose hops. 361 4.5. Network Element Lacks Control Plane or Routing Capability 363 It is common in legacy optical networks for the network elements not 364 to have a control plane or routing capability. Such network elements 365 only have a data plane and a management plane, and all 366 cross-connections are made from the management plane. It is 367 desirable in this case to run the path computation on the PCE, and 368 send the cross-connection commands to each node on the computed path. 369 That is, the PCC would be an element of the management plane, perhaps 370 residing in the NMS or OSS. 372 This scenario is important for ASON-capable networks, and may also be 373 used for interworking between GMPLS-capable and GMPLS-incapable 374 networks. 376 4.6. Backup Path Computation for Bandwidth Protection 378 A PCE can be used to compute backup paths in the context of fast 379 reroute protection of TE LSPs. In this model all backup TE LSPs 380 protecting a given facility are computed in a coordinated manner by a 381 PCE. This allows complete bandwidth sharing between backup tunnels 382 protecting independent elements, while avoiding any extensions to TE 383 LSP signaling. Both centralized and distributed computation models 384 are applicable. In the distributed case each LSR can be a PCE to 385 compute the paths of backup tunnels to protect against the failure of 386 adjacent network links or nodes. 388 4.7. Multi-Layer Networks 390 A server-layer network of one switching capability may support 391 multiple networks of another (more granular) switching capability. 392 For example, a TDM network may provide connectivity for client-layer 393 networks such as IP, MPLS or Layer 2 [MRN]. 395 The server-layer network is unlikely to provide the same connectivity 396 paradigm as the client networks so that bandwidth granularity in the 397 server-layer network may be much coarser than in the client-layer 398 network. Similarly, there is likely to be a management separation 399 between the two networks providing independent address spaces. 400 Further, where multiple client-layer networks make use of the same 401 server-layer network, those client-layer networks may have 402 independent policies, control parameters, address spaces and routing 403 preferences. 405 The different client and server layer networks may be considered as 406 distinct path computation regions within a PCE domain, and so the PCE 407 architecture is useful to allow path computation from one 408 client-layer network region, across the server-layer network to 409 another client-layer network region. 411 In this case, the PCEs are responsible for resolving address space 412 issues, handling differences in policy and control parameters, and 413 coordinating resources between the networks. Note that, because of 414 the differences in bandwidth granularity, connectivity across the 415 server-layer network may be provided through virtual TE links or 416 Forwarding Adjacencies: the PCE may offer a point of control 417 responsible for the decision to provision new TE links or Forwarding 418 Adjacencies across the server-layer network. 420 4.8. Non-Motivations 422 4.8.1. The Whole Internet 424 PCE is not considered to be a solution that is applicable to the 425 entire Internet. That is, the applicability of PCE is limited to a 426 set of domains with known relationships. The scale of this limitation 427 is similar to the peering relationships between Service Providers. 429 4.8.2. Guaranteed TE LSP Establishment 431 When two or more paths for TE LSPs are computed on the same set of TE 432 link state information, it is possible that the resultant paths will 433 compete for limited resources within the network. This may result in 434 success for only the first TE LSP to be signaled, or might even mean 435 that no TE LSP can be established. 437 Back-off times, alternate path computations, and crankback can help 438 to mitigate this sort of problem, and PCE may also improve the 439 chances of successful TE LSP setup. However, a single, centralized 440 PCE is not viewed as a solution that can guarantee TE LSP 441 establishment since the potential for network failures or contention 442 for resources still exists where the centralized TED cannot fully 443 reflect current (i.e., real-time) network state. 445 5. Overview of the PCE-Based Architecture 447 This section gives an overview of the architecture of the PCE 448 model. It needs to be read in conjunction with the details provided 449 in the next section to provide a full view of the flexibility of the 450 model. 452 5.1. Composite PCE Node 454 Figure 1 below shows the components of a typical composite PCE node 455 (that is, a router that also implements the PCE functionality) that 456 utilizes path computation. The routing protocol is used to exchange 457 TE information from which the TED is constructed. Service requests to 458 provision TE LSPs are received by the node and converted into 459 signaling requests, but this conversion may require path computation 460 which is requested from a PCE. The PCE operates on the TED in order 461 to respond with the requested path. 463 --------------- 464 | --------- | Routing ---------- 465 | | | | Protocol | | 466 | | TED |<-+----------+-> | 467 | | | | | | 468 | --------- | | | 469 | | | | | 470 | | Input | | | 471 | v | | | 472 | --------- | | | 473 | | | | | Adjacent | 474 | | PCE | | | Node | 475 | | | | | | 476 | --------- | | | 477 | ^ | | | 478 | |Request | | | 479 | |Response| | | 480 | v | | | 481 | --------- | | | 482 Service | | | | Signaling| | 483 Request | |Signaling| | Protocol | | 484 ------+->| Engine |<-+----------+-> | 485 | | | | | | 486 | --------- | ---------- 487 --------------- 489 Figure 1. Composite PCE Node 491 Note that the routing adjacency between the composite PCE node and 492 any other router may be performed by means of direct connectivity or 493 any tunneling mechanism. 495 5.2. External PCE 497 Figure 2 shows a PCE that is external to the requesting network 498 element. A service request is received by the head-end node and 499 before it can initiate signaling to establish the service, it makes 500 a path computation request to the external PCE. The PCE uses the TED 501 as input to the computation and returns a response. 503 ---------- 504 | ----- | 505 | | TED |<-+------------> 506 | ----- | TED synchronization 507 | | | mechanism (for example, routing protocol) 508 | | | 509 | v | 510 | ----- | 511 | | PCE | | 512 | ----- | 513 ---------- 514 ^ 515 | Request/ 516 | Response 517 v 518 Service ---------- Signaling ---------- 519 Request | Head-End | Protocol | Adjacent | 520 ---->| Node |<---------->| Node | 521 ---------- ---------- 523 Figure 2. External PCE Node 525 Note that in this case, the node that supports the PCE function may 526 also be an LSR or router performing forwarding in its own right (i.e. 527 it may be a composite PCE node), but those functions are purely 528 orthogonal to the operation of the function in the instance being 529 considered here. 531 5.3. Multiple PCE Path Computation 533 Figure 3 illustrates how multiple PCE path computations may be 534 performed along the path of a signaled service. As in the previous 535 example, the head-end PCC makes a request to an external PCE, but the 536 path that is returned is such that the next network element finds it 537 necessary to perform further computation. This may be the case when 538 the path returned is a partial path that does not reach the intended 539 destination or when the computed path is loose. The downstream 540 network element consults another PCE to establish the next hop(s) in 541 the path. 543 Note that either or both PCEs in this case could be composite PCE 544 nodes as in Section 5.1. 546 ---------- ---------- 547 | | | | 548 | PCE | | PCE | 549 | | | | 550 | ----- | | ----- | 551 | | TED | | | | TED | | 552 | ----- | | ----- | 553 ---------- ---------- 554 ^ ^ 555 | Request/ | Request/ 556 | Response | Response 557 v v 558 Service -------- Signaling ------------ Signaling ------------ 559 Request |Head-End| Protocol |Intermediate| Protocol |Intermediate| 560 ---->| Node |<--------->| Node |<--------->| Node | 561 -------- ------------ ------------ 563 Figure 3. Multiple PCE Path Computation 565 5.4. Multiple PCE Path Computation with Inter-PCE Communication 567 The PCE in Section 5.3 was not able to supply a full path for the 568 requested service and this resulted in the adjacent node needing to 569 make its own computation request. As illustrated in Figure 4, the 570 same problem may be solved by introducing inter-PCE communication, 571 and cooperation between PCEs so that the PCE consulted by the 572 head-end network node makes a request of another PCE to help with the 573 computation. 575 ---------- ---------- 576 | | Inter-PCE Request/Response | | 577 | PCE |<--------------------------------->| PCE | 578 | | | | 579 | ----- | | ----- | 580 | | TED | | | | TED | | 581 | ----- | | ----- | 582 ---------- ---------- 583 ^ 584 | Request/ 585 | Response 586 v 587 Service ---------- Signaling ---------- Signaling ---------- 588 Request | Head-End | Protocol | Adjacent | Protocol | Adjacent | 589 ---->| Node |<---------->| Node |<---------->| Node | 590 ---------- ---------- ---------- 592 Figure 4. Multiple PCE Path Computation with Inter-PCE Communication 593 Multiple PCE path computation with inter-PCE communication involves 594 coordination between distributed PCEs such that the result of the 595 computation performed by one PCE depends on information supplied by 596 other PCEs. This model does not provide a distributed computation 597 algorithm, but allows distinct PCEs to be responsible for computation 598 of parts (segments) of the path. 600 PCE-PCE communication is discussed further in Section 6.6. 602 Note that a PCC might not see the difference between centralized 603 computation, and multiple PCE path computation with inter-PCE 604 communication. That is, the PCC network node or component that 605 requests the computation makes a single request and receives a full 606 or partial path in response, but the response is actually achieved 607 through the coordinated, cooperative efforts of more than one PCE. 609 5.5 Management-Based PCE Usage 611 It must be observed that the PCC is not necessarily an LSR. For 612 example, in Figure 5 the NMS supplies the head-end LSR with a fully 613 computed explicit path for the TE LSP that it is to establish through 614 signaling. The NMS uses a management plane mechanism to send this 615 request such as the TE MIB module [RFC3812]. 617 The NMS constructs the explicit path that it supplies to the head-end 618 LSR using information provided by the operator. It consults the PCE 619 which returns a path for the NMS to use. 621 Although Figure 5 shows the PCE as remote from the NMS it could, of 622 course, be collocated with the NMS. 624 ----------- 625 | ----- | 626 Service | | TED |<-+------------> 627 Request | ----- | TED synchronization 628 | | | | mechanism (for example, 629 v | | | routing protocol) 630 ------------- Request/ | v | 631 | | Response| ----- | 632 | NMS |<--------+->| PCE | | 633 | | | ----- | 634 ------------- ----------- 635 Service | 636 Request | 637 v 638 ---------- Signaling ---------- 639 | Head-End | Protocol | Adjacent | 640 | Node |<---------->| Node | 641 ---------- ---------- 643 Figure 5. Management-based PCE Usage 645 5.6 Areas for Standardization 647 The following areas require standardization within the PCE 648 architecture. 650 - communication between PCCs and PCEs, and between cooperating PCEs 652 - requirements for extensions to existing routing and/or signaling 653 protocols in support of PCE discovery and signaling of inter-domain 654 paths 656 - definition of metrics to evaluate path quality, scalability, 657 responsiveness and robustness of path computation models 659 - MIB modules related to communication protocols, routing and 660 signaling extensions and metrics. 662 6. PCE Architectural Considerations 664 This section provides a list of the PCE architectural components. 665 Specific realizations and implementation details (state machines or 666 algorithms, etc.) of PCE-based solutions are out of the scope of this 667 document. 669 Note also that PCE-based path computation does not affect in any way 670 the use of the computed paths. For example, the use of PCE does not 671 change the way in which Traffic Engineering LSPs are signaled, 672 maintained and torn down, but strictly relates to the path 673 computation aspects of such TE LSPs. 675 This section presents an architectural view of PCE. That is, it 676 describes the components that exist and how they interact. Note that 677 the architectural model, and in particular the functional model, may 678 be perceived differently by different components of the PCE system. 679 For example, the PCC will not be aware of whether a PCE consults 680 other PCEs. The PCC view of the PCE architecture is discussed in 681 Section 7. 683 6.1. Centralized Computation Model 685 A "centralized computation model" considers that all path 686 computations for a given domain will be performed by a single, 687 centralized PCE. This may be a dedicated server (for example, an 688 external PCE node), or a designated router (for example, a composite 689 PCE node) in the network. In this model, all PCCs in the domain would 690 send their path computation requests to the central PCE. While a 691 domain in this context might be an IGP area or AS, it might also be a 692 sub-group of network nodes that is defined by its dependence on the 693 PCE. 695 This model has a single point of failure: the PCE. In order to avoid 696 this issue, the centralized computation model may designate a backup 697 PCE that can take over the computation responsibility in a controlled 698 manner in the event of a failure of the primary PCE. Note that at any 699 moment in time there is only one active PCE in any domain. 701 6.2. Distributed Computation Model 703 A "distributed computation model" refers to a domain or network that 704 may include multiple PCEs, and where computation of paths is shared 705 among the PCEs. A given path may in turn be computed by a single PCE 706 ("single PCE path computation") or multiple PCEs ("multiple PCE path 707 computation"). A PCC may be linked to a particular PCE, or may be 708 able to choose freely among several PCEs - the method of choice 709 between PCEs is out of scope of this document, but see Section 6.4 710 for a discussion of PCE discovery which impacts on this choice. It 711 will often be the case that the computation of an individual path is 712 performed entirely by a single PCE. For example, this is usually the 713 case in MPLS TE within a single IGP area where the ingress LSR / 714 composite PCE node is responsible for computing the path or for 715 contacting an external PCE. Conversely, multiple PCE path computation 716 implies that more than one PCE is involved in the computation of a 717 single path. An example of this is where loose hop expansion is 718 performed by transit LSRs / composite PCE nodes on an MPLS TE LSP. 719 Another example is the use of multiple cooperating PCEs to compute 720 the path of a single TE LSP across multiple domains. 722 6.3. Synchronization 724 It is often the case that multiple paths need to be computed to 725 support a single service (for example, for protection or load 726 sharing). A PCC that determines that it requires more than one path 727 to be computed may send a series of individual requests to the PCE. 728 In this case of non-synchronized path computation, the PCE will make 729 multiple individual path computations to generate the paths and the 730 PCC may send its individual requests to different PCEs. 732 Alternatively, the PCC may send a single request to a PCE asking for 733 a set of paths to be computed but specifying that non-synchronized 734 path computation is acceptable. The PCE may compute each path in turn 735 exactly as it would have done had the PCC made multiple requests, and 736 the PCE may devolve some computations to other PCEs if it chooses. 738 Conversely, the PCC may issue a single request to the PCE asking for 739 all of the paths to be computed in a synchronized manner. The PCE 740 will then perform simultaneous computation of the set of requested 741 path. Such synchronized computation can often provide more optimal 742 results. 744 The involvement of more than one PCE in the computation of a series 745 of paths is by its nature non-synchronized. However, a set of 746 cooperating PCEs may be synchronized under the control of a single 747 PCE. For example, a PCC may send a request to a PCE which invokes 748 domain specific computations by other PCEs before supplying a result 749 to the PCC. 751 It is desirable to add a parameter to the PCC-PCE protocol to request 752 that the PCE supplies a set of alternate paths for use by the PCC 753 should the establishment of the TE LSP using the principal path fail 754 to complete. While alternate paths may not always be successful if 755 the first path fails, including alternate paths in a PCE response 756 could have less overhead than having the PCC make separate requests 757 for subsequent path computations as the need arises. This technique 758 is used in some existing CSPF implementations. 760 6.4. PCE Discovery and Load Balancing 762 The PCE architecture requires that the PCC/PCE know the location of 763 one or more PCEs that it can use for the computation of a path. Such 764 knowledge may come through a discovery mechanism that simply relies 765 on local configuration, or can imply dynamic PCE discovery along with 766 various static (for example, Boolean capability) or dynamically 767 computed variables (for example, computing resources). Proxy PCE 768 advertisement whereby the existence of a PCE is advertised via a 769 proxy PCE is a viable alternative, should the PCE be incapable of 770 such advertisement itself. In this later case, it is a requirement 771 for the proxy to adequately advertise the PCE status and capability 772 in a timely and synchronized fashion. 774 In the event that multiple PCEs are available to serve a particular 775 path computation request, the PCC must select a PCE to satisfy the 776 request. The details of such a selection, in order for instance to 777 efficiently share the computation load across multiple PCEs, is local 778 to the PCC and out of the scope of this document. 780 A PCE SHOULD advertise its capabilities, such as: 782 - set of constraints that it can account for (diversity, SRLGs, 783 Optical impairments, wavelength continuity, etc.) 784 - computational capacity (for example, the number of computations it 785 can perform per second) 786 - number of switching capability layers (and which ones) 787 - number of path selection criteria (and which ones) 788 - whether it is a stateless PCE or it can send updates about 789 better paths that might be available in the future 790 - whether it can compute P2MP trees (and which types) 791 - whether it can ensure resource sharing between backup tunnels. 793 This information would help a PCC that dynamically learns about 794 PCEs available on the network to decide which of them to use. 795 Alternatively, a PCC might ask a PCE to perform a particular type 796 of service and receive a response that says that the PCE is unable to 797 perform the service, but specifying the things that the PCE can do. 798 Note that the parameters mentioned above are not meant to be 799 exhaustive and are listed for the sake of illustration. 801 6.5. Detecting PCE Liveness 803 The ability to detect a PCE's liveness is a mandatory piece of the 804 overall architecture and could be achieved by several means. If some 805 form of regular advertisement (such as through IGP extensions) is 806 used for PCE discovery, it is expected that the PCE liveness will be 807 determined by means of status advertisement (for example, IGP 808 LSA/LSPs). 810 The inability of a PCE to service a request (perhaps due to excessive 811 load) may be reported to the PCC through a failure message, but the 812 failure of a PCE or the communications mechanism while processing a 813 request cannot be reported in this way. Further, in the case of 814 excessive load, the PCE may not have sufficient resources to send a 815 failure message. Thus the PCC should employ other mechanisms such as 816 protocol timers to determine the liveness of the PCE. This is 817 particularly important in the case of inter-domain path computation 818 where the PCE liveness may not be detected by means of the IGP that 819 runs in the PCC's domain. 821 6.6. PCC-PCE & PCE-PCE Communication 823 Once the PCC has selected a PCE, and provided that the PCE is not 824 local to the PCC, a request/response protocol is required for the PCC 825 to communicate the path computation requests to the PCE and for the 826 PCE to return the path computation response. 828 The path computation request may include a significant set of 829 requirements including: 831 - the source and destination of the path 832 - the bandwidth and other QoS parameters desired 833 - resources, resource affinities and shared risk link groups (SRLGs) 834 to use/avoid 835 - the number of disjoint paths required and if near-disjoint paths 836 are acceptable 837 - the level of robustness of the path resources 838 - and so on. 840 The level of robustness of the path resources covers a qualitative 841 assessment of the vulnerability of the resources that may be used. 842 For example, one might grade resources based on empirical evidence 843 (mean time between failures), on known risks (there is major building 844 work going on near this conduit), or on prejudice (vendor X's 845 software is always crashing). A PCC could request that only robust 846 resources be used, or allow any resource. 848 In case of a positive response from the PCE, one or more paths would 849 be returned to the requesting node. In the event of a failure to 850 compute the desired path(s), an error is returned together with as 851 much information as possible about the reasons for the failure(s), 852 and potentially with advice about which constraints might be relaxed 853 to be more likely to achieve a positive result in a future request. 855 Note that the resultant path(s) may be made up of a set of strict or 856 loose hops, or any combination of strict and loose hops. Moreover, a 857 hop may have the form of a non-explicit abstract node. 859 A request/response protocol is also required for a PCE to communicate 860 path computation requests to another PCE and for the PCE to return 861 the path computation response. The path computation request may 862 include a significant set of requirements including those defined 863 above. In case of a positive response from the PCE, one or more paths 864 would be returned to the requesting PCE. In the event of a failure to 865 compute the desired path(s), an error is returned together with as 866 much information as possible about the reasons for the failure, and 867 potentially advice about which constraints might be relaxed to be 868 more likely to achieve a positive result. Note that the resultant 869 path(s) may be made up of a set of strict or loose hops, or any 870 combination of strict and loose hops. Moreover, a hop may have the 871 form of a non-explicit abstract node. 873 An important feature of PCEs that are cooperating to compute a path 874 is that they apply compatible or identical computation algorithms. 875 This may require coordination through the communication between the 876 PCEs. 878 Note that when multiple PCEs cooperate to compute a path it is 879 important that they have a coordinated view of the meaning of 880 constraints such as costs, resource affinities and class of service. 881 This is particularly significant where the PCEs are responsible for 882 different domains. It is assumed that this is a matter of policy 883 between domains and between PCEs, and is achieved through 884 configuration not through protocol communications. 886 No assumption is made in this architecture about whether the PCC-PCE 887 and PCE-PCE communication protocols are identical. 889 6.7. PCE TED Synchronization 891 As previously described, the PCE operates on a TED. Information on 892 network status to build the TED may be provided in the domain by 893 various means: 895 1) Participation in IGP distribution of TE information. The standard 896 method of distribution of TE information within an IGP area is 897 through the use of extensions to the IGP [RFC3630, RFC3748]. This 898 mechanism allows participating nodes to build a TED, and this is 899 the standard technique, for example, within a single area MPLS 900 or GMPLS network. A node that hosts the PCE function may collect 901 TE information in this way by maintaining at least one routing 902 adjacency with a router in the domain. The PCE node may be 903 adjacent or non-adjacent (via some tunneling techniques) to the 904 router. Such a technique provides a mechanism for ensuring that 905 the TED is efficiently synchronized with the network state and is 906 the normal case, for example, when the PCE is co-resident with the 907 LSRs in an MPLS or GMPLS network. 909 2) Out-of-band TED synchronization. It may not be convenient or 910 possible for a PCE to participate in the IGPs of one or more 911 domains (for example, when there are very many domains, when IGP 912 participation is not desired, or when some domains are not running 913 TE-aware IGPs). In this case some mechanism may need to be defined 914 to allow the PCE node to retrieve the TED from each domain. Such a 915 mechanism could be incremental (like the IGP in the previous 916 case), or could involve a bulk transfer of the complete TED. The 917 latter might significantly limit the capability to ensure TED 918 synchronization which might result in an increase in the failure 919 rate of computed paths, or the computation of sub-optimal paths. 920 Consideration should also be given to the impact of the TED 921 distribution on the network and on the network node within the 922 domain that is asked to distribute the database. This is 923 particularly relevant in the case of frequent network state 924 changes. 926 3) Information in the TED can include information obtained from 927 sources other than the IGP. For example, information about link 928 usage policies can be configured by the operator. Path computation 929 can also act on a far wider set of information that includes data 930 about the TE LSPs provisioned within the network. This information 931 can include TE LSP routes, reserved bandwidth, and measured 932 traffic volume passing through the TE LSP. 934 Such TE LSP information can enhance TE LSP (re)optimization to 935 provide "full network" (re)optimization, and can allow traffic 936 fluctuations to be taken into account. Detailed TE LSP information 937 may also facilitate reconfiguration of the Virtual Network 938 Topology (VNT) [MRN], in which lower layer TE LSPs such as optical 939 paths provide TE links for use by the higher layer, since this 940 reconfiguration is also a "full network" problem. 942 Note that synchronization techniques may apply to both intra- and 943 inter-domain TEDs. Further, the techniques can be mixed for use in 944 different domains. The degree of synchronization between the PCE and 945 the network is subject to implementation and/or policy. However, 946 better synchronization generally leads to paths that are more likely 947 to succeed. 949 It must also be highlighted that the PCE may have access to only a 950 partial TED: for instance in the case of inter-domain path 951 computation where each such domain may be managed by different 952 entities. In such cases, each PCE may have access to a partial TED 953 and cooperative techniques between PCEs may be used to achieve 954 end-to-end path computation without any requirement for any PCE to 955 handle the complete TED related to the set of traversed domains by 956 the TE LSP in question. 958 6.8. Stateful Versus Stateless PCEs 960 A PCE can be either stateful or stateless. In the former case, there 961 is a strict synchronization between the PCE and not only the network 962 states (in term of topology and resource information), but also the 963 set of computed paths and reserved resources in use in the network. 964 In other words, the PCE utilizes information from the TED as well as 965 information about existing paths (for example, TE LSPs) in the 966 network when processing new requests. Note that although this allows 967 for optimal path computation and increased path computation success, 968 stateful PCEs require reliable state synchronization mechanisms, with 969 potentially significant control plane overhead and the maintenance of 970 a large amount of data/states (for example, full mesh of TE LSPs). 972 For example, if there is only one PCE in the domain, all TE LSP 973 computation is done by this PCE, which can then track all the 974 existing TE LSPs and stay synchronized (each TE LSP state change must 975 be tracked by the PCE). However, this model could require substantial 976 control plane resources. If there are multiple PCEs in the network, 977 TE LSP computation and information is distributed among PCEs and so 978 the resources required to perform the computations are also 979 distributed. However, synchronization issues discussed in Section 6.7 980 also come into play. 982 The maintenance of a stateful database can be non-trivial. However, 983 in a single centralized PCE environment, a stateful PCE is almost a 984 simple matter of remembering all of the TE LSPs the PCE has computed, 985 if it can also be known that the TE LSPs were actually set up, and 986 when they were torn down. Out-of-band TED synchronization can also be 987 complex with multiple PCE setup in a distributed PCE computation 988 model, and could be prone to race conditions, scalability concerns, 989 etc. Even if the PCE has detailed information on all paths, 990 priorities, and layers, taking such information into account for path 991 computation could be highly complex. PCEs might synchronize state by 992 communicating with each other, but when TE LSPs are set up using 993 distributed computation performed among several PCEs, the problems of 994 synchronization and race condition avoidance become larger and more 995 complex. 997 There is benefit in knowing which TE LSPs exist, and their routing, 998 to support such applications as placing a high priority TE LSP in a 999 crowded network such that it preempts as few other TE LSPs as 1000 possible (also known as the "minimal perturbation" problem). Note 1001 that preempting based on the minimum number of links might not result 1002 in the smallest number of TE LSPs being disrupted. Another 1003 application concerns the construction and maintenance of a Virtual 1004 Network Topology [MRN]. It is also helpful to understand which other 1005 TE LSPs exist in the network in order to decide how to manage the 1006 forward adjacencies that exist or need to be set up. The cost-benefit 1007 of stateful PCE computation would be helpful to determine if the 1008 benefit in path computation is sufficient to offset the additional 1009 drain on the network and computational resources. 1011 Conversely, stateless PCEs do not have to remember any computed path 1012 and each set of request(s) is processed independently of each other. 1013 For example, stateless PCEs may compute paths based on current TED 1014 information, which could be out of sync with actual network state 1015 given other recent PCE-computed paths changes. Note that a PCC may 1016 include a set of previously computed paths in its request, in order 1017 to take them into account, for instance to avoid double bandwidth 1018 accounting, or to try to minimize changes (minimum perturbation 1019 problem). 1021 It should be observed that the stateless PCE does operate on 1022 information about network state. The TED contains link state and 1023 bandwidth availability information as distributed by the IGPs or 1024 collected through some other means. This information could be 1025 further enhanced to provide increased granularity and more detail to 1026 cover, for example, the current bandwidth usage on certain links 1027 according to resource affinities or forwarding equivalence classes. 1028 Such information is, however, not PCE state information and so a 1029 model that uses it is still described as stateless in the PCE 1030 context. 1032 A limited form of statefulness might be applied within an otherwise 1033 stateful PCE. The PCE may retain some context from paths it has 1034 recently computed so that it avoid suggesting the use of the same 1035 resources for other TE LSPs. 1037 6.9. Monitoring 1039 PCE Monitoring is undoubtedly of the utmost importance in any PCE 1040 architecture. This must include the collection of variables related 1041 to the PCE status and operation. For example, it will be necessary to 1042 understand the way in which the TED is being kept synchronized, the 1043 rate of arrival of new requests and the computation times, the range 1044 of PCCs that are using the PCE, and the operation of any PCC-PCE 1045 protocol. 1047 6.10. Policy and Confidentiality 1049 As stated in [INTER-AS], the case of inter-provider TE LSP 1050 computation requires the ability to compute a path while preserving 1051 confidentiality across multiple Service Providers cores. Thus any PCE 1052 architecture solution must support the ability to return partial 1053 paths by means of loose hops (for example, where each loose hops 1054 would for instance identify a boundary LSR). Confidentiality and 1055 security of PCC-PCE and PCE-PCE messages must also be ensured. 1057 The ability to compute a path at the request of the head end PCC, but 1058 to supply the path in segments to the domain boundary PCCs may also 1059 be desirable. 1061 The use of the PCE architecture makes the need for proper 1062 consideration of Policy more obvious. There is clearly no change in 1063 the requirements for appropriate Policy mechanisms for inter-domain 1064 TE LSPs. This application of Policy is required to protect the 1065 resources of one domain from requests initiated in another domain and 1066 may involve considerations of inter-provider agreements, billing 1067 regimes, resource scarcity, and client priority. Policy as directly 1068 applicable to TE LSPs forms part of the signaling mechanism for the 1069 establishment of the TE LSPs. 1071 When a path for an inter-domain TE LSP is being computed it is not 1072 required to consider Policy. However, failure to do so may result in 1073 the TE LSP failing to be established or being assigned fewer 1074 resources than intended resulting in a substandard service. Thus, 1075 where a PCE invoked by a head-end LSR has visibility into other 1076 domains, it should be capable of applying Policy considerations to 1077 the computation (equivalent to another constraint) and should be 1078 aware of the inter-domain Policy agreements. Where path computation 1079 is the result of cooperation between PCEs, each of which is 1080 responsible for a particular domain, the Policy issues should where 1081 possible be resolved at the time of computation so that the TE LSP is 1082 more likely to be signaled successfully. In such context Policy 1083 violation during inter-domain TE LSP computation may lead to path 1084 computation interruption which should be notified to the requester 1085 along with the cause. 1087 At the same time, interactions between cooperating PCEs may 1088 themselves be subject to Policy. For example, a PCE may not wish to 1089 divulge answers or full details in response to a request from a PCE 1090 in another domain. Similarly, a PCE may wish to apply Policy to the 1091 way that it services requests from an individual PCC - it may decide 1092 that a particular PCC should be assigned lower priority in the queue 1093 of computation requests, be given access to a specific subset of the 1094 available computation algorithms, or have paths computed using a 1095 restricted TED. 1097 Thus there are multiple dimensions to Policy in the PCE context and 1098 this needs to form part of the protocol solutions that are developed. 1100 6.11. Unsolicited Interactions 1102 It may be that the PCC-PCE communications (see Section 6.6) can be 1103 usefully extended beyond a simple request/response interaction. For 1104 example, the PCE and PCC could exchange capabilities using this 1105 protocol. Additionally, the protocol could be used to collect and 1106 report information in support of a stateful PCE. 1108 Further, it may be the case that a PCE is able to update a path that 1109 it computed earlier (perhaps in reaction to a change in the network), 1110 and in this case the PCE-PCC communication could support an 1111 "unsolicited" path computation message to supply this new path to the 1112 PCC. It should be noted, however, that this function would require 1113 that the PCE retained a record of previous computations and had a 1114 clear trigger for performing recomputations. The PCC would also need 1115 to be able to identify the new path with the old path and determine 1116 whether it should act on the new path. Furthermore, the PCC should be 1117 able to report the outcome of such path changes to the requesting 1118 PCE. Note that the PCE-PCC interaction is not a management 1119 interaction and the PCC is not obliged to utilize any additional path 1120 supplied by the PCE. 1122 These functions fit easily within the architecture described here 1123 but are left for further discussion within separate requirements 1124 documents. 1126 6.12. Relationship with Crankback 1128 Crankback routing is a mechanism whereby a failure to establish a 1129 path, or a failure of an existing path may be corrected by a new 1130 path computation and fresh signaling. Crankback routing relies on the 1131 distribution of crankback information along with the failure 1132 notification so that the new computation can be performed avoiding 1133 the failure or blockage point. 1135 In the context of PCE, crankback information may be passed back to 1136 the head-end where the process of computation and signaling can be 1137 repeated using the failed resource as an exclusion in the computation 1138 process. But crankback may be used to attempt to correct the 1139 problem at intermediate points along the path. Such crankback 1140 recomputation nodes are most likely to be domain boundaries where the 1141 PCC had already invoked a PCE. Thus, a failure within a domain is 1142 reported to the ingress domain boundary which will attempt to compute 1143 an alternate path across the domain. Failing this, the problem may be 1144 reported to the previous domain, and communicated to the ingress 1145 boundary for that domain which may attempt to select a more 1146 successful path either by choosing a different entry point into the 1147 next domain, or by selecting a route through a different set of 1148 domains. 1150 7. The View from the Path Computation Client 1152 The view of the PCE architecture, and particularly the functional 1153 model, is subtly different from the PCC's perspective. This is partly 1154 because the PCC has limited knowledge of the way in which the PCEs 1155 cooperate to answer its requests, but depends more on the fact that 1156 the PCC is concerned with different questions. 1158 The PCC is interested in the following: 1160 - Selecting a PCE that is able to promptly provide a computed path 1161 meeting the supplied constraints. 1163 - How many computation requests will the PCC have to send? Will the 1164 desired path be computed by the first PCE contacted (possibly in 1165 cooperation with other PCEs), or will the PCC have to consult other 1166 PCEs to fill in gaps in the path? 1168 - How many other path computations will need to be issued from within 1169 the network in order to establish the TE LSP? 1171 This last question might be considered to be out of scope for the 1172 head-end LSR, but an important constraint that the PCC may wish to 1173 apply is that the path should be computed in its entirety and 1174 supplied without loose hops or non-simple abstract nodes. 1176 Thus, with its limited perspective, the PCC will see Multiple PCE 1177 Path Computation (Section 5.3) as important, and will distinguish 1178 two subcases: the first is as shown in Figure 3 with subsequent 1179 computation requests made by other PCCs along the path of the TE LSP; 1180 the second having multiple computation requests issued by the 1181 head-end LSR. On the other hand, the PCC will not be aware of 1182 Multiple PCE Path Computation with Inter-PCE Communication (Section 1183 5.4) which it will perceive as no different from the simple External 1184 PCE Node case (Section 5.2). 1186 The PCC, therefore, will be acutely aware that a Centralized PCE 1187 Model (Section 6.1) might still require Multiple PCE Path 1188 Computations with the head-end or subsequent PCCs required to issue 1189 further requests to the central PCE. Conversely, the PCC may be 1190 protected from the Distributed PCE Model (Section 6.2) by the fact 1191 that the first PCE it consults uses inter-PCE communication to 1192 achieve a complete computation result so that no further computation 1193 requests are required. 1195 These distinctions can be completely classified by determining 1196 whether the computation response includes all necessary paths, and 1197 whether those paths are fully explicit (that is, containing only 1198 strict hops between simple abstract nodes). 1200 8. Evaluation Metrics 1202 Evaluation metrics that may be used to evaluate the efficiency and 1203 applicability of any PCE-based solution are listed below. Note that 1204 these metrics are not being used to determine paths, but are used to 1205 evaluate potential solutions to the PCE architecture. 1207 - Optimality: The ability to maximize network utilization and 1208 minimize cost, considering QoS objectives, multiple regions and 1209 network layers. Note that models that require the sequential 1210 involvement of multiple PCEs (for example, the multiple PCE model 1211 described in Section 5.3) might create path loops unless careful 1212 policy is applied. 1214 - Scalability: The implications of routing, TE LSP signaling and PCE 1215 communication overhead such as the number of messages and the size 1216 of messages (including LSAs, crankback information, queries, 1217 distribution mechanisms, etc.). 1219 - Load sharing: The ability to allow multiple PCEs to spread the path 1220 computation load by allowing multiple PCEs to each take 1221 responsibility for a subset of the total path computation requests. 1223 - Multi-path computation: The ability to compute multiple and 1224 potentially diverse paths to satisfy load-sharing of traffic and 1225 protection/restoration needs including end-to-end diversity and 1226 protection within individual domains. 1228 - Reoptimization: The ability to perform TE LSP path reoptimization. 1229 This also includes the ability to perform inter-layer correlation 1230 when considering the reoptimization at any specific layer. 1232 - Path computation time: The time to compute individual paths, 1233 multiple diverse paths, and to satisfy bulk path computation 1234 requests. (Note that such a metric can only be applied to problems 1235 that are not NP-complete.) 1237 - Network stability: The ability to minimize any perturbation on 1238 existing TE state resulting from the computation and establishment 1239 of new TE paths. 1241 - Ability to maintain accurate synchronization between TED and 1242 network topology and resource states. 1244 - Speed with which TED synchronization is achieved. 1246 - Impact of the synchronization process on the data flows in the 1247 network. 1249 - Ability to deal with situations where paths satisfying a required 1250 set of constraints cannot be found by the PCE. 1252 - Policy: Application of Policy to the PCC-PCE and PCE-PCE 1253 communications as well as to the computation of paths that respect 1254 inter-domain TE LSP establishment Policies. 1256 Note that other metrics may also be considered. Such metrics should 1257 be used when evaluating a particular PCE-based architecture. It must 1258 also be highlighted that the potential tradeoffs of the optimization 1259 of such metrics should be evaluated (for instance, increasing the 1260 path optimality is likely to have consequences on the computation 1261 time). 1263 9. Manageability Considerations 1265 The PCE architecture introduces several elements that are subject to 1266 manageability. The PCE itself must be managed as must its 1267 communications with PCCs and other PCEs. The mechanism by which PCEs 1268 and PCCs discover each other are also subject to manageability. 1270 Many of the issues of manageability are already covered in other 1271 sections of this document. 1273 9.1. Control of Function and Policy 1275 It must be possible to enable and disable the PCE function at a PCE, 1276 and this will lead to the PCE accepting, rejecting, or simply not 1277 receiving requests from PCCs. Graceful shutdown of the PCE function 1278 should also be considered so that in controlled circumstances (such 1279 as software upgrade) a PCE does not just 'disappear' but warns its 1280 PCCs and gracefully handles any queued computation requests (perhaps 1281 by completing them, forwarding them to another PCE, or rejecting 1282 them). 1284 Similarly it must be possible to control the application of Policy at 1285 the PCE through configuration. This control may include the 1286 restriction of certain functions or algorithms, the configuration of 1287 access rights and priorities for PCCs, and the relationships with 1288 other PCEs both inside and outside the domain. 1290 9.2. Information and Data Models 1292 It is expected that the operations of PCEs and PCCs will be modeled 1293 and controlled through appropriate MIB modules. The tables in the new 1294 MIB modules will need to reflect the relationships between entities 1295 and to control and report on configurable options. 1297 Statistics gathering will form an important part of the operation of 1298 PCEs. The operator must be able to determine the historical 1299 interactions of a PCC with its PCEs, the performance that it has 1300 seen, and success rate of its requests. Similarly, it is important 1301 for an operator to be able to inspect a PCE and determine its load 1302 and whether an individual PCC is responsible for a disproportionate 1303 amount of the load. It will also be important to be able to record 1304 and inspect statistics about the communications between the PCC and 1306 PCE, including issues such as malformed messages, unauthorized 1307 messages and messages discarded owing to congestion. In this respect 1308 there is clearly an overlap between manageability and security. 1310 Statistics for the PCE architecture can be made available through 1311 appropriate tables in the new MIB modules. 1313 The new MIB modules should also be used to provide notifications 1314 (formerly known as traps) when key thresholds are crossed or when 1315 important events occur. Great care must be exercised to ensure that 1316 the network is not flooded with SNMP notifications. Thus it might be 1317 inappropriate to issue a notification every time that a PCE receives 1318 a request to compute a path. In any case, full control must be 1319 provided through the MIB modules to allow notifications to be 1320 disabled. 1322 9.3. Liveness Detection and Monitoring 1324 Section 6.5 discusses the importance of a PCC being able to detect 1325 the liveness of a PCE. PCE-PCC communications techniques must enable 1326 a PCC to determine the liveness of a PCE both before it sends a 1327 request and in the period between sending a request and receiving a 1328 response. 1330 It is less important for a PCE to know about the liveness of PCCs, 1331 and within the simple request/response model, this is only helpful: 1333 - to gain a predictive view of the likely loading of a PCE in the 1334 future 1336 - to allow a PCE to abandon processing of a received request. 1338 9.4. Verifying Correct Operation 1340 Correct operation for the PCE architecture can be classified as 1341 determining the correct point-to-point connectivity between PCCs and 1342 PCEs, and assessing the validity of the computed paths. The former is 1343 a security issue that may be enhanced by authentication and monitored 1344 through event logging and records as described in Section 9.1. It may 1345 also be a routing issue to ensure that PCC-PCE connectivity is 1346 possible. 1348 Verifying computed paths is more complex. The information to perform 1349 this function can, however, be made available to the operator through 1350 MIB tables provided full records are kept of the constraints passed 1351 on the request, the path computed and provided on the response, and 1352 any additional information supplied by the PCE such as the constraint 1353 relaxation policies applied. 1355 9.5. Requirements on Other Protocols and Functional Components 1357 At the architectural stage it is impossible to make definitive 1358 statements about the impact on other protocols and functional 1359 components since the solutions work has not been completed. However, 1360 it is possible to make some observations. 1362 - Dependence on underlying transport protocols 1364 PCE-PCC communications may choose to utilize underlying protocols 1365 to provide transport mechanisms. In this case some of the 1366 manageability considerations described in the previous sections may 1367 be devolved to those protocols. 1369 - Re-use of existing protocols for discovery 1371 Without prejudicing the requirements and solutions work for PCE 1372 discovery (see Section 6.4) it is possible that use will be made of 1373 existing protocols to facilitate this function. In this case some 1374 of the manageability considerations described in the previous 1375 sections may be devolved to those protocols. 1377 - Impact on LSRs and TE LSP signaling 1379 The primary example of a PCC identified in this architecture is an 1380 MPLS or GMPLS LSR. Consideration must therefore be given to the 1381 manageability of the LSRs and the additional manageability 1382 constraints applicable to the TE LSP signaling protocols. 1384 As well as allowing the PCC management described in the previous 1385 sections, an LSR must be configurable to determine whether it will 1386 use a remote PCE at all - the options being to use hop-by-hop 1387 routing or to supply the PCE function itself. It is likely to be 1388 important to be able to distinguish within an LSR whether the route 1389 used for a TE LSP was supplied in a signaling message from another 1390 LSR, by an operator, or by a PCE, and in the case where it was 1391 supplied in a signaling message whether it was enhanced or expanded 1392 by a PCE. 1394 9.6. Impact on Network Operation 1396 This architecture may have two impacts on the operation of a network. 1397 It increases TE LSP setup times while requests are sent to and 1398 processed by a remote PCE, and it may cause congestion within the 1399 network if a significant number of computation requests are issued in 1400 a small period of time. These issues are most severe in busy networks 1401 and after network failures, although the effect may be mitigated if 1402 the protection paths are precomputed or if the path computation load 1403 is distributed among a set of PCEs. 1405 Issues of potential congestion during recovery from failures may be 1406 mitigated through the use of pre-established protection schemes such 1407 as fast reroute. 1409 It is important that network congestion be managed proactively 1410 because it may be impossible to manage it reactively once the network 1411 is congested. It should be possible for an operator to rate limit the 1412 requests that a PCC sends to a PCE, and a PCE should be able to 1413 report impending congestion (according to a configured threshold) 1414 both to the operator and to its PCCs. 1416 10. Security Considerations 1418 The impact of the use of a PCE-based architecture must be considered 1419 in the light of the impact that it has on the security of the 1420 existing routing and signaling protocols and techniques in use within 1421 the network. There is unlikely to be any impact on intra-domain 1422 security, but an increase in inter-domain information flows and the 1423 facilitation of inter-domain path establishment may increase the 1424 vulnerability to security attacks. 1426 Of particular relevance are the implications for confidentiality 1427 inherent in a PCE-based architecture for multi-domain networks. It is 1428 not necessarily the case that a multi-domain PCE solution will 1429 compromise security, but solutions MUST examine their effects in this 1430 area. 1432 Applicability statements for particular combinations of signaling, 1433 routing and path computation techniques are expected to contain 1434 detailed security sections. 1436 It should be observed that the use of a non-local PCE (that is, not 1437 co-resident with the PCC) does introduce additional security issues. 1438 Most notable amongst these are: 1440 - Interception of PCE requests or responses 1442 - Impersonation of PCE 1444 - Falsification of TE information 1445 - Denial of service attacks on PCE or PCE communication mechanisms. 1447 It is expected that PCE solutions will address these issues in detail 1448 using authentication and security techniques. 1450 11. IANA Considerations 1452 This informational document makes no requests for IANA action. 1454 12. Acknowledgements 1456 The authors would like to extend their warmest thanks to (in 1457 alphabetical order) Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed 1458 Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella, 1459 Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou, 1460 Richard Rabbat, Takao Shimizu, and Raymond Zhang for their review and 1461 suggestions. 1463 13. Intellectual Property Considerations 1465 The IETF takes no position regarding the validity or scope of any 1466 Intellectual Property Rights or other rights that might be claimed to 1467 pertain to the implementation or use of the technology described in 1468 this document or the extent to which any license under such rights 1469 might or might not be available; nor does it represent that it has 1470 made any independent effort to identify any such rights. Information 1471 on the procedures with respect to rights in RFC documents can be 1472 found in BCP 78 and BCP 79. 1474 Copies of IPR disclosures made to the IETF Secretariat and any 1475 assurances of licenses to be made available, or the result of an 1476 attempt made to obtain a general license or permission for the use of 1477 such proprietary rights by implementers or users of this 1478 specification can be obtained from the IETF on-line IPR repository at 1479 http://www.ietf.org/ipr. 1481 The IETF invites any interested party to bring to its attention any 1482 copyrights, patents or patent applications, or other proprietary 1483 rights that may cover technology that may be required to implement 1484 this standard. Please address the information to the IETF at 1485 ietf-ipr@ietf.org. 1487 14. Normative References 1489 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 1490 RFC 3667, February 2004. 1492 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 1493 Technology", BCP 79, RFC 3668, February 2004. 1495 15. Informational References 1497 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and 1498 J. McManus, "Requirements for Traffic Engineering over 1499 MPLS", RFC 2702, September 1999. 1501 [RFC2547] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC 2547, 1502 March 1999. 1504 [RFC3209] Awduche, D., et. all, "Extensions to RSVP for LSP 1505 Tunnels", RFC 3209, December 2001. 1507 [RFC3630] Katz et al., "Traffic Engineering (TE) Extensions to 1508 OSPF Version 2", RFC 3630, September 2003. 1510 [RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label 1511 Switching (GMPLS) Signaling - Resource ReserVation 1512 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1513 RFC 3473, January 2003. 1515 [RFC3748] Smit, H. and Li, T., "Intermediate System to 1516 Intermediate System (IS-IS) - Extensions for Traffic 1517 Engineering (TE)", RFC 3784, June 2004. 1519 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 1520 "Multiprotocol Label Switching (MPLS) Traffic 1521 Engineering (TE) Management Information Base (MIB)", 1522 RFC 3812, June 2004. 1524 [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for 1525 Support of Inter-Area and Inter-AS MPLS Traffic 1526 Engineering", RFC 4105, June 2005. 1528 [INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic 1529 Engineering requirements", 1530 draft-ietf-tewg-interas-mpls-te-req, work in progress. 1532 [MRN] Shiomoto, K., et. al., "Requirements for GMPLS-based 1533 multi-region and multi-layer networks", 1534 draft-shiomoto-ccamp-gmpls-mrn-reqs, work in progress. 1536 16. Contact Information 1538 Adrian Farrel 1539 Old Dog Consulting 1540 EMail: adrian@olddog.co.uk 1541 Jean-Philippe Vasseur 1542 Cisco Systems, Inc. 1543 300 Beaver Brook Road 1544 Boxborough , MA - 01719 1545 USA 1546 Email: jpv@cisco.com 1548 Jerry Ash 1549 AT&T 1550 Room MT D5-2A01 1551 200 Laurel Avenue 1552 Middletown, NJ 07748, USA 1553 Phone: +1-(732)-420-4578 1554 Fax: +1-(732)-368-8659 1555 Email: gash@att.com 1557 17. Full Copyright Statement 1559 Copyright (C) The Internet Society (2005). This document is subject 1560 to the rights, licenses and restrictions contained in BCP 78, and 1561 except as set forth therein, the authors retain all their rights. 1563 This document and the information contained herein are provided on an 1564 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1565 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1566 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1567 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1568 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1569 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.