idnits 2.17.1 draft-ietf-pce-architecture-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1814. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1727. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1733. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1671: '...y, but solutions MUST examine their ef...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2006) is 6586 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: 'RFC2702' is defined on line 1737, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 1744, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 1754, but no explicit reference was found in the text == Unused Reference: 'RFC4105' is defined on line 1768, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) -- Obsolete informational reference (is this intentional?): RFC 3784 (ref. 'RFC3748') (Obsoleted by RFC 5305) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Adrian Farrel 2 IETF Internet Draft Old Dog Consulting 3 Proposed Status: Informational Jean-Philippe Vasseur 4 Expires: October 2006 Cisco Systems, Inc. 5 Jerry Ash 6 AT&T 8 April 2006 10 draft-ietf-pce-architecture-05.txt 12 A Path Computation Element (PCE) Based Architecture 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be 34 accessed at http://www.ietf.org/shadow.html. 36 Abstract 38 Constraint-based path computation is a fundamental building block for 39 traffic engineering systems such as Multiprotocol Label Switching 40 (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) 41 networks. Path computation in large, multi-domain, multi-region or 42 multi-layer networks is complex and may require special 43 computational components and cooperation between the different 44 network domains. 46 This document specifies the architecture for a Path Computation 47 Element (PCE)-based model to address this problem space. This 48 document does not attempt to provide a detailed description of all 49 the architectural components, but rather it describes a set of 50 building blocks for the PCE architecture from which solutions may be 51 constructed. 53 1. Introduction ................................................... 3 54 2. Terminology .................................................... 3 55 3. Definitions .................................................... 4 56 4. Motivation for a PCE-based Architecture ........................ 6 57 4.1. CPU-intensive Path Computation ............................. 6 58 4.2. Partial Visibility ......................................... 7 59 4.3. Absence of the TED or Use of Non-TE-Enabled IGP ............ 7 60 4.4. Node Outside the Routing Domain ............................ 8 61 4.5. Network Element Lacks Control Plane or Routing Capability .. 8 62 4.6. Backup Path Computation for Bandwidth Protection ........... 8 63 4.7. Multi-Layer Networks ....................................... 8 64 4.8. Path Selection Policy ...................................... 9 65 4.9. Non-Motivations ........................................... 10 66 4.9.1. The Whole Internet ................................... 10 67 4.9.2. Guaranteed TE LSP Establishment ...................... 10 68 5. Overview of the PCE-Based Architecture ........................ 10 69 5.1. Composite PCE Node ........................................ 10 70 5.2. External PCE .............................................. 11 71 5.3. Multiple PCE Path Computation ............................. 12 72 5.4. Multiple PCE Path Computation with Inter-PCE Communication 13 73 5.5. Management-Based PCE Usage ................................ 14 74 5.6. Areas for Standardization ................................. 15 75 6. PCE Architectural Considerations .............................. 15 76 6.1. Centralized Computation Model ............................. 16 77 6.2. Distributed Computation Model ............................. 16 78 6.3. Synchronization ........................................... 17 79 6.4. PCE Discovery and Load Balancing .......................... 17 80 6.5. Detecting PCE Liveness .................................... 19 81 6.6. PCC-PCE & PCE-PCE Communication ........................... 19 82 6.7. PCE TED Synchronization ................................... 21 83 6.8. Stateful Versus Stateless PCEs ............................ 22 84 6.9. Monitoring ................................................ 24 85 6.10. Confidentiality .......................................... 24 86 6.11. Policy ................................................... 24 87 6.11.1. PCE Policy Architecture ............................ 25 88 6.11.2. Policy Realization ................................. 26 89 6.11.3 Type of Policies .................................... 27 90 6.11.4. Relationship to Signaling .......................... 27 91 6.12. Unsolicited Interactions ................................. 28 92 6.13. Relationship with Crankback .............................. 28 93 7. The View from the Path Computation Client ..................... 29 94 8. Evaluation Metrics ............................................ 30 95 9. Manageability Considerations .................................. 31 96 9.1. Control of Function and Policy ............................ 31 97 9.2. Information and Data Models ............................... 32 98 9.3. Liveness Detection and Monitoring ......................... 32 99 9.5. Verifying Correct Operation ............................... 33 100 9.5. Requirements on Other Protocols and Functional Components . 33 101 9.6. Impact on Network Operation ............................... 34 102 10. Security Considerations ...................................... 34 103 11. IANA Considerations .......................................... 34 104 12. Acknowledgements ............................................. 35 105 13. Intellectual Property Considerations ......................... 35 106 14. Normative References ......................................... 35 107 15. Informational References ..................................... 36 108 16. Contact Information .......................................... 37 109 17. Full Copyright Statement ..................................... 37 111 1. Introduction 113 Constraint-based path computation is a fundamental building block for 114 traffic engineering in MPLS and GMPLS networks. Path computation in 115 large, multi-domain networks is complex and may require 116 special computational components and cooperation between the elements 117 in different domains. This document specifies the architecture for a 118 Path Computation Element (PCE)-based model to address this problem 119 space. 121 This document describes a set of building blocks for the PCE 122 architecture from which solutions may be constructed. For example, it 123 discusses PCE-based implementations including composite, external, 124 and multiple PCE path computation. Furthermore, it discusses 125 architectural considerations including centralized computation, 126 distributed computation, synchronization, PCE discovery and load 127 balancing, detection of PCE liveness, communication between Path 128 Computation Clients (PCCs) and the PCE (PCC-PCE communication) and 129 PCE-PCE communication, Traffic Engineering Database (TED) 130 synchronization, stateful and stateless PCEs, monitoring, policy and 131 confidentiality, and evaluation metrics. 133 The model of the Internet is to distribute network functionality 134 (e.g., routing) within the network. PCE functionality is not intended 135 to contradict this model, and can be used to exactly match the model, 136 for example, when the PCE functionality co-exists with each Label 137 Switching Router (LSR) in the network. PCE is also able to augment 138 functionality in the network where the Internet model cannot supply 139 adequate solutions, for example, where traffic engineering 140 information is not exchanged between network domains. 142 2. Terminology 144 CSPF: Constraint-based Shortest Path First. 146 LER: Label Edge Router. 148 LSDB: Link State Database. 150 LSP: Label Switched Path. 152 LSR: Label Switching Router. 154 PCC: Path Computation Client : any client application requesting a 155 path computation to be performed by the Path Computation Element. 157 PCE: Path Computation Element: an entity (component, application or 158 network node) that is capable of computing a network path or route 159 based on a network graph and applying computational constraints (see 160 further description in Section 3). 162 TED: Traffic Engineering Database which contains the topology and 163 resource information of the domain. The TED may be fed by IGP 164 extensions or potentially by other means. 166 TE LSP: Traffic Engineering MPLS Label Switched Path. 168 3. Definitions 170 A Path Computation Element (PCE) is an entity that is capable of 171 computing a network path or route based on a network graph, and of 172 applying computational constraints during the computation. The PCE 173 entity is an application that can be located within a network node or 174 component, on an out-of-network server, etc. For example, a PCE would 175 be able to compute the path of a TE LSP by operating on the TED and 176 considering bandwidth and other constraints applicable to the TE LSP 177 service request. 179 A domain is any collection of network elements within a common sphere 180 of address management or path computation responsibility. Examples of 181 domains include IGP areas, Autonomous Systems (ASs), and multiple ASs 182 within a Service Provider network. Domains of path computation 183 responsibility may also exist as sub-domains of areas or ASs. 185 In order to fully characterize a PCE and clarify these definitions, 186 the following important considerations must also be examined: 188 1) Path computation is applicable in intra-domain, inter-domain, and 189 inter-layer contexts. 191 a. Inter-domain path computation may involve the association of 192 topology, routing and policy information from multiple domains 193 from which relationships may be deduced in order to help in 194 performing path computation. 196 b. Inter-layer path computation refers to the use of PCE where 197 multiple layers are involved and when the objective is to 198 perform path computation at one or multiple layers while taking 199 into account topology and resource information at these layers. 201 Overlapping domains are not within the scope of this document. In 202 the inter-domain case, the domains may belong to a single or 203 multiple Service Providers. 205 2) a. In "single PCE path computation," a single PCE is used to 206 compute a given path in a domain. There may be multiple PCEs in 207 a domain, but only one PCE per domain is involved in any single 208 path computation. 210 b. In "multiple PCE path computation," multiple PCEs are used to 211 compute a given path in a domain. 213 3) a. "Centralized computation model" refers to a model whereby all 214 paths in a domain are computed by a single, centralized PCE. 216 b. Conversely, "Distributed computation model" refers to the 217 computation of paths in a domain being shared among multiple 218 PCEs. 220 Paths that span multiple domains may be computed using the 221 distributed model with one or more PCEs responsible for each 222 domain, or the centralized model by defining a domain that 223 encompasses all of the other domains. 225 From these definitions, a centralized computation model inherently 226 uses single PCE path computation. However, a distributed 227 computation model could use either single PCE path computation or 228 multiple PCE path computations. There would be no such thing as a 229 centralized model which uses multiple PCEs. 231 4) The PCE may or may not be located at the head-end of the path. For 232 example, a conventional intra-domain solution is to have path 233 computation performed by the head-end LSR of an MPLS TE LSP; in 234 this case, the head-end LSR contains a PCE. But solutions also 235 exist where other nodes on the path must contribute to the path 236 computation (for example, loose hops) making them PCEs in their 237 own right. At the same time, the path computation may be made by 238 some other PCE physically distinct from the computed path. 240 5) The path computed by the PCE may be an "explicit path" (that 241 is, the full explicit path from start to destination, made of a 242 list of strict hops) or a "strict/loose path" (that is, a mix 243 of strict and loose hops comprising at least one loose hop 244 representing the destination), where a hop may be an abstract node 245 such as an AS. 247 6) A PCE-based path computation model does not mean to be exclusive 248 and can be used in conjunction with other path computation models. 249 For instance, the path of an inter-AS TE LSP may be computed using 250 a PCE-based path computation model in some ASs, whereas the 251 set of traversed ASs may be specified by other means (not 252 determined by a PCE). Furthermore, different path computation 253 models may be used for different TE LSPs. 255 7) This document does not make any assumptions about the nature or 256 implementation of a PCE. A PCE could be implemented on a router, 257 an LSR, a dedicated network server, etc. Moreover, the PCE 258 function is orthogonal to the forwarding capability of the node on 259 which it is implemented. 261 4. Motivation for a PCE-based Architecture 263 Several motivations for a PCE-based architecture (described in 264 Section 5) are listed below. This list is not meant to be exhaustive 265 and is provided for the sake of illustration. 267 It should be highlighted that the aim of this section is to provide 268 some application examples for which a PCE-based path may be suitable: 269 this also clearly states that such a model does not aim to replace 270 existing path computation models but would apply to specific existing 271 or future situations. 273 As can be seen from these examples, PCE does not replace the existing 274 Internet model where intelligence is distributed within the network. 275 Instead, it builds on this model and makes use of distributed centers 276 of information or computational ability. PCE should not, therefore, 277 necessarily be seen as a centralized, "all-seeing oracle in the sky", 278 but as the cooperative operation of distributed functionality used to 279 address specific challenges such as the computation of a shortest 280 inter-domain constrained path. 282 4.1. CPU-intensive Path Computation 284 There are many situations where the computation of a path may be 285 highly CPU-intensive: examples of CPU-intensive path computations 286 include the resolution of problems such as: 288 - Placing a set of TE LSPs within a domain so 289 as to optimize an objective function (for example, minimization of 290 the maximum link utilization) 292 - Multi-criteria path computation (for example, delay and link 293 utilization, inclusion of switching capabilities, adaptation 294 features, encoding types and optical constraints within a GMPLS 295 optical network) 297 - Computation of minimal cost Point to Multipoint trees (Steiner 298 trees). 300 In these situations, it may not be possible or desirable for some 301 routers to perform path computation because of the constraints on 302 their CPUs, in which case the path computations may be off-loaded to 303 some other PCE(s) which may, themselves, be routers or may be 304 dedicated PCE servers. 306 4.2. Partial Visibility 308 There are several scenarios where the node responsible for path 309 computation has limited visibility of the network topology to the 310 destination. This limitation may occur, for instance, when an ingress 311 router attempts to establish a TE LSP to a destination that lies in a 312 separate domain, since TE information is not exchanged across the 313 domain boundaries. In such cases, it is possible to use loose routes 314 to establish the TE LSP, relying on routers at the domain borders to 315 establish the next piece of the path, however, it is not possible to 316 guarantee that the optimal (shortest) path will be used, nor even 317 that a viable path will be discovered except, possibly, through 318 repeated trial and error using crankback or other signaling 319 extensions. 321 This problem of inter-domain path computation may most probably be 322 addressed through distributed computation with cooperation among PCEs 323 within each of the domains, and potentially using crankback between 324 the domains to dynamically resolve provisioning issues. 325 Alternatively, a central "all-seeing" PCE that has access to the 326 complete set of topology information may be used, but in this case 327 there are challenges of scalability(both the size of the TED and the 328 responsiveness of a single PCE handling requests for many domains) 329 and of preservation of confidentiality when the domains belong to 330 different Service Providers. 332 Note that the issues described here can be further highlighted in the 333 context of TE LSP reoptimization, or the establishment of multiple 334 diverse TE LSPs for protection or load sharing. 336 4.3. Absence of the TED or use of Non-TE-Enabled IGP 338 The traffic engineering database (TED) may be a large drain on the 339 resources of a network node (such as an edge router or LER) both from 340 a memory perspective and because it may require non-negligible CPU 341 activity to maintain. The use of a distinct PCE may be appropriate in 342 such circumstances, and a separate node can be used to establish and 343 maintain the TED, and to make it available for path computation. 345 The IGPs run within some networks are not sufficient to build a full 346 TED. For example, a network may run OSPF/IS-IS without the 347 OSPF-TE/ISIS-TE extensions, or some routers in the network may not 348 support the TE extensions. In these cases, in order to successfully 349 compute paths through the network, the TED must be constructed or 350 supplemented through configuration action, and updated as network 351 resources are reserved or released. Such a TED could be distributed 352 to the routers that need to perform path computation, or held 353 centrally (on a distinct node that supports PCE) for centralized 354 computation. 356 4.4. Node Outside the Routing Domain 358 An LER might not be part of the routing domain for administrative 359 reasons (for example, a customer-edge (CE) router connected to the 360 provider-edge (PE) router in the context of MPLS VPN [RFC2547] and 361 for which it is desired to provide a CE to CE TE LSP path). 363 This scenario suggests a solution that does not involve doing 364 computation on the ingress (TE LSP head-end, CE) router, and that 365 does not rely on the configuration of static loose hops. In this 366 case, optimal shortest paths can not be guaranteed. A solution that 367 a distinct PCE can help here. Note that the PCE in this case may, 368 itself, provide a path that includes loose hops. 370 4.5. Network Element Lacks Control Plane or Routing Capability 372 It is common in legacy optical networks for the network elements not 373 to have a control plane or routing capability. Such network elements 374 only have a data plane and a management plane, and all 375 cross-connections are made from the management plane. It is 376 desirable in this case to run the path computation on the PCE, and 377 send the cross-connection commands to each node on the computed path. 378 That is, the PCC would be an element of the management plane, perhaps 379 residing in the Network Management System (NMS) or Operations Support 380 System (OSS). 382 This scenario is important for Automatically Switched Optical Network 383 (ASON)-capable networks, and may also be used for interworking 384 between GMPLS-capable and GMPLS-incapable networks. 386 4.6. Backup Path Computation for Bandwidth Protection 388 A PCE can be used to compute backup paths in the context of fast 389 reroute protection of TE LSPs. In this model all backup TE LSPs 390 protecting a given facility are computed in a coordinated manner by a 391 PCE. This allows complete bandwidth sharing between backup tunnels 392 protecting independent elements, while avoiding any extensions to TE 393 LSP signaling. Both centralized and distributed computation models 394 are applicable. In the distributed case each LSR can be a PCE to 395 compute the paths of backup tunnels to protect against the failure of 396 adjacent network links or nodes. 398 4.7. Multi-Layer Networks 400 A server-layer network of one switching capability may support 401 multiple networks of another (more granular) switching capability. 402 For example, a TDM network may provide connectivity for client-layer 403 networks such as IP, MPLS or Layer 2 [MLN]. 405 The server-layer network is unlikely to provide the same connectivity 406 paradigm as the client networks so that bandwidth granularity in the 407 server-layer network may be much coarser than in the client-layer 408 network. Similarly, there is likely to be a management separation 409 between the two networks providing independent address spaces. 410 Further, where multiple client-layer networks make use of the same 411 server-layer network, those client-layer networks may have 412 independent policies, control parameters, address spaces and routing 413 preferences. 415 The different client and server layer networks may be considered as 416 distinct path computation regions within a PCE domain, and so the PCE 417 architecture is useful to allow path computation from one 418 client-layer network region, across the server-layer network to 419 another client-layer network region. 421 In this case, the PCEs are responsible for resolving address space 422 issues, handling differences in policy and control parameters, and 423 coordinating resources between the networks. Note that, because of 424 the differences in bandwidth granularity, connectivity across the 425 server-layer network may be provided through virtual TE links or 426 Forwarding Adjacencies: the PCE may offer a point of control 427 responsible for the decision to provision new TE links or Forwarding 428 Adjacencies across the server-layer network. 430 4.8 Path Selection Policy 432 A PCE may have a local policy that impacts path computation and 433 selection in response to a path computation request. Such policy may 434 act on information provided by the requesting PCC. The result of 435 applying such policy includes, for example, rejection of the path 436 computation request, or provision of a path that does not meet all 437 of the requested constraints. Further, the policy may support 438 administratively configured paths, or selection among transit 439 providers. Inclusion of policy within PCE may simplify the 440 application of policy within the path computation/selection process. 442 Similarly, a PCC may apply local policy to the selection of a PCE to 443 compute a specific path, and to the constraints that are requested. 445 In a PCE context, the policy may be sensitive to the type of path 446 that is being computed. For example, a different set of policies may 447 be applied for an intra-area or single-layer path, than would be 448 provided for an inter-area or multi-layer path. 450 Note that synchronization of policy between PCEs or between PCCs and 451 PCEs may be necessary. Such issues are outside the scope of the PCE 452 architecture, but within scope for the PCE policy framework and 453 application which is described in a separate document. 455 4.9. Non-Motivations 457 4.9.1. The Whole Internet 459 PCE is not considered to be a solution that is applicable to the 460 entire Internet. That is, the applicability of PCE is limited to a 461 set of domains with known relationships. The scale of this limitation 462 is similar to the peering relationships between Service Providers. 464 4.9.2. Guaranteed TE LSP Establishment 466 When two or more paths for TE LSPs are computed on the same set of TE 467 link state information, it is possible that the resultant paths will 468 compete for limited resources within the network. This may result in 469 success for only the first TE LSP to be signaled, or might even mean 470 that no TE LSP can be established. 472 Batch processing of computation requests, back-off times, computation 473 of alternate paths, and crankback can help to mitigate this sort of 474 problem, and PCE may also improve the chances of successful TE LSP 475 setup. However, a single, centralized PCE is not viewed as a solution 476 that can guarantee TE LSP establishment since the potential for 477 network failures or contention for resources still exists where the 478 centralized TED cannot fully reflect current (i.e., real-time) 479 network state. 481 5. Overview of the PCE-Based Architecture 483 This section gives an overview of the architecture of the PCE 484 model. It needs to be read in conjunction with the details provided 485 in the next section to provide a full view of the flexibility of the 486 model. 488 5.1. Composite PCE Node 490 Figure 1 below shows the components of a typical composite PCE node 491 (that is, a router that also implements the PCE functionality) that 492 utilizes path computation. The routing protocol is used to exchange 493 TE information from which the TED is constructed. Service requests to 494 provision TE LSPs are received by the node and converted into 495 signaling requests, but this conversion may require path computation 496 which is requested from a PCE. The PCE operates on the TED subject to 497 local policy in order to respond with the requested path. 499 --------------- 500 | --------- | Routing ---------- 501 | | | | Protocol | | 502 | | TED |<-+----------+-> | 503 | | | | | | 504 | --------- | | | 505 | | | | | 506 | | Input | | | 507 | v | | | 508 | --------- | | | 509 | | | | | Adjacent | 510 | | PCE | | | Node | 511 | | | | | | 512 | --------- | | | 513 | ^ | | | 514 | |Request | | | 515 | |Response| | | 516 | v | | | 517 | --------- | | | 518 Service | | | | Signaling| | 519 Request | |Signaling| | Protocol | | 520 ------+->| Engine |<-+----------+-> | 521 | | | | | | 522 | --------- | ---------- 523 --------------- 525 Figure 1. Composite PCE Node 527 Note that the routing adjacency between the composite PCE node and 528 any other router may be performed by means of direct connectivity or 529 any tunneling mechanism. 531 5.2. External PCE 533 Figure 2 shows a PCE that is external to the requesting network 534 element. A service request is received by the head-end node and 535 before it can initiate signaling to establish the service, it makes 536 a path computation request to the external PCE. The PCE uses the TED 537 subject to local policy as input to the computation and returns a 538 response. 540 ---------- 541 | ----- | 542 | | TED |<-+-----------> 543 | ----- | TED synchronization 544 | | | mechanism (for example, routing protocol) 545 | | | 546 | v | 547 | ----- | 548 | | PCE | | 549 | ----- | 550 ---------- 551 ^ 552 | Request/ 553 | Response 554 v 555 Service ---------- Signaling ---------- 556 Request | Head-End | Protocol | Adjacent | 557 ---->| Node |<---------->| Node | 558 ---------- ---------- 560 Figure 2. External PCE Node 562 Note that in this case, the node that supports the PCE function may 563 also be an LSR or router performing forwarding in its own right (i.e. 564 it may be a composite PCE node), but those functions are purely 565 orthogonal to the operation of the function in the instance being 566 considered here. 568 5.3. Multiple PCE Path Computation 570 Figure 3 illustrates how multiple PCE path computations may be 571 performed along the path of a signaled service. As in the previous 572 example, the head-end PCC makes a request to an external PCE, but the 573 path that is returned is such that the next network element finds it 574 necessary to perform further computation. This may be the case when 575 the path returned is a partial path that does not reach the intended 576 destination or when the computed path is loose. The downstream 577 network element consults another PCE to establish the next hop(s) in 578 the path. In this case, all policy decisions are made independently 579 at each PCE based on information passed from the PCC. 581 Note that either or both PCEs in this case could be composite PCE 582 nodes as in Section 5.1. 584 ---------- ---------- 585 | | | | 586 | PCE | | PCE | 587 | | | | 588 | ----- | | ----- | 589 | | TED | | | | TED | | 590 | ----- | | ----- | 591 ---------- ---------- 592 ^ ^ 593 | Request/ | Request/ 594 | Response | Response 595 v v 596 Service -------- Signaling ------------ Signaling ------------ 597 Request |Head-End| Protocol |Intermediate| Protocol |Intermediate| 598 ---->| Node |<--------->| Node |<--------->| Node | 599 -------- ------------ ------------ 601 Figure 3. Multiple PCE Path Computation 603 5.4. Multiple PCE Path Computation with Inter-PCE Communication 605 The PCE in Section 5.3 was not able to supply a full path for the 606 requested service and this resulted in the adjacent node needing to 607 make its own computation request. As illustrated in Figure 4, the 608 same problem may be solved by introducing inter-PCE communication, 609 and cooperation between PCEs so that the PCE consulted by the 610 head-end network node makes a request of another PCE to help with the 611 computation. 613 ---------- ---------- 614 | | Inter-PCE Request/Response | | 615 | PCE |<--------------------------------->| PCE | 616 | | | | 617 | ----- | | ----- | 618 | | TED | | | | TED | | 619 | ----- | | ----- | 620 ---------- ---------- 621 ^ 622 | Request/ 623 | Response 624 v 625 Service ---------- Signaling ---------- Signaling ---------- 626 Request | Head-End | Protocol | Adjacent | Protocol | Adjacent | 627 ---->| Node |<---------->| Node |<---------->| Node | 628 ---------- ---------- ---------- 630 Figure 4. Multiple PCE Path Computation with Inter-PCE Communication 631 Multiple PCE path computation with inter-PCE communication involves 632 coordination between distinct PCEs such that the result of the 633 computation performed by one PCE depends on path fragment information 634 supplied by other PCEs. This model does not provide a distributed 635 computation algorithm, but allows distinct PCEs to be responsible for 636 computation of parts (segments) of the path. 638 PCE-PCE communication is discussed further in Section 6.6. 640 Note that a PCC might not see the difference between centralized 641 computation, and multiple PCE path computation with inter-PCE 642 communication. That is, the PCC network node or component that 643 requests the computation makes a single request and receives a full 644 or partial path in response, but the response is actually achieved 645 through the coordinated, cooperative efforts of more than one PCE. 647 In this model, all policy decisions may be made independently at each 648 PCE based on computation information passed from the previous PCE. 649 Alternatively, there may be explicit communication of policy 650 information between PCEs. 652 5.5 Management-Based PCE Usage 654 It must be observed that the PCC is not necessarily an LSR. For 655 example, in Figure 5 the NMS supplies the head-end LSR with a fully 656 computed explicit path for the TE LSP that it is to establish through 657 signaling. The NMS uses a management plane mechanism to send this 658 request, and encodes the data using a representation such as the TE 659 MIB module [RFC3812]. 661 The NMS constructs the explicit path that it supplies to the head-end 662 LSR using information provided by the operator. It consults the PCE 663 which returns a path for the NMS to use. 665 Although Figure 5 shows the PCE as remote from the NMS it could, of 666 course, be collocated with the NMS. 668 ----------- 669 | ----- | 670 Service | | TED |<-+-----------> 671 Request | ----- | TED synchronization 672 | | | | mechanism (for example, 673 v | | | routing protocol) 674 ------------- Request/ | v | 675 | | Response| ----- | 676 | NMS |<--------+> | PCE | | 677 | | | ----- | 678 ------------- ----------- 679 Service | 680 Request | 681 v 682 ---------- Signaling ---------- 683 | Head-End | Protocol | Adjacent | 684 | Node |<---------->| Node | 685 ---------- ---------- 687 Figure 5. Management-based PCE Usage 689 5.6 Areas for Standardization 691 The following areas require standardization within the PCE 692 architecture. 694 - communication between PCCs and PCEs, and between cooperating PCEs, 695 including the communication of policy related information 697 - requirements for extending existing routing and signaling protocols 698 in support of PCE discovery and signaling of inter-domain paths 700 - definition of metrics to evaluate path quality, scalability, 701 responsiveness, robustness and policy support of path computation 702 models 704 - MIB modules related to communication protocols, routing and 705 signaling extensions, metrics, and PCE monitoring information. 707 6. PCE Architectural Considerations 709 This section provides a list of the PCE architectural components. 710 Specific realizations and implementation details (state machines or 711 algorithms, etc.) of PCE-based solutions are out of the scope of this 712 document. 714 Note also that PCE-based path computation does not affect in any way 715 the use of the computed paths. For example, the use of PCE does not 716 change the way in which Traffic Engineering LSPs are signaled, 717 maintained and torn down, but strictly relates to the path 718 computation aspects of such TE LSPs. 720 This section presents an architectural view of PCE. That is, it 721 describes the components that exist and how they interact. Note that 722 the architectural model, and in particular the functional model, may 723 be perceived differently by different components of the PCE system. 724 For example, the PCC will not be aware of whether a PCE consults 725 other PCEs. The PCC view of the PCE architecture is discussed in 726 Section 7. 728 6.1. Centralized Computation Model 730 A "centralized computation model" considers that all path 731 computations for a given domain will be performed by a single, 732 centralized PCE. This may be a dedicated server (for example, an 733 external PCE node), or a designated router (for example, a composite 734 PCE node) in the network. In this model, all PCCs in the domain would 735 send their path computation requests to the central PCE. While a 736 domain in this context might be an IGP area or AS, it might also be a 737 sub-group of network nodes that is defined by its dependence on the 738 PCE. 740 This model has a single point of failure: the PCE. In order to avoid 741 this issue, the centralized computation model may designate a backup 742 PCE that can take over the computation responsibility in a controlled 743 manner in the event of a failure of the primary PCE. Any policies 744 present on the primary PCE should also be present on the backup, 745 although the primary policies may themselves be subject to policy 746 governing how they are implemented on the backup. Note that at any 747 moment in time there is only one active PCE in any domain. 749 6.2. Distributed Computation Model 751 A "distributed computation model" refers to a domain or network that 752 may include multiple PCEs, and where computation of paths is shared 753 among the PCEs. A given path may in turn be computed by a single PCE 754 ("single PCE path computation") or multiple PCEs ("multiple PCE path 755 computation"). A PCC may be linked to a particular PCE, or may be 756 able to choose freely among several PCEs - the method of choice 757 between PCEs is out of scope of this document, but see Section 6.4 758 for a discussion of PCE discovery which impacts on this choice. 759 Implementation of policy should be consistent across the set of 760 available PCEs. 762 It will often be the case that the computation of an individual path 763 is performed entirely by a single PCE. For example, this is usually 764 the case in MPLS TE within a single IGP area where the ingress LSR / 765 composite PCE node is responsible for computing the path or for 766 contacting an external PCE. Conversely, multiple PCE path computation 767 implies that more than one PCE is involved in the computation of a 768 single path. An example of this is where loose hop expansion is 769 performed by transit LSRs / composite PCE nodes on an MPLS TE LSP. 770 Another example is the use of multiple cooperating PCEs to compute 771 the path of a single TE LSP across multiple domains. 773 6.3. Synchronization 775 It is often the case that multiple paths need to be computed to 776 support a single service (for example, for protection or load 777 sharing). A PCC that determines that it requires more than one path 778 to be computed may send a series of individual requests to the PCE. 779 In this case of non-synchronized path computation requests, the PCE 780 may make multiple individual path computations to generate the paths 781 and the PCC may send its individual requests to different PCEs. 783 Alternatively, the PCC may send a single request to a PCE asking for 784 a set of paths to be computed, but specifying that non-synchronized 785 path computation is acceptable. The PCE may compute each path in turn 786 exactly as it would have done had the PCC made multiple requests, and 787 the PCE may devolve some computations to other PCEs if it chooses. On 788 the other hand, the PCE is not prohibited from performing all 789 computations together in a synchronized manner as described below. 791 The PCC may also issue a single request to the PCE asking for all of 792 the paths to be computed in a synchronized manner. The PCE will then 793 perform simultaneous computation of the set of requested paths. Such 794 synchronized computation can often provide better results. 796 The involvement of more than one PCE in the computation of a series 797 of paths is by its nature non-synchronized. However, a set of 798 cooperating PCEs may be synchronized under the control of a single 799 PCE. For example, a PCC may send a request to a PCE which invokes 800 domain-specific computations by other PCEs before supplying a result 801 to the PCC. 803 It is desirable to add a parameter to the PCC-PCE protocol to request 804 that the PCE supplies a set of alternate paths for use by the PCC 805 should the establishment of the TE LSP using the principal path fail 806 to complete. While alternate paths may not always be successful if 807 the first path fails, including alternate paths in a PCE response 808 could have less overhead than having the PCC make separate requests 809 for subsequent path computations as the need arises. This technique 810 is used in some existing CSPF implementations. 812 6.4. PCE Discovery and Load Balancing 814 In order that a PCC can communicate efficiently with a PCE, it must 815 know the location of the PCE. That is, it is an architectural 816 decision made here that PCC requests are targeted to a specific PCE, 817 and not broadcast to the network for any PCE to respond. This 818 decision means that only the selected PCE will operate on any single 819 request, and saves network resources during request propagation and 820 processing resources at the PCEs that are not required to respond. 822 The knowledge of the location of a PCE may be achieved through local 823 configuration at the PCC, or may rely on a protocol-based discovery 824 mechanism that may be governed by policy. 826 Where there is more than one PCE known to a PCC, the PCC must have 827 sufficient information to select an appropriate PCE for its purposes, 828 under the control of policy. Such a selection procedure allows for 829 load sharing between PCEs, and supports PCEs with different 830 computation capabilities including different visibility scopes. Thus, 831 the information available to the PCC must include details of the PCE 832 capabilities, which may be fixed or may vary dynamically in time. 834 The PCC may learn PCE capabilities through static configuration or it 835 may discover the information dynamically. Note that even when the 836 location of the PCE is configured at the PCC, the PCC may still 837 discover the PCE capabilities dynamically. Dynamic PCE capabilities 838 cannot be configured and can only be discovered. 840 Proxy PCE advertisement whereby the existence of a PCE is advertised 841 via a proxy PCE is a viable alternative, should the PCE be incapable 842 of such advertisement itself. In this case, it is a requirement for 843 the proxy to adequately advertise the PCE status and capability in a 844 timely and synchronized fashion. 846 In the event that multiple PCEs are available to serve a particular 847 path computation request, the PCC must select a PCE to satisfy the 848 request. The details of such a selection, in order for instance to 849 efficiently share the computation load across multiple PCEs, or to 850 request secondary computations after partial or failed computations, 851 is local to the PCC, may be based on policy and out of the scope of 852 this document. 854 PCE capabilities that may be advertised or configured could include 855 (and not be limited to): 857 - set of constraints that it can account for (diversity, SRLGs, 858 Optical impairments, wavelength continuity, etc.) 859 - computational capacity (for example, the number of computations it 860 can perform per second) 861 - number of switching capability layers (and which ones) 862 - number of path selection criteria (and which ones) 863 - whether it is a stateless PCE or it can send updates about 864 better paths that might be available in the future 865 - whether it can compute P2MP trees (and which types) 866 - whether it can ensure resource sharing between backup tunnels. 868 This information would help a PCC to decide which PCE to use. 870 Requirements for PCE advertisement will be documented separately. 871 Note that there is no restriction within the architecture about how 872 location and capabilities are advertised, and the two elements should 873 be considered to be functionally distinct. 875 A PCC might also ask a PCE to perform a particular type of service 876 without knowledge of the PCE's capabilities, and receive a response 877 that says that the PCE is unable to perform the service. The 878 response could specify the capabilities of the PCE and might also 879 suggest another PCE that has the requested capabilities. 881 6.5. Detecting PCE Liveness 883 The ability to detect a PCE's liveness is a mandatory piece of the 884 overall architecture and could be achieved by several means. If some 885 form of regular advertisement (such as through IGP extensions) is 886 used for PCE discovery, it is expected that the PCE liveness will be 887 determined by means of status advertisement (for example, IGP 888 LSA/LSPs). 890 The inability of a PCE to service a request (perhaps due to excessive 891 load) may be reported to the PCC through a failure message, but the 892 failure of a PCE or the communications mechanism while processing a 893 request cannot be reported in this way. Further, in the case of 894 excessive load, the PCE may not have sufficient resources to send a 895 failure message. Thus the PCC should employ other mechanisms such as 896 protocol timers to determine the liveness of the PCE. This is 897 particularly important in the case of inter-domain path computation 898 where the PCE liveness may not be detected by means of the IGP that 899 runs in the PCC's domain. 901 6.6. PCC-PCE & PCE-PCE Communication 903 Once the PCC has selected a PCE, and provided that the PCE is not 904 local to the PCC, a request/response protocol is required for the PCC 905 to communicate the path computation requests to the PCE and for the 906 PCE to return the path computation response. Discussion of the 907 security requirements and implications for this protocol is provided 908 in Section 10 of this document. 910 The path computation request may include a significant set of 911 requirements including: 913 - the source and destination of the path 914 - the bandwidth and other QoS parameters desired 915 - resources, resource affinities and shared risk link groups (SRLGs) 916 to use/avoid 917 - the number of disjoint paths required and if near-disjoint paths 918 are acceptable 919 - the levels of resiliency, reliability and robustness of the path 920 resources 921 - policy related information. 923 The level of robustness of the path resources covers a qualitative 924 assessment of the vulnerability of the resources that may be used. 925 For example, one might grade resources based on empirical evidence 926 (mean time between failures), on known risks (there is major building 927 work going on near this conduit), or on prejudice (vendor X's 928 software is always crashing). A PCC could request that only robust 929 resources be used, or allow any resource. 931 In case of a positive response from the PCE, one or more paths would 932 be returned to the requesting node. In the event of a failure to 933 compute the desired path(s), an error is returned together with as 934 much information as possible about the reasons for the failure(s), 935 and potentially with advice about which constraints might be relaxed 936 to be more likely to achieve a positive result in a future request. 938 Note that the resultant path(s) may be made up of a set of strict or 939 loose hops, or any combination of strict and loose hops. Moreover, a 940 hop may have the form of a non-explicit abstract node. 942 A request/response protocol is also required for a PCE to communicate 943 path computation requests to another PCE and for the PCE to return 944 the path computation response. The path computation request may 945 include a significant set of requirements including those defined 946 above. In case of a positive response from the PCE, one or more paths 947 would be returned to the requesting PCE. In the event of a failure to 948 compute the desired path(s), an error is returned together with as 949 much information as possible about the reasons for the failure, and 950 potentially advice about which constraints might be relaxed to be 951 more likely to achieve a positive result. Note that the resultant 952 path(s) may be made up of a set of strict or loose hops, or any 953 combination of strict and loose hops. Moreover, a hop may have the 954 form of a non-explicit abstract node. 956 An important feature of PCEs that are cooperating to compute a path 957 is that they apply compatible or identical computation algorithms and 958 coordinated policies. This may require coordination through the 959 communication between the PCEs. 961 Note that when multiple PCEs cooperate to compute a path it is 962 important that they have a coordinated view of the meaning of 963 constraints such as costs, resource affinities and class of service. 964 This is particularly significant where the PCEs are responsible for 965 different domains. It is assumed that this is a matter of policy 966 between domains and between PCEs. 968 No assumption is made in this architecture about whether the PCC-PCE 969 and PCE-PCE communication protocols are identical. 971 6.7. PCE TED Synchronization 973 As previously described, the PCE operates on a TED. Information on 974 network status to build the TED may be provided in the domain by 975 various means: 977 1) Participation in IGP distribution of TE information. The standard 978 method of distribution of TE information within an IGP area is 979 through the use of extensions to the IGP [RFC3630, RFC3748]. This 980 mechanism allows participating nodes to build a TED, and this is 981 the standard technique, for example, within a single area MPLS 982 or GMPLS network. A node that hosts the PCE function may collect 983 TE information in this way by maintaining at least one routing 984 adjacency with a router in the domain. The PCE node may be 985 adjacent or non-adjacent (via some tunneling techniques) to the 986 router. Such a technique provides a mechanism for ensuring that 987 the TED is efficiently synchronized with the network state and is 988 the normal case, for example, when the PCE is co-resident with the 989 LSRs in an MPLS or GMPLS network. 991 2) Out-of-band TED synchronization. It may not be convenient or 992 possible for a PCE to participate in the IGPs of one or more 993 domains (for example, when there are very many domains, when IGP 994 participation is not desired, or when some domains are not running 995 TE-aware IGPs). In this case some mechanism may need to be defined 996 to allow the PCE node to retrieve the TED from each domain. Such a 997 mechanism could be incremental (like the IGP in the previous 998 case), or could involve a bulk transfer of the complete TED. The 999 latter might significantly limit the capability to ensure TED 1000 synchronization which might result in an increase in the failure 1001 rate of computed paths, or the computation of sub-optimal paths. 1002 Consideration should also be given to the impact of the TED 1003 distribution on the network and on the network node within the 1004 domain that is asked to distribute the database. This is 1005 particularly relevant in the case of frequent network state 1006 changes. 1008 3) Information in the TED can include information obtained from 1009 sources other than the IGP. For example, information about link 1010 usage policies can be configured by the operator. Path computation 1011 can also act on a far wider set of information that includes data 1012 about the TE LSPs provisioned within the network. This information 1013 can include TE LSP routes, reserved bandwidth, and measured 1014 traffic volume passing through the TE LSP. 1016 Such TE LSP information can enhance TE LSP (re)optimization to 1017 provide "full network" (re)optimization, and can allow traffic 1018 fluctuations to be taken into account. Detailed TE LSP information 1019 may also facilitate reconfiguration of the Virtual Network 1020 Topology (VNT) [MLN], in which lower layer TE LSPs such as optical 1021 paths provide TE links for use by the higher layer, since this 1022 reconfiguration is also a "full network" problem. 1024 Note that synchronization techniques may apply to both intra- and 1025 inter-domain TEDs. Further, the techniques can be mixed for use in 1026 different domains. The degree of synchronization between the PCE and 1027 the network is subject to implementation and/or policy. However, 1028 better synchronization generally leads to paths that are more likely 1029 to succeed. 1031 It must also be highlighted that the PCE may have access to only a 1032 partial TED: for instance in the case of inter-domain path 1033 computation where each such domain may be managed by different 1034 entities. In such cases, each PCE may have access to a partial TED 1035 and cooperative techniques between PCEs may be used to achieve 1036 end-to-end path computation without any requirement for any PCE to 1037 handle the complete TED related to the set of traversed domains by 1038 the TE LSP in question. 1040 6.8. Stateful Versus Stateless PCEs 1042 A PCE can be either stateful or stateless. In the former case, there 1043 is a strict synchronization between the PCE and not only the network 1044 states (in term of topology and resource information), but also the 1045 set of computed paths and reserved resources in use in the network. 1046 In other words, the PCE utilizes information from the TED as well as 1047 information about existing paths (for example, TE LSPs) in the 1048 network when processing new requests. Note that although this allows 1049 for optimal path computation and increased path computation success, 1050 stateful PCEs require reliable state synchronization mechanisms, with 1051 potentially significant control plane overhead and the maintenance of 1052 a large amount of data/states (for example, full mesh of TE LSPs). 1054 For example, if there is only one PCE in the domain, all TE LSP 1055 computation is done by this PCE, which can then track all the 1056 existing TE LSPs and stay synchronized (each TE LSP state change must 1057 be tracked by the PCE). However, this model could require substantial 1058 control plane resources. If there are multiple PCEs in the network, 1059 TE LSP computation and information is distributed among PCEs and so 1060 the resources required to perform the computations are also 1061 distributed. However, synchronization issues discussed in Section 6.7 1062 also come into play. 1064 The maintenance of a stateful database can be non-trivial. However, 1065 in a single centralized PCE environment, a stateful PCE is almost a 1066 simple matter of remembering all of the TE LSPs the PCE has computed, 1067 if it can also be known that the TE LSPs were actually set up, and 1068 when they were torn down. Out-of-band TED synchronization can also be 1069 complex with multiple PCE setup in a distributed PCE computation 1070 model, and could be prone to race conditions, scalability concerns, 1071 etc. Even if the PCE has detailed information on all paths, 1072 priorities, and layers, taking such information into account for path 1073 computation could be highly complex. PCEs might synchronize state by 1074 communicating with each other, but when TE LSPs are set up using 1075 distributed computation performed among several PCEs, the problems of 1076 synchronization and race condition avoidance become larger and more 1077 complex. 1079 There is benefit in knowing which TE LSPs exist, and their routing, 1080 to support such applications as placing a high priority TE LSP in a 1081 crowded network such that it preempts as few other TE LSPs as 1082 possible (also known as the "minimal perturbation" problem). Note 1083 that preempting based on the minimum number of links might not result 1084 in the smallest number of TE LSPs being disrupted. Another 1085 application concerns the construction and maintenance of a Virtual 1086 Network Topology [MLN]. It is also helpful to understand which other 1087 TE LSPs exist in the network in order to decide how to manage the 1088 forward adjacencies that exist or need to be set up. The cost-benefit 1089 of stateful PCE computation would be helpful to determine if the 1090 benefit in path computation is sufficient to offset the additional 1091 drain on the network and computational resources. 1093 Conversely, stateless PCEs do not have to remember any computed path 1094 and each set of request(s) is processed independently of each other. 1095 For example, stateless PCEs may compute paths based on current TED 1096 information, which could be out of sync with actual network state 1097 given other recent PCE-computed paths changes. Note that a PCC may 1098 include a set of previously computed paths in its request, in order 1099 to take them into account, for instance to avoid double bandwidth 1100 accounting, or to try to minimize changes (minimum perturbation 1101 problem). 1103 It should be observed that the stateless PCE does operate on 1104 information about network state. The TED contains link state and 1105 bandwidth availability information as distributed by the IGPs or 1106 collected through some other means. This information could be 1107 further enhanced to provide increased granularity and more detail to 1108 cover, for example, the current bandwidth usage on certain links 1109 according to resource affinities or forwarding equivalence classes. 1110 Such information is, however, not PCE state information and so a 1111 model that uses it is still described as stateless in the PCE 1112 context. 1114 A limited form of statefulness might be applied within an otherwise 1115 stateful PCE. The PCE may retain some context from paths it has 1116 recently computed so that it avoid suggesting the use of the same 1117 resources for other TE LSPs. 1119 6.9. Monitoring 1121 PCE Monitoring is undoubtedly of the utmost importance in any PCE 1122 architecture. This must include the collection of variables related 1123 to the PCE status and operation. For example, it will be necessary to 1124 understand the way in which the TED is being kept synchronized, the 1125 rate of arrival of new requests and the computation times, the range 1126 of PCCs that are using the PCE, and the operation of any PCC-PCE 1127 protocol. 1129 6.10. Confidentiality 1131 As stated in [RFC4216], the case of inter-provider TE LSP 1132 computation requires the ability to compute a path while preserving 1133 confidentiality across multiple Service Providers cores. That is, one 1134 Service Provider must not be required to divulge any information 1135 about its resources or topology in order to support inter-provider 1136 TE LSP path computation. Thus any PCE architecture solution 1137 must support the ability to return partial paths by means of loose 1138 hops (for example, where each loose hops would for instance 1139 identify a boundary LSR). 1141 This requirement is not a security issue, but relates to Service 1142 Provider policy. Confidentiality, integrity, and authentication of 1143 PCC-PCE and PCE-PCE messages must also be ensured and is described in 1144 Section 10. 1146 The ability to compute a path at the request of the head end PCC, but 1147 to supply the path in segments to the domain boundary PCCs may also 1148 be desirable. 1150 6.11. Policy 1152 Policy impacts multiple aspects of the PCE architecture. There are 1153 two applications of policy for consideration: 1154 - application of policy within an architectural entity (PCC or PCE) 1155 - application of policy to PCE related communications. 1157 Policy as directly applicable to TE LSPs forms part of the signaling 1158 mechanism for the establishment of the TE LSPs and is not described 1159 here. 1161 It is envisioned that policy will be largely applied as a local 1162 matter within each PCC and PCE. However, this document needs to 1163 define policy models that can be supported within the PCE 1164 architecture and by PCE-related communication. 1166 Some example policies include: 1167 - selection of a PCE by a PCC 1168 - rejection of a request by the PCE based on the identity of the 1169 requesting PCC 1170 - selection by the PCE of a path or application of additional 1171 constraints to a computation based on the PCC, the computation 1172 target, the time of day, etc. 1174 6.11.1. PCE Policy Architecture 1176 Two examples of the use of policy components within the PCE 1177 architecture are illustrated in Figures 6 and 7. Policy components 1178 could equally be applied to the other PCE configurations shown in 1179 Section 5. In each configuration, policy may be consulted before a 1180 response is provided by a PCE and may also be consulted by the 1181 PCC/PCE that receives the response. 1183 A PCE may have a local policy that impacts the paths selected to 1184 satisfy a particular PCE request. A policy may be applied based on 1185 any information provided from a PCC. 1187 In Figure 6 the policy component is shown providing input to the PCE 1188 component. This policy component may consult an external policy 1189 database, but this is outside the scope of this document. 1191 ------------------------------ 1192 | --------- | Routing ---------- 1193 | | | | Protocol | | 1194 | | TED |<-+----------+-> | 1195 | | | | | | 1196 | --------- | | | 1197 | | | | | 1198 | | Input | | | 1199 | v | | | 1200 | --------- --------- | | | 1201 | | Policy | | | | | Adjacent | 1202 | |Component|--->| PCE | | | Node | 1203 | | | | | | | | 1204 | --------- --------- | | | 1205 | ^ | | | 1206 | |Request | | | 1207 | |Response| | | 1208 | v | | | 1209 | --------- | | | 1210 Service | | | | Signaling| | 1211 Request | |Signaling| | Protocol | | 1212 ------+---------------->| Engine |<-+----------+-> | 1213 | | | | | | 1214 | --------- | ---------- 1215 ------------------------------ 1217 Figure 6. Policy Component in the Composite PCE Node 1219 Note that policy information may be conveyed on the internal 1220 interfaces, and on the external protocol interfaces. 1222 Figure 7 displays the case of a distinct PCE function through the 1223 example of the multiple PCE with inter-PCE communication example 1224 (compare with figure 4). Each PCE takes input from local policy as 1225 part of the router computation/determination process. The local 1226 policy components may consult external policy components or 1227 databases, but that is out of scope of this document. 1229 Note that policy information may be conveyed on the external 1230 protocol interfaces, including the inter-PCE interface. 1232 ------------------ ------------------ 1233 | | Inter-PCE Request/Response| | 1234 | PCE |<------------------------->| PCE | 1235 | | | | 1236 | ------ ----- | | ------ ----- | 1237 | |Policy| | TED | | | |Policy| | TED | | 1238 | ------ ----- | | ------ ----- | 1239 ------------------ ------------------ 1240 ^ 1241 | Request/ 1242 | Response 1243 v 1244 Service ---------- Signaling ---------- Signaling ---------- 1245 Request| Head-End | Protocol | Adjacent | Protocol | Adjacent | 1246 ---->| Node |<---------->| Node |<---------->| Node | 1247 ---------- ---------- ---------- 1249 Figure 7. Policy Components in Multiple PCEs 1251 6.11.2. Policy Realization 1253 There are multiple options for how policy information is coordinated. 1255 - Policy decisions may be made by PCCs before consulting PCEs. This 1256 type of decision includes selection of PCE, application of 1257 constraints, and interpretation of service requests. 1259 - Policy decisions may be made independently at a PCE, or at each 1260 cooperating PCE. That is, the PCE(s) may make policy decisions 1261 independent of other policy decisions made at PCCs or other PCEs. 1263 - There may also be explicit communication of policy information 1264 between PCC and PCE, or between PCEs to achieve some level of 1265 coordination of policy between entities. The type of information 1266 conveyed to support policy has important implications on what 1267 policies may be applied at each PCE, and the requirements for the 1268 exchange of policy information inform the choice or implementation 1269 of communication protocols including PCC-PCE, PCE-PCE, and 1270 discovery protocols. 1272 6.11.3 Type of Policies 1274 Within the context of PCE, we identify several types of policies: 1276 o User-specific policies operate on information that is specific to 1277 the user of a service or the service itself. That is, the service 1278 for which the path is being computed, not the computation service. 1279 Examples of such information includes the contents of objects of a 1280 signaling or provisioning message, the port ID over which the 1281 message was received, a VPN ID, a reference point type, or the 1282 identity of the user initiating the request. User-specific policies 1283 could be applied by a PCC while building a path computation 1284 request, or by a PCE while processing the request provided that 1285 sufficient information is supplied by the PCC to the PCE. 1287 o Request-specific policies operate on information that is specific 1288 to a path computation request and is carried in 1289 the request. Examples of such information include constraints, 1290 diversities, constraint and diversity relaxation strategies, and 1291 optimization functions. Request-specific policies directly affect 1292 the path selection process because they specify which links, nodes, 1293 path segments and/or paths are not acceptable or, on the contrary, 1294 may be desirable to appear in the resulting paths. 1296 o Domain-specific policies operate on the identify of the domain in 1297 which the requesting PCC exists, and upon the identities of the 1298 domains through which the resulting paths are routed. These 1299 policies have the same effect as user-specific policies with the 1300 difference that they can be applied to a group of users rather than 1301 an individual user. One example of domain-specific policy is a 1302 restriction on what information a PCE publishes within a given 1303 domain. In such a case, PCEs in some domains may advertise just 1304 their presence while others may advertise details regarding their 1305 capabilities, client authentication process, and computation 1306 resource availability. 1308 6.11.4. Relationship to Signaling 1310 When a path for an inter-domain TE LSP is being computed it is not 1311 required to consider signaling plane policy. However, failure to do 1312 so may result in the TE LSP failing to be established, or being 1313 assigned fewer resources than intended resulting in a substandard 1314 service. Thus, where a PCE invoked by a head-end LSR has visibility 1315 into other domains, it should be capable of applying policy 1316 considerations to the computation and should be aware of the 1317 inter-domain policy agreements. Where path computation is the result 1318 of cooperation between PCEs, each of which is responsible for a 1319 particular domain, the policy issues should, where possible be 1320 resolved at the time of computation so that the TE LSP is more likely 1321 to be signaled successfully. In such context policy violation during 1322 inter-domain TE LSP computation may lead to path computation 1323 interruption which should be notified to the requester along with the 1324 cause. 1326 6.12. Unsolicited Interactions 1328 It may be that the PCC-PCE communications (see Section 6.6) can be 1329 usefully extended beyond a simple request/response interaction. For 1330 example, the PCE and PCC could exchange capabilities using this 1331 protocol. Additionally, the protocol could be used to collect and 1332 report information in support of a stateful PCE. 1334 Further, it may be the case that a PCE is able to update a path that 1335 it computed earlier (perhaps in reaction to a change in the network 1336 or a change in policy), and in this case the PCE-PCC communication 1337 could support an "unsolicited" path computation message to supply 1338 this new path to the PCC. It should be noted, however, that this 1339 function would require that the PCE retained a record of previous 1340 computations and had a clear trigger for performing recomputations. 1341 The PCC would also need to be able to identify the new path with the 1342 old path and determine whether it should act on the new path. 1343 Furthermore, the PCC should be able to report the outcome of such 1344 path changes to the requesting PCE. Note that the PCE-PCC interaction 1345 is not a management interaction and the PCC is not obliged to utilize 1346 any additional path supplied by the PCE. 1348 These functions fit easily within the architecture described here 1349 but are left for further discussion within separate requirements 1350 documents. 1352 6.13. Relationship with Crankback 1354 Crankback routing is a mechanism whereby a failure to establish a 1355 path, or a failure of an existing path may be corrected by a new 1356 path computation and fresh signaling. Crankback routing relies on the 1357 distribution of crankback information along with the failure 1358 notification so that the new computation can be performed avoiding 1359 the failure or blockage point. 1361 In the context of PCE, crankback information may be passed back to 1362 the head-end where the process of computation and signaling can be 1363 repeated using the failed resource as an exclusion in the computation 1364 process. But crankback may be used to attempt to correct the 1365 problem at intermediate points along the path. Such crankback 1366 recomputation nodes are most likely to be domain boundaries where the 1367 PCC had already invoked a PCE. Thus, a failure within a domain is 1368 reported to the ingress domain boundary which will attempt to compute 1369 an alternate path across the domain. Failing this, the problem may be 1370 reported to the previous domain, and communicated to the ingress 1371 boundary for that domain which may attempt to select a more 1372 successful path either by choosing a different entry point into the 1373 next domain, or by selecting a route through a different set of 1374 domains. 1376 7. The View from the Path Computation Client 1378 The view of the PCE architecture, and particularly the functional 1379 model, is subtly different from the PCC's perspective. This is partly 1380 because the PCC has limited knowledge of the way in which the PCEs 1381 cooperate to answer its requests, but depends more on the fact that 1382 the PCC is concerned with different questions. 1384 The PCC is interested in the following: 1386 - Selecting a PCE that is able to promptly provide a computed path 1387 meeting the supplied constraints. 1389 - How many computation requests will the PCC have to send? Will the 1390 desired path be computed by the first PCE contacted (possibly in 1391 cooperation with other PCEs), or will the PCC have to consult other 1392 PCEs to fill in gaps in the path? 1394 - How many other path computations will need to be issued from within 1395 the network in order to establish the TE LSP? 1397 This last question might be considered to be out of scope for the 1398 head-end LSR, but an important constraint that the PCC may wish to 1399 apply is that the path should be computed in its entirety and 1400 supplied without loose hops or non-simple abstract nodes. 1402 Thus, with its limited perspective, the PCC will see Multiple PCE 1403 Path Computation (Section 5.3) as important, and will distinguish 1404 two subcases: the first is as shown in Figure 3 with subsequent 1405 computation requests made by other PCCs along the path of the TE LSP; 1406 the second having multiple computation requests issued by the 1407 head-end LSR. On the other hand, the PCC will not be aware of 1408 Multiple PCE Path Computation with Inter-PCE Communication (Section 1409 5.4) which it will perceive as no different from the simple External 1410 PCE Node case (Section 5.2). 1412 The PCC, therefore, will be acutely aware that a Centralized PCE 1413 Model (Section 6.1) might still require Multiple PCE Path 1414 Computations with the head-end or subsequent PCCs required to issue 1415 further requests to the central PCE. Conversely, the PCC may be 1416 protected from the Distributed PCE Model (Section 6.2) by the fact 1417 that the first PCE it consults uses inter-PCE communication to 1418 achieve a complete computation result so that no further computation 1419 requests are required. 1421 These distinctions can be completely classified by determining 1422 whether the computation response includes all necessary paths, and 1423 whether those paths are fully explicit (that is, containing only 1424 strict hops between simple abstract nodes). 1426 8. Evaluation Metrics 1428 Evaluation metrics that may be used to evaluate the efficiency and 1429 applicability of any PCE-based solution are listed below. Note that 1430 these metrics are not being used to determine paths, but are used to 1431 evaluate potential solutions to the PCE architecture. 1433 - Optimality: The ability to maximize network utilization and 1434 minimize cost, considering QoS objectives, multiple regions and 1435 network layers. Note that models that require the sequential 1436 involvement of multiple PCEs (for example, the multiple PCE model 1437 described in Section 5.3) might create path loops unless careful 1438 policy is applied. 1440 - Scalability: The implications of routing, TE LSP signaling and PCE 1441 communication overhead such as the number of messages and the size 1442 of messages (including LSAs, crankback information, queries, 1443 distribution mechanisms, etc.). 1445 - Load sharing: The ability to allow multiple PCEs to spread the path 1446 computation load by allowing multiple PCEs to each take 1447 responsibility for a subset of the total path computation requests. 1449 - Multi-path computation: The ability to compute multiple and 1450 potentially diverse paths to satisfy load-sharing of traffic and 1451 protection/restoration needs including end-to-end diversity and 1452 protection within individual domains. 1454 - Reoptimization: The ability to perform TE LSP path reoptimization. 1455 This also includes the ability to perform inter-layer correlation 1456 when considering the reoptimization at any specific layer. 1458 - Path computation time: The time to compute individual paths, 1459 multiple diverse paths, and to satisfy bulk path computation 1460 requests. (Note that such a metric can only be applied to problems 1461 that are not NP-complete.) 1463 - Network stability: The ability to minimize any perturbation on 1464 existing TE state resulting from the computation and establishment 1465 of new TE paths. 1467 - Ability to maintain accurate synchronization between TED and 1468 network topology and resource states. 1470 - Speed with which TED synchronization is achieved. 1472 - Impact of the synchronization process on the data flows in the 1473 network. 1475 - Ability to deal with situations where paths satisfying a required 1476 set of constraints cannot be found by the PCE. 1478 - Policy: Application of policy to the PCC-PCE and PCE-PCE 1479 communications as well as to the computation of paths that respect 1480 inter-domain TE LSP establishment policies. 1482 Note that other metrics may also be considered. Such metrics should 1483 be used when evaluating a particular PCE-based architecture. It must 1484 also be highlighted that the potential tradeoffs of the optimization 1485 of such metrics should be evaluated (for instance, increasing the 1486 path optimality is likely to have consequences on the computation 1487 time). 1489 9. Manageability Considerations 1491 The PCE architecture introduces several elements that are subject to 1492 manageability. The PCE itself must be managed as must its 1493 communications with PCCs and other PCEs. The mechanism by which PCEs 1494 and PCCs discover each other are also subject to manageability. 1496 Many of the issues of manageability are already covered in other 1497 sections of this document. 1499 9.1. Control of Function and Policy 1501 It must be possible to enable and disable the PCE function at a PCE, 1502 and this will lead to the PCE accepting, rejecting, or simply not 1503 receiving requests from PCCs. Graceful shutdown of the PCE function 1504 should also be considered so that in controlled circumstances (such 1505 as software upgrade) a PCE does not just 'disappear' but warns its 1506 PCCs and gracefully handles any queued computation requests (perhaps 1507 by completing them, forwarding them to another PCE, or rejecting 1508 them). 1510 Similarly it must be possible to control the application of policy at 1511 the PCE through configuration. This control may include the 1512 restriction of certain functions or algorithms, the configuration of 1513 access rights and priorities for PCCs, and the relationships with 1514 other PCEs both inside and outside the domain. 1516 The policy configuration interface is yet to be determined. The 1517 interface may be purely a local matter, or may be supported via a 1518 standardized interface (such as, a MIB module). 1520 9.2. Information and Data Models 1522 It is expected that the operations of PCEs and PCCs will be modeled 1523 and controlled through appropriate MIB modules. The tables in the new 1524 MIB modules will need to reflect the relationships between entities 1525 and to control and report on configurable options. 1527 Statistics gathering will form an important part of the operation of 1528 PCEs. The operator must be able to determine the historical 1529 interactions of a PCC with its PCEs, the performance that it has 1530 seen, and success rate of its requests. Similarly, it is important 1531 for an operator to be able to inspect a PCE and determine its load 1532 and whether an individual PCC is responsible for a disproportionate 1533 amount of the load. It will also be important to be able to record 1534 and inspect statistics about the communications between the PCC and 1536 PCE, including issues such as malformed messages, unauthorized 1537 messages and messages discarded owing to congestion. In this respect 1538 there is clearly an overlap between manageability and security. 1540 Statistics for the PCE architecture can be made available through 1541 appropriate tables in the new MIB modules. 1543 The new MIB modules should also be used to provide notifications when 1544 key thresholds are crossed or when important events occur. Great care 1545 must be exercised to ensure that the network is not flooded with SNMP 1546 notifications. Thus it might be inappropriate to issue a notification 1547 every time that a PCE receives a request to compute a path. In any 1548 case, full control must be provided to allow notifications to be 1549 disabled using, for example, the mechanisms defined in the 1550 SNMP-NOTIFICATION-MIB module in [RFC3413]. 1552 9.3. Liveness Detection and Monitoring 1554 Section 6.5 discusses the importance of a PCC being able to detect 1555 the liveness of a PCE. PCE-PCC communications techniques must enable 1556 a PCC to determine the liveness of a PCE both before it sends a 1557 request and in the period between sending a request and receiving a 1558 response. 1560 It is less important for a PCE to know about the liveness of PCCs, 1561 and within the simple request/response model, this is only helpful: 1563 - to gain a predictive view of the likely loading of a PCE in the 1564 future 1566 - to allow a PCE to abandon processing of a received request. 1568 9.4. Verifying Correct Operation 1570 Correct operation for the PCE architecture can be classified as 1571 determining the correct point-to-point connectivity between PCCs and 1572 PCEs, and assessing the validity of the computed paths. The former is 1573 a security issue that may be enhanced by authentication and monitored 1574 through event logging and records as described in Section 9.1. It may 1575 also be a routing issue to ensure that PCC-PCE connectivity is 1576 possible. 1578 Verifying computed paths is more complex. The information to perform 1579 this function can, however, be made available to the operator through 1580 MIB tables provided full records are kept of the constraints passed 1581 on the request, the path computed and provided on the response, and 1582 any additional information supplied by the PCE such as the constraint 1583 relaxation policies applied. 1585 9.5. Requirements on Other Protocols and Functional Components 1587 At the architectural stage it is impossible to make definitive 1588 statements about the impact on other protocols and functional 1589 components since the solutions work has not been completed. However, 1590 it is possible to make some observations. 1592 - Dependence on underlying transport protocols 1594 PCE-PCC communications may choose to utilize underlying protocols 1595 to provide transport mechanisms. In this case some of the 1596 manageability considerations described in the previous sections may 1597 be devolved to those protocols. 1599 - Re-use of existing protocols for discovery 1601 Without prejudicing the requirements and solutions work for PCE 1602 discovery (see Section 6.4) it is possible that use will be made of 1603 existing protocols to facilitate this function. In this case some 1604 of the manageability considerations described in the previous 1605 sections may be devolved to those protocols. 1607 - Impact on LSRs and TE LSP signaling 1609 The primary example of a PCC identified in this architecture is an 1610 MPLS or GMPLS LSR. Consideration must therefore be given to the 1611 manageability of the LSRs and the additional manageability 1612 constraints applicable to the TE LSP signaling protocols. 1614 As well as allowing the PCC management described in the previous 1615 sections, an LSR must be configurable to determine whether it will 1616 use a remote PCE at all - the options being to use hop-by-hop 1617 routing or to supply the PCE function itself. It is likely to be 1618 important to be able to distinguish within an LSR whether the route 1619 used for a TE LSP was supplied in a signaling message from another 1620 LSR, by an operator, or by a PCE, and in the case where it was 1621 supplied in a signaling message whether it was enhanced or expanded 1622 by a PCE. 1624 - Reuse of existing policy models and mechanisms 1626 As policy support mechanisms can be quite extensive, it is 1627 worthwhile to explore to what extent this prior work can be 1628 leveraged and applied to PCE. This desire to leverage prior work 1629 should not be interpreted as a requirement to use any particular 1630 solution or protocol. 1632 9.6. Impact on Network Operation 1634 This architecture may have two impacts on the operation of a network. 1635 It increases TE LSP setup times while requests are sent to and 1636 processed by a remote PCE, and it may cause congestion within the 1637 network if a significant number of computation requests are issued in 1638 a small period of time. These issues are most severe in busy networks 1639 and after network failures, although the effect may be mitigated if 1640 the protection paths are precomputed or if the path computation load 1641 is distributed among a set of PCEs. 1643 Issues of potential congestion during recovery from failures may be 1644 mitigated through the use of pre-established protection schemes such 1645 as fast reroute. 1647 It is important that network congestion be managed proactively 1648 because it may be impossible to manage it reactively once the network 1649 is congested. It should be possible for an operator to rate limit the 1650 requests that a PCC sends to a PCE, and a PCE should be able to 1651 report impending congestion (according to a configured threshold) 1652 both to the operator and to its PCCs. 1654 9.7. Other Considerations 1656 No other management considerations have been identified. 1658 10. Security Considerations 1660 The impact of the use of a PCE-based architecture must be considered 1661 in the light of the impact that it has on the security of the 1662 existing routing and signaling protocols and techniques in use within 1663 the network. There is unlikely to be any impact on intra-domain 1664 security, but an increase in inter-domain information flows and the 1665 facilitation of inter-domain path establishment may increase the 1666 vulnerability to security attacks. 1668 Of particular relevance are the implications for confidentiality 1669 inherent in a PCE-based architecture for multi-domain networks. It is 1670 not necessarily the case that a multi-domain PCE solution will 1671 compromise security, but solutions MUST examine their effects in this 1672 area. 1674 Applicability statements for particular combinations of signaling, 1675 routing and path computation techniques are expected to contain 1676 detailed security sections. 1678 It should be observed that the use of a non-local PCE (that is, not 1679 co-resident with the PCC) does introduce additional security issues. 1680 Most notable amongst these are: 1682 - Interception of PCE requests or responses 1684 - Impersonation of PCE, or PCC 1686 - Falsification of TE information, policy information or PCE 1687 capabilities 1689 - Denial of service attacks on PCE or PCE communication mechanisms. 1691 It is expected that PCE solutions will address these issues in detail 1692 using authentication and security techniques. 1694 11. IANA Considerations 1696 This informational document makes no requests for IANA action. 1698 12. Acknowledgements 1700 The authors would like to extend their warmest thanks to (in 1701 alphabetical order) Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed 1702 Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella, 1703 Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou, 1704 Richard Rabbat, Payam Torab, Takao Shimizu, and Raymond Zhang for 1705 their review and suggestions. Lou Berger provided valuable and 1706 detailed contributions to the discussion of policy in this document. 1708 Thanks also to Pekka Savola, Russ Housley and Dave Kessens for review 1709 and constructive discussions during the final stages of publication. 1711 13. Intellectual Property Considerations 1713 The IETF takes no position regarding the validity or scope of any 1714 Intellectual Property Rights or other rights that might be claimed to 1715 pertain to the implementation or use of the technology described in 1716 this document or the extent to which any license under such rights 1717 might or might not be available; nor does it represent that it has 1718 made any independent effort to identify any such rights. Information 1719 on the procedures with respect to rights in RFC documents can be 1720 found in BCP 78 and BCP 79. 1722 Copies of IPR disclosures made to the IETF Secretariat and any 1723 assurances of licenses to be made available, or the result of an 1724 attempt made to obtain a general license or permission for the use of 1725 such proprietary rights by implementers or users of this 1726 specification can be obtained from the IETF on-line IPR repository at 1727 http://www.ietf.org/ipr. 1729 The IETF invites any interested party to bring to its attention any 1730 copyrights, patents or patent applications, or other proprietary 1731 rights that may cover technology that may be required to implement 1732 this standard. Please address the information to the IETF at 1733 ietf-ipr@ietf.org. 1735 14. Informational References 1737 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and 1738 J. McManus, "Requirements for Traffic Engineering over 1739 MPLS", RFC 2702, September 1999. 1741 [RFC2547] Rosen, E. and Rekhter, Y. "BGP/MPLS VPNs", RFC 2547, 1742 March 1999. 1744 [RFC3209] Awduche, D., et. all, "Extensions to RSVP for LSP 1745 Tunnels", RFC 3209, December 2001. 1747 [RFC3630] Katz et al., "Traffic Engineering (TE) Extensions to 1748 OSPF Version 2", RFC 3630, September 2003. 1750 [RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network 1751 Management Protocol (SNMP) Applications", STD 62, RFC 1752 3413, December 2002. 1754 [RFC3473] Berger, L., et. al., "Generalized Multi-Protocol Label 1755 Switching (GMPLS) Signaling - Resource ReserVation 1756 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1757 RFC 3473, January 2003. 1759 [RFC3748] Smit, H. and Li, T., "Intermediate System to 1760 Intermediate System (IS-IS) - Extensions for Traffic 1761 Engineering (TE)", RFC 3784, June 2004. 1763 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 1764 "Multiprotocol Label Switching (MPLS) Traffic 1765 Engineering (TE) Management Information Base (MIB)", 1766 RFC 3812, June 2004. 1768 [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements for 1769 Support of Inter-Area and Inter-AS MPLS Traffic 1770 Engineering", RFC 4105, June 2005. 1772 [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS Traffic 1773 Engineering requirements", RFC 4216, November 2005. 1775 [MLN] Shiomoto, K., et. al., "Requirements for GMPLS-based 1776 multi-region and multi-layer networks", 1777 draft-ietf-ccamp-gmpls-mln-reqs, work in progress. 1779 15. Contact Information 1781 Adrian Farrel 1782 Old Dog Consulting 1783 EMail: adrian@olddog.co.uk 1785 Jean-Philippe Vasseur 1786 Cisco Systems, Inc. 1787 300 Beaver Brook Road 1788 Boxborough , MA - 01719 1789 USA 1790 Email: jpv@cisco.com 1792 Jerry Ash 1794 AT&T 1795 Room MT D5-2A01 1796 200 Laurel Avenue 1797 Middletown, NJ 07748, USA 1798 Phone: (732)-420-4578 1799 Fax: (732)-368-8659 1800 Email: gash@att.com 1802 16. Full Copyright Statement 1804 Copyright (C) The Internet Society (2006). This document is subject 1805 to the rights, licenses and restrictions contained in BCP 78, and 1806 except as set forth therein, the authors retain all their rights. 1808 This document and the information contained herein are provided on an 1809 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1810 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1811 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1812 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1813 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1814 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.