idnits 2.17.1 draft-ietf-pce-policy-enabled-path-comp-04.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1592. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (October 31, 2008) is 5654 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-16 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Igor Bryskin (Adva Optical) 2 Category: Informational Dimitri Papadimitriou (Alcatel) 3 Expiration Date: April 31, 2009 Lou Berger (LabN Consulting) 4 Jerry Ash (AT&T) 6 October 31, 2008 8 Policy-Enabled Path Computation Framework 10 draft-ietf-pce-policy-enabled-path-comp-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on April 31, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 The Path Computation Element (PCE) Architecture introduces the 44 concept of policy in the context of path computation. This document 45 provides additional details on policy within the PCE Architecture and 46 also provides context for the support of PCE Policy. This document 47 introduces the use of the Policy Core Information Model (PCIM) as a 48 framework for supporting path computation policy. This document also 49 provides representative scenarios for the support of PCE Policy. 51 Table of Contents 53 1 Introduction .............................................. 3 54 1.1 Terminology ............................................... 4 55 2 Background ................................................ 4 56 2.1 Motivation ................................................ 5 57 2.2 Policy Attributes ......................................... 7 58 2.3 Representative Policy Scenarios ........................... 8 59 2.3.1 Scenario: Policy Configured Paths ......................... 8 60 2.3.2 Scenario: Provider Selection Policy ....................... 11 61 2.3.3 Scenario: Policy Based Constraints ........................ 12 62 2.3.4 Scenario: Advanced Load Balancing (ALB) Example .......... 15 63 3 Requirements .............................................. 16 64 4 Path Computation Policy Information Model (PCPIM) ......... 18 65 5 Policy-Enabled Path Computation Framework Components ...... 20 66 6 Policy Component Configurations ........................... 21 67 6.1 PCC-PCE Configurations .................................... 21 68 6.2 Policy Repositories ....................................... 23 69 6.3 Cooperating PCE Configurations ............................ 25 70 6.4 Policy Configuration Management ........................... 26 71 7 Inter-Component Communication ............................. 26 72 7.1 Policy Communication ..................................... 26 73 7.2 PCE Discovery Policy Considerations ....................... 28 74 8 Path Computation Sequence of Events ....................... 29 75 8.1 Policy-enabled PCC, Policy-enabled PCE .................... 29 76 8.2 Policy-ignorant PCC, Policy-enabled PCE ................... 30 77 9 Introduction of New Constraints ........................... 32 78 10 Security Considerations ................................... 32 79 11 Acknowledgments ........................................... 33 80 12 IANA Considerations ....................................... 33 81 13 References ................................................ 33 82 13.1 Normative References ...................................... 33 83 13.2 Informative References .................................... 34 84 14 Authors' Addresses ........................................ 35 85 15 Full Copyright Statement .................................. 36 86 16 Intellectual Property ..................................... 36 87 1. Introduction 89 The Path Computation Element (PCE) Architecture is introduced in 90 [RFC4655]. This document describes the impact of policy-based 91 decision making when incorporated into the PCE architecture and 92 provides additional details on, and context for applying policy 93 within the PCE Architecture. 95 Policy-based Management (PBM), see [RFC3198], is a network management 96 approach that enables a network to automatically perform actions in 97 response to network events or conditions based on pre-established 98 rules, also denoted as policies, from a network administrator. PBM 99 enables network administrators to operate in a high-level manner 100 through rule-based strategy (policies can be defined as a set of 101 rules and actions); the latter are translated automatically (i.e., 102 dynamically, without human interference) into individual device 103 configuration directives, aimed at controlling a network as a whole. 104 Two IETF Working Groups have considered policy networking in the 105 past: The Resource Allocation Protocol (RAP) working group and the 106 Policy Framework working group. 108 A framework for policy-based admission control [RFC2753] was defined 109 and a protocol for use between Policy Enforcement Points (PEP) and 110 Policy Decision Points (PDP) was specified: Common Open Policy 111 Service (COPS) [RFC2748]. This document uses the terms PEP and PDP to 112 refer to the functions defined in the COPS context. This document 113 makes no assumptions nor requires that the actual COPS protocol be 114 used. Any suitable policy exchange protocol (for example, SOAP 115 [W3CSOAP]) may be substituted. 117 The IETF has also produced a general framework for representing, 118 managing, sharing, and reusing policies in a vendor-independent, 119 interoperable, and scalable manner. It has also defined an extensible 120 information model for representing policies, called the Policy Core 121 Information Model (PCIM) [RFC3060]; and an extension to this model to 122 address the need for QoS management, called the QoS Policy 123 Information Model (QPIM) [RFC3644]. However, additional mechanisms 124 are needed in order to specify policies related to the path 125 computation logic as well as its control. 127 In Section 2, this document presents policy related background and 128 scenarios to provide a context for this work. Section 3 provides 129 requirements that must be addressed by mechanisms and protocols that 130 enable policy-based control over path computation requests and 131 decisions. Section 4 introduces PCIM as a core component in a 132 framework for providing policy-enabled path computation. Section 5 133 introduces a set of components that may be used to support policy- 134 enabled path computation. Sections 6, 7 and 8 provide details on 135 possible component configurations, communication and events. Section 136 10 discusses the ability to introduce new constraints with minimal 137 impact. It should be noted that this document, in Section 4, only 138 introduces PCIM, specific PCIM definitions to support path 139 computation will be discussed in a separate document. 141 1.1. Terminology 143 The reader is assumed to be familiar with the following terms: 144 BEEP: Blocks Extensible Exchange Protocol, see [RFC3080]. 145 CIM: Common Information Model, see [DMTF]. 146 COPS: Common Open Policy Service, see [RFC2748]. 147 CSPF: Constraint-based Shortest Path First, see [RFC3630]. 148 LSP: Label Switched Path, see [RFC3031]. 149 LSR: Label Switching Router, see [RFC3031]. 150 PBM: Policy-based Management, see [RFC3198]. 151 PC: Path Computation. 152 PCC: Path Computation Client, see [RFC4655]. 153 PCCIM: Path Computation Core Information Model. 154 PCE: Path Computation Element, see [RFC4655]. 155 PCEP: Path Computation Element Communication Protocol, 156 see [PCEP]. 157 PCIM: Policy Core Information Model, see [RFC3060]. 158 PDP: Policy Decision Points, see [RFC2753]. 159 PEP: Policy Enforcement Points, see [RFC2753]. 160 QPIM: QoS Policy Information Model, see [RFC3644]. 161 SLA: Service Level Agreement. 162 SOAP: Simple Object Access Protocol, see [W3CSOAP]. 163 TE: Traffic Engineering, see [RFC3209] and [RFC3473]. 164 TED: Traffic Engineering Database, see [RFC3209] and [RFC3473]. 165 TE LSP: Traffic Engineering MPLS Label Switched Path, see 166 [RFC3209] and [RFC3473]. 168 2. Background 170 This section provides some general background on the use of policies 171 within the PCE architecture. It presents the rationale behind the use 172 of policies in the TE path computation process, as well as 173 representative policies usage scenarios. This information is intended 174 to provide context for the presented PCE policy framework. This 175 section does not attempt to present an exhaustive list of rationales 176 or scenarios. 178 2.1. Motivation 180 The PCE architecture as introduced in [RFC4655] includes policy as an 181 integral part of the PCE architecture. This section presents some of 182 the rationale for this inclusion. 184 Network operators require a certain level of flexibility to shape the 185 TE path computation process, so that the process can be aligned with 186 their business and operational needs. Many aspects of the path 187 computation may be governed by policies. For example, a PCC may use 188 policies configured by the operator to decide which optimization 189 criteria, constraints, diversities and their relaxation strategies to 190 request while computing path(s) for a particular service. Depending 191 on SLAs, TE and cost/performance ratio goals, path computation 192 requests may be issued differently for different services. A given 193 Service A, for instance, may require two SRLG-disjoint paths for 194 building end-to-end recovery scheme, while for a Service B link- 195 disjoint paths may be sufficient. Service A may need paths with 196 minimal end-to-end delay, while Service B may be looking for shortest 197 (minimal-cost) paths. Different constraint relaxation strategies may 198 be applied while computing paths for Service A and for Service B, and 199 so forth. So based on distinct service requirements distinct or 200 similar policies may be adopted when issuing/handling path 201 computation requests. 203 Likewise, a PCE may apply policies to decide which algorithm(s) to 204 use while performing path computations requested from a particular 205 PCC or for a particular domain, see [RFC4927]; whether to seek the 206 cooperation of other PCEs to satisfy a particular request or to 207 handle a request on its own (possibly responding with non explicit 208 paths); or how the request should be modified before being sent to 209 other member(s) of a group of cooperating PCEs, etc. 211 Additional motivation for supporting policies within the PCE 212 architecture can be described as follows. Historically, a path 213 computation entity was an intrinsic part of an LSR's control plane 214 and always co-located with the LSR's signaling and routing 215 subsystems. This approach allowed for unlimited flexibility in 216 providing various path computation enhancements, such as: adding new 217 types of constraints, diversities and their relaxation strategies, 218 adopting new objective functions and optimization criteria, etc. All 219 that had to be done to support an enhancement was to upgrade the 220 control plane software of a particular LSR (and no other LSRs or any 221 other network elements). 223 With the introduction of the PCE architecture, the introduction of 224 new PCE capabilities becomes more complicated: it isn't enough for a 225 PCE to upgrade its own software. In order to take advantage of a 226 PCE's new capabilities, new advertising and signaling objects may 227 need to be standardized, all PCCs may need to be upgraded with new 228 software, and new interoperability problems may need to be resolved, 229 etc. 231 Within the context of the PCE architecture, it is therefore highly 232 desirable to find a way to introduce new path computation 233 capabilities without requiring modifying either the 234 discovery/communication protocols or the PCC software. One way to 235 achieve this objective is to consider path selection constraints, 236 their relaxations and objective functions, as path computation 237 request-specific policies. Furthermore, such policies may be 238 configured and managed by a network operator as any other policies 239 and may be interpreted in real time by PCCs and PCEs. 241 There are a number of advantages and useful by-products of such an 242 approach: 244 - New path computation capabilities may be introduced without 245 changing PCE-PCC communication and discovery protocols or PCC 246 software. Only the PCE module providing the path computation 247 capabilities (referred to in this document as a path 248 computation engine) needs to be updated. 250 - Existing constraints, objective functions and their relaxations 251 may be aggregated and otherwise associated, thus producing new, 252 more complex objective functions that do not require a change 253 of code even on the PCEs supporting the functions. 255 - Different elements such as conditions, actions, variables, 256 etc., may be re-used by multiple constraints, diversities, and 257 optimizations. 259 - PCCs and PCEs need to handle other (that is, not request- 260 specific) policies. Path computation-related policies of all 261 types can be placed within the same policy repositories, can be 262 managed by the same policy management tools, and can be 263 interpreted using the same mechanisms. Also policies need to be 264 supported by PCCs and PCEs independent of the peculiarities of a 265 specific PCC-PCE communication protocol, see [PCEP]. Thus, 266 introducing a new (request-specific) type of policies describing 267 constraints and other elements of a path computation request 268 will be a natural and relatively inexpensive addition to the 269 policy-enabled path computation architecture. 271 2.2. Policy Attributes 273 This section provides a summary listing of the policy attributes that 274 may be included in the policy exchanges described in the scenarios 275 that follow. This list is provided for guidance and is not intended 276 to be exclusive. Implementation of this framework might include 277 additional policy attributes not listed here. 279 Identities 281 - LSP head-end 282 - LSP destination 283 - PCC 284 - PCE 286 LSP identifiers 288 - LSP head-end 289 - LSP destination 290 - Tunnel identifier 291 - Extended tunnel identifier 292 - LSP ID 293 - Tunnel name 295 Requested LSP qualities 297 - bandwidth 298 - traffic parameters 299 - LSP attributes 300 - explicit path inclusions 301 - explicit path exclusions 302 - link protection level 303 - setup priority 304 - holding priority 305 - preexisting LSP route 307 Requested path computation behavior 309 - objective function 310 - other LSPs to be considered 312 Additional policy information 314 - Transparent policy information as received in RSVP-TE 316 2.3. Representative Policy Scenarios 318 This section provides example scenarios of how policies may be 319 applied using the PCE policy framework within the PCE architecture 320 context. Actual networks may deploy one of the scenarios discussed, 321 some combination of the presented scenarios, or other scenarios (not 322 discussed). This section should not be viewed as limiting other 323 applications of policies within the PCE architecture. 325 2.3.1. Scenario: Policy Configured Paths 327 A very simple usage scenario for PCE policy would be to use PCE to 328 centrally administer configured paths. Configured paths are composed 329 of strict and loose hops in the form of Explicit Route Objects 330 (EROs), see [RFC3209], and are used by one or more LSPs. Typically, 331 such paths are configured at the LSP ingress. In the context of 332 policy-enabled path computation, an alternate approach is possible. 334 In particular, service-specific policies can be installed that will 335 provide configured path(s) for a specific service request. The 336 request may be identified based on service parameters such as end- 337 points, requested QoS, or even a token that identifies the initiator 338 of a service request. The configured path(s) would then be used as 339 input to the path computation process, which would return explicit 340 routes by expanding of all specified loose hops. 342 Example of policy: 343 if(service_destination matches 10.132.12.0/24) 344 use path: 10.125.13.1=>10.125.15.1=>10.132.12.1 345 else 346 compute path dynamically 347 ---------------------- 348 | ----- | 349 | | TED |<-+------------> 350 | ----- | TED synchronization 351 | | | mechanism (e.g., routing protocol) 352 | | | 353 | v | 354 | ------ ----- | Inter-PCE Request/Response 355 | |Policy|<-->| PCE |<.+...........> (when present) 356 | ------ ----- | 357 ---------------------- 358 ^ 359 | Request/ 360 | Response 361 v 362 Service ------------- Signaling 363 Request |[PCC][Policy]| Protocol 364 <------>| Node |<-------> 365 or Signaling ------------- 366 Protocol 368 Figure 1: Policy Enabled PCC and PCE 370 Path computation policies may be applied at either a PCC or a PCE, 371 see Figure 1. In the PCC case, the configured path would be processed 372 at the PCC and then passed to the PCE along with the PCE request, 373 probably in the form of (inclusion) constraints. When applied at the 374 PCE, the configured path would be used locally. Both cases require 375 some method to configure and manage policies. In the PCC case, the 376 real benefit would come when there is an automated policy 377 distribution mechanism. 379 ------------------ ------------------- 380 | | | | 381 | PCE | | PCE | 382 | | | | 383 | ------ ----- | | ----- ------ | 384 | |Policy| | TED | | | | TED | |Policy| | 385 | ------ ----- | | ----- ------ | 386 ------------------ ------------------- 387 ^ ^ 388 | Request/ | Request/ 389 | Response | Response 390 v v 391 Service -------- Signaling ------------ Signaling ------------ 392 Request|Head-End| Protocol |Intermediate| Protocol |Intermediate| 393 ---->| Node |<--------->| Node |<--------->| Node | 394 -------- ------------ ------------ 396 Figure 2. Multiple PCE Path Computation 398 ------------------ ------------------ 399 | | Inter-PCE Request/Response | | 400 | PCE |<-------------------------->| PCE | 401 | | | | 402 | ------ ----- | | ------ ----- | 403 | |Policy| | TED | | | |Policy| | TED | | 404 | ------ ----- | | ------ ----- | 405 ------------------ ------------------ 406 ^ 407 | Request/ 408 | Response 409 v 410 Service ---------- Signaling ---------- Signaling ---------- 411 Request| Head-End | Protocol | Adjacent | Protocol | Adjacent | 412 ---->| Node |<---------->| Node |<---------->| Node | 413 ---------- ---------- ---------- 415 Figure 3. Multiple PCE Path Computation with Inter-PCE Communication 417 Policy-configured paths may also be used in environments with 418 multiple (more than one) cooperating PCEs (see Figures 2 and 3). For 419 example, consider the case when there is limited TE visibility and 420 independent PCEs are used to determine path(s) within each area of 421 the TE visibility. In such a case, it may not be possible (or 422 desirable) to configure entire explicit path(s) on a single PCE. 423 However, it is possible to configure explicit path(s) for each area 424 of the TE visibility and each responsible PCE. One by one, the PCEs 425 would then map an incoming signaling request to appropriate 426 configured path(s). Note that to make such a scenario work it would 427 likely be necessary to start and finish the configured paths on TE 428 domain boundary nodes. Clearly, consistent PCE Policy Repositories 429 are also critical in this example. 431 2.3.2. Scenario: Provider Selection Policy 433 A potentially more interesting scenario is applying PC policies in 434 multi-provider topologies. There are numerous interesting policy 435 applications in such topologies. A rudimentary example is simple 436 access control, that is, deciding which PCCs are permitted to request 437 inter-domain path computation. 439 A more complicated example is applying policy to determine which 440 domain or network provider will be used to support a particular PCE 441 request. Consider the topology presented in Figure 4. In this example 442 there are multiple transit domains available to provide a path from a 443 source domain to a destination domain. Furthermore, each transit 444 domain may have one or more options for reaching a particular domain. 445 Each domain will need to select which of the multiple available paths 446 will be used to satisfy a particular PCE request. 448 In today's typical path computation process, TE reachability, 449 availability and metric are the basic criteria for path selection. 450 However, policies can provide an important added consideration in the 451 decision process. For example, transit domain A may be more expensive 452 and provide lower delay or loss than transit domain B. Likewise, a 453 transit domain may wish to treat PCE requests from its own customers 454 differently than requests from other providers. In both cases, 455 computation based on traffic engineering databases will result in 456 multiple transit domain that provide reachability, and policies can 457 be used to govern which PCE requests get better service. 459 +-------+ 460 +----------+Transit+----------+ 461 +---+---+ | Domain| +---+---+ 462 |Transit| | C | |Transit| 463 +--------+ Domain| +---+---+ | Domain+--------+ 464 | | A +--+ | +--+ F | | 465 +--+---+ +---+---+ | | | +---+---+ +--+---+ 466 |Source| | | +---+---+ | | |Target| 467 |Domain| | +---+Transit+---+ | |Domain| 468 +--+---+ | +---+ Domain|---+ | +--+---+ 469 | +---+---+ | | D | | +---+---+ | 470 | |Transit| | +---+---+ | |Transit| | 471 +--------+ Domain+--+ | +--+ Domain+--------+ 472 | B | | | G | 473 +---+---+ +---+---+ +---+---+ 474 | |Transit| | 475 +----------+ Domain+----------+ 476 | E | 477 +-------+ 479 Figure 4: Multi-Domain Network with Multiple Transit Options 481 There are multiple options for differentiating which PCE requests use 482 a particular transit domain and get a particular (better or worse) 483 level of service. For example, a PCE in the source domain may use 484 user and request-specific policies to determine the level of service 485 to provide. A PCE in the source domain may also use domain-specific 486 policies to choose which transit domains are acceptable. A PCE in a 487 transit domain may use request-specific policies to determine if a 488 request is from a direct customer or another provider, and then use 489 domain-specific policies to identify how the request should be 490 processed. 492 Example of policy: 493 if(path computation request issued by a PCC within Source Domain) 494 route the path through Transit Domain A 495 else 496 route the path through Transit Domain B 498 2.3.3. Scenario: Policy Based Constraints 500 Another usage scenario is the use of policy to provide constraints in 501 a PCE request. Consider an LSR with a policy enabled PCC, as shown in 502 Figure 1, which receives a service request via signaling, including 503 over a NNI or UNI reference point, or receives a configuration 504 request over a management interface to establish a service. In either 505 case the path(s) needed to support the service are not explicitly 506 specified in the message/request, and hence path computation is 507 needed. 509 In this case, the PCC may apply user or service-specific policies to 510 decide how the path selection process should be constrained, that is, 511 which constraints, diversities, optimization criterion and constraint 512 relaxation strategies should be applied in order for the service 513 LSP(s) to have a likelihood to be successfully established and 514 provide necessary QoS and resilience against network failures. When 515 deciding on the set of constraints the PCC uses as an input all 516 information it knows about the user and service, such as the contents 517 of the received message, port ID over which message was received, 518 associated VPN ID, signaling/reference point type, request time, etc. 519 Once the constraints and other parameters of the required path 520 computation are determined, the PCC generates a path computation 521 request which includes the request-specific policies that describe 522 the determined set of constraints, optimizations, and other 523 parameters that indicate how the request is to be considered in the 524 path computation process. 526 Example of policy: 527 if(LSP belongs to a WDM layer network) 528 Compute the path with wavelength continuity constraint with the 529 maximum OSNR at the path end optimization 530 else if(LSP belongs to a connection oriented Ethernet layer network) 531 Compute the path with minimum end-to-end delay 532 else 533 Compute the shortest path 535 The PCC may also apply server-specific policies in order to select 536 which PCE to use from the set of known (i.e., discovered or 537 configured) PCEs. The PCC may also use server-specific policies to 538 form the request to match the PCE's capabilities so that the request 539 will not be rejected and has a higher likelihood of being satisfied 540 in an efficient way. An example of a request modification as the 541 result of a server-specific policy is removing a constraint not 542 supported by the PCE. Once the policy processing is completed at the 543 PCC, and the path computation request resulting from the original 544 service request is updated by the policy processing, the request is 545 sent to the PCE. 547 Example of policy: 548 if(LSP belongs to a WDM layer network) 549 Identify a PCE supporting wavelength continuity and optical 550 impairment constraints; send a request to such PCE, requesting 551 path computation with the following constraints: 552 a) wavelength continuity; 553 b) maximum PMD at the path end. 554 if(the path computation fails) 555 remove the maximum PMD constraint and try the computation again 557 The PCE that receives the request validates and otherwise processes 558 the request, applying the policies found in the request as well as 559 any policies that are available at the PCE, e.g., client and domain- 560 specific polices. As a result of the policy processing, the PCE may 561 decide to reject the request. 563 Example of policy: 564 Authenticate the PCC requesting the path computation using the 565 PCC ID found in the path computation request; 566 Reject the request if the authentication fails 568 It The PCE also may decide to respond with one or several pre- 569 computed paths if user or client specific polices instruct the PCE to 570 do so. If the PCE decides to satisfy the request by performing a path 571 computation, it determines if it needs the cooperation of other PCEs 572 and defines parameters for path computations to be performed locally 573 and remotely. After that, the PCE instructs a co-located path 574 computation engine to perform the local path computation(s) and, if 575 necessary, sends path computation requests to one or more other PCEs. 576 It then waits for the responses from the local path computation 577 engine and, when used, the remote PCE. It then combines the resulting 578 paths and sends the result back to the requesting PCC. The response 579 may indicate policies describing the resulting paths, their 580 characteristics (summary cost, expected end-to-end delay, etc.). as 581 well as additional information related to the request, e.g., which 582 constraints were honored, which were dismissed, and which were 583 relaxed and in what way. 585 Example of policy: 586 if(the path destination belongs to domain A) 587 Instruct local path computation engine to perform the path 588 computation; 589 else 590 Identify the PCE supporting the destination domain; 591 Send path computation request to such PCE; 592 Wait for and process the response 593 Send the path computation response to the requesting PCC 595 The PCC processes the response and instructs the LSR to encode the 596 received path(s) into the outgoing signaling message(s). 598 2.3.4. Scenario: Advanced Load Balancing (ALB) Example 600 Figure 5 illustrates a problem that stems from the coupling between 601 BGP and IGP in the BGP decision process. If a significant portion of 602 the traffic destined to the data center (or customer network) enters 603 a PCE-enabled network from AS 1 and all IGP links weights are the 604 same, then both PE3 and PE4 will prefer to reach the data center 605 using the routes advertised by PE2. PE5 will use the router-IDs of 606 PE1 and PE2 to break the tie and might therefore also select to use 607 the path through PE2 (if the router ID of PE2 is smaller than that of 608 PE1). Either way the net result is that the link between PE2 and CE 609 will carry most of the traffic while the link between PE1 and CE will 610 be mostly idle. 612 .............................. 613 . AS 1 . 614 . . 615 . +---+ +---+ +----+ . 616 ....|PE8|...|PE9|...|PE10|.... 617 +---+ +---+ +----+ 618 | | | 619 +---+ +---+ +---+ 620 ......|PE3|...|PE4|...|PE5|...... 621 . +---+ +---+ +---+ . 622 .............. +---+ \ / ___/ +---+ 623 . . _|PE2|_____+--+__/ / _|PE6| 624 . +--+ / +---+ |P1|_____+--+_______/ +---+ 625 . Customer |CE|= . +--+ |P2| . 626 . Network +--+ \_+---+ \ +--+ . 627 . . |PE1|________+--+___/| x===x . PCE used 628 .............. +---+ |P3| | |PCE| . by all 629 . +--+ | x===x . AS0 nodes 630 . AS 0 +---+ . 631 ..................|PE7|.......... 632 +---+ 634 Figure 5: Advanced Load Balancing 636 This is a common problem for providers and customers alike. Analysis 637 of Netflow records, see [IRSCP], for a large ISP network on a typical 638 day has shown that for 71.8% of multi-homed customers there is a 639 complete imbalance, where the most loaded link carries all the 640 traffic and the least loaded link carries none. 642 PCE policies can address this problem by basing the routing decision 643 at the ingress routers on the offered load towards the multi-homed 644 customer. For example, in Figure 5 PCE policies could be configured 645 such that traffic load is monitored (e.g., based on Netflow data) at 646 ingress routers PE3 to PE7 towards the data center prefixes served by 647 egress routers PE1 and PE2. Using this offered load information, the 648 path computations returned by PCE, based on the enabled PCE policies, 649 can direct traffic to the appropriate egress router, on a per-ingress 650 router basis. For example, the PCE path computation might direct 651 traffic from both PE4 and PE5 to egress PE1, thus overriding the 652 default IGP based selection. Alternatively, traffic from each 653 ingress router to each egress link could be split 50-50. 655 This scenario is a good example of how a policy governed PCE can 656 account for some information that was not or cannot be advertised as 657 TE link/node attributes, and, therefore, cannot be subject for 658 explicit path computation constraints. More generally, such 659 information can be pretty much anything. For example, traffic demand 660 forecasts, flow monitoring feedback, any administrative policies, 661 etc. Further examples are described in [IRSCP] of how PCE policies 662 might address certain network routing problems, such as selective 663 DDoS blackholing, planned maintenance, and VPN gateway selection. 665 Example of policy: 666 for(all traffic flows destined to Customer Network) 667 if(flow ingresses on PE3, PE4 or PE5) 668 route the flow over PE1 669 else 670 route the flow over PE2 672 3. Requirements 674 The following requirements must be addressed by mechanisms and 675 protocols that enable policy-based control over path computation 676 requests and decisions: 678 - (G)MPLS path computation-specific 679 The mechanisms must meet the policy-based control requirements 680 specific to the problem of path computation using RSVP-TE as the 681 signaling protocol on MPLS and GMPLS LSRs. 683 - Support for non-(G)MPLS PCCs 684 The mechanisms must be sufficiently generic to support 685 non-(G)MPLS (LSR) clients such as an NMS, or network planner, 686 etc. 688 - Support for many policies 689 The mechanisms must include support for many policies and policy 690 configurations. In general, the determination and configuration 691 of viable policies are the responsibility of the service 692 provider. 694 - Provision for monitoring and accounting information 695 The mechanisms must include support for monitoring policy state, 696 and provide access information. In particular, mechanisms must 697 provide usage and access information that may be used for 698 accounting purposes. 700 - Fault tolerance and recovery 701 The mechanisms must include provisions for fault tolerance and 702 recovery from failure cases such as failure of PCC/PCE PDPs, 703 disruption in communication that separate a PCC/PCE PDP from its 704 associated PCC/PCE PEPs. 706 - Support for policy-ignorant nodes 707 The mechanisms should not be mandatory for every node in a 708 network. Policy based path computation control may be enforced at 709 a subset of nodes, for example, on boundary nodes within an 710 administrative domain. These policy-capable nodes will function 711 as trusted nodes from the point of view of the policy-ignorant 712 nodes in that administrative domain. Alternatively, policy may be 713 applied solely on PCEs with all PCCs being policy-ignorant nodes. 715 - Scalability 716 One of the important requirements for the mechanisms is 717 scalability. The mechanisms must scale at least to the same 718 extent that RSVP-TE signaling scales in terms of accommodating 719 multiple LSPs and network nodes in the path of an LSP. There are 720 several sensitive areas in terms of scalability of policy based 721 path computation control. First, not every policy aware node in 722 an infrastructure should be expected to contact a remote 723 PDP. This would cause potentially long delays in verifying 724 requests. Additionally, the policy control architecture must 725 scale at least as well as RSVP-TE protocol based on factors such 726 as the size of RSVP-TE messages, the time required for the 727 network to service an RSVP-TE request, local processing time 728 required per node, and local memory consumed per node. These 729 scaling considerations are of particular importance during 730 re-routing of a set of LSPs. 732 - Security and denial of service considerations 733 The policy control architecture, protocols and mechanisms must be 734 secure as far as the following aspects are concerned: 736 o First, the mechanisms proposed must minimize theft and denial 737 of service threats. 739 o Second, it must be ensured that the entities (such as PEPs 740 and PDPs) involved in policy control can verify each other's 741 identity and establish necessary trust before communicating. 743 - Inter-AS and inter-area requirements 744 There are several inter-AS policy related requirements discussed 745 in [RFC4216] and [INTERAS-PCEP], and inter-area policy related 746 requirements discussed in [RFC4927]. These requirements 747 must be addressed by policy-enabled PCE mechanisms and protocols. 749 It should be noted that this document only outlines the communication 750 elements and mechanisms needed to allow a wide variety of possible 751 policies to be applied for path computation control. It does not 752 include any discussion of any specific policy behavior. Nor does it 753 define or require use of specific policies. 755 4. Path Computation Policy Information Model (PCPIM) 757 The Policy Core Information Model (PCIM) introduced in [RFC3060] and 758 expanded in [RFC3460] presents the object-oriented information model 759 for representing general policy information. 761 This model defines two hierarchies of object classes: 763 - Structural classes representing policy information and control of 764 policies. 766 - Association classes that indicate how instances of the structural 767 classes are related to each other. 769 These classes can be mapped to various concrete implementations, for 770 example, to a directory that uses LDAPv3 as its access protocol. 772 Figure 6 shows an abstract from the class inheritance hierarchy for 773 PCIM. 775 ManagedElement (abstract) 776 | 777 +--Policy (abstract) 778 | | 779 | +---PolicySet (abstract) 780 | | | 781 | | +---PolicyGroup 782 | | | 783 | | +---PolicyRule 784 | | 785 | +---PolicyCondition (abstract) 786 | | | 787 | | +---PolicyTimePeriodCondition 788 | | | 789 | | +---VendorPolicyCondition 790 | | | 791 | | +---SimplePolicyCondition 792 | | | 793 | | +---CompoundPolicyCondition 794 | | | 795 | | +---CompoundFilterCondition 796 | | 797 | +---PolicyAction (abstract) 798 | | | 799 | | +---VendorPolicyAction 800 | | | 801 | | +---SimplePolicyAction 802 | | | 803 | | +---CompoundPolicyAction 804 | | 805 | +---PolicyVariable (abstract) 806 | | | 807 | | +---PolicyExplicitVariable 808 | | | 809 | | +---PolicyImplicitVariable 810 | | | 811 | | +---(subtree of more specific classes) 812 | | 813 | +---PolicyValue (abstract) 814 | | 815 | +---(subtree of more specific classes) 817 Figure 6: PCIM Class Inheritance 819 The policy classes and associations defined in PCIM are sufficiently 820 generic to allow them to represent policies related to anything. 822 Policy models for application-specific areas such as the Path 823 Computation Service may extend the PCIM in several ways. The 824 preferred way is to use the PolicyGroup, PolicyRule, and 825 PolicyTimePeriodCondition classes directly as a foundation for 826 representing and communicating policy information. Then, specific 827 subclasses derived from PolicyCondition and PolicyAction can capture 828 application-specific definitions of conditions and actions of 829 policies. 831 Policy Quality of Service Information Model [RFC3644] further extends 832 the PCIM to represent QoS policy information for large-scale policy 833 domains. New classes introduced in this document describing QoS and 834 RSVP related variables, conditions and actions can be used as a 835 foundation for the PCPIM. 837 Detailed description of the PCPIM will be provided in a separate 838 documents. 840 5. Policy-Enabled Path Computation Framework Components 842 The following components are defined as part of the framework to 843 support policy-enabled path computation: 845 - PCE Policy Repository 846 A database from which PCE policies are available in the form of 847 instances of PCPIM classes. PCE Policies are configured and 848 managed by PCE Policy Management Tools; 850 - PCE Policy Decision Point (PCE-PDP) 851 A logical entity capable of retrieving relevant path computation 852 policies from one or more Policy Repositories and delivering the 853 information to associated PCE-PEP(s); 855 - PCE Policy Enforcement Point (PCE-PEP) 856 A logical entity capable of issuing device specific Path 857 Computation Engine configuration requests for the purpose of 858 enforcing the policies; 860 - PCC Policy Decision Point (PCC-PDP) 861 A logical entity capable of retrieving relevant path computation 862 policies from one or more Policy Repositories and delivering the 863 information to associated PCC-PEP(s); 865 - PCC Policy Enforcement Point (PCC-PEP) 866 A logical entity capable of issuing device specific Path 867 Computation Service User configuration requests for the purpose 868 of enforcing the policies. 870 From the policy perspective a PCC is logically decomposed into two 871 parts: PCC-PDP and PCC-PEP. When present, a PCC-PEP is co-located 872 with a Path Computation Service User entity that requires remote path 873 computation (for example, the GMPLS control plane of an LSR). The 874 PCC-PEP and PCC-PDP may be physically co-located (as per [RFC2748]) 875 or separated. In the later case they talk to each other via such 876 protocols as SOAP [W3CSOAP] or BEEP [RFC3080]. 878 Likewise, a PCE is logically decomposed into two parts: PCE-PEP and 879 PCE-PDP. When present, PCE-PEP is co-located with a Path Computation 880 Engine entity that actually provides the Path Computation Service 881 (that is, runs path computation algorithms). PCE-PEP and PCE-PDP may 882 be physically co-located or separated. In the later case they 883 communicate using such protocols as SOAP and/or BEEP. 885 PCC-PDP/PCE-PDP may be co-located with, or separated from, an 886 associated PCE Policy Repository. In the latter case, the PDPs use 887 some access protocol (for example, LDAPv3 or SNMP). The task of PDPs 888 is to retrieve policies from the repository(ies) and convey them to 889 respective PEPs either in unsolicited way or upon the PEPs requests. 891 A PCC-PEP may receive policy information not only from PCC-PDPs(s) 892 but also from PCE-PEP(s) via PCC-PCE communication and/or PCE 893 discovery protocols. Likewise, a PCE-PEP may receive policy 894 information not only from PCE-PDPs(s) but also from PCC-PEP(s), via 895 the PCC-PCE communication protocol [PCEP]. 897 Any given policy can be interpreted (that is, translated into a 898 sequence of concrete device specific configuration requests) either 899 on a PDP or on the associated PEP or partly on the PDP and partly on 900 the PEP. 902 Generally speaking, the task of the PCC-PEP is to select the PCE and 903 build path computation requests applying service-specific policies 904 provided by the PCC-PDP. The task of the PCE-PEP is to control path 905 computations by applying request-specific policies found in the 906 requests as well as client-specific and domain-specific policies 907 supplied by the PCE-PDP. 909 6. Policy Component Configurations 911 6.1. PCC-PCE Configurations 913 The PCE policy architecture supports policy being applied at a PCC 914 and at a PCE. While the architecture supports policy being applied at 915 both, there is no requirement for policy to always be applied at 916 both, or even at either. The use of policy in a network, on PCCs and 917 on PCEs, is a specific network design choice. Some networks may 918 choose to apply policy only at PCCs (Figure 7), some at PCEs (Figure 919 8), and others at both PCCs and PCEs (Figure 9). Regardless of where 920 policy is applied it must be applied in a consistent fashion in order 921 to achieve the intended results. 923 ......................... 924 . . 925 . PCE Policy Management . 926 . . 927 ......................... 928 . 929 . 930 --------- Policy ----------------------- 931 | PCC-PDP |<--------- | PCE Policy Repository | 932 --------- ----------------------- 933 ^ 934 | e.g., SOAP 935 v 936 --------- PCEP --------- 937 | PCC-PEP |<------------------------------------------->| PCE | 938 --------- PCC-PCE Communication Protocol --------- 940 Figure 7: Policies Applied On PCC Only 942 Along with supporting flexibility in where policy may be applied, the 943 PCE architecture is also flexible in terms of where specific types of 944 policies may be applied. Also the PCE architecture allows for the 945 application of only a subset of policy types. [RFC4655] defines 946 several PC policy types. Each of these may be applied at either a PCC 947 or a PCE or both. Clearly when policy is only applied at PCCs or at 948 PCEs, all PCE policy types used in the network must be applied at 949 those locations. 951 ......................... 952 . . 953 . PCE Policy Management . 954 . . 955 ......................... 956 . 957 . 958 ----------------------- Policy --------- 959 | PCE Policy Repository | -------->| PCE-PDP | 960 ----------------------- --------- 961 ^ 962 e.g., SOAP | 963 v 964 --------- PCEP --------- 965 | PCC |<------------------------------------------->| PCE-PEP | 966 --------- PCC-PCE Communication Protocol --------- 968 Figure 8: Policies Applied On Only 970 In the case where policy is only applied at a PCE, it is expected 971 that the PCC will pass to the PCE all information about the service 972 that it can gather in the path computation request (most likely in 973 the form of PCPIM policy variables). The PCE is expected to 974 understand this information and apply appropriate policies while 975 defining the actual parameters of the path computation to be 976 performed. Note that in this scenario the PCC cannot apply server- 977 specific or any other policies, and PCE selection is static. 979 When applying policy at both PCC and PCE, it is necessary to select 980 which types of policies are applied at each. In such configurations, 981 it is likely that the application of policy types will be distributed 982 across PCC and PCE rather than applying all of them at both. For 983 example, user-specific and server-specific policies may be applied at 984 a PCC, request and client specific policies may be applied at a PCE, 985 while domain-specific policies may be applied at both the PCC and 986 PCE. 988 In the case when policy is only applied at a PCC, the PCC must apply 989 all the types of required policies, for example user, service, server 990 and domain-specific policies. The PCC uses the policies to construct 991 a path computation request that appropriately represents the applied 992 policies. The request will necessarily be limited to the set of 993 "basic" (that is, non-policy capable) constraints explicitly defined 994 by the PCC-PCE communication protocol. 996 6.2. Policy Repositories 998 Within the policy-enabled path computation framework policy 999 repositories may be used in a single or multiple PCE policy 1000 repository configuration: 1002 o) Single PCE Policy Repository 1004 In this configuration there is a single PCE Policy Repository shared 1005 between PCCs and PCEs. 1007 ......................... 1008 . . 1009 . PCE Policy Management . 1010 . . 1011 ......................... 1012 . 1013 . 1014 --------- Policy a ----------------------- Policy b --------- 1015 | PCC-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP | 1016 --------- ----------------------- --------- 1017 ^ ^ 1018 | e.g., SOAP e.g., SOAP | 1019 v v 1020 --------- PCEP --------- 1021 | PCC-PEP |<------------------------------------------->| PCE-PEP | 1022 --------- PCC-PCE Communication Protocol --------- 1024 Figure 9: Single PCC/PCE Policy Repository 1026 o) Multiple PCE Policy Repositories 1028 The repositories in this case may be fully or partially synchronized 1029 by some discovery/ synchronization management protocol or may be 1030 completely independent. Note that the situation when PCE Policy 1031 Repository A exactly matches PC Policy Repository B, results in the 1032 single PCE Policy Repository configuration case. 1034 -------------- -------------- 1035 | PCE Policy | | PCE Policy | 1036 ---| Repository A | | Repository B |--- 1037 | -------------- -------------- | 1038 | | 1039 | Policy a Policy b | 1040 | | 1041 v v 1042 --------- --------- 1043 | PCC-PDP | | PCE-PDP | 1044 --------- --------- 1045 ^ ^ 1046 | e.g., SOAP e.g., SOAP | 1047 v v 1048 --------- PCEP --------- 1049 | PCC-PEP |<------------------------------------------->| PCE-PEP | 1050 --------- PCC-PCE Communication Protocol --------- 1052 Figure 10: Multiple PCE/PCC Policy Repositories 1054 6.3. Cooperating PCE Configurations 1056 The previous section shows the relationship between PCCs and PCEs. A 1057 parallel relationship exists between cooperating PCEs, and, in fact, 1058 this relationship can be viewed as the same as the relationship 1059 between PCCs and PCEs. The one notable difference is that there will 1060 be cases where having a shared PCE Policy Repository will not be 1061 desirable, for example, when the PCEs are managed by different 1062 entities. Note that in this case it still remains necessary for the 1063 policies to be consistent across the domains in order to identify 1064 usable paths. The other notable difference is that a PCE, while 1065 processing a path computation request, may need to apply requester- 1066 specific (that is, client-specific) policies in order to modify the 1067 request before sending it to other cooperating PCE(s). This 1068 relationship is particularly important as the PCE Architecture allows 1069 for configuration where all PCCs are not policy-enabled. 1071 The following are example configurations. These examples do not 1072 represent an exhaustive list and other configurations are expected. 1074 o) Single Policy Repository 1076 In this configuration there is a single PCE Policy repository shared 1077 between PCEs. This configuration is likely to be useful within a 1078 single administrative domain where multiple PCEs are provided for 1079 redundancy or load distribution purposes. 1081 ......................... 1082 . . 1083 . PCE Policy Management . 1084 . . 1085 ......................... 1086 . 1087 . 1088 --------- Policy a ----------------------- Policy b --------- 1089 | PCE-PDP |<--------- | PCE Policy Repository | -------->| PCE-PDP | 1090 --------- ----------------------- --------- 1091 ^ ^ 1092 | e.g., SOAP e.g., SOAP | 1093 v v 1094 --------- --------- 1095 | PCE-PEP |<------------------------------------------->| PCE-PEP | 1096 --------- PCE-PCE Communication Protocol --------- 1098 Figure 11: Single PCC Policy Repository 1100 o) Multiple Policy Repositories 1101 The repositories in this case may be fully or partially synchronized 1102 by some discovery/synchronization management protocol(s) or may be 1103 completely independent. In the multi-domain case it is expected that 1104 the repositories will be distinct, providing, however. consistent 1105 policies. 1107 -------------- -------------- 1108 | PCE Policy | | PCE Policy | 1109 ---| Repository A | | Repository B |--- 1110 | -------------- -------------- | 1111 | | 1112 | Policy a Policy b | 1113 | | 1114 v v 1115 --------- --------- 1116 | PCE-PDP | | PCE-PDP | 1117 --------- --------- 1118 ^ ^ 1119 | e.g., SOAP e.g., SOAP | 1120 v v 1121 --------- PCEP --------- 1122 | PCE-PEP |<------------------------------------------->| PCE-PEP | 1123 --------- PCC-PCE Communication Protocol --------- 1125 Figure 12: Multiple PCC Policy Repositories 1127 6.4. Policy Configuration Management 1129 The management of path computation policy information used by PCCs 1130 and PCEs is largely out of scope of the described framework. The 1131 framework assumes that such information is installed, removed and 1132 otherwise managed using typical policy management techniques. Policy 1133 Repositories may be populated and managed via static configuration, 1134 standard and proprietary policy management tools, or even dynamically 1135 via policy management/discovery protocols and applications. 1137 7. Inter-Component Communication 1139 7.1. Policy Communication 1141 Flexibility in the application of policy types is imperative from the 1142 architecture perspective. However, this commodity implies added 1143 complexity on the part of the PCE related communication protocols. 1145 One added complexity is that PCE communication protocols must carry 1146 certain information to support various policy types that may be 1147 applied. For example, in the case where policy is only applied at a 1148 PCE, a PCC-PCE request must carry sufficient information for the PCE 1149 to apply service or user-specific policies. This does imply that a 1150 PCC must have sufficient understanding of what policies can be 1151 applied at the PCE. Such information may be obtained via local 1152 configuration, static coding or even via a PCE discovery mechanism. 1153 The PCC must also have sufficient understanding to properly encode 1154 the required information for each policy type. 1156 Another added complexity is that PCE communication protocols must 1157 also be able to carry information that may result from a policy 1158 decision. For example, user or service-specific policy applied at a 1159 PCC may result in policy related information that must be carried 1160 along with the request for use by a PCE. This complexity is 1161 particularly important as it may be used to introduce new path 1162 computation parameters (e.g., constraints, objection functions, etc.) 1163 without modification of the core PCC and PCE. This communication will 1164 likely simply require the PCE communication protocols to support 1165 opaque policy related information elements. 1167 A final added complexity is that PCE communication protocols must 1168 also be able to support updated or unsolicited responses from a PCE. 1169 For example, changes in PCE policy may force a change to a previously 1170 provided path. Such updated or unsolicited responses may contain 1171 information that the PCC must act on, and may contain policy 1172 information that must be provided to a PCC. 1174 PCC-PEP and PCE-PEP or a pair of PCE-PEPs communicate via a request- 1175 response type PCC-PCE Communication Protocol, i.e., [PCEP]. This 1176 document makes no assumptions as to what exact protocol is used to 1177 support this communication. This document does assume that the 1178 semantics of a path computation request are sufficiently abstract and 1179 general, and support both PCE-PCC and PCE-PCE communication. 1181 From a policy perspective, a path computation request should include 1182 at a minimum: 1183 o One or more source addresses; 1184 o One or more destination addresses; 1185 o Computation type (P2P, P2MP, MP2P, etc.); 1186 o Number of required paths; 1187 o Zero or more policy descriptors in the following format: 1188 , 1189 , , ,..., 1190 , , ,..., 1191 ... 1192 , , ,..., 1194 A successful path computation response, at minimum, should include 1195 the list of computed paths and may include policies (in the form of 1196 policy descriptors as in path computation request, see above) for use 1197 in evaluating and otherwise applying the computed paths. 1199 PCC-PCE Communication Protocol provides transport for policy 1200 information and should not understand nor make any assumptions about 1201 the semantics of policies specified in path computation requests and 1202 responses. 1204 Note: This document explicitly allows for (but does not require) the 1205 PCC to decide that all necessary constraints, objective functions, 1206 etc. pertinent to the computation of paths for the service in 1207 question are to be determined by the PCE performing the computation. 1208 In this case the PCC will use a set of policies (more precisely, 1209 PCPIM policy variables) describing the service-specific information. 1210 These policies may be placed within the path computation request and 1211 delivered to the PCE via a PCC-PCE communication protocol such as 1212 [PCEP]. The PCE (more precisely, PCE-PEP) is expected to understand 1213 this information and use it to determine the constraints and 1214 optimization functions applying local policies (that is, policies 1215 locally configured or provided by the associated PCE-PDP(s)). 1217 7.2. PCE Discovery Policy Considerations 1219 Dynamic PCE discovery allows for PCCs and PCEs to automatically 1220 discover a set of PCEs (including information required for the PCE 1221 selection). It also allows for PCCs and PCEs to dynamically detect 1222 new PCEs or any modification of PCEs status. Policy can be applied in 1223 two ways in this context: 1225 1. Restricting the scope of information distribution for the 1226 mandatory set of information (in particular the PCE presence 1227 and location). 1229 2. Restricting the type and nature of the optional information 1230 distributed by the discovery protocol. The latter is also 1231 subject to policy since the PCE architecture allows for 1232 distributing this information using either PCE discovery 1233 protocol(s) or PCC-PCE communication protocol(s). One important 1234 policy decision in this context is the nature of the information 1235 to be distributed, especially, when this information is not 1236 strictly speaking a "discovery" information, rather, the PCE 1237 state changes. Client-specific and domain-specific policies may 1238 be applied when deciding whether this information should be 1239 distributed and to which clients of the path computation service 1240 (that is, which PCCs and/or PCEs) 1242 Another place where policy applies is at the administrative 1243 boundaries. In multi-domain networks multiple PCEs will communicate 1244 with each other and across administrative boundaries. In such cases, 1245 domain-specific polices would be applied to 1) filter the information 1246 exchanged between peering PCEs during the discovery process (to the 1247 bare minimum in most cases if at all allowed by the security policy) 1248 and 2) limit the content of information being passed in path 1249 computation request and responses. 1251 8. Path Computation Sequence of Events 1253 This section presents a non-exhaustive list of representative 1254 scenarios. 1256 8.1. Policy-enabled PCC, Policy-enabled PCE 1258 When a GMPLS LSR receives a Setup (RSVP Path) message from an 1259 upstream LSR, the LSR may decide to use a remote Path Computation 1260 Entity. The following sequence of events occurs in this case: 1262 - A PCC-PEP co-located with the LSR applies the service-specific 1263 policies to select a PCE for the service path computation as 1264 well as to build the path computation request (that is, to 1265 select a list of policies, their variables, conditions and 1266 actions expressing constraints, diversities, objective functions 1267 and relaxation strategies appropriate for the service path 1268 computation). The policies may be: 1270 a) Statically configured on the PCC-PEP; 1272 b) Communicated to the PCC-PEP by a remote or local PCC-PDP 1273 via protocol such as SOAP either pro-actively (most of the 1274 cases) or upon an explicit request by the PCC-PEP in case when 1275 some specifics of the new service have not been covered yet by 1276 the policies so far known to the PCC-PEP) 1278 The input for the decision process on the PCC-PEP is the 1279 information found in the signaling message as well as any other 1280 service-specific information such as port ID over which the message 1281 was received, associated VPN ID, the reference point type (UNI, E- 1282 NNI, etc.) and so forth. After the path computation request is 1283 built it is sent directly to the PCE-PEP using the PCC-PCE 1284 Communication Protocol, e.g., [PCEP]. 1286 - PCE-PEP validates and otherwise processes the request applying 1287 the policies found in the request as well as client and domain 1288 specific polices. The latter, again, may be either statically 1289 configured on the PCE-PEP or provided by the associated local or 1290 remote PCE-PDP via a protocol such as SOAP. The outcome of the 1291 decision process is the following information: 1293 a) Whether the request should be satisfied, rejected or 1294 dismissed. 1296 b) The sets of sources and destinations for which paths should 1297 be locally computed. 1299 c) The set of constraints, diversities, optimization functions 1300 and relaxations to be considered in each of locally performed 1301 path computation. 1303 d) The address of the next-in-chain PCE. 1305 e) The path computation request to be sent to the 1306 next-in-chain PCE. 1308 The PCE-PEP instructs a co-located path computation engine to 1309 perform the local path computation(s) and, if necessary, sends the 1310 path computation request to the next-in-chain PCE using a PCC-PCE 1311 Communication Protocol. Then it waits for the responses from the 1312 local path computation engine and the remote PCE, combines the 1313 resulting paths and sends them back to the PCC-PEP using the PCC- 1314 PCE Communication Protocol. The response contains the resulting 1315 paths as well as policies describing some additional information 1316 (for example, which of constraints were honored, which were 1317 dismissed and which were relaxed and in what way) 1319 - PCC-PEP instructs the signaling sub-system of the GMPLS LSR to 1320 encode the received path(s) into the outgoing Setup message(s). 1322 8.2. Policy-ignorant PCC, Policy-enabled PCE 1324 This case parallels the previous example, but the user and service- 1325 specific policies should be applied at the PCE as the PCC is policy 1326 ignorant. Again, when a GMPLS LSR has received a Setup (RSVP Path) 1327 message from an upstream LSR, the LSR may decide to use a non co- 1328 located Path Computation Entity. The following sequence of events 1329 occurs in this case: 1331 - The PCC constructs a PCE request using information found in the 1332 signaling/provisioning message as well as any other service 1333 specific information such as port ID over which the message was 1334 received, associated VPN ID, the reference point type (UNI, E- 1335 NNI, etc.) and so forth. This information is encoded in the 1336 request in the form of policy variables. After the request is 1337 built it is sent directly to the PCE-PEP using a PCC-PCE 1338 Communication Protocol. 1340 - PCE-PEP validates and otherwise processes the request 1341 interpreting the policy variables found in the request and 1342 applying user, service- and also client- and domain- specific 1343 polices to build the actual path computation request. The 1344 policies, again, may be either statically configured on the 1345 PCE-PEP or provided by the associated local or remote PCE-PDP via 1346 a protocol such as SOAP. The outcome of the decision process is 1347 the following information: 1349 a) Whether the request should be satisfied, rejected or 1350 dismissed. 1352 b) The sets of sources and destinations for which paths should 1353 be locally computed. 1355 c) The set of constraints, diversities, optimization functions 1356 and relaxations to be considered in each of locally performed 1357 path computation. 1359 d) The address of the next-in-chain PCE. 1361 e) The path computation request to be sent to the next-in- 1362 chain PCE. 1364 The PCE-PEP instructs a co-located path computation engine to 1365 perform the local path computation(s) and, if necessary, sends the 1366 path computation request to the next-in-chain PCE using the PCC-PCE 1367 Communication Protocol. Then it waits for the responses from the 1368 local path computation engine and the remote PCE, combines the 1369 resulting paths and sends them back to the PCC-PEP using the PCC- 1370 PCE Communication Protocol. The response contains the resulting 1371 paths as well as policies describing some additional information 1372 (for example, which of constraints were honored, which were 1373 dismissed and which were relaxed and in what way) 1375 - PCC-PEP instructs the signaling sub-system of the GMPLS LSR to 1376 encode the received path(s) into the outgoing Setup message(s). 1378 9. Introduction of New Constraints 1380 An important aspect of the policy-enable path computation framework 1381 discussed above is the ability to introduce new constraints with 1382 minimal impact. In particular, only those components and mechanisms 1383 that will use a new constraint need to be updated in order to support 1384 the new constraint. Importantly, those components and mechanisms that 1385 will not use the new constraint, must not require any change in order 1386 for the new constraint to be utilized. For example, the PCE 1387 communication protocols must not require any changes to support new 1388 constraints. Likewise, PCC and PCEs that will not process new 1389 constraints must not require any modification. 1391 Consider the case where a PCE has been upgraded with software 1392 supporting optical physical impairment constraint, such as 1393 Polarization Mode Dispersion (PMD), that previously was not supported 1394 in the domain. In this case, one or more new policies will be 1395 installed in the PCE Policy Repository (associated with the PCE) 1396 defining the constraint (rules that determine application criteria, 1397 set of policy variables, conditions, actions, etc.) and its 1398 relaxation strategy(ies). The new policies will be also propagated 1399 into other PCE Policy Repositories within the domain via discovery 1400 and synchronization protocols or via local configuration. PCE-PDPs 1401 and PCC-PDPs will then retrieve the corresponding policies from the 1402 repository(ies). From then on PCC-PDPs will instruct associated PCC- 1403 PEPs to add the new policy information into path computation requests 1404 for services with certain parameters (for example, for services 1405 provisioned in the OCh layer). 1407 It is important to note that policy-enabled path computation model 1408 naturally solves the PCE capability discovery issues. Suppose a PCE 1409 working in a single PCE Policy Repository configuration starts to 1410 support a new constraint. Once a corresponding policy installed in 1411 the repository, it automatically becomes available for all repository 1412 users, that is, PCCs. In the multi-repository case some policy 1413 synchronization must be provided, however, this problem is one of the 1414 management plane which is solved already. 1416 10. Security Considerations 1418 This document adds to the policy security considerations mentioned in 1419 [RFC4655]. In particular it is now necessary to consider the security 1420 issues related to policy information maintained in PCE Policy 1421 Repositories and policy related transactions. The most notable 1422 issues, some of which are also listed in [RFC4655], are: 1424 - Unauthorized access to the PCE Policy Repositories; 1425 - Interception of policy information when it is retrieved from 1426 the repositories and/or transported from PDPs to PEPs; 1428 - Interception of policy related information in path computation 1429 requests and responses; 1431 o Impersonation of user and client identities; 1433 o Falsification of policy information and/or PCE capabilities; 1435 o Denial of service attacks on policy related communication 1436 mechanisms. 1438 As with [RFC4655], it is expected that PCE solutions will address the 1439 PCE aspects of these issues in detail. 1441 11. Acknowledgments 1443 Adrian Farrel contributed significantly to this document. We would 1444 like to thank Bela Berde for fruitful discussions on PBM and Policy- 1445 driven path computation. We would also like to thank Kobus Van der 1446 Merwe for providing insights and examples regarding PCE policy 1447 applications. 1449 12. IANA Considerations 1451 None. 1453 13. References 1455 13.1. Normative References 1457 [RFC2753] R. Yavatkar, D. Pendarakis, R. Guerin, A Framework for 1458 Policy Based Admission Control, RFC 2753, January 2000. 1460 [RFC3060] B. Moore, et al., Policy Core Information Model -- 1461 Version 1 Specification, RFC 3060, February 2001. 1463 [RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP 1464 Tunnels", RFC 3209, December 2001. 1466 [RFC3460] Moore, B. Ed., "Policy Core Information Model (PCIM) 1467 Extensions", RFC 3460, January 2003. 1469 [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label 1470 Switching (GMPLS) Signaling Resource ReserVation 1471 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 1472 3473, January 2003. 1474 [RFC3644] Y. Snir, et al., Policy Quality of Service (QoS) 1475 Information Model, RFC 3644, November 2003. 1477 [RFC4216] Zhang, R., Vasseur, J-P., Eds., "MPLS Inter-Autonomous 1478 System (AS) Traffic Engineering (TE) Requirements", 1479 RFC4216, November 2005. 1481 [RFC4655] Farrel, A., Vasseur, JP., Ash, J., "Path Computation 1482 Element (PCE) Architecture", RFC 4655, August 2006. 1484 [RFC4927] Le Roux, J-L., Ed., "PCE Communication Protocol 1485 (PCECP) Specific Requirements for Inter-Area 1486 MPLS and GMPLS Traffic Engineering", June 2007. 1488 13.2. Informative References 1490 [DMTF] Common Information Model (CIM) Schema, version 2.x. 1491 Distributed Management Task Force, Inc. The components 1492 of the CIM v2.x schema are available via links on the 1493 following DMTF web page: 1494 http://www.dmtf.org/standards/standard_cim.php. 1496 [IRSCP] Van der Merwe, J., et al., "Dynamic Connectivity 1497 Management with an Intelligent Route Service Control 1498 Point," ACM SIGCOMM Workshop on Internet Network 1499 Management (INM), Pisa, Italy, September 11, 2006. 1501 [PCEP] Vasseur, J., Le Roux, J., Eds., "Path Computation Element 1502 (PCE) Communication Protocol (PCEP)", Work in Progress, 1503 draft-ietf-pce-pcep-16.txt, October 14, 2008. 1505 [RFC2748] D. Durham, et al., The COPS (Common Open Policy Service) 1506 protocol, RFC 2748, IETF, January 2000. 1508 [RFC3031] Rosen, E,. Viswanathan, V. Callon, R., "Multiprotocol 1509 Label Switching Architecture", RFC 3031, January 2001. 1511 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol 1512 Core", RFC 3080, March 2001. 1514 [RFC3198] Westerinen, A., et al., "Terminology for Policy-Based 1515 Management", RFC 3198, November 2001. 1517 [RFC3630] Katz, D., Kompella, K., Yeung., D., "Traffic Engineering 1518 (TE) Extensions to OSPF Version 2", RFC 3630, September 1519 2003. 1521 [INTERAS-PCEP] Bitar, N., Zhang, R., Kumaki, K., Eds., "Inter-AS 1522 Requirements for the Path Computation Element 1523 Communication Protocol (PCECP)", February 2006. 1525 [W3CSOAP] Hadley, M., Mendelsohn, N., Moreau, J., Nielsen, H., 1526 and Gudgin, M., "SOAP Version 1.2 Part 1: Messaging 1527 Framework", W3C REC REC-soap12-part1-20030624, June 1528 2003. 1530 14. Authors' Addresses 1532 Igor Bryskin 1533 ADVA Optical 1534 7926 Jones Branch Drive 1535 Suite 615 1536 McLean, VA 22102 1537 Email: ibryskin@advaoptical.com 1539 Dimitri Papadimitriou (Alcatel) 1540 Fr. Wellesplein 1, 1541 B-2018 Antwerpen, Belgium 1542 Phone: +32 3 240-8491 1543 Email: dimitri.papadimitriou@alcatel.be 1545 Lou Berger 1546 LabN Consulting, LLC 1547 Phone: +1 301 468 9228 1548 Email: lberger@labn.net 1550 Jerry Ash 1551 AT&T 1552 Email: gash5107@yahoo.com 1554 15. Full Copyright Statement 1556 Copyright (C) The IETF Trust (2008). 1558 This document is subject to the rights, licenses and restrictions 1559 contained in BCP 78, and except as set forth therein, the authors 1560 retain all their rights. 1562 This document and the information contained herein are provided on an 1563 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1564 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1565 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1566 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1567 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1568 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1570 16. Intellectual Property 1572 The IETF takes no position regarding the validity or scope of any 1573 Intellectual Property Rights or other rights that might be claimed 1574 to pertain to the implementation or use of the technology 1575 described in this document or the extent to which any license 1576 under such rights might or might not be available; nor does it 1577 represent that it has made any independent effort to identify any 1578 such rights. Information on the procedures with respect to rights 1579 in RFC documents can be found in BCP 78 and BCP 79. 1581 Copies of IPR disclosures made to the IETF Secretariat and any 1582 assurances of licenses to be made available, or the result of an 1583 attempt made to obtain a general license or permission for the use 1584 of such proprietary rights by implementers or users of this 1585 specification can be obtained from the IETF on-line IPR repository 1586 at http://www.ietf.org/ipr. 1588 The IETF invites any interested party to bring to its attention 1589 any copyrights, patents or patent applications, or other 1590 proprietary rights that may cover technology that may be required 1591 to implement this standard. Please address the information to the 1592 IETF at ietf-ipr@ietf.org. 1594 Acknowledgement 1596 Funding for the RFC Editor function is provided by the IETF 1597 Administrative Support Activity (IASA). 1599 Generated on: Tue Oct 28 19:31:33 EDT 2008