idnits 2.17.1 draft-ietf-pce-architecture-00.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.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1044. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 954. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 961. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 967. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (March 2005) is 6981 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 974, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 977, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 982, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 989, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 992, but no explicit reference was found in the text == Unused Reference: 'INTER-AREA' is defined on line 996, 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) -- No information found for draft-ietf-tewg- - is the name correct? Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Internet Draft PCE Working Group Adrian Farrel 3 Proposed Status: Informational Old Dog Consulting 4 Expires: September 2005 Jean-Philippe Vasseur 5 Cisco Systems, Inc. 6 Jerry Ash 7 AT&T 8 March 2005 10 draft-ietf-pce-architecture-00.txt 12 Path Computation Element (PCE) Architecture 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other groups 25 may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 Constraint-based path computation is a fundamental building block for 41 traffic engineering systems such as Multiprotocol Label Switching (MPLS) 42 and Generalized Multiprotocol Label Switching (GMPLS) networks. Path 43 computation in large, multi-domain, multi-region or multi-layer 44 networks is highly complex and may require special computational 45 components and cooperation between the different network domains. 47 This document specifies the architecture for a Path Computation Element 48 (PCE)-based model to address this problem space. This document does not 49 attempt to provide a detailed description of all the architectural 50 components, but rather it describes a set of building blocks for the PCE 51 architecture from which solutions may be constructed. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions used in this document . . . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 5. Motivation for a PCE-based Architecture . . . . . . . . . . . . . 4 60 5.1. CPU-intensive Path Computation/Global Optimization . . . . . 5 61 5.2. Partial Visibility . . . . . . . . . . . . . . . . . . . . . 5 62 5.3. Absence of the TED or Use of Non-TE-Enabled IGP . . . . . . 5 63 5.4. Node Outside the Routing Domain . . . . . . . . . . . . . . 6 64 5.5. Network Element Lacks Control Plan or Routing Capability . . 6 65 5.6. Backup Path Computation for Bandwidth Protection . . . . . . 6 66 5.7. Multi-Layer Networks . . . . . . . . . . . . . . . . . . . . 6 67 6. Overview of the PCE-Based Architecture . . . . . . . . . . . . . 7 68 6.1. Composite PCE . . . . . . . . . . . . . . . . . . . . . . . 7 69 6.2. External PCE . . . . . . . . . . . . . . . . . . . . . . . . 8 70 6.3. Multiple PCE Path Computation . . . . . . . . . . . . . . . 9 71 6.4. Multiple PCE Path Computation with Inter-PCE Communication . 10 72 6.5. Areas for Standardization . . . . . . . . . . . . . . . . . 73 7. PCE Architectural Considerations . . . . . . . . . . . . . . . . 10 74 7.1. Centralized Computation Model . . . . . . . . . . . . . . . 11 75 7.2. Distributed Computation Model . . . . . . . . . . . . . . . 11 76 7.3. Synchronization . . . . . . . . . . . . . . . . . . . . . . 11 77 7.4. PCE Discovery and Load Balancing . . . . . . . . . . . . . . 12 78 7.5. Detecting PCE Liveness . . . . . . . . . . . . . . . . . . . 12 79 7.6. PCC-PCE & PCE-PCE Communication . . . . . . . . . . . . . . 12 80 7.7. PCE TED Synchronization . . . . . . . . . . . . . . . . . . 13 81 7.8. Stateful Versus Stateless PCEs . . . . . . . . . . . . . . . 14 82 7.9. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 7.10. Policy and Confidentiality . . . . . . . . . . . . . . . . 14 84 8. PCE Evaluation Metrics . . . . . . . . . . . . . . . . . . . . . 15 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 88 12. Intellectual Property Considerations . . . . . . . . . . . . . . 16 89 13. Normative References . . . . . . . . . . . . . . . . . . . . . . 17 90 14. Informational References . . . . . . . . . . . . . . . . . . . . 17 91 15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 92 16. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 18 93 1. Introduction 95 Constraint-based path computation is a fundamental building block for 96 traffic engineering in MPLS and GMPLS networks. Path computation in 97 large, multi-domain networks is highly complex and may require special 98 computational components and cooperation between the different domains. 99 This document specifies the architecture for a Path Computation Element 100 (PCE)-based model to address this problem space. 102 This document does not attempt to provide a detailed description of all 103 the architectural components. Rather, it describes a set of building 104 blocks for the PCE architecture from which solutions may be constructed. 105 For example, it discusses PCE-based implementations including composite, 106 external, and multiple PCE path computation. Furthermore, it discusses 107 architectural considerations including centralized computation, 108 distributed computation, synchronization, PCE discovery and load 109 balancing, detecting PCE liveness, PCC-PCE and PCE-PCE communication, 110 TED synchronization, stateful and stateless PCEs, monitoring, policy 111 and confidentiality, and evaluation metrics. 113 2. Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 3. Terminology 121 CSPF: Constraint-based Shortest Path First. 123 LER: Label Edge Router. 125 LSDB: Link State Database. 127 LSP: Label Switched Path. 129 LSR: Label Switching Router. 131 PCC: Path Computation Client : any client application requesting a path 132 computation to be performed by the Path Computation Element. 134 PCE: Path Computation Element: an entity (component, application or 135 network node) that is capable of computing a network path or route based 136 on a network graph and applying computational constraints (see further 137 description in section 3). 139 TED: Traffic Engineering Database which contains the topology and 140 resource information of the domain. The TED may be fed by IGP extensions 141 or potentially by other means. 143 TE LSP: Traffic Engineering MPLS Label Switched Path. 145 4. Definitions 147 A Path Computation Element (PCE) is an entity that is capable of 148 computing a network path or route based on a network graph, and applying 149 computational constraints. The PCE entity is an application that can be 150 located within a network node or component, on an out-of-network server, 151 etc. For example, a PCE would be able to compute the path of a TE LSP by 152 operating on the TED and considering the bandwidth and other constraints 153 applicable to the TE LSP service request. 155 A domain is any collection of network elements within a common sphere of 156 address management or path computational responsibility. Examples of 157 domains include IGP areas, Autonomous Systems (ASs), multiple ASs within 158 a service provider network, or multiple ASs across multiple service 159 provider networks. However, domains of computational responsibility may 160 also exist as sub-domains of areas or ASs. 162 In order to fully characterize a PCE and clarify these definitions, the 163 following important considerations must also be examined: 165 1) Path computation is applicable in both intra-domain, inter-domain, 166 and inter-layer contexts. Inter-domain path computation may involve the 167 correlation of topology and routing information between domains. 168 Inter-layer path computation refers to the use of PCE where multiple 169 layers are involved and when the objective is to perform path 170 computation at one or multiple layers while taking into account topology 171 and resource information at these layers. Overlapping domains are not 172 within the scope of this document. In the inter-domain case, the 173 domains may belong to a single or multiple Service Providers. 175 2) In "single PCE path computation," a single PCE is used to compute a 176 given path in a domain. In "multiple PCE path computation," multiple 177 PCEs are used to compute a given path in a domain. 179 3) "Centralized computation model" refers to a model whereby all paths 180 in a domain are computed by a single, centralized PCE. Conversely, 181 "Distributed computation model" refers to the computation of paths in a 182 domain being shared among multiple PCEs. Paths that span multiple 183 domains may be computed using the distributed model with a PCE 184 responsible for each domain, or the centralized model by defining a 185 domain that encompasses all of the other domains. From these 186 definitions, a centralized computation model inherently uses single PCE 187 path computation. However, a distributed computation model could use 188 either single PCE path computation or multiple PCE path computations. 189 There would be no such thing as a centralized model which uses multiple 190 PCE path computations. 192 4) The PCE may or may not be located at the head-end of the path. For 193 example, a conventional intra-domain solution is to have path 194 computation performed by the head-end LSR of an MPLS TE LSP; in this 195 case, the head-end LSR contains a PCE. But solutions also exist where 196 other nodes on the path must contribute to the path computation (for 197 example, loose hops) making them PCEs in their own right. At the same 198 time, the path computation may be made by some other PCE physically 199 distinct from the computed path. 201 5) The path computed by the PCE may be an 'explicit PCE path' (that is, 202 the full explicit path from start to destination, made of a list of 203 strict hops) or a 'strict/loose PCE path' (that is, a mix of strict and 204 loose hops comprising of at least one loose hop representing the 205 destination), where a hop may be an abstract node such as an AS. 207 6) A PCE-based path computation model does not mean to be exclusive and 208 can be used in conjunction with other path computation models. For 209 instance, the path of an inter-AS TE LSP may be computed using a 210 PCE-based path computation model in some IGP areas, whereas the set of 211 traversed ASes may be specified by other means (not determined by any 212 PCE). 214 7) This document does not make any assumptions about the nature or 215 implementation of a PCE. A PCE could be implemented on a router, an LSR, 216 a dedicated network server, etc. Moreover, the PCE function is 217 orthogonal to the forwarding capability of the node on which it is 218 implemented. 220 5. Motivation for a PCE-based Architecture 222 Several motivations for a PCE-based architecture (described in section 223 5) are listed below. This list is not meant to be exhaustive and is 224 provided for the sake of illustration. 226 It should be highlighted that the aim of this section is to provide some 227 application examples for which a PCE-based path may be suitable: this 228 also clearly states that such a model does not aim to replace existing 229 path computation model but would apply to specific existing situations. 231 5.1. CPU-intensive Path Computation/Global Optimization 233 There are many situations where the computation of a path may be highly 234 CPU-intensive: examples of CPU-intensive path computations include the 235 resolutions of NP-complete problems such as: 237 - Global optimization in placing a set of TE LSPs within a domain so as 238 to optimize an objective function (for example, minimization of the 239 maximum link utilization) 241 - Multi-criteria path computation (for example, delay and link 242 utilization, inclusion of switching capabilities, adaptation features, 243 encoding types and optical constraints within a GMPLS optical network) 244 - Computation of minimal cost Point to Multipoint trees (Steiner 245 trees). 247 In these situations, it may not be possible or desirable for a router to 248 perform path computation because of the constraints on its CPU, in which 249 case the path computation may be off-loaded to some other PCE(s). 251 5.2. Partial Visibility 253 There are several scenarios where the node responsible for path 254 computation has limited visibility of the network topology to the 255 destination. This limitation may occur, for instance, when an ingress 256 router attempts to establish an LSP to a destination that lies in a 257 separate domain, since TE information is not exchanged across the domain 258 boundaries. In such cases, it is possible to use loose routes to 259 establish the LSP, relying on routers at the domain borders to establish 260 the next piece of the path, however, it is not possible to guarantee 261 that the optimal (shortest) path will be used, nor even that a viable 262 path will be discovered except, possibly, through repeated trial and 263 error using crankback or other signaling extensions. 265 This problem of inter-domain path computation may most probably be 266 addressed through distributed computation with cooperation among PCEs 267 within each of the domains, or perhaps by using a central "all-seeing" 268 PCE. In this latter case there are challenges of scalability (both the 269 size of the TED and the responsiveness of a single PCE handling requests 270 for many domains) and of preservation of confidentiality when the 271 domains belong to different Service Providers. 273 Note that the issues described here can be further highlighted in the 274 context of LSP re-optimization, or the establishment of multiple diverse 275 LSPs for protection or load sharing. 277 5.3. Absence of the TED or use of Non-TE-Enabled IGP 279 The traffic engineering database (TED) may be a large drain on the 280 resources of a network node (such as an edge router or LER) both from a 281 memory perspective and because it may require non-negligible CPU 282 activity to maintain. The use of a distinct PCE may be appropriate in 283 such circumstances, and a separate node can be used to establish and 284 maintain the TED, and to make it available for path computation. 286 The IGPs run within some networks are not sufficient to build a full 287 TED. For example, a network may run OSPF/IS-IS without the 288 OSPF-TE/ISIS-TE extensions, or some routers in the network may not 289 support the TE extensions. In these cases, in order to successfully 290 compute paths through the network, the TED must be constructed or 291 supplemented through configuration action, and updated as network 292 resources are reserved or released. Such a TED could be distributed to 293 each router so that each router can perform path computation, or held 294 centrally (on a distinct node that supports PCE) for centralized path 295 computation. 297 5.4. Node Outside the Routing Domain 299 An LER might not be part of the routing domain for administrative 300 reasons (for example, a customer-edge (CE) router connected to the 301 provider-edge (PE) router in the context of MPLS VPN [RFC2547] and for 302 which it is desired to provide a CE to CE TE LSP path). 304 This scenario suggests a solution that does not involve doing 305 computation on the ingress router, and that does not rely on static 306 loose hops configuration in which case optimal shortest paths could not 307 be achieved. A distinct PCE-based solution can help here. Note that the 308 PCE in this case may, itself, provide a path that includes loose hops. 310 5.5. Network Element Lacks Control Plan or Routing Capability 312 It is common in legacy optical networks for the network elements not to 313 have a control plane or routing capability. On such network elements 314 there only exists the data plane and management plane, and all 315 cross-connections are made from the management plane. It is desirable in 316 this case to run the path computation on the PCE, and send the 317 cross-connection commands to each node on the computed path. This 318 scenario is important for ASON-capable networks, and may also be used 319 for interworking between GMPLS-capable and GMPLS-incapable networks. 321 5.6. Backup Path Computation for Bandwidth Protection 323 A PCE can be used to compute backup paths in the context of fast reroute 324 protection of TE-LSPs. In this model all backup TE-LSPs protecting a 325 given facility are computed in a coordinated manner by a PCE. This 326 allows ensuring complete bandwidth sharing between bypass tunnels 327 protection independent elements, while avoiding any extensions to LSP 328 signaling. Both centralized and distributed computation models are 329 applicable. In the distributed case each LSR can be a PCE to compute its 330 own protection. 332 5.7. Multi-Layer Networks 334 A server-layer network of one switching capability may support multiple 335 networks of another (more granular) switching capability. For example, a 336 TDM network may provide connectivity for client-layer networks such as 337 IP, MPLS or Layer 2 [MRN]. 339 The server-layer network is unlikely to provide the same connectivity 340 paradigm as the client networks so that bandwidth granularity in the 341 server-layer network may be much coarser than in the client-layer 342 network. Similarly, there is likely to be a management separation 343 between the two networks providing independent address spaces. 344 Further, where multiple client-layer networks make use of the same 345 server-layer network, those client-layer networks may have 346 independent policies, control parameters, address spaces and routing 347 preferences. 349 The different client and server layer networks may be considered as 350 distinct path computation regions within a PCE domain, and so the PCE 351 architecture is 352 useful to allow path computation from one client-layer network region, 353 across the server-layer network to another client-layer network region. 355 In this case, the PCE is responsible for resolving address space issues, 356 handling differences in policy and control parameters, and coordinating 357 resources between the networks. Note that, because of the differences 358 in bandwidth granularity, connectivity across the server-layer network 359 may be provided through virtual TE links or Forwarding Adjacencies: 360 the PCE may offer a point of control responsible for the decision to 361 provision new TE links or Forwarding Adjacencies across the 362 server-layer network. 364 6. Overview of the PCE-Based Architecture 366 This section is intended to give an overview of the network architecture 367 of the PCE model. It needs to be read in conjunction with the details 368 provided in the next section to provide a full view of the flexibility 369 of the model. 371 6.1. Composite PCE 373 Figure 1 below shows the components of a typical composite PCE node 374 (that is, a router that also implements the PCE functionality) that 375 utilizes path computation. The routing protocol is used to exchange TE 376 information from which the TED is constructed. Service requests to 377 provision TE LSPs are received by the node and converted into signaling 378 requests, but these may first require path computation which is 379 requested from a Path Computation Element, the PCE. The PCE operates on 380 the TED in order to respond with the requested path. 382 --------------- 383 | --------- | Routing ---------- 384 | | | | Protocol | | 385 | | TED |<-+----------+-> | 386 | | | | | | 387 | --------- | | | 388 | | | | | 389 | | Input | | | 390 | v | | | 391 | --------- | | | 392 | | | | | Adjacent | 393 | | PCE | | | Node | 394 | | | | | | 395 | --------- | | | 396 | ^ | | | 397 | |Request | | | 398 | |Response| | | 399 | v | | | 400 | --------- | | | 401 Service | | | | Signaling| | 402 Request | |Signaling| | Protocol | | 403 ------+->| Engine |<-+----------+-> | 404 | | | | | | 405 | --------- | ---------- 406 --------------- 408 Figure 1. Composite PCE Node 410 Note that the routing adjacency between the composite PCE node and any 411 other router may be performed by means of direct connectivity or any 412 tunneling mechanism. 414 6.2. External PCE 416 Figure 2 shows PCE support that is external from the requesting network 417 element. A service request is received by the head-end node and before 418 it can signal to establish the service it makes a request to the 419 external PCE for a path to be computed. The PCE makes the computation 420 using the TED and returns a response. 422 ---------- 423 | ----- | 424 | | TED |<-+------------> 425 | ----- | TED synchronization 426 | | | mechanism (for example, routing protocol) 427 | | | 428 | v | 429 | ----- | 430 | | PCE | | 431 | ----- | 432 ---------- 433 ^ 434 | Request/ 435 | Response 436 v 437 Service ---------- Signaling ---------- 438 Request| Head-End | Protocol | Adjacent | 439 ---->| Node |<---------->| Node | 440 ---------- ---------- 442 Figure 2. External PCE Node 444 Note that in this case, the node that supports the PCE function may also 445 perform forwarding, but those functions are purely orthogonal. 447 6.3. Multiple PCE Path Computation 449 Figure 3 illustrates how multiple PCE path computations may be performed 450 along the path of a signaled service. As in the previous example, the 451 head-end PCC makes a request to an external PCE, but the path that is 452 returned is such that the next network element finds it necessary to 453 perform further computation. It consults another PCE to establish the 454 next hop in the path. 456 Note that either or both PCEs in this case could be co-resident with the 457 network node as in Section 5.1. 459 ---------- ---------- 460 | | | | 461 | PCE | | PCE | 462 | | | | 463 | ----- | | ----- | 464 | | TED | | | | TED | | 465 | ----- | | ----- | 466 ---------- ---------- 467 ^ ^ 468 | Request/ | Request/ 469 | Response | Response 470 v v 471 Service ---------- Signaling ------------- Signaling ------------ 472 Request| Head-End | Protocol |Intermediate | Protocol |Intermediate| 473 ---->| Node |<---------->| Node |<--------->| Node | 474 ---------- ------------- ------------ 476 Figure 3. Multiple PCE Path Computation 478 6.4. Multiple PCE Path Computation with Inter-PCE Communication 480 The PCE in Section 5.3 was not able to supply a full path for the 481 requested service and this resulted in the adjacent node needing to make 482 its own computation request. As illustrated in Figure 4, the same 483 problem is solved by introducing inter-PCE communication and cooperation 484 between PCEs so that the PCE consulted by the head-end network node 485 makes a request of another PCE to help with the computation. 487 ---------- ---------- 488 | | Inter-PCE Request/Response | | 489 | PCE |<--------------------------------->| PCE | 490 | | | | 491 | ----- | | ----- | 492 | | TED | | | | TED | | 493 | ----- | | ----- | 494 ---------- ---------- 495 ^ 496 | Request/ 497 | Response 498 v 499 Service ---------- Signaling ---------- Signaling ---------- 500 Request| Head-End | Protocol | Adjacent | Protocol | Adjacent | 501 ---->| Node |<---------->| Node |<---------->| Node | 502 ---------- ---------- ---------- 504 Figure 4. Multiple PCE Path Computation with Inter-PCE Communication 506 Multiple PCE path computation with inter-PCE communication involves 507 coordination between distributed PCEs such that the result of the 508 computation performed by one PCE depends on information supplied by 509 other PCEs. PCE-PCE communication is discussed further in section 6.6. 511 Note that a PCC cannot see the difference between centralized 512 computation, and multiple PCE path computation with inter-PCE 513 communication. That is, the PCC network node or component that requests 514 the computation makes a single request and receives a full or partial 515 path in response, but the response is actually achieved through the 516 coordinated, cooperative efforts of more than one PCE. 518 6.5 Areas for Standardization 520 According to the PCE charter, the following are the standardization 521 areas that the PCE working group will address: 523 - communication between PCCs and PCEs, and between cooperating PCEs 524 - requirements for extensions to existing routing and signaling 525 protocols in support of PCE discovery and signaling of inter-domain 526 paths 527 - definition of metrics to evaluate path quality, scalability, 528 responsiveness and robustness of path computation models. 530 7. PCE Architectural Considerations 532 The aim of this section is to provide a list of the PCE architectural 533 components. Specific realizations and implementation details (state 534 machines or algorithms, etc.) of PCE-based solutions are out of the 535 scope of this document. 537 Note also that PCE-based path computation does not affect in any way the 538 use of the computed paths. For example, the use of PCE does not change 539 the way in which Traffic Engineering LSPs are signaled, maintained and 540 torn down, but strictly relates to the path computation aspects of such 541 TE LSPs. 543 7.1. Centralized Computation Model 545 A "centralized computation model" considers that all path computations 546 for a given domain will be performed by a single, centralized PCE. This 547 may be a dedicated server (for example, an external PCE node), or a 548 nominated router (for example, a composite PCE node) in the network. In 549 this model, all PCCs in the domain would send their path computation 550 requests to the central PCE. While a domain in this context might be an 551 IGP area or AS, it might also be a sub-group of network nodes that is 552 defined by its dependence on the PCE. 554 7.2. Distributed Computation Model 556 A "distributed computation model" refers to a domain or network that may 557 include multiple PCEs, and where computation of paths is shared among 558 the PCEs. A given path may in turn be computed by a single PCE ("single 559 PCE path computation") or multiple PCEs ("multiple PCE path 560 computation"). A PCC may be linked to a particular PCE, or may be able 561 to choose freely among several PCEs - the method of choice between PCEs 562 is out of scope of this document, but see section 6.4. It will often be 563 the case that the computation of an individual path is performed 564 entirely by a single PCE. For example, this is usually the case in MPLS 565 TE within a single IGP where the ingress LSR/composite node is 566 responsible for computing the path or for contacting an external PCE. 567 Conversely, multiple PCE path computation implies the involvement of 568 more than one PCE in the computation of a single path. An example of 569 this is where loose hop expansion is performed by transit LSRs/composite 570 nodes on an MPLS TE LSP. Another example is the use of multiple 571 cooperative PCE involved in the computation of a single LSP path. 573 7.3. Synchronization 575 It is often the case that multiple paths need to be computed to support 576 a single service (for example, for protection or load sharing). 577 A PCC that determines that it requires more than one path to be computed 578 may send a series of individual requests to the PCE. In this case, the 579 PCE may make multiple individual path computations to generate the set 580 of paths - the resultant paths are non-synchronized and are exactly 581 those that would have been generated had the PCC made multiple requests. 582 In this case of non-synchronized path computation, the path computation 583 of a set of TE LSPs can be shared among a set of PCEs (that is, one path 584 computed by each PCE). Furthermore, each PCE can be backed up by one or 585 more PCEs, should it fail. 587 Conversely, the PCC may issue a single request to the PCE asking for all 588 of the paths. The PCE will then in turn perform the simultaneous 589 computation of the set of requested path. Such synchronized computation 590 usually provides more optimal results. 592 The involvement of more than one PCE in the computation of a series of 593 paths is by its nature non-synchronized. However, a set of cooperating 594 PCEs may be synchronized under the control of a single PCE. For example, 595 a PCC may send a request to a PCE which invokes domain specific 596 computations by other PCEs before supplying a result to the PCC. 598 It is desirable to add a parameter to the PCC-PCE protocol to request 599 alternate paths should the primary path fail to complete. While 600 alternate paths may not always be successful if the primary fails, 601 including alternate paths in a PCE response could perhaps have less 602 overhead than having the PCC make separate requests for a second path, 603 third path, etc. This technique is used in some existing CSPF 604 implementations. 606 7.4. PCE Discovery and Load Balancing 608 The PCE architecture requires that the PCC knows the location of one or 609 more PCEs that it can use for the computation of a path. Such knowledge 610 may come through a discovery mechanism that simply relies on local 611 configuration, or can imply dynamic PCE discovery along with various 612 static (for example, Boolean capability) or dynamically computed 613 variables (for example, computing resources). Proxy PCE advertisement 614 whereby the existence of a PCE is advertised via a proxy PCE is a viable 615 alternative, should the PCE be incapable of such advertisement itself. 616 In this later case, it is a requirement for the proxy to adequately 617 advertise the PCE status and capability in a timely and synchronized 618 fashion. 620 In the event that multiple PCEs are available to serve a particular path 621 computation request, the PCC must select a PCE to satisfy the request. 622 The details of such a selection, in order for instance to efficiently 623 share the computation load across multiple PCEs, is local to the PCC and 624 out of the scope of this document. 626 A PCE SHOULD advertise its capabilities, such as: 628 - set of constraints that it can account for (diversity, SRLGs, 629 Optical impairments, wavelength continuity, etc.) 630 - number of switching capability layers (and which ones) 631 - number of path selection criteria (and which ones) 632 - whether it is a stateless PCE or it can send updates about 633 better paths that might be available in the future 634 - whether it can compute P2MP trees (and which types) 635 - whether it can ensure resource sharing between backup tunnels 637 This information would help a PCC that dynamically learns about 638 PCEs available on the network to decide which of them to use. 639 Alternatively, a PCC might ask a PCE to perform a particular type 640 of service and receive a response that says it is unable to 641 perform the service, specify the things it can do. Note that the 642 parameters mentioned above are not meant to be exhaustive and are 643 listed for the sake of illustration. 645 7.5. Detecting PCE Liveness 647 The ability to detect a PCE's liveness is a mandatory piece of the 648 overall architecture and could be achieved by several means. If some 649 form of regular advertisement (such as through IGP extensions) is used 650 for PCE discovery, it is expected that the PCE liveness will be 651 determined by means of status advertisement (for example, IGP LSA/LSPs). 653 The failure of a PCE while processing a request, or the inability of a 654 PCE to service a request (perhaps due to excessive load) may be 655 determined by the PCC through the use of timers. This is particularly 656 true in the case of inter-domain path computation where the PCE liveness 657 may not be detected by means of the IGP. The detection of a PCE failure 658 can be achieved by using the PCC-PCE protocol, much like the mechanisms 659 involving timers used in RSVP and LDP. 661 7.6. PCC-PCE & PCE-PCE Communication 663 Once the PCC has selected a PCE, and provided that the PCE is not local 664 to the PCC, a request/response protocol is required for the PCC to 665 communicate the path computation requests to the PCE and for the PCE to 666 return the path computation response. 668 The path computation request may include a significant set of 669 requirements including 671 - the source and destination of the path 672 - the bandwidth and other QoS parameters desired 673 - resources, resource affinities and shared risk link groups (SRLGs) to 674 use/avoid 675 - the number of disjoint paths required and if near-disjoint paths are 676 acceptable 677 - the level of robustness of the path resources 678 - and so on. 680 The level of robustness of the path resources covers a qualitative 681 assessment of the vulnerability of the resources that may be used. For 682 example, one might grade resources based on empirical evidence (mean 683 time between failures), on known risks (there is major building work 684 going on near this conduit), or on prejudice (vendor X's software is 685 always crashing). A PCC could request that only robust resources be 686 used, or allow any resource. Of course, this information does not 687 comprise part of the TE information advertise by IGPs. It must come from 688 somewhere else. 690 In case of a positive response from the PCE, one or more paths would be 691 returned to the requesting node. In the event of a failure to compute 692 the desired path(s), an error is returned together with as much 693 information as possible about the reasons for the failure, and 694 potentially advice about which constraints might be relaxed to be more 695 likely to achieve a positive result. 697 Note that the resultant path(s) may be made up of a set of strict or 698 loose hops, or any combination of strict and loose hops. Moreover, a hop 699 may have the form of a non-explicit abstract node. 701 A request/response protocol is also required for a PCE to communicate 702 path computation requests to another PCE and for the PCE to return the 703 path computation response. The path computation request may include a 704 significant set of requirements including those defined above. In case 705 of a positive response from the PCE, one or more paths would be returned 706 to the requesting PCE. In the event of a failure to compute the desired 707 path(s), an error is returned together with as much information as 708 possible about the reasons for the failure, and potentially advice about 709 which constraints might be relaxed to be more likely to achieve a 710 positive result. Note that the resultant path(s) may be made up of a 711 set of strict or loose hops, or any combination of strict and loose 712 hops. Moreover, a hop may have the form of a non-explicit abstract node. 714 No assumption is made at this stage about whether the PCC-PCE and 715 PCE-PCE communication protocols are identical. 717 7.7. PCE TED Synchronization 719 As previously described, the PCE operates on a TED. Information on 720 network status to build the TED may be provided in the domain by various 721 means: 723 1) Participation in IGP distribution of TE information. The 724 standard method of distribution of TE information within an IGP area is 725 using extensions to the IGP. This mechanism allows participating nodes 726 to build a TED, and this is the standard technique, for example, within 727 a single area MPLS network. A node that hosts the PCE function may 728 collect TE information in this way by maintaining at least one routing 729 adjacency with a router in the domain. The PCE node may be adjacent or 730 non-adjacent (via some tunneling techniques) to the router. Such a 731 technique provides a mechanism for ensuring that the TED is efficiently 732 synchronized with the network state and is the normal case, for example, 733 when the PCE is co-resident with the LSRs in an MPLS network. 735 2) Out-of-band TED synchronization. It may not be convenient or 736 possible for a PCE node to participate in the IGPs of one or more 737 domains (for example, when there are very many domains, when IGP 738 participation is not desired, or when some domains are not running 739 TE-aware IGPs). In this case some mechanism may need to be defined to 740 allow the PCE node to retrieve the TED from each domain. Such a 741 mechanism could be incremental (like the IGP in the previous case), or 742 could involve a bulk transfer of the complete TED. The latter might 743 significantly limit the capability to ensure TED synchronization which 744 might result in an increase in the failure rate of computed paths. 745 Consideration should also be given to the impact of the TED distribution 746 on the network and on the network node within the domain that is asked 747 to distribute the database. This is particularly relevant in the case of 748 frequent network state changes. 750 3) Information in the TED can include LSP information obtained 751 from sources other than the IGP. For example, this information 752 can include LSP routes, reserved bandwidth, and measured traffic 753 volume passing through the LSP. Such LSP information is required 754 to perform LSP re-optimization, as described in Sections 4.4 and 755 7, which can be take into account the traffic fluctuations. Also, 756 such LSP information is needed to reconfigure virtual network 757 topology (VNT), in which lower layer LSPs such as optical paths 758 form the VNT. The VNT is used for routing of higher-region 759 traffic such as IP traffic. 761 Note that synchronization techniques apply to both intra- and 762 inter-domain TEDs. Further, the techniques can be mixed for use with 763 different domains. The degree of synchronization between the PCE and the 764 network is subject to implementation and/or policy. However, better 765 synchronization leads to paths that are more likely to succeed. 767 It must also be highlighted that the PCE may have access to only a 768 partial TED: for instance in the case of inter-domain path computation 769 where each such domain may be managed by different entities. In such 770 cases, each PCE may have a access to a partial TED and cooperative 771 techniques between PCEs may be used to achieve end-to-end path 772 computation without any requirement for any PCE to handle the complete 773 TED related to the set of traversed domains by the LSP path in question. 775 7.8. Stateful Versus Stateless PCEs 777 A PCE can be either stateful or stateless. In the former case, there is 778 a strict synchronization between the PCE and not only the network states 779 (in term of topology and resource information), but also the set of 780 computed paths and reserved resources in use in the network. In other 781 words, the PCE utilizes information from the TED as well as information 782 about existing paths (for example, TE LSPs) in the network when 783 processing new requests. Note that although this allows for optimal path 784 computation and increased path computation success, stateful PCEs 785 require reliable state synchronization mechanisms, with potentially 786 significant control plane overhead and the maintenance of a large amount 787 of data/states (for example, full mesh of TE LSPs). 789 For example, if there is only one PCE in the domain, all LSP computation 790 is done by this PCE, which can then track all the existing LSPs and stay 791 synchronized. However, this could require substantial control plane 792 resources to accomplish. If there are multiple PCEs in the network, LSP 793 computation and information is distributed among PCEs and the resources 794 required is also distributed. However, synchronization issues discussed 795 in Section 6.7 also come into play. 797 The maintenance of a stateful database can be non-trivial. However, in 798 a single centralized PCE environment, a stateful PCE is almost a simple 799 matter of remembering all of the LSPs the PCE has computed, if it can 800 also be known that the LSPs were actually set up, and when they were 801 torn down. Out-of-band TED synchronization can also be complex with 802 multiple PCE setup in a distributed PCE computation model, and could be 803 prone to race conditions, scalability concerns, etc. Even if the PCE 804 has detailed information on all paths, priorities, and layers, taking 805 such information into account for path computation could be highly 806 complex. PCEs might synchronize state by communicating with each other, 807 but when LSPs are set up using distributed computation performed among 808 several PCEs, the problem of synchronization becomes larger and more 809 complex. 811 There is benefit in knowing which LSPs exist, and their routing, to 812 support such applications as placing a high priority LSP in a crowded 813 network such that it preempts as few other LSPs as possible. Note that 814 preempting based on the minimum number of links might not result in the 815 smallest number of LSPs being disrupted. Another application concerns 816 the construction and maintenance of a Virtual Network Topology [MRN]. 817 It is also helpful to understand which other LSPs exist in the network 818 in order to decide how to manage the forward adjacencies that exist or 819 need to be set up. The cost-benefit of stateful PCE computation would be 820 helpful to determine if the benefit in path computation is sufficient to 821 offset the additional drain on the network computational resources. 823 Conversely, stateless PCEs do not have to remember any computed path and 824 each set of request(s) is processed independently of each other. For 825 example, stateless PCEs may compute paths based on current TED 826 information, which could be out of sync with actual network state given 827 other recent PCE-computed paths changes. Note that a PCC may include a 828 set of previously computed paths in its request, in order to take them 829 into account, for instance to avoid double bandwidth accounting, or to 830 try to minimize changes (minimum perturbation problem). 832 7.9. Monitoring 834 PCE Monitoring is undoubtedly of the utmost importance in any PCE 835 architecture. This must include the collection of variables related to 836 the PCE status and operation. For example, it will be necessary to 837 understand the way in which the TED is being kept synchronized, the rate 838 of arrival of new requests and the computation times, the range of PCCs 839 that are using the PCE, and the operation of any PCC-PCE protocol. 841 7.10. Policy and Confidentiality 843 As stated in [INTER-AS], the case of inter-provider TE LSP path 844 computation requires the ability to compute a path while preserving 845 confidentiality across multiple Service Providers cores. Thus any PCE 846 architecture solution must support the ability to return partial paths 847 by means of loose hops (for example, where each loose hops would for 848 instance identify a boundary LSR). Confidentiality and security of 849 PCC-PCE and PCE-PCE messages must also be ensured. 851 As mentioned in section 6.9, the ability to compute a path at the 852 request of the head end PCC, but to supply the path in segments to the 853 domain boundary PCCs may also be desirable. 855 8. PCE Evaluation Metrics 857 PCE evaluation metrics that may be used to evaluate the efficiency and 858 applicability of any PCE-based solution are listed below. 860 - Optimality: The ability to maximize network utilization and minimize 861 cost, considering QoS objectives, multiple regions and network layers. 863 - Scalability: The implications of routing and signaling overhead 864 (includes LSAs, crankbacks, queries, distribution mechanisms, etc.). 866 - Load sharing: The ability to allow multiple PCEs to spread the path 867 computation load. 869 - Multi-path computation: The ability to compute multiple and 870 potentially diverse paths to satisfy load-sharing of traffic and 871 protection/restoration needs including end-to-end diversity and 872 protection within individual domains. 874 - Reoptimization: The ability to perform TE LSP path reoptimization. 875 This also includes the ability to perform inter-layer correlation when 876 considering the reoptimization at any specific layer. 878 - Path computation time. The time to compute individual paths, multiple 879 diverse paths, and to satisfy bulk path computation requests. 881 - Network stability: The ability to minimize any perturbation on 882 existing TE state resulting from the computation and establishment of 883 new TE paths. 885 - Ability to maintain accurate synchronization between TED and network 886 topology and resource states. 888 - Speed with which TED synchronization is achieved. 890 - Impact of the synchronization process on the data flows in the 891 network. 893 Note that other metrics may also be considered. Such metrics should be 894 used when evaluating a particular PCE-based architecture. It must also 895 be highlighted that the potential tradeoffs of the optimization of such 896 metrics should be evaluated (for instance, increasing the path 897 optimality is likely to have consequences on the computation time). 899 9. Security Considerations 901 The impact of the use of a PCE-based architecture MUST be considered in 902 the light of the impact that it has on the security of the existing 903 routing and signaling protocols and techniques in use within the 904 network. There is unlikely to be any impact on intra-domain security, 905 but an increase in inter-domain information flows and the facilitation 906 of inter-domain path establishment may increase the vulnerability to 907 security attacks. 909 Of particular relevance are the implications for confidentiality 910 inherent in a PCE-based architecture for multi-domain networks. It is 911 not necessarily the case that a multi-domain PCE solution will 912 compromise security, but solutions MUST examine their effects in this 913 area. 915 Applicability statements for particular combinations of signaling, 916 routing and path computation techniques are expected to contain detailed 917 security sections. 919 It should be observed that the use of a non-local PCE (that is, not 920 co-resident with the PCC) does introduce additional security issues. 921 Most notable amongst these are: 923 - Interception of PCE requests or responses 925 - Impersonation of PCE 927 - Falsification of TE information 929 - Denial of service attacks on PCE or PCE communication mechanisms. 931 It is expected that PCE solutions will address these issues in detail 932 using authentication and security techniques. 934 10. IANA Considerations 936 This document makes no requests for IANA action. 938 11. Acknowledgements 940 The authors would like to extend their warmest thanks to (in 941 alphabetical order) Zafar Ali, Dean Cheng, Kireeti Kompella, Jean-Louis 942 Le Roux, Eiji Oki, Dimitri Papadimitriou, and Raymond Zhang for their 943 Review and suggestions. 945 12. Intellectual Property Considerations 947 The IETF takes no position regarding the validity or scope of any 948 Intellectual Property Rights or other rights that might be claimed to 949 pertain to the implementation or use of the technology described in this 950 document or the extent to which any license under such rights might or 951 might not be available; nor does it represent that it has made any 952 independent effort to identify any such rights. Information on the 953 procedures with respect to rights in RFC documents can be found in BCP 954 78 and BCP 79. 956 Copies of IPR disclosures made to the IETF Secretariat and any 957 assurances of licenses to be made available, or the result of an attempt 958 made to obtain a general license or permission for the use of such 959 proprietary rights by implementers or users of this specification can be 960 obtained from the IETF on-line IPR repository at 961 http://www.ietf.org/ipr. 963 The IETF invites any interested party to bring to its attention any 964 copyrights, patents or patent applications, or other proprietary rights 965 that may cover technology that may be required to implement this 966 standard. Please address the information to the IETF at 967 ietf-ipr@ietf.org. 969 13. Normative References 971 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 972 Requirement Levels", BCP 14, RFC 2119, March 1997. 974 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, 975 February 2004. 977 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 978 Technology", BCP 79, RFC 3668, February 2004. 980 14. Informational References 982 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus, 983 "Requirements for Traffic Engineering over MPLS", RFC 2702, September 984 1999. 986 [RFC2547] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC2547, March 987 1999. 989 [RFC3209] Awduche, D., et. all, "Extensions to RSVP for LSP Tunnels", 990 RFC 3209, December 2001. 992 [RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label 993 Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic 994 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 996 [INTER-AREA] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for 997 Support of Inter-Area and Inter-AS MPLS Traffic Engineering", 998 draft-ietf-tewg- interarea-mpls-te-req-03.txt, November 2004 (work in 999 progress). 1001 [INTER-AS] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic 1002 Engineering requirements", draft-ietf-tewg-interas-mpls-te-req-09.txt, 1003 September 2004 (work in progress). 1005 [MRN] Papadimitriou, D., et. al., "Generalized MPLS Architecture for 1006 Multi-Region Networks,"draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt, 1007 February 2004 (work in progress). 1009 15. Authors' Addresses 1011 Adrian Farrel 1012 Old Dog Consulting 1013 Phone: +44 (0) 1978 860944 1014 Fax: +44 (0) 870-130-5411 1015 EMail: adrian@olddog.co.uk 1016 Jean-Philippe Vasseur 1017 Cisco Systems, Inc. 1018 300 Beaver Brook Road 1019 Boxborough , MA - 01719 1020 USA 1021 Email: jpv@cisco.com 1023 Jerry Ash 1024 AT&T 1025 Room MT D5-2A01 1026 200 Laurel Avenue 1027 Middletown, NJ 07748, USA 1028 Phone: +1-(732)-420-4578 1029 Fax: +1-(732)-368-8659 1030 Email: gash@att.com 1032 16. Full Copyright Statement 1034 Copyright (C) The Internet Society (2005). This document is subject to 1035 the rights, licenses and restrictions contained in BCP 78, and except as 1036 set forth therein, the authors retain all their rights. 1038 This document and the information contained herein are provided on an 1039 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 1040 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1041 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1042 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1043 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1044 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.