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