idnits 2.17.1 draft-berger-pce-policy-architecture-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 833. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 87 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([PCE-ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 2005) is 6766 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3377 (Obsoleted by RFC 4510) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (Movaz Networks) 2 Category: Informational Igor Bryskin (Movaz Networks) 3 Expiration Date: April 2006 Dimitri Papadimitriou (Alcatel) 5 October 2005 7 PCE Policy Architecture 9 draft-berger-pce-policy-architecture-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 The PCE architecture [PCE-ARCH] introduces the concept of path 37 computation related policy at a high level. This document provides 38 additional details on policy as applied to the PCE architecture. 40 Contents 42 1 Introduction .............................................. 3 43 1.1 PCE Components ............................................ 3 44 1.2 Areas for Standardization ................................. 9 45 2 PCE Policy Architecture ................................... 10 46 2.1 Types of Policies ......................................... 10 47 2.1.1 User and Request Specific Policies ........................ 10 48 2.1.2 Client and Server Specific Policies ....................... 10 49 2.1.3 Local and Domain Specific Policies ........................ 11 50 2.2 Policy Application ........................................ 11 51 2.3 Policy Communication Support .............................. 13 52 2.4 PCE Discovery Policy Considerations ....................... 13 53 2.5 Policy Management ......................................... 14 54 3 Representative Policy Scenario ............................ 14 55 3.1 Scenario: Policy Configured Paths ......................... 15 56 3.2 Scenario: Provider Selection Policy ....................... 16 57 3.3 Scenario: Policy Based Constraints ........................ 17 58 4 Security Considerations ................................... 18 59 5 IANA Considerations ....................................... 19 60 6 References ................................................ 19 61 6.1 Normative References ...................................... 19 62 6.2 Informative References .................................... 19 63 7 Authors' Addresses ........................................ 20 64 8 Full Copyright Statement .................................. 20 65 9 Intellectual Property ..................................... 20 67 1. Introduction 69 The PCE architecture is introduced in [PCE-ARCH]. This document 70 describes the impact policy on the PCE architecture. Other 71 documents, for example [PCE-POL-COMMS], will provide implications on 72 more detailed aspects of PCE implementation. 74 Policy impacts multiple aspects of the PCE architecture. The first 75 is internal impact; the second is impact on PCE related 76 communication. 78 It is envisioned that policy will be largely applied as a local mater 79 within each PCE. That said, it is necessary to define the policy 80 models that the PCE architecture can support. Some example policies 81 include rejection of a request based on requesting PCC or identified 82 constraints, selection of a path based on the computation target, or 83 the selection of a path based on the time of day. The definition of 84 supported policy models will drive PCE solutions and will enable 85 proper and complete evaluation of specific PCE solutions. PCE 86 supported policy models are discussed later in this document. 88 While the implementation and enforcement of policy is largely a local 89 matter, the policies that may be applied impact the communication 90 protocols used to support PCE. This includes PCC-PCE, PCE-PCE and 91 PCE discovery communication. The primary impact is to the 92 information carried by the protocols. To a lesser degree, policy 93 support requirements may also drive the required protocol 94 transactions. As the more detailed requirements for each PCE 95 communication protocol is defined, it is important for these 96 documents to articulate supported (and unsupported) policy models and 97 the related requirements. Also, any defined solution must be 98 evaluated on its ability to support these policy models and 99 requirements. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 1.1. PCE Components 107 From a component perspective, PCE policy is supported via a Policy 108 Database. The Policy database provides non-TE information and is 109 used by a PCE when responding to a requested path computation. 110 Additionally, policy may also be used to govern what requests are 111 made to the PCE from a PCC. [PCE-ARCH] shows the PCE architecture 112 applied to four different node configurations. Figures 1 through 113 Figure 4 shows these configurations updated to reflect PCE Policy. 115 In each configuration, policy is consulted before a response is 116 provided by a PCE. A PCE may have local policy information that 117 impacts the one or more paths selected to satisfy a particular PCE 118 request. A local policy may be applied based on any information 119 provided from a PCC. The policy may have any number of results 120 including, for example, rejecting the request, identifying one or 121 more paths that provide different quality of service, or providing 122 one or more paths that have different costs, different end-to-end 123 delays or other different characteristics. Additionally, changes in 124 PCE policy may lead to a change to a previously provided path. 126 Another, important policy decision is the one related to the TED 127 selection. Indeed, the selection of the TED repository for the path 128 computation itself can be subject to policing. This means that this 129 document extends the PCE architecture by allowing the access point to 130 the PCE to be disjoint from the access point to the TED that will be 131 used for path computation purposes. This extension will likely 132 impact inter-PCE communication, and selection of a "next PCE" when 133 multiple PCEs are involved during the path computation. 135 Path computation related policy must also be sensitive to where it is 136 being applied. For example, a different set of policies may be 137 applied for an intra-area or single-layer PCE request, than would be 138 provided for an inter-area or multi-layer PCE request. 140 In each configuration, all policy decisions are made independently at 141 each PCE based on information passed from the previous PCE. 142 Alternatively, in the multiple PCE path computation with inter-PCE 143 communication configuration, see Figure 4, there is likely to be 144 explicit communication of policy information between PCEs. The type 145 of information conveyed to support policy will have significant 146 implications on what policies may be applied at each PCE. 148 Note that while the policy component is shown as co-resident, the 149 policy database may be implemented using some form of distributed 150 database. Such distributed approaches have no impact on the PCE 151 policy architecture and are therefore out of scope of this document. 153 ------------------------------ 154 | --------- | Routing ---------- 155 | | | | Protocol | | 156 | | TED |<-+----------+-> | 157 | | | | | | 158 | --------- | | | 159 | | | | | 160 | | Input | | | 161 | v | | | 162 | --------- --------- | | | 163 | | Policy | | | | | Adjacent | 164 | | Database|<-->| PCE | | | Node | 165 | | | | | | | | 166 | --------- --------- | | | 167 | ^ | | | 168 | |Request | | | 169 | |Response| | | 170 | v | | | 171 | --------- | | | 172 Service | | | | Signaling| | 173 Request | |Signaling| | Protocol | | 174 ------+---------------->| Engine |<-+----------+-> | 175 | | | | | | 176 | --------- | ---------- 177 ------------------------------ 179 Figure 1. Composite PCE Node 181 ---------------------- 182 | ----- | 183 | | TED |<-+------------> 184 | ----- | TED synchronization 185 | | | mechanism (e.g.,, routing protocol) 186 | | | 187 | v | 188 | ------ ----- | 189 | |Policy|<-->| PCE | | 190 | ------ ----- | 191 ---------------------- 192 ^ 193 | Request/ 194 | Response 195 v 196 Service ---------- Signaling ---------- 197 Request| Head-End | Protocol | Adjacent | 198 ---->| Node |<---------->| Node | 199 ---------- ---------- 201 Figure 2. External PCE Node 203 ------------------ ------------------- 204 | | | | 205 | PCE | | PCE | 206 | | | | 207 | ------ ----- | | ----- ------ | 208 | |Policy| | TED | | | | TED | |Policy| | 209 | ------ ----- | | ----- ------ | 210 ------------------ ------------------- 211 ^ ^ 212 | Request/ | Request/ 213 | Response | Response 214 v v 215 Service -------- Signaling ------------ Signaling ------------ 216 Request|Head-End| Protocol |Intermediate| Protocol |Intermediate| 217 ---->| Node |<--------->| Node |<--------->| Node | 218 -------- ------------ ------------ 220 Figure 3. Multiple PCE Path Computation 222 ------------------ ------------------ 223 | | Inter-PCE Request/Response | | 224 | PCE |<-------------------------->| PCE | 225 | | | | 226 | ------ ----- | | ------ ----- | 227 | |Policy| | TED | | | |Policy| | TED | | 228 | ------ ----- | | ------ ----- | 229 ------------------ ------------------ 230 ^ 231 | Request/ 232 | Response 233 v 234 Service ---------- Signaling ---------- Signaling ---------- 235 Request| Head-End | Protocol | Adjacent | Protocol | Adjacent | 236 ---->| Node |<---------->| Node |<---------->| Node | 237 ---------- ---------- ---------- 239 Figure 4. Multiple PCE Path Computation with Inter-PCE Communication 241 The PCE architecture allows for there to be multiple PCEs for a 242 number of reasons, including for redundancy or for distributed path 243 computation purposes. Independent of purpose, in the configurations 244 where multiple PCEs exist, the Policy Databases should be consistent 245 across the PCEs in order for a PCE request to be satisfied as 246 intended. The means by which such consistency is established is 247 viewed as a configuration issue. The policy configuration interface 248 is not specified or restricted by the PCE Policy Architecture. The 249 interface may be purely a local matter, or may be supported via a 250 standardized interface or policy distribution mechanism (e.g., MIB or 251 LDAP.) 253 Policy may also play a part in the selection of a PCE by a PCC when 254 multiple PCEs exists, see Figures 3 and 4. Policy may also influence 255 a request made by a PCC to a PCE. Figure 5, shows the PCC components 256 used to support the application of such policy. Note Figure 5 also 257 allows for multiple PCEs. 259 ---------------------- 260 | ----- | 261 | | TED |<-+------------> 262 | ----- | TED synchronization 263 | | | mechanism (e.g., routing protocol) 264 | | | 265 | v | 266 | ------ ----- | Inter-PCE Request/Response 267 | |Policy|<-->| PCE |<.+...........> (when present) 268 | ------ ----- | 269 ---------------------- 270 ^ 271 | Request/ 272 | Response 273 v 274 Service ------------- Signaling 275 Request|[PCC][Policy]| Protocol 276 ...--->| Node |<----.... 277 or Signaling ------------- 278 Protocol 280 Figure 5: Policy Enabled PCC 282 As stated in [PCE-ARCH], the PCC is not necessarily an LSR. Policy 283 also is applied in such configurations. The example shown in [PCE- 284 ARCH] is of an NMS. Figure 6 shows this example updated to support 285 policy. 287 ---------------------- 288 | ----- | 289 Service | | TED |<------------+------------> 290 Request | ----- | TED synchronization 291 | | | | mechanism (e.g., 292 v | | | routing protocol) 293 ------------- Request/ | v | 294 | | Response| ----- ------ | 295 | NMS |<--------+->| PCE |<-->|Policy| | 296 | | | ----- ------ | 297 ------------- ---------------------- 298 Service | 299 Request | 300 v 301 ---------- Signaling ---------- 302 | Head-End | Protocol | Adjacent | 303 | Node |<---------->| Node | 304 ---------- ---------- 306 Figure 6. Management-based PCE Usage 308 1.2. Areas for Standardization 310 The following areas require standardization within the PCE policy 311 architecture: 313 - Communication between PCCs and PCEs, and between cooperating 314 PCEs, including the definition of policy related information 315 communication. 317 - Communication of policy related information dissemination e.g. as 318 part of the PCE discovery or some other communication process. 320 - Definition of metrics to evaluate policy support of path 321 computation models. The focal point of this effort is to evaluate 322 potential solutions to the Policy aspects of the PCE architecture. 324 - MIB modules related to policy support. 326 - Configuration related support for policy databases. 328 2. PCE Policy Architecture 330 This section provides definitions and other aspects related to the 331 support of policy by the PCE architecture. 333 2.1. Types of Policies 335 For the purposes of PCE, we breakdown policy into multiple 336 categories: user specific, request specific, client specific, server 337 specific and domain specific. 339 2.1.1. User and Request Specific Policies 341 User specific policies are policies that use as conditions user or 342 service specified information. Examples of such information includes 343 the contents of objects of a signaling or provisioning message, port 344 ID over which the message was received, VPN ID, reference point type, 345 or even the identity of the user initiating the request. User 346 specific policies could be applied while building a path computation 347 request. For example, Service A may require two SRLG disjoint paths 348 for building end-to-end recovery scheme, while for service B link- 349 disjoint paths may be sufficient. Alternatively, service A may need 350 paths with minimal end-to-end delay, while service B may be looking 351 for shortest (minimal-cost) paths. A final example is that different 352 constraint relaxation strategies could be applied while computing 353 paths for service A and for service B. 355 Request specific policies are policies that use as conditions 356 information found in a path computation request. Examples of request 357 specific policies include constraints, diversities, constraint and 358 diversity relaxation strategies, and optimization functions. 359 Request-specific policies directly affect the path selection process 360 because they specify which links, nodes, path segments and/or paths 361 that are not acceptable or, on the contrary, may be desirable to 362 appear in the resulting paths. 364 2.1.2. Client and Server Specific Policies 366 Client specific policies are policies that use as a condition the 367 requesting Path Computation Client (PCC) or, in the inter-PCE 368 requesting case, a requesting Path Computation Engine (PCE). A PCE 369 may take specific action depending on the identity of the requester. 370 Some examples are the PCE may choose to drop or relax certain 371 specified constraints or impose additional ones, select an algorithm 372 or heuristic for the path computation, decide whether cooperation of 373 other PCEs are needed and whether explicit resulting paths should be 374 generated or loose ones are sufficient. 376 Server specific policies are policies that are associated with a 377 particular Path Computation Engine and applied at a PCC or at a PCE 378 initiating a inter-PCE request. A PCC or PCE may take specific 379 action depending on the identity of the identity of the PCE to which 380 it may make a request. One examples of this is that a requester may 381 select a PCE based on its capabilities. Another example is that a 382 requester may include different information in a path computation 383 request based on the capabilities of a specific PCE. Capabilities in 384 this context mean the ability of a PCE to provide specific functions, 385 such as support for certain path computation constraints or 386 optimization functions, method of PCE related communication 387 authentication, or billing. 389 2.1.3. Local and Domain Specific Policies 391 Local specific policies are policies that use as a condition the ID 392 the PCC acting on behalf one (or more) LSRs. These policies uses 393 conditions that are specific to the PCC to which they apply. In a 394 network including multiple PCCs these conditions can be applied 395 independently of the policies applying to the other PCC policies. 397 Domain specific policies are policies that use as a condition the ID 398 of a path computation domain the requesting PCC belongs to and/or IDs 399 of domains the resulting paths go through. These policies have the 400 same affect on the path computation process as client specific 401 policies with the difference that they could be associated 402 with/applied for a group of clients rather than individual clients. 403 One example of domain-specific policy is a policy restricting which 404 information a PCE should publish within a given domain. In such a 405 case, PCEs in some domains may advertise just its presence while 406 others may advertise details regarding its capabilities, client 407 authentication process, billing, and computation resource 408 availability. 410 2.2. Policy Application 412 The PCE policy architecture supports policy being applied at a PCC 413 and at a PCE. While the architecture supports policy being applied 414 at both, there is no requirement for policy to always being applied 415 at both or even at either. The use of policy in a network, on PCCs 416 and on PCEs, is specific network design choice. Some networks may 417 choose to apply policy only at PCCs, some may choose to only apply 418 policies at PCEs, and others will may choose to apply policies at 419 both. Regardless of how policy is applied, as previously mentioned, 420 it must be applied in a consistent fashion in order to achieve the 421 results intended. 423 Section 1.1 shows some possible example configurations of where 424 policy can be applied within the PCE architecture. Figures 1 through 425 6 show policy being applied at a PCE. Figure 5 shows policy being 426 applied at both a PCC and a PCE. 428 Along with supporting a flexibility in where policy may be applied, 429 the PCE policy architecture is also flexible in terms of where 430 specific types of policies may be applied. Also the PCE policy 431 architecture allows for the application of only a subset of policy 432 types. Section 2.1 defines multiple types of policies. Each of 433 these may be applied at either a PCC or a PCE. Clearly when policy 434 is only applied at PCCs or at PCEs, all policy types used in a 435 network must be applied at those locations. 437 In the case when policy is only applied at a PCE, it is expected that 438 the PCC will pass to the PCE all information about the service that 439 it could gather in the path computation request, most likely in the 440 form of policy information. The PCE is expected to understand this 441 policy information and apply appropriate policies while defining the 442 actual parameters of the path computation to be performed. Note that 443 in this case, the PCC cannot use local or server policy information 444 to select a PCE. 446 When applying policy at both PCCs and PCEs, it is necessary to select 447 which types of policies are applied at each. In such configurations, 448 it is likely that the application of policy types will be distributed 449 across PCCs and PCEs rather than applying all types at both. 450 Particularly for those policy types that apply to the role being 451 performed by the component. For example, user specific, server 452 specific and request specific policies may be applied at PCCs, domain 453 specific policies may be applied at PCEs and client specific policies 454 may be applied at both. Client specific policies may also be 455 relative to the location where the policy is applied, i.e., at the 456 PCC the client is the service requester, while at the PCE the client 457 is the requesting PCC or PCE. 459 In the case when policy is only applied at a PCC, the PCC must apply 460 all the types of required policies, for example user, service, and 461 domain-specific policies. The PCC uses the policies to construct a 462 path computation request that appropriately represents the applied 463 policies. The request will necessarily be limited to the set of 464 "basic", non-policy capable, constraints explicitly defined by the 465 PCC-PCE communication protocol. 467 2.3. Policy Communication Support 469 The described PCE policy architecture allows for a fair bit of 470 flexibility in where and in what types of policy is applied. This is 471 critical from the architecture perspective, but it does imply added 472 complexity on the part of the PCE related communication protocols. 474 The first added complexity is that the PCE communication protocols 475 must carry sufficient information to support the types of policies 476 that may be applied. For example, in the case where policy is only 477 applied at a PCE, a PCC-PCE request must carry sufficient information 478 for the PCE to apply request or even user specific policies. This 479 does imply that a PCC must have sufficient understanding of what 480 policy types may be applied at a PCE. Such information may be 481 obtained via such approaches as configuration, static coding, or even 482 via a PCE discovery mechanism. The PCC must also have sufficient 483 understanding to properly encode the required information for each 484 type of policy. 486 The second added complexity is that the PCE communication protocols 487 must also be able to carry information that may result from a policy 488 decision. For example, user specific policy applied at a PCC may 489 result in policy related information that must be carried along with 490 the request for use by a PCE policy component. This complexity is 491 particularly important as it may be used to introduce new path 492 computation related constraints without modification of the core PCC 493 and PCE. This communication will likely simply require the PCE 494 communication protocol(s) to support opaque policy related 495 information elements. 497 The final added complexity is that the PCE communication protocols 498 must also be able to support updated or unsolicited responses from a 499 PCE. For example, changes in PCE policy may force a change to a 500 previously provided path. Such updated or unsolicited responses may 501 contain information that the PCC must act on, and may contain policy 502 (opaque) information that must be provided to a PCC's policy 503 component. 505 2.4. PCE Discovery Policy Considerations 507 Dynamic PCE discovery allows PCCs/PCEs to automatically discover a 508 set of PCEs, including information required for PCE selection, and to 509 dynamically detect new PCEs or any modification of PCE's information. 510 Policy can be applied in two ways in this context: 512 1. Restricting the scope of information distribution for the 513 mandatory set of information (in particular the PCE location). 515 2. Restricting the type and nature of the optional information 516 distributed by the discovery protocol. The latter is also subject to 517 policy since the PCE architecture allows for distributing this 518 information using either the discovery protocol or the specific PCC- 519 PCE communication protocol. Here the most important policy decision 520 is determined by the nature of the information to be discovered in 521 particular when this information is not strictly speaking a 522 "discovery" information, but a PCE state information exchange the 523 policy should allow for making use of the appropriate protocol to 524 exchange that information with the client PCC/PCE 526 Another level where policing applies is at the administrative 527 boundaries. This class of polices applies in particular when 528 multiple PCEs would have to communicate one each other and cross an 529 administrative boundary. In this context, several specific polices 530 would be applied to 1) filter the information exchanged with peering 531 PCEs during the discovery process (to the bare minimum in most cases 532 if at all allowed by the security policy) and 2) strictly limit the 533 exchange of information during path computation request/responses. 535 2.5. Policy Management 537 The management of policy information used at PCCs and PCEs is largely 538 out of scope of the PCE architecture. The architecture assumes that 539 such information is installed using typical policy management 540 techniques and are available for use by policy components co-resident 541 with PCCs and PCEs. The policy management techniques may be 542 statically configured, managed via an information or policy 543 management protocol, e.g., LDAPv3 [RFC3377], or even dynamically 544 established. 546 3. Representative Policy Scenario 548 This section provides some example of policy may be applied using the 549 PCE policy architecture. The intent of this section is to provide 550 several diverse examples of how policy may be applied within the PCE 551 architecture. Actual networks may use one of the scenarios 552 discussed, some combination of the presented scenarios, or other 553 scenarios not discussed. This section should not be viewed as 554 limiting other applications of policy within the PCE architecture. 556 [Authors' note: it is expected that this section will generate a 557 number of divergent views of how PCE policy may be applied within the 558 architecture. We view this as beneficial and that it is imperative 559 for the PCE policy architecture to be sufficiently flexible to 560 accommodate all views, and that each perspective be suitably 561 represented in this section.] 563 3.1. Scenario: Policy Configured Paths 565 A very simple usage scenario for PCE policy would be to use PCE to 566 centrally administer configured path. Configured paths are composed 567 of strict and loose explicit hops, EROs see [RFC3209], and are used 568 by one or more LSPs. Typically such paths are configured at the LSP 569 ingress. With PCE policy, an alternate approach is possible. 571 Using PCE policy, user specific policies can be created that will 572 provide a configured path for a specific user request. The user 573 request could be identified based on service parameters such as end- 574 points, requested service/QoS, or even a token that identifies the 575 end-user. The configured path would then be used as input to PCE 576 computation process. The PCE process would return any explicit 577 routes and expand all possible loose hops. 579 This described policy could be applied at either PCC or PCE, see 580 Figure 5. In the PCC case, the configured path would be expanded at 581 the PCC and then passed to the PCE along with the PCE request, 582 probably in the form of constraints. When applied at the PCE, the 583 configured path would be internally expanded and used. Both cases 584 require some method to configure and manage policies. In the PCC 585 case, the real benefit would come when there is an automated policy 586 distribution mechanism. 588 Policy configured paths can also be used in multiple PCE 589 environments, see Figures 3 and 4. For example, consider the case 590 where there is limited visibility and multiple PCEs are used to 591 resolve each region of visibility. In this example, it may not be 592 possible, or desirable to configure the whole explicit path on the 593 first PCE. What could be done, is to configure the explicit path for 594 each area of visibility with each responsible PCE. Each PCE would 595 then map an incoming request to the matching configured path. For 596 this example to work, it would likely be necessary to include the 597 exit point from, or the entry point into, each area of visibility. 598 Clearly, policy database consistent is also critical in this example. 600 3.2. Scenario: Provider Selection Policy 602 A more interesting usage scenario is applying policy to multi-domain, 603 multi-provider, networks. There a number of interesting applications 604 of policy in such networks. A rudimentary example is simple access 605 control, i.e., which users, clients or PCEs are permitted to request 606 inter-domain path computation. 608 A more interesting example is applying policy to select which domain, 609 or provider, is used to support a particular PCE request. Consider a 610 topology that has multiple transit networks, see Figure 7. In this 611 case, there are multiple transit networks available to provide a path 612 from a source domain to a destination (or target) domain. 613 Furthermore, each transit network may have one or more options for 614 reaching the target domain. Each domain may need to select which of 615 the multiple available paths can be used to satisfy a particular PCE 616 request. 618 Clear reachability is a base criteria for path selection, but policy 619 may be a more interesting and important criteria. For example 620 transit network A may be more expensive and provide lower delay or 621 loss than transit network C. Likewise, a transit network may wish to 622 treat PCE requests from its own customers differently than requests 623 from another provider. In both cases, computation based on traffic 624 engineering databases will result in multiple transit networks that 625 provide reachability, but policy can be used to dictate which PCE 626 requests get the better service. 628 +----------------+ 629 |Transit Domain A| +----------------+ 630 +----------------+ |Transit Domain D| 631 +------+ +----------------+ +----------------+ +------+ 632 |Source| |Transit Domain B| +----------------+ |Target| 633 |Domain| +----------------+ |Transit Domain E| |Domain| 634 +------+ +----------------+ +----------------+ +------+ 635 |Transit Domain C| +----------------+ 636 +----------------+ |Transit Domain F| 637 +----------------+ 639 Figure 7: Multi-domain network with multiple transit options 641 There are multiple options for differentiating which PCE requests use 642 a particular transit domain and get better service. For example, the 643 source domain may use user and client specific policies, to determine 644 the level of service to provide and use domain specific policies to 645 choose which transit domains are acceptable. A transit domain may 646 use a combination of client specific policies to determine if a 647 request is from a direct customer or another provider, and then use 648 domain specific policies to identify how the request should be 649 processed. 651 While this description presumes multiple PCEs, while envisioned to be 652 less common, it is also possible to apply provider selection policy 653 in single PCE environments. In this case, the single PCE will apply 654 all policies, (e.g., user, client and domain specific policies) to 655 determine the appropriate constraints for a particular PCE request. 657 While less likely, the described policy could be also applied at a 658 PCC. In the PCC case, the provider related policy would be expanded 659 at the PCC and then passed to the PCE along with the PCE request, 660 probably in the form of constraints. 662 Independent of the number of PCEs, or the application of policy at 663 PCCs, there must be some method to configure and manage policies 664 consistently. 666 It is also worth noting that this basic approach can also be used 667 within a domain to provide different paths and services based on 668 users, PCC, VPN ID, or even application. 670 3.3. Scenario: Policy Based Constraints 672 Another usage scenario is to use policy to provide additional 673 constraints for PCE request. Consider an LSR with a policy capable 674 PCC, as shown in Figure 5, which receives a signaling message via 675 signaling, including over a NNI or UNI reference point, or receives 676 configuration request over a management interface to establish a 677 service. The path(s) for LSP(s) that are needed to support the 678 service are not explicitly specified in the message/request; hence 679 path computation is needed. 681 In this case, the PCC may apply user or service specific policies to 682 decide how the path selection process should be constrained, that is, 683 which constraints, diversities, optimizations and relaxations should 684 be applied in order for the service LSP(s) to have a likelihood to be 685 successfully established and provide necessary QoS and resilience 686 against network failures. When deciding on the set of constraints 687 the PCC uses as an input all information it knows about the user and 688 service, including the contents of the received message, port ID over 689 which message was received, associated VPN ID, signaling/reference 690 point type, request time, etc. Once the constraints and other 691 parameters of the required path computation is determined, the PCC 692 generates a path computation request which includes the request- 693 specific policies that describe the determined set of constraints, 694 optimizations, and other parameters that describe how the request 695 must considered in the path computation process. 697 The PCC may also apply server specific policies for each of known, 698 i.e., discovered or configured, PCE in order to select which PCE to 699 use. The PCC may also use server specific policies to form the 700 request to match the PCE's capabilities so that the request will not 701 be rejected and so that it has a higher likelihood of being satisfied 702 in an efficient way. An example of modification as a result of a 703 server specific policy is to remove a constraint not supported by the 704 PCE. Once the policy processing is complete one the PCC, and the PCE 705 request resulting from the original service request is updated by the 706 policy processing, the request is sent to the PCE. 708 The PCE that receives the request validates and otherwise processes 709 the request applying the policies found in the request as well as any 710 policies that are applied at the PCE, e.g., client and domain 711 specific polices. As a result of the policy processing the PCE may 712 decide to reject the request. It also may decide to respond with one 713 or several pre-computed paths if user or client-specific polices 714 instruct the PCE to do so. If the PCE decides to satisfy the request 715 by performing a path computation, it determines if it needs the 716 cooperation of other PCEs and defines parameters for path 717 computations to be performed locally and remotely. After that the 718 PCE instructs a co-located path computation engine to perform the 719 local path computation(s) and, if necessary, sends path computation 720 request(s) to one or more other PCEs. It then waits for the 721 responses from the local path computation engine and, when used, the 722 remote PCE. It then combines the resulting paths and sends them back 723 to the requesting PCC. The response may represent policies 724 describing the resulting paths, their characteristics (summary cost, 725 expected end-to-end delay, etc.) as well as additional information 726 related to the request, e.g., which of constraints were honored, 727 which were dismissed and which were relaxed and in what way. 729 PCC processes the response and instructs the LSR to encode the 730 received path(s) into the outgoing signaling message(s). 732 4. Security Considerations 734 This document adds a policy dimension to the considerations mentioned 735 in [PCE-ARCH]. In particular it is now necessary to consider the 736 security of policy information and policy related transactions. The 737 most notable of these are: 739 - Interception of policy related information in PCE requests 740 and responses. 742 - Impersonation of user and client identities. 744 - Falsification of policy information or PCE capabilities. 746 - Denial of service attacks on policy related communication 747 mechanisms. 749 As with [PCE-ARCH], it is expected that PCE solutions will address 750 these issues in detail. 752 5. IANA Considerations 754 This document makes no requests to IANA. 756 6. References 758 6.1. Normative References 760 [PCE-ARCH] Farrel, A., Vasseur, JP., Ash, J., "Path Computation 761 Element (PCE) Architecture", July 2005. 763 6.2. Informative References 765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 766 Requirement Levels," RFC 2119. 768 [RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for 769 LSP Tunnels", RFC 3209, December 2001. 771 [RFC3377] Hodges, J., Morgan, R., "Lightweight Directory Access 772 Protocol (v3): Technical Specification", September 2002. 774 [PCE-POL-COMMS] Bryskin, I., Papadimitriou, D., Berger, L., 775 "Policy-Enabled Path Computation Communication 776 Requirements", October 2005. 778 7. Authors' Addresses 780 Lou Berger 781 Movaz Networks, Inc 782 Phone: +1 703-847-1801 783 Email: lberger@movaz.com 785 Igor Bryskin 786 Movaz Networks, Inc 787 Phone: +1 703-847-4208 788 Email: ibryskin@movaz.com 790 Dimitri Papadimitriou 791 Alcatel 792 Francis Wellensplein 1, 793 B-2018 Antwerpen, Belgium 794 Phone : +32 3 240 8491 795 Email: dimitri.papadimitriou@alcatel.be 797 8. Full Copyright Statement 799 Copyright (C) The Internet Society (2005). This document is subject 800 to the rights, licenses and restrictions contained in BCP 78, and 801 except as set forth therein, the authors retain all their rights. 803 This document and the information contained herein are provided on an 804 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 805 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 806 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 807 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 808 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 809 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 811 9. Intellectual Property 813 The IETF takes no position regarding the validity or scope of any 814 Intellectual Property Rights or other rights that might be claimed to 815 pertain to the implementation or use of the technology described in 816 this document or the extent to which any license under such rights 817 might or might not be available; nor does it represent that it has 818 made any independent effort to identify any such rights. Information 819 on the procedures with respect to rights in RFC documents can be 820 found in BCP 78 and BCP 79. 822 Copies of IPR disclosures made to the IETF Secretariat and any 823 assurances of licenses to be made available, or the result of an 824 attempt made to obtain a general license or permission for the use of 825 such proprietary rights by implementers or users of this 826 specification can be obtained from the IETF on-line IPR repository at 827 http://www.ietf.org/ipr. 829 The IETF invites any interested party to bring to its attention any 830 copyrights, patents or patent applications, or other proprietary 831 rights that may cover technology that may be required to implement 832 this standard. Please address the information to the IETF at ietf- 833 ipr@ietf.org. 835 Generated on: Mon Oct 17 00:29:11 EDT 2005