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