idnits 2.17.1 draft-ietf-pce-policy-enabled-path-comp-03.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 1458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1482. 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 : ---------------------------------------------------------------------------- No issues found here. 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, 2007) is 6019 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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, 2008 Lou Berger (LabN Consulting) 4 Jerry Ash (AT&T) 6 October 31, 2007 8 Policy-Enabled Path Computation Framework 10 draft-ietf-pce-policy-enabled-path-comp-03.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, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 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 Contents 53 1 Introduction .............................................. 3 54 1.1 Terminology ............................................... 4 55 2 Background ................................................ 4 56 2.1 Motivation ................................................ 5 57 2.2 Representative Policy Scenarios ........................... 7 58 2.2.1 Scenario: Policy Configured Paths ......................... 7 59 2.2.2 Scenario: Provider Selection Policy ....................... 10 60 2.2.3 Scenario: Policy Based Constraints ........................ 11 61 2.2.4 Scenario: Advanced Load Balancing (ALB) Example .......... 13 62 3 Requirements .............................................. 14 63 4 Path Computation Policy Information Model (PCPIM) ......... 16 64 5 Policy-Enabled Path Computation Framework Components ...... 18 65 6 Policy Component Configurations ........................... 19 66 6.1 PCC-PCE Configurations .................................... 19 67 6.2 Policy Repositories ....................................... 21 68 6.3 Cooperating PCE Configurations ............................ 23 69 6.4 Policy Configuration Management ........................... 24 70 7 Inter-Component Communication ............................. 24 71 7.1 Policy Communication ..................................... 24 72 7.2 PCE Discovery Policy Considerations ....................... 26 73 8 Path Computation Sequence of Events ....................... 27 74 8.1 Policy-enabled PCC, Policy-enabled PCE .................... 27 75 8.2 Policy-ignorant PCC, Policy-enabled PCE ................... 28 76 9 Introduction of New Constraints ........................... 30 77 10 Security Considerations ................................... 30 78 11 Acknowledgments ........................................... 31 79 12 IANA Considerations ....................................... 31 80 13 References ................................................ 31 81 13.1 Normative References ...................................... 31 82 13.2 Informative References .................................... 32 83 14 Authors' Addresses ........................................ 33 84 Full Copyright Statement .................................. 33 85 Intellectual Property ..................................... 34 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 93 architecture and provides additional details on, and context for 94 applying policy within the PCE Architecture. 96 Policy-based Management (PBM), see [RFC3198], is a network management 97 approach that enables a network to automatically perform actions in 98 response to network events or conditions based on pre-established 99 rules, also denoted as policies, from a network administrator. PBM 100 enables network administrators to operate in a high-level manner 101 through rule-based strategy (policies can be defined as a set of 102 rules and actions); the latter are translated automatically (i.e., 103 dynamically, without human interference) into individual device 104 configuration directives, aimed at controlling a network as a whole. 105 Two IETF Working Groups have considered policy networking in the 106 past: The Resource Allocation Protocol (RAP) working group and the 107 Policy Framework working group. 109 A framework for policy-based admission control [RFC2753] was defined 110 and a protocol for use between Policy Enforcement Points (PEP) and 111 Policy Decision Points (PDP) was specified: Common Open Policy 112 Service (COPS) [RFC2748]. This document uses the terms PEP and PDP to 113 refer to the functions defined in the COPS context. This document 114 makes no assumptions nor requires that the actual COPS protocol be 115 used. 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 CIM: Common Information Model, see [DMTF]. 145 COPS: Common Open Policy Service, see [RFC2748]. 146 COPS-PR: COPS Usage for Policy Provisioning, see [RFC3084]. 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 PCIM: Policy Core Information Model, see [RFC3060]. 156 PDP: Policy Decision Points, see [RFC2753]. 157 PEP: Policy Enforcement Points, see [RFC2753]. 158 QPIM: QoS Policy Information Model, see [RFC3644]. 159 SLA: Service Level Agreement. 160 TE: Traffic Engineering, see [RFC3209] and [RFC3473]. 161 TED: Traffic Engineering Database, see [RFC3209] and [RFC3473]. 162 TE LSP: Traffic Engineering MPLS Label Switched Path, see 163 [RFC3209] and [RFC3473]. 165 2. Background 167 This section provides some general background on the use of policies 168 within the PCE architecture. It presents the rationale behind the use 169 of policies in the TE path computation process, as well as 170 representative policies usage scenarios. This information is intended 171 to provide context for the presented PCE policy framework. This 172 section does not attempt to present an exhaustive list of rationales 173 or scenarios. 175 2.1. Motivation 177 The PCE architecture as introduced in [RFC4655] includes policy as an 178 integral part of the PCE architecture. This section presents some of 179 the rationale for this inclusion. 181 Network operators require a certain level of flexibility to shape the 182 TE path computation process, so that the process can be aligned with 183 their business and operational needs. Many aspects of the path 184 computation may be governed by policies. For example, a PCC may use 185 policies configured by the operator to decide which optimization 186 criteria, constraints, diversities and their relaxation strategies to 187 request while computing path(s) for a particular service. Depending 188 on SLAs, TE and cost/performance ratio goals, path computation 189 requests may be issued differently for different services. A given 190 Service A, for instance, may require two SRLG-disjoint paths for 191 building end-to-end recovery scheme, while for a Service B link- 192 disjoint paths may be sufficient. Service A may need paths with 193 minimal end-to-end delay, while Service B may be looking for shortest 194 (minimal-cost) paths. Different constraint relaxation strategies may 195 be applied while computing paths for Service A and for Service B, and 196 so forth. So based on distinct service requirements distinct or 197 similar policies may be adopted when issuing/handling path 198 computation requests. 200 Likewise, a PCE may apply policies to decide which algorithm(s) to 201 use while performing path computations requested from a particular 202 PCC or for a particular domain, see [RFC4927]; whether to seek the 203 cooperation of other PCEs to satisfy a particular request or to 204 handle a request on its own (possibly responding with non explicit 205 paths); or how the request should be modified before being sent to 206 other member(s) of a group of cooperating PCEs, etc. 208 Additional motivation for supporting policies within the PCE 209 architecture can be described as follows. Historically, a path 210 computation entity was an intrinsic part of an LSR's control plane 211 and always co-located with the LSR's signaling and routing 212 subsystems. This approach allowed for unlimited flexibility in 213 providing various path computation enhancements, such as: adding new 214 types of constraints, diversities and their relaxation strategies, 215 adopting new objective functions and optimization criteria, etc. All 216 that had to be done to support an enhancement was to upgrade the 217 control plane software of a particular LSR (and no other LSRs or any 218 other network elements). 220 With the introduction of the PCE architecture, the introduction of 221 new PCE capabilities becomes more complicated: it isn't enough for a 222 PCE to upgrade its own software. In order to take advantage of a 223 PCE's new capabilities, new advertising and signaling objects may 224 need to be standardized, all PCCs may need to be upgraded with new 225 software, and new interoperability problems may need to be resolved, 226 etc. 228 Within the context of the PCE architecture, it is therefore highly 229 desirable to find a way to introduce new path computation 230 capabilities without requiring modifying either the 231 discovery/communication protocols or the PCC software. One way to 232 achieve this objective is to consider path selection constraints, 233 their relaxations and objective functions, as path computation 234 request-specific policies. Furthermore, such policies may be 235 configured and managed by a network operator as any other policies 236 and may be interpreted in real time by PCCs and PCEs. 238 There are a number of advantages and useful by-products of such an 239 approach: 241 - New path computation capabilities may be introduced without 242 changing PCE-PCC communication and discovery protocols or PCC 243 software. Only the PCE module providing the path computation 244 capabilities (referred to in this document as a path 245 computation engine) needs to be updated. 247 - Existing constraints, objective functions and their relaxations 248 may be aggregated and otherwise associated, thus producing new, 249 more complex objective functions that do not require a change 250 of code even on the PCEs supporting the functions. 252 - Different elements such as conditions, actions, variables, 253 etc., may be re-used by multiple constraints, diversities, and 254 optimizations. 256 - PCCs and PCEs need to handle other (that is, not request- 257 specific) policies. Path computation-related policies of all 258 types can be placed within the same policy repositories, can be 259 managed by the same policy management tools, and can be 260 interpreted using the same mechanisms. Also policies need to be 261 supported by PCCs and PCEs independent of the peculiarities of a 262 specific PCC-PCE communication protocol. Thus, introducing a new 263 (request-specific) type of policies describing constraints and 264 other elements of a path computation request will be a natural 265 and relatively inexpensive addition to the policy-enabled path 266 computation architecture. 268 2.2. Representative Policy Scenarios 270 This section provides example scenarios of how policies may be 271 applied using the PCE policy framework within the PCE architecture 272 context. Actual networks may deploy one of the scenarios discussed, 273 some combination of the presented scenarios, or other scenarios (not 274 discussed). This section should not be viewed as limiting other 275 applications of policies within the PCE architecture. 277 2.2.1. Scenario: Policy Configured Paths 279 A very simple usage scenario for PCE policy would be to use PCE to 280 centrally administer configured paths. Configured paths are composed 281 of strict and loose hops in the form of Explicit Route Objects 282 (EROs), see [RFC3209], and are used by one or more LSPs. Typically, 283 such paths are configured at the LSP ingress. In the context of 284 policy-enabled path computation, an alternate approach is possible. 286 In particular, service-specific policies can be installed that will 287 provide configured path(s) for a specific service request. The 288 request may be identified based on service parameters such as end- 289 points, requested QoS, or even a token that identifies the initiator 290 of a service request. The configured path(s) would then be used as 291 input to the path computation process, which would return explicit 292 routes by expanding of all specified loose hops. 294 ---------------------- 295 | ----- | 296 | | TED |<-+------------> 297 | ----- | TED synchronization 298 | | | mechanism (e.g., routing protocol) 299 | | | 300 | v | 301 | ------ ----- | Inter-PCE Request/Response 302 | |Policy|<-->| PCE |<.+...........> (when present) 303 | ------ ----- | 304 ---------------------- 305 ^ 306 | Request/ 307 | Response 308 v 309 Service ------------- Signaling 310 Request |[PCC][Policy]| Protocol 311 <------>| Node |<-------> 312 or Signaling ------------- 313 Protocol 315 Figure 1: Policy Enabled PCC and PCE 317 Path computation policies may be applied at either a PCC or a PCE, 318 see Figure 1. In the PCC case, the configured path would be processed 319 at the PCC and then passed to the PCE along with the PCE request, 320 probably in the form of (inclusion) constraints. When applied at the 321 PCE, the configured path would be used locally. Both cases require 322 some method to configure and manage policies. In the PCC case, the 323 real benefit would come when there is an automated policy 324 distribution mechanism. 326 ------------------ ------------------- 327 | | | | 328 | PCE | | PCE | 329 | | | | 330 | ------ ----- | | ----- ------ | 331 | |Policy| | TED | | | | TED | |Policy| | 332 | ------ ----- | | ----- ------ | 333 ------------------ ------------------- 334 ^ ^ 335 | Request/ | Request/ 336 | Response | Response 337 v v 338 Service -------- Signaling ------------ Signaling ------------ 339 Request|Head-End| Protocol |Intermediate| Protocol |Intermediate| 340 ---->| Node |<--------->| Node |<--------->| Node | 341 -------- ------------ ------------ 343 Figure 2. Multiple PCE Path Computation 345 ------------------ ------------------ 346 | | Inter-PCE Request/Response | | 347 | PCE |<-------------------------->| PCE | 348 | | | | 349 | ------ ----- | | ------ ----- | 350 | |Policy| | TED | | | |Policy| | TED | | 351 | ------ ----- | | ------ ----- | 352 ------------------ ------------------ 353 ^ 354 | Request/ 355 | Response 356 v 357 Service ---------- Signaling ---------- Signaling ---------- 358 Request| Head-End | Protocol | Adjacent | Protocol | Adjacent | 359 ---->| Node |<---------->| Node |<---------->| Node | 360 ---------- ---------- ---------- 362 Figure 3. Multiple PCE Path Computation with Inter-PCE Communication 364 Policy-configured paths may also be used in environments with 365 multiple (more than one) cooperating PCEs (see Figures 2 and 3). For 366 example, consider the case when there is limited TE visibility and 367 independent PCEs are used to determine path(s) within each area of 368 the TE visibility. In such a case, it may not be possible (or 369 desirable) to configure entire explicit path(s) on a single PCE. 370 However, it is possible to configure explicit path(s) for each area 371 of the TE visibility and each responsible PCE. One by one, the PCEs 372 would then map an incoming signaling request to appropriate 373 configured path(s). Note that to make such a scenario work it would 374 likely be necessary to start and finish the configured paths on TE 375 domain boundary nodes. Clearly, consistent PC Policy Repositories are 376 also critical in this example. 378 2.2.2. Scenario: Provider Selection Policy 380 A potentially more interesting scenario is applying PC policies in 381 multi-provider topologies. There are numerous interesting policy 382 applications in such topologies. A rudimentary example is simple 383 access control, that is, deciding which PCCs are permitted to request 384 inter-domain path computation. 386 A more complicated example is applying policy to determine which 387 domain or network provider will be used to support a particular PCE 388 request. Consider the topology presented in Figure 4. In this example 389 there are multiple transit domains available to provide a path from a 390 source domain to a destination domain. Furthermore, each transit 391 domain may have one or more options for reaching a particular domain. 392 Each domain will need to select which of the multiple available paths 393 will be used to satisfy a particular PCE request. 395 In today's typical path computation process, TE reachability, 396 availability and metric are the basic criteria for path selection. 397 However, policies can provide an important added consideration in the 398 decision process. For example, transit domain A may be more expensive 399 and provide lower delay or loss than transit domain B. Likewise, a 400 transit domain may wish to treat PCE requests from its own customers 401 differently than requests from other providers. In both cases, 402 computation based on traffic engineering databases will result in 403 multiple transit domain that provide reachability, and policies can 404 be used to govern which PCE requests get better service. 406 +-------+ 407 +----------+Transit+----------+ 408 +---+---+ | Domain| +---+---+ 409 |Transit| | C | |Transit| 410 +--------+ Domain| +---+---+ | Domain+--------+ 411 | | A +--+ | +--+ F | | 412 +--+---+ +---+---+ | | | +---+---+ +--+---+ 413 |Source| | | +---+---+ | | |Target| 414 |Domain| | +---+Transit+---+ | |Domain| 415 +--+---+ | +---+ Domain|---+ | +--+---+ 416 | +---+---+ | | D | | +---+---+ | 417 | |Transit| | +---+---+ | |Transit| | 418 +--------+ Domain+--+ | +--+ Domain+--------+ 419 | B | | | G | 420 +---+---+ +---+---+ +---+---+ 421 | |Transit| | 422 +----------+ Domain+----------+ 423 | E | 424 +-------+ 426 Figure 4: Multi-Domain Network with Multiple Transit Options 428 There are multiple options for differentiating which PCE requests use 429 a particular transit domain and get a particular (better or worse) 430 level of service. For example, a PCE in the source domain may use 431 user and request-specific policies to determine the level of service 432 to provide. A PCE in the source domain may also use domain-specific 433 policies to choose which transit domains are acceptable. A PCE in a 434 transit domain may use request-specific policies to determine if a 435 request is from a direct customer or another provider, and then use 436 domain-specific policies to identify how the request should be 437 processed. 439 2.2.3. Scenario: Policy Based Constraints 441 Another usage scenario is the use of policy to provide constraints in 442 a PCE request. Consider an LSR with a policy enabled PCC, as shown in 443 Figure 1, which receives a service request via signaling, including 444 over a NNI or UNI reference point, or receives a configuration 445 request over a management interface to establish a service. In either 446 case the path(s) needed to support the service are not explicitly 447 specified in the message/request, and hence path computation is 448 needed. 450 In this case, the PCC may apply user or service-specific policies to 451 decide how the path selection process should be constrained, that is, 452 which constraints, diversities, optimization criterion and constraint 453 relaxation strategies should be applied in order for the service 454 LSP(s) to have a likelihood to be successfully established and 455 provide necessary QoS and resilience against network failures. When 456 deciding on the set of constraints the PCC uses as an input all 457 information it knows about the user and service, such as the contents 458 of the received message, port ID over which message was received, 459 associated VPN ID, signaling/reference point type, request time, etc. 460 Once the constraints and other parameters of the required path 461 computation are determined, the PCC generates a path computation 462 request which includes the request-specific policies that describe 463 the determined set of constraints, optimizations, and other 464 parameters that indicate how the request is to be considered in the 465 path computation process. 467 The PCC may also apply server-specific policies in order to select 468 which PCE to use from the set of known (i.e., discovered or 469 configured) PCEs. The PCC may also use server-specific policies to 470 form the request to match the PCE's capabilities so that the request 471 will not be rejected and has a higher likelihood of being satisfied 472 in an efficient way. An example of a request modification as the 473 result of a server-specific policy is removing a constraint not 474 supported by the PCE. Once the policy processing is completed at the 475 PCC, and the path computation request resulting from the original 476 service request is updated by the policy processing, the request is 477 sent to the PCE. 479 The PCE that receives the request validates and otherwise processes 480 the request, applying the policies found in the request as well as 481 any policies that are available at the PCE, e.g., client and domain- 482 specific polices. As a result of the policy processing, the PCE may 483 decide to reject the request. It also may decide to respond with one 484 or several pre-computed paths if user or client specific polices 485 instruct the PCE to do so. If the PCE decides to satisfy the request 486 by performing a path computation, it determines if it needs the 487 cooperation of other PCEs and defines parameters for path 488 computations to be performed locally and remotely. After that, the 489 PCE instructs a co-located path computation engine to perform the 490 local path computation(s) and, if necessary, sends path computation 491 requests to one or more other PCEs. It then waits for the responses 492 from the local path computation engine and, when used, the remote 493 PCE. It then combines the resulting paths and sends the result back 494 to the requesting PCC. The response may indicate policies describing 495 the resulting paths, their characteristics (summary cost, expected 496 end-to-end delay, etc.). as well as additional information related to 497 the request, e.g., which constraints were honored, which were 498 dismissed, and which were relaxed and in what way. 500 The PCC processes the response and instructs the LSR to encode the 501 received path(s) into the outgoing signaling message(s). 503 2.2.4. Scenario: Advanced Load Balancing (ALB) Example 505 Figure 5 illustrates a problem that stems from the coupling between 506 BGP and IGP in the BGP decision process. If a significant portion of 507 the traffic destined to the data center (or customer network) enters 508 a PCE-enabled network from AS 1 and all IGP links weights are the 509 same, then both PE3 and PE4 will prefer to reach the data center 510 using the routes advertised by PE2. PE5 will use the router-IDs of 511 PE1 and PE2 to break the tie and might therefore also select to use 512 the path through PE2 (if the router ID of PE2 is smaller than that of 513 PE1). Either way the net result is that the link between PE2 and CE 514 will carry most of the traffic while the link between PE1 and CE will 515 be mostly idle. 517 .............................. 518 . AS 1 . 519 . . 520 . +---+ +---+ +----+ . 521 ....|PE8|...|PE9|...|PE10|.... 522 +---+ +---+ +----+ 523 | | | 524 +---+ +---+ +---+ 525 ......|PE3|...|PE4|...|PE5|...... 526 . +---+ +---+ +---+ . 527 .............. +---+ \ / ___/ +---+ 528 . . _|PE2|_____+--+__/ / _|PE6| 529 . +--+ / +---+ |P1|_____+--+_______/ +---+ 530 . Customer |CE|= . +--+ |P2| . 531 . Network +--+ \_+---+ \ +--+ . 532 . . |PE1|________+--+___/| x===x . PCE used 533 .............. +---+ |P3| | |PCE| . by all 534 . +--+ | x===x . AS0 nodes 535 . AS 0 +---+ . 536 ..................|PE7|.......... 537 +---+ 539 Figure 5: Advanced Load Balancing 541 This is a common problem for providers and customers alike. Analysis 542 of Netflow records, see [IRSCP], for a large ISP network on a typical 543 day has shown that for 71.8% of multi-homed customers there is a 544 complete imbalance, where the most loaded link carries all the 545 traffic and the least loaded link carries none. 547 PCE policies can address this problem by basing the routing decision 548 at the ingress routers on the offered load towards the multi-homed 549 customer. For example, in Figure 5 PCE policies could be configured 550 such that traffic load is monitored (e.g., based on Netflow data) at 551 ingress routers PE3 to PE7 towards the data center prefixes served by 552 egress routers PE1 and PE2. Using this offered load information, the 553 path computations returned by PCE, based on the enabled PCE policies, 554 can direct traffic to the appropriate egress router, on a per-ingress 555 router basis. For example, the PCE path computation might direct 556 traffic from both PE4 and PE5 to egress PE1, thus overriding the 557 default IGP based selection. Alternatively, traffic from each 558 ingress router to each egress link could be split 50-50. 560 This scenario is a good example of how a policy governed PCE can 561 account for some information that was not or cannot be advertised as 562 TE link/node attributes, and, therefore, cannot be subject for 563 explicit path computation constraints. More generally, such 564 information can be pretty much anything. For example, traffic demand 565 forecasts, flow monitoring feedback, any administrative policies, 566 etc. Further examples are described in [IRSCP] of how PCE policies 567 might address certain network routing problems, such as selective 568 DDoS blackholing, planned maintenance, and VPN gateway selection. 570 3. Requirements 572 The following requirements must be addressed by mechanisms and 573 protocols that enable policy-based control over path computation 574 requests and decisions: 576 - (G)MPLS path computation-specific 577 The mechanisms must meet the policy-based control requirements 578 specific to the problem of path computation using RSVP-TE as the 579 signaling protocol on MPLS and GMPLS LSRs. 581 - Support for non-(G)MPLS PCCs 582 The mechanisms must be sufficiently generic to support 583 non-(G)MPLS (LSR) clients such as an NMS, or network planner, 584 etc. 586 - Support for many policies 587 The mechanisms must include support for many policies and policy 588 configurations. In general, the determination and configuration 589 of viable policies are the responsibility of the service 590 provider. 592 - Provision for monitoring and accounting information 593 The mechanisms must include support for monitoring policy state, 594 and provide access information. In particular, mechanisms must 595 provide usage and access information that may be used for 596 accounting purposes. 598 - Fault tolerance and recovery 599 The mechanisms must include provisions for fault tolerance and 600 recovery from failure cases such as failure of PCC/PCE PDPs, 601 disruption in communication that separate a PCC/PCE PDP from its 602 associated PCC/PCE PEPs. 604 - Support for policy-ignorant nodes 605 The mechanisms should not be mandatory for every node in a 606 network. Policy based path computation control may be enforced at 607 a subset of nodes, for example, on boundary nodes within an 608 administrative domain. These policy-capable nodes will function 609 as trusted nodes from the point of view of the policy-ignorant 610 nodes in that administrative domain. Alternatively, policy may be 611 applied solely on PCEs with all PCCs being policy-ignorant nodes. 613 - Scalability 614 One of the important requirements for the mechanisms is 615 scalability. The mechanisms must scale at least to the same 616 extent that RSVP-TE signaling scales in terms of accommodating 617 multiple LSPs and network nodes in the path of an LSP. There are 618 several sensitive areas in terms of scalability of policy based 619 path computation control. First, not every policy aware node in 620 an infrastructure should be expected to contact a remote 621 PDP. This would cause potentially long delays in verifying 622 requests. Additionally, the policy control architecture must 623 scale at least as well as RSVP-TE protocol based on factors such 624 as the size of RSVP-TE messages, the time required for the 625 network to service an RSVP-TE request, local processing time 626 required per node, and local memory consumed per node. These 627 scaling considerations are of particular importance during 628 re-routing of a set of LSPs. 630 - Security and denial of service considerations 631 The policy control architecture, protocols and mechanisms must be 632 secure as far as the following aspects are concerned: 634 o First, the mechanisms proposed must minimize theft and denial 635 of service threats. 637 o Second, it must be ensured that the entities (such as PEPs 638 and PDPs) involved in policy control can verify each other's 639 identity and establish necessary trust before communicating. 641 - Inter-AS and inter-area requirements 642 There are several inter-AS policy related requirements discussed 643 in [RFC4216] and [INTERAS-PCEP], and inter-area policy related 644 requirements discussed in [RFC4927]. These requirements 645 must be addressed by policy-enabled PCE mechanisms and protocols. 647 It should be noted that this document only outlines the communication 648 elements and mechanisms needed to allow a wide variety of possible 649 policies to be applied for path computation control. It does not 650 include any discussion of any specific policy behavior. Nor does it 651 define or require use of specific policies. 653 4. Path Computation Policy Information Model (PCPIM) 655 The Policy Core Information Model (PCIM) introduced in [RFC3060] and 656 expanded in [RFC3460] presents the object-oriented information model 657 for representing general policy information. 659 This model defines two hierarchies of object classes: 661 - Structural classes representing policy information and control of 662 policies. 664 - Association classes that indicate how instances of the structural 665 classes are related to each other. 667 These classes can be mapped to various concrete implementations, for 668 example, to a directory that uses LDAPv3 as its access protocol. 670 Figure 6 shows an abstract from the class inheritance hierarchy for 671 PCIM. 673 ManagedElement (abstract) 674 | 675 +--Policy (abstract) 676 | | 677 | +---PolicySet (abstract) 678 | | | 679 | | +---PolicyGroup 680 | | | 681 | | +---PolicyRule 682 | | 683 | +---PolicyCondition (abstract) 684 | | | 685 | | +---PolicyTimePeriodCondition 686 | | | 687 | | +---VendorPolicyCondition 688 | | | 689 | | +---SimplePolicyCondition 690 | | | 691 | | +---CompoundPolicyCondition 692 | | | 693 | | +---CompoundFilterCondition 694 | | 695 | +---PolicyAction (abstract) 696 | | | 697 | | +---VendorPolicyAction 698 | | | 699 | | +---SimplePolicyAction 700 | | | 701 | | +---CompoundPolicyAction 702 | | 703 | +---PolicyVariable (abstract) 704 | | | 705 | | +---PolicyExplicitVariable 706 | | | 707 | | +---PolicyImplicitVariable 708 | | | 709 | | +---(subtree of more specific classes) 710 | | 711 | +---PolicyValue (abstract) 712 | | 713 | +---(subtree of more specific classes) 715 Figure 6: PCIM Class Inheritance 717 The policy classes and associations defined in PCIM are sufficiently 718 generic to allow them to represent policies related to anything. 720 Policy models for application-specific areas such as the Path 721 Computation Service may extend the PCIM in several ways. The 722 preferred way is to use the PolicyGroup, PolicyRule, and 723 PolicyTimePeriodCondition classes directly as a foundation for 724 representing and communicating policy information. Then, specific 725 subclasses derived from PolicyCondition and PolicyAction can capture 726 application-specific definitions of conditions and actions of 727 policies. 729 Policy Quality of Service Information Model [RFC3644] further extends 730 the PCIM to represent QoS policy information for large-scale policy 731 domains. New classes introduced in this document describing QoS and 732 RSVP related variables, conditions and actions can be used as a 733 foundation for the PCPIM. 735 Detailed description of the PCPIM will be provided in a separate 736 documents. 738 5. Policy-Enabled Path Computation Framework Components 740 The following components are defined as part of the framework to 741 support policy-enabled path computation: 743 - PC Policy Repository 744 A database from which PC policies are available in the form of 745 instances of PCPIM classes. PC Policies are configured and 746 managed by PC Policy Management Tools; 748 - PCE Policy Decision Point (PCE-PDP) 749 A logical entity capable of retrieving relevant path computation 750 policies from one or more Policy Repositories and delivering the 751 information to associated PCE-PEP(s); 753 - PCE Policy Enforcement Point (PCE-PEP) 754 A logical entity capable of issuing device specific Path 755 Computation Engine configuration requests for the purpose of 756 enforcing the policies; 758 - PCC Policy Decision Point (PCC-PDP) 759 A logical entity capable of retrieving relevant path computation 760 policies from one or more Policy Repositories and delivering the 761 information to associated PCC-PEP(s); 763 - PCC Policy Enforcement Point (PCC-PEP) 764 A logical entity capable of issuing device specific Path 765 Computation Service User configuration requests for the purpose 766 of enforcing the policies. 768 From the policy perspective a PCC is logically decomposed into two 769 parts: PCC-PDP and PCC-PEP. When present, a PCC-PEP is co-located 770 with a Path Computation Service User entity that requires remote path 771 computation (for example, the GMPLS control plane of an LSR). The 772 PCC-PEP and PCC-PDP may be physically co-located (as per [RFC2748]) 773 or separated. In the later case they talk to each other via such 774 protocols as COPS and/or COPS-PR [RFC3084]. 776 Likewise, a PCE is logically decomposed into two parts: PCE-PEP and 777 PCE-PDP. When present, PCE-PEP is co-located with a Path Computation 778 Engine entity that actually provides the Path Computation Service 779 (that is, runs path computation algorithms). PCE-PEP and PCE-PDP may 780 be physically co-located or separated. In the later case they 781 communicate using such protocols as COPS and/or COPS-PR. 783 PCC-PDP/PCE-PDP may be co-located with, or separated from, an 784 associated PC Policy Repository. In the latter case, the PDPs use 785 some access protocol (for example, LDAPv3 or SNMP). The task of PDPs 786 is to retrieve policies from the repository(ies) and convey them to 787 respective PEPs either in unsolicited way or upon the PEPs requests. 789 A PCC-PEP may receive policy information not only from PCC-PDPs(s) 790 but also from PCE-PEP(s) via PCC-PCE communication and/or PCE 791 discovery protocols. Likewise, a PCE-PEP may receive policy 792 information not only from PCE-PDPs(s) but also from PCC-PEP(s), via 793 PCC-PCE communication protocol. 795 Any given policy can be interpreted (that is, translated into a 796 sequence of concrete device specific configuration requests) either 797 on a PDP or on the associated PEP or partly on the PDP and partly on 798 the PEP. 800 Generally speaking, the task of the PCC-PEP is to select the PCE and 801 build path computation requests applying service-specific policies 802 provided by the PCC-PDP. The task of the PCE-PEP is to control path 803 computations by applying request-specific policies found in the 804 requests as well as client-specific and domain-specific policies 805 supplied by the PCE-PDP. 807 6. Policy Component Configurations 809 6.1. PCC-PCE Configurations 811 The PCE policy architecture supports policy being applied at a PCC 812 and at a PCE. While the architecture supports policy being applied at 813 both, there is no requirement for policy to always be applied at 814 both, or even at either. The use of policy in a network, on PCCs and 815 on PCEs, is a specific network design choice. Some networks may 816 choose to apply policy only at PCCs (Figure 7), some at PCEs (Figure 817 8), and others at both PCCs and PCEs (Figure 9). Regardless of where 818 policy is applied it must be applied in a consistent fashion in order 819 to achieve the intended results. 821 ........................ 822 . . 823 . PC Policy Management . 824 . . 825 ........................ 826 . 827 . 828 --------- Policy ---------------------- 829 | PCC-PDP |<--------- | PC Policy Repository | 830 --------- ---------------------- 831 ^ 832 | e.g., COPS 833 v 834 --------- --------- 835 | PCC-PEP |<------------------------------------------->| PCE | 836 --------- PCC-PCE Communication Protocol --------- 838 Figure 7: Policies Applied On PCC Only 840 Along with supporting flexibility in where policy may be applied, the 841 PCE architecture is also flexible in terms of where specific types of 842 policies may be applied. Also the PCE architecture allows for the 843 application of only a subset of policy types. [RFC4655] defines 844 several PC policy types. Each of these may be applied at either a PCC 845 or a PCE or both. Clearly when policy is only applied at PCCs or at 846 PCEs, all PC policy types used in the network must be applied at 847 those locations. 849 ........................ 850 . . 851 . PC Policy Management . 852 . . 853 ........................ 854 . 855 . 856 ---------------------- Policy --------- 857 | PC Policy Repository | -------->| PCE-PDP | 858 ---------------------- --------- 859 ^ 860 e.g., COPS | 861 v 862 --------- --------- 863 | PCC |<------------------------------------------->| PCE-PEP | 864 --------- PCC-PCE Communication Protocol --------- 866 Figure 8: Policies Applied On Only 868 In the case where policy is only applied at a PCE, it is expected 869 that the PCC will pass to the PCE all information about the service 870 that it can gather in the path computation request (most likely in 871 the form of PCPIM policy variables). The PCE is expected to 872 understand this information and apply appropriate policies while 873 defining the actual parameters of the path computation to be 874 performed. Note that in this scenario the PCC cannot apply server- 875 specific or any other policies, and PCE selection is static. 877 When applying policy at both PCC and PCE, it is necessary to select 878 which types of policies are applied at each. In such configurations, 879 it is likely that the application of policy types will be distributed 880 across PCC and PCE rather than applying all of them at both. For 881 example, user-specific and server-specific policies may be applied at 882 a PCC, request and client specific policies may be applied at a PCE, 883 while domain-specific policies may be applied at both the PCC and 884 PCE. 886 In the case when policy is only applied at a PCC, the PCC must apply 887 all the types of required policies, for example user, service, server 888 and domain-specific policies. The PCC uses the policies to construct 889 a path computation request that appropriately represents the applied 890 policies. The request will necessarily be limited to the set of 891 "basic" (that is, non-policy capable) constraints explicitly defined 892 by the PCC-PCE communication protocol in use. 894 6.2. Policy Repositories 896 Within the policy-enabled path computation framework policy 897 repositories may be used in a single or multiple PC policy repository 898 configuration: 900 o) Single PC Policy Repository 902 In this configuration there is a single PC Policy Repository shared 903 between PCCs and PCEs. 905 ........................ 906 . . 907 . PC Policy Management . 908 . . 909 ........................ 910 . 911 . 912 --------- Policy a ---------------------- Policy b --------- 913 | PCC-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP | 914 --------- ---------------------- --------- 915 ^ ^ 916 | e.g., COPS e.g., COPS | 917 v v 918 --------- --------- 919 | PCC-PEP |<------------------------------------------->| PCE-PEP | 920 --------- PCC-PCE Communication Protocol --------- 922 Figure 9: Single PCC/PCE Policy Repository 924 o) Multiple PC Policy Repositories 926 The repositories in this case may be fully or partially synchronized 927 by some discovery/ synchronization management protocol or may be 928 completely independent. Note that the situation when PC Policy 929 Repository A exactly matches PC Policy Repository B, results in the 930 single PC Policy Repository configuration case. 932 -------------- -------------- 933 | PC Policy | | PC Policy | 934 ---| Repository A | | Repository B |--- 935 | -------------- -------------- | 936 | | 937 | Policy a Policy b | 938 | | 939 v v 940 --------- --------- 941 | PCC-PDP | | PCE-PDP | 942 --------- --------- 943 ^ ^ 944 | e.g., COPS e.g., COPS | 945 v v 946 --------- --------- 947 | PCC-PEP |<------------------------------------------->| PCE-PEP | 948 --------- PCC-PCE Communication Protocol --------- 950 Figure 10: Multiple PCE/PCC Policy Repositories 952 6.3. Cooperating PCE Configurations 954 The previous section shows the relationship between PCCs and PCEs. A 955 parallel relationship exists between cooperating PCEs, and, in fact, 956 this relationship can be viewed as the same as the relationship 957 between PCCs and PCEs. The one notable difference is that there will 958 be cases where having a shared PC Policy Repository will not be 959 desirable, for example, when the PCEs are managed by different 960 entities. Note that in this case it still remains necessary for the 961 policies to be consistent across the domains in order to identify 962 usable paths. The other notable difference is that a PCE, while 963 processing a path computation request, may need to apply requester- 964 specific (that is, client-specific) policies in order to modify the 965 request before sending it to other cooperating PCE(s). This 966 relationship is particularly important as the PCE Architecture allows 967 for configuration where all PCCs are not policy-enabled. 969 The following are example configurations. These examples do not 970 represent an exhaustive list and other configurations are expected. 972 o) Single Policy Repository 974 In this configuration there is a single PC Policy repository shared 975 between PCEs. This configuration is likely to be useful within a 976 single administrative domain where multiple PCEs are provided for 977 redundancy or load distribution purposes. 979 ........................ 980 . . 981 . PC Policy Management . 982 . . 983 ........................ 984 . 985 . 986 --------- Policy a ---------------------- Policy b --------- 987 | PCE-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP | 988 --------- ---------------------- --------- 989 ^ ^ 990 | e.g., COPS e.g., COPS | 991 v v 992 --------- --------- 993 | PCE-PEP |<------------------------------------------->| PCE-PEP | 994 --------- PCE-PCE Communication Protocol --------- 996 Figure 11: Single PCC Policy Repository 998 o) Multiple Policy Repositories 999 The repositories in this case may be fully or partially synchronized 1000 by some discovery/synchronization management protocol(s) or may be 1001 completely independent. In the multi-domain case it is expected that 1002 the repositories will be distinct, providing, however. consistent 1003 policies. 1005 -------------- -------------- 1006 | PC Policy | | PC Policy | 1007 ---| Repository A | | Repository B |--- 1008 | -------------- -------------- | 1009 | | 1010 | Policy a Policy b | 1011 | | 1012 v v 1013 --------- --------- 1014 | PCE-PDP | | PCE-PDP | 1015 --------- --------- 1016 ^ ^ 1017 | e.g., COPS e.g., COPS | 1018 v v 1019 --------- --------- 1020 | PCE-PEP |<------------------------------------------->| PCE-PEP | 1021 --------- PCC-PCE Communication Protocol --------- 1023 Figure 12: Multiple PCC Policy Repositories 1025 6.4. Policy Configuration Management 1027 The management of path computation policy information used by PCCs 1028 and PCEs is largely out of scope of the described framework. The 1029 framework assumes that such information is installed, removed and 1030 otherwise managed using typical policy management techniques. Policy 1031 Repositories may be populated and managed via static configuration, 1032 standard and proprietary policy management tools, or even dynamically 1033 via policy management/discovery protocols and applications. 1035 7. Inter-Component Communication 1037 7.1. Policy Communication 1039 Flexibility in the application of policy types is imperative from the 1040 architecture perspective. However, this commodity implies added 1041 complexity on the part of the PCE related communication protocols. 1043 One added complexity is that PCE communication protocols must carry 1044 certain information to support various policy types that may be 1045 applied. For example, in the case where policy is only applied at a 1046 PCE, a PCC-PCE request must carry sufficient information for the PCE 1047 to apply service or user-specific policies. This does imply that a 1048 PCC must have sufficient understanding of what policies can be 1049 applied at the PCE. Such information may be obtained via local 1050 configuration, static coding or even via a PCE discovery mechanism. 1051 The PCC must also have sufficient understanding to properly encode 1052 the required information for each policy type. 1054 Another added complexity is that PCE communication protocols must 1055 also be able to carry information that may result from a policy 1056 decision. For example, user or service-specific policy applied at a 1057 PCC may result in policy related information that must be carried 1058 along with the request for use by a PCE. This complexity is 1059 particularly important as it may be used to introduce new path 1060 computation parameters (e.g., constraints, objection functions, etc.) 1061 without modification of the core PCC and PCE. This communication will 1062 likely simply require the PCE communication protocols to support 1063 opaque policy related information elements. 1065 A final added complexity is that PCE communication protocols must 1066 also be able to support updated or unsolicited responses from a PCE. 1067 For example, changes in PCE policy may force a change to a previously 1068 provided path. Such updated or unsolicited responses may contain 1069 information that the PCC must act on, and may contain policy 1070 information that must be provided to a PCC. 1072 PCC-PEP and PCE-PEP or a pair of PCE-PEPs communicate via a request- 1073 response type PCC-PCE Communication Protocol. This document makes no 1074 assumptions as to what exact protocol is used to support this 1075 communication. This document does assume that the semantics of a 1076 path computation request are sufficiently abstract and general, and 1077 support both PCE-PCC and PCE-PCE communication. 1079 From a policy perspective, a path computation request should include 1080 at a minimum: 1081 o One or more source addresses; 1082 o One or more destination addresses; 1083 o Computation type (P2P, P2MP, MP2P, etc.); 1084 o Number of required paths; 1085 o Zero or more policy descriptors in the following format: 1086 , 1087 , , ,..., 1088 , , ,..., 1089 ... 1090 , , ,..., 1092 A successful path computation response, at minimum, should include 1093 the list of computed paths and may include policies (in the form of 1094 policy descriptors as in path computation request, see above) for use 1095 in evaluating and otherwise applying the computed paths. 1097 PCC-PCE Communication Protocol provides transport for policy 1098 information and should not understand nor make any assumptions about 1099 the semantics of policies specified in path computation requests and 1100 responses. 1102 Note: This document explicitly allows for (but does not require) the 1103 PCC to decide that all necessary constraints, objective functions, 1104 etc. pertinent to the computation of paths for the service in 1105 question are to be determined by the PCE performing the computation. 1106 In this case the PCC will use a set of policies (more precisely, 1107 PCPIM policy variables) describing the service-specific information. 1108 These policies may be placed within the path computation request and 1109 delivered to the PCE via a PCC-PCE communication protocol. The PCE 1110 (more precisely, PCE-PEP) is expected to understand this information 1111 and use it to determine the constraints and optimization functions 1112 applying local policies (that is, policies locally configured or 1113 provided by the associated PCE-PDP(s)). 1115 7.2. PCE Discovery Policy Considerations 1117 Dynamic PCE discovery allows for PCCs and PCEs to automatically 1118 discover a set of PCEs (including information required for the PCE 1119 selection). It also allows for PCCs and PCEs to dynamically detect 1120 new PCEs or any modification of PCEs status. Policy can be applied in 1121 two ways in this context: 1123 1. Restricting the scope of information distribution for the 1124 mandatory set of information (in particular the PCE presence 1125 and location). 1127 2. Restricting the type and nature of the optional information 1128 distributed by the discovery protocol. The latter is also 1129 subject to policy since the PCE architecture allows for 1130 distributing this information using either PCE discovery 1131 protocol(s) or PCC-PCE communication protocol(s). One important 1132 policy decision in this context is the nature of the information 1133 to be distributed, especially, when this information is not 1134 strictly speaking a "discovery" information, rather, the PCE 1135 state changes. Client-specific and domain-specific policies may 1136 be applied when deciding whether this information should be 1137 distributed and to which clients of the path computation service 1138 (that is, which PCCs and/or PCEs) 1140 Another place where policy applies is at the administrative 1141 boundaries. In multi-domain networks multiple PCEs will communicate 1142 with each other and across administrative boundaries. In such cases, 1143 domain-specific polices would be applied to 1) filter the information 1144 exchanged between peering PCEs during the discovery process (to the 1145 bare minimum in most cases if at all allowed by the security policy) 1146 and 2) limit the content of information being passed in path 1147 computation request and responses. 1149 8. Path Computation Sequence of Events 1151 This section presents a non-exhaustive list of representative 1152 scenarios. 1154 8.1. Policy-enabled PCC, Policy-enabled PCE 1156 When a GMPLS LSR receives a Setup (RSVP Path) message from an 1157 upstream LSR, the LSR may decide to use a remote Path Computation 1158 Entity. The following sequence of events occurs in this case: 1160 - A PCC-PEP co-located with the LSR applies the service-specific 1161 policies to select a PCE for the service path computation as 1162 well as to build the path computation request (that is, to 1163 select a list of policies, their variables, conditions and 1164 actions expressing constraints, diversities, objective functions 1165 and relaxation strategies appropriate for the service path 1166 computation). The policies may be: 1168 a) Statically configured on the PCC-PEP; 1170 b) Communicated to the PCC-PEP by a remote or local PCC-PDP 1171 via protocol such as COPS either pro-actively (most of the 1172 cases) or upon an explicit request by the PCC-PEP in case when 1173 some specifics of the new service have not been covered yet by 1174 the policies so far known to the PCC-PEP) 1176 The input for the decision process on the PCC-PEP is the 1177 information found in the signaling message as well as any other 1178 service-specific information such as port ID over which the message 1179 was received, associated VPN ID, the reference point type (UNI, E- 1180 NNI, etc.) and so forth. After the path computation request is 1181 built it is sent directly to the PCE-PEP using the PCC-PCE 1182 Communication Protocol. 1184 - PCE-PEP validates and otherwise processes the request applying 1185 the policies found in the request as well as client and domain 1186 specific polices. The latter, again, may be either statically 1187 configured on the PCE-PEP or provided by the associated local or 1188 remote PCE-PDP via a protocol such as COPS. The outcome of the 1189 decision process is the following information: 1191 a) Whether the request should be satisfied, rejected or 1192 dismissed. 1194 b) The sets of sources and destinations for which paths should 1195 be locally computed. 1197 c) The set of constraints, diversities, optimization functions 1198 and relaxations to be considered in each of locally performed 1199 path computation. 1201 d) The address of the next-in-chain PCE. 1203 e) The path computation request to be sent to the 1204 next-in-chain PCE. 1206 The PCE-PEP instructs a co-located path computation engine to 1207 perform the local path computation(s) and, if necessary, sends the 1208 path computation request to the next-in-chain PCE using a PCC-PCE 1209 Communication Protocol. Then it waits for the responses from the 1210 local path computation engine and the remote PCE, combines the 1211 resulting paths and sends them back to the PCC-PEP using the PCC- 1212 PCE Communication Protocol. The response contains the resulting 1213 paths as well as policies describing some additional information 1214 (for example, which of constraints were honored, which were 1215 dismissed and which were relaxed and in what way) 1217 - PCC-PEP instructs the signaling sub-system of the GMPLS LSR to 1218 encode the received path(s) into the outgoing Setup message(s). 1220 8.2. Policy-ignorant PCC, Policy-enabled PCE 1222 This case parallels the previous example, but the user and service- 1223 specific policies should be applied at the PCE as the PCC is policy 1224 ignorant. Again, when a GMPLS LSR has received a Setup (RSVP Path) 1225 message from an upstream LSR, the LSR may decide to use a non co- 1226 located Path Computation Entity. The following sequence of events 1227 occurs in this case: 1229 - The PCC constructs a PCE request using information found in the 1230 signaling/provisioning message as well as any other service 1231 specific information such as port ID over which the message was 1232 received, associated VPN ID, the reference point type (UNI, E- 1233 NNI, etc.) and so forth. This information is encoded in the 1234 request in the form of policy variables. After the request is 1235 built it is sent directly to the PCE-PEP using a PCC-PCE 1236 Communication Protocol. 1238 - PCE-PEP validates and otherwise processes the request 1239 interpreting the policy variables found in the request and 1240 applying user, service- and also client- and domain- specific 1241 polices to build the actual path computation request. The 1242 policies, again, may be either statically configured on the 1243 PCE-PEP or provided by the associated local or remote PCE-PDP via 1244 a protocol such as COPS. The outcome of the decision process is 1245 the following information: 1247 a) Whether the request should be satisfied, rejected or 1248 dismissed. 1250 b) The sets of sources and destinations for which paths should 1251 be locally computed. 1253 c) The set of constraints, diversities, optimization functions 1254 and relaxations to be considered in each of locally performed 1255 path computation. 1257 d) The address of the next-in-chain PCE. 1259 e) The path computation request to be sent to the next-in- 1260 chain PCE. 1262 The PCE-PEP instructs a co-located path computation engine to 1263 perform the local path computation(s) and, if necessary, sends the 1264 path computation request to the next-in-chain PCE using the PCC-PCE 1265 Communication Protocol. Then it waits for the responses from the 1266 local path computation engine and the remote PCE, combines the 1267 resulting paths and sends them back to the PCC-PEP using the PCC- 1268 PCE Communication Protocol. The response contains the resulting 1269 paths as well as policies describing some additional information 1270 (for example, which of constraints were honored, which were 1271 dismissed and which were relaxed and in what way) 1273 - PCC-PEP instructs the signaling sub-system of the GMPLS LSR to 1274 encode the received path(s) into the outgoing Setup message(s). 1276 9. Introduction of New Constraints 1278 An important aspect of the policy-enable path computation framework 1279 discussed above is the ability to introduce new constraints with 1280 minimal impact. In particular, only those components and mechanisms 1281 that will use a new constraint need to be updated in order to support 1282 the new constraint. Importantly, those components and mechanisms that 1283 will not use the new constraint, must not require any change in order 1284 for the new constraint to be utilized. For example, the PCE 1285 communication protocols must not require any changes to support new 1286 constraints. Likewise, PCC and PCEs that will not process new 1287 constraints must not require any modification. 1289 Consider the case where a PCE has been upgraded with software 1290 supporting optical physical impairment constraint, such as 1291 Polarization Mode Dispersion (PMD), that previously was not supported 1292 in the domain. In this case, one or more new policies will be 1293 installed in the PC Policy Repository (associated with the PCE) 1294 defining the constraint (rules that determine application criteria, 1295 set of policy variables, conditions, actions, etc.) and its 1296 relaxation strategy(ies). The new policies will be also propagated 1297 into other PC Policy Repositories within the domain via discovery and 1298 synchronization protocols or via local configuration. PCE-PDPs and 1299 PCC-PDPs will then retrieve the corresponding policies from the 1300 repository(ies). From then on PCC-PDPs will instruct associated PCC- 1301 PEPs to add the new policy information into path computation requests 1302 for services with certain parameters (for example, for services 1303 provisioned in the OCh layer). 1305 It is important to note that policy-enabled path computation model 1306 naturally solves the PCE capability discovery issues. Suppose a PCE 1307 working in a single PC Policy Repository configuration starts to 1308 support a new constraint. Once a corresponding policy installed in 1309 the repository, it automatically becomes available for all repository 1310 users, that is, PCCs. In the multi-repository case some policy 1311 synchronization must be provided, however, this problem is one of the 1312 management plane which is solved already. 1314 10. Security Considerations 1316 This document adds to the policy security considerations mentioned in 1317 [RFC4655]. In particular it is now necessary to consider the security 1318 issues related to policy information maintained in PC Policy 1319 Repositories and policy related transactions. The most notable 1320 issues, some of which are also listed in [RFC4655], are: 1322 - Unauthorized access to the PC Policy Repositories; 1323 - Interception of policy information when it is retrieved from 1324 the repositories and/or transported from PDPs to PEPs; 1326 - Interception of policy related information in path computation 1327 requests and responses; 1329 o Impersonation of user and client identities; 1331 o Falsification of policy information and/or PCE capabilities; 1333 o Denial of service attacks on policy related communication 1334 mechanisms. 1336 As with [RFC4655], it is expected that PCE solutions will address the 1337 PCE aspects of these issues in detail. 1339 11. Acknowledgments 1341 We would like to thank Bela Berde for fruitful discussions on PBM and 1342 Policy-driven path computation, Adrian Farrel for his detailed input. 1343 We would also like to thank Kobus Van der Merwe for providing 1344 insights and examples regarding PCE policy applications. 1346 12. IANA Considerations 1348 None. 1350 13. References 1352 13.1. Normative References 1354 [RFC2753] R. Yavatkar, D. Pendarakis, R. Guerin, A Framework for 1355 Policy Based Admission Control, RFC 2753, January 2000. 1357 [RFC2748] D. Durham, et al., The COPS (Common Open Policy Service) 1358 protocol, RFC 2748, IETF, January 2000. 1360 [RFC3060] B. Moore, et al., Policy Core Information Model -- 1361 Version 1 Specification, RFC 3060, February 2001. 1363 [RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP 1364 Tunnels", RFC 3209, December 2001. 1366 [RFC3460] Moore, B. Ed., "Policy Core Information Model (PCIM) 1367 Extensions", RFC 3460, January 2003. 1369 [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label 1370 Switching (GMPLS) Signaling Resource ReserVation 1371 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 1372 3473, January 2003. 1374 [RFC3644] Y. Snir, et al., Policy Quality of Service (QoS) 1375 Information Model, RFC 3644, November 2003. 1377 [RFC4216] Zhang, R., Vasseur, J-P., Eds., "MPLS Inter-Autonomous 1378 System (AS) Traffic Engineering (TE) Requirements", 1379 RFC4216, November 2005. 1381 [RFC4655] Farrel, A., Vasseur, JP., Ash, J., "Path Computation 1382 Element (PCE) Architecture", RFC 4655, August 2006. 1384 [RFC4927] Le Roux, J-L., Ed., "PCE Communication Protocol 1385 (PCECP) Specific Requirements for Inter-Area 1386 MPLS and GMPLS Traffic Engineering", June 2007. 1388 13.2. Informative References 1390 [DMTF] Common Information Model (CIM) Schema, version 2.x. 1391 Distributed Management Task Force, Inc. The components 1392 of the CIM v2.x schema are available via links on the 1393 following DMTF web page: 1394 http://www.dmtf.org/standards/standard_cim.php. 1396 [IRSCP] Van der Merwe, J., et. al., "Dynamic Connectivity 1397 Management with an Intelligent Route Service Control 1398 Point," ACM SIGCOMM Workshop on Internet Network 1399 Management (INM), Pisa, Italy, September 11, 2006. 1401 [RFC3031] Rosen, E,. Viswanathan, V. Callon, R., "Multiprotocol 1402 Label Switching Architecture", RFC 3031, January 2001. 1404 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 1405 K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. 1406 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 1407 RFC 3084, February 2001. 1409 [RFC3198] Westerinen, A., et al., "Terminology for Policy-Based 1410 Management", RFC 3198, November 2001. 1412 [RFC3630] Katz, D., Kompella, K., Yeung., D., "Traffic Engineering 1413 (TE) Extensions to OSPF Version 2", RFC 3630, September 1414 2003. 1416 [INTERAS-PCEP] Bitar, N., Zhang, R., Kumaki, K., Eds., "Inter-AS 1417 Requirements for the Path Computation Element 1418 Communication Protocol (PCECP)", February 2006. 1420 14. Authors' Addresses 1422 Igor Bryskin 1423 ADVA Optical 1424 7926 Jones Branch Drive 1425 Suite 615 1426 McLean, VA 22102 1427 Email: ibryskin@advaoptical.com 1429 Dimitri Papadimitriou (Alcatel) 1430 Fr. Wellesplein 1, 1431 B-2018 Antwerpen, Belgium 1432 Phone: +32 3 240-8491 1433 Email: dimitri.papadimitriou@alcatel.be 1435 Lou Berger 1436 LabN Consulting, LLC 1437 Phone: +1 301 468 9228 1438 Email: lberger@labn.net 1440 Jerry Ash 1441 AT&T 1442 Email: gash5107@yahoo.com 1444 Full Copyright Statement 1446 Copyright (C) The IETF Trust (2007). 1448 This document is subject to the rights, licenses and restrictions 1449 contained in BCP 78, and except as set forth therein, the authors 1450 retain all their rights. 1452 This document and the information contained herein are provided on an 1453 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1454 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1455 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1456 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1457 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1458 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1460 Intellectual Property 1462 The IETF takes no position regarding the validity or scope of any 1463 Intellectual Property Rights or other rights that might be claimed to 1464 pertain to the implementation or use of the technology described in 1465 this document or the extent to which any license under such rights 1466 might or might not be available; nor does it represent that it has 1467 made any independent effort to identify any such rights. Information 1468 on the procedures with respect to rights in RFC documents can be 1469 found in BCP 78 and BCP 79. 1471 Copies of IPR disclosures made to the IETF Secretariat and any 1472 assurances of licenses to be made available, or the result of an 1473 attempt made to obtain a general license or permission for the use of 1474 such proprietary rights by implementers or users of this 1475 specification can be obtained from the IETF on-line IPR repository at 1476 http://www.ietf.org/ipr. 1478 The IETF invites any interested party to bring to its attention any 1479 copyrights, patents or patent applications, or other proprietary 1480 rights that may cover technology that may be required to implement 1481 this standard. Please address the information to the IETF at ietf- 1482 ipr@ietf.org. 1484 Acknowledgement 1486 Funding for the RFC Editor function is provided by the IETF 1487 Administrative Support Activity (IASA). 1489 Generated on: Fri Oct 26 16:05:21 EDT 2007