idnits 2.17.1 draft-ietf-pce-policy-enabled-path-comp-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 1288. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1299. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1312. ** 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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters 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 (July 2006) is 6495 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Igor Bryskin (Movaz Networks) 2 Category: Informational Dimitri Papadimitriou (Alcatel) 3 Expiration Date: January 2007 Lou Berger (LabN Consulting, LLC) 5 July 2006 7 Policy-Enabled Path Computation Framework 9 draft-ietf-pce-policy-enabled-path-comp-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 policy in 37 the context of path computation. This document provides additional 38 details on policy within the PCE Architecture and also provides 39 context for the support of PCE Policy. This document introduces the 40 use of the Policy Core Information Model (PCIM) as a framework for 41 supporting path computation policy. This document also provides 42 representative scenarios for the support of PCE Policy. 44 Contents 46 1 Terminology ............................................... 3 47 2 Introduction .............................................. 3 48 3 Background ................................................ 4 49 3.1 Motivations ............................................... 4 50 3.2 Representative Policy Scenarios ........................... 6 51 3.2.1 Scenario: Policy Configured Paths ......................... 6 52 3.2.2 Scenario: Provider Selection Policy ....................... 7 53 3.2.3 Scenario: Policy Based Constraints ........................ 8 54 4 Requirements .............................................. 10 55 5 Path Computation Policy Information Model (PCPIM) ......... 11 56 6 Policy-Enabled Path Computation Framework Components ...... 13 57 7 Policy Component Configurations ........................... 15 58 7.1 PCC-PCE Configurations .................................... 15 59 7.2 Policy Repositories ....................................... 17 60 7.3 Cooperating PCE Configurations ............................ 18 61 7.4 Policy Configuration Management ........................... 20 62 8 Inter-Component Communication ............................. 20 63 8.1 Policy Communication ..................................... 20 64 8.2 PCE Discovery Policy Considerations ....................... 22 65 9 Path Computation Sequence of Events ....................... 22 66 9.1 Policy-enabled PCC, Policy-enabled PCE .................... 23 67 9.2 Policy-ignorant PCC, Policy-enabled PCE ................... 24 68 10 Introduction of New Constraints ........................... 25 69 11 Security Considerations ................................... 26 70 12 Acknowledgements .......................................... 27 71 13 IANA Considerations ....................................... 27 72 14 References ................................................ 27 73 14.1 Normative References ...................................... 27 74 14.2 Informative References .................................... 28 75 15 Authors' Addresses ........................................ 28 76 16 Full Copyright Statement .................................. 29 77 17 Intellectual Property ..................................... 29 78 Conventions used in this document 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 1. Terminology 86 The reader is assumed to be familiar with the following terms: 87 CSPF: Constraint-based Shortest Path First, see [RFC3630]. 88 LSP: Label Switched Path, see [RFC3031]. 89 LSR: Label Switching Router, see [RFC3031]. 90 PCC: Path Computation Client, see [PCE-ARCH]. 91 PCE: Path Computation Element, see [PCE-ARCH]. 92 TE LSP: Traffic Engineering MPLS Label Switched Path, see 93 [RFC3209] and [RFC3473]. 94 CIM: Common Information Model, see [DMTF]. 95 PCIM: Policy Core Information Model, see [RFC3060]. 96 PC: Path Computation. 97 PCCIM: Path Computation Core Information Model. 98 QPIM: QoS Policy Information Model, see [RFC3644]. 99 PBM: Policy-based Management, see [RFC3198]. 100 PEP: Policy Enforcement Points, see [RFC2753]. 101 PDP: Policy Decision Points, see [RFC2753]. 102 COPS: Common Open Policy Service, see [RFC2748]. 103 COPS-PR: COPS Usage for Policy Provisioning, see [RFC3084]. 105 2. Introduction 107 The PCE architecture is introduced in [PCE-ARCH]. This document 108 describes the impact of policy on the PCE architecture and provides 109 additional details on, and context for, policy within the PCE 110 Architecture. 112 Policy-based Management (PBM) enables network administrators to 113 operate in a high-level manner through rule-based policies; the 114 latter are translated automatically into individual device 115 configuration directives, aimed at controlling a network as a whole. 116 Two IETF Working Groups have considered policy networking in the 117 past: The Resource Allocation Protocol working group and the Policy 118 Framework working group. 120 A framework for policy-based admission control [RFC2753] was defined 121 and a protocol for use between Policy Enforcement Points (PEP) and 122 Policy Decision Points (PDP) was specified: Common Open Policy 123 Service (COPS) [RFC2748]. This document uses the terms PEP and PDP to 124 refer to the functions defined in the COPS context. This document 125 makes no assumptions nor requires that the actual COPS protocol be 126 used. 128 The IETF has also produced a general framework for representing, 129 managing, sharing, and reusing policies in a vendor independent, 130 interoperable, and scalable manner. It has also defined an extensible 131 information model for representing policies, called the Policy Core 132 Information Model (PCIM) [RFC3060], and an extension to this model to 133 address the need for QoS management, called the QoS Policy 134 Information Model (QPIM) [RFC3644]. However, additional mechanisms 135 are needed in order to specify policies related to the path 136 computation logic as well as its control. 138 This document introduces PCIM as a core component in a framework for 139 providing policy-enabled path computation. This document also covers 140 the other aspects of the framework. It also discusses related 141 background to provide a context for this work. Specific PCIM 142 definition to support path computation will be discussed in a 143 separate document. 145 3. Background 147 This section provides some general background on the use of policy 148 within the PCE architecture. It presents some rational behind the use 149 of policy, as well as representative policy usage scenarios. This 150 information is intended to provide context for the presented policy 151 framework. This section does not attempt to present an exhaustive 152 list of rational or scenarios. 154 3.1. Motivations 156 The PCE architecture is introduced in [PCE-ARCH]. It includes policy 157 as an integral part of the PCE architecture. This section presents 158 some of the rational for this inclusion. 160 Network operators require a certain level of flexibility to shape the 161 TE path computation process, so that the process can be aligned with 162 their business and operational needs. Many aspects of the path 163 computation may be governed by policies. For example, a PCC may use 164 policies configured by the operator to decide which optimizations, 165 constraints, diversities and their relaxation strategies to request 166 while computing path(s) for a particular service. Depending on SLAs, 167 TE and cost/performance ratio goals, path computation requests may be 168 built differently for different services. Service A, for instance, 169 may require two SRLG-disjoint paths for building end-to-end recovery 170 scheme, while for service B link-disjoint paths may be sufficient. 171 Service A may need paths with minimal end-to-end delay, while service 172 B may be looking for shortest (minimal-cost) paths. Different 173 constraint relaxation strategies may be applied while computing paths 174 for service A and for service B, and so forth. 176 Likewise, a PCE may apply policies to decide which algorithm or 177 algorithms to use while performing path computations requested from a 178 particular PCC or for a particular domain, see [PCECP-IA-REQ]; 179 whether to seek the cooperation of other PCEs to satisfy a particular 180 request or to handle a request on its own (possibly responding with 181 non explicit paths); or how the request should be modified before 182 being sent to other member(s) of a group of cooperating PCEs, etc. 184 Additional motivations for supporting policy within the PCE 185 architecture can be described as follows. Historically, a path 186 computation entity was an intrinsic part of an LSR's control plane 187 and always co-located with the LSR's signaling and routing 188 subsystems. This approach allowed for unlimited flexibility in 189 providing various path computation enhancements, such as: adding new 190 types of constraints, diversities and their relaxation strategies, 191 adopting new objective functions and optimization criterions, etc. 192 All that had to be done to support an enhancement was to upgrade the 193 control plane software of a particular LSR (and no other LSRs or any 194 other network elements). 196 With the introduction of the PCE architecture, the introduction of 197 new PCE capabilities becomes more complicated: it isn't enough for a 198 PCE to upgrade its own software. In order to take advantage of a 199 PCE's new capabilities, new advertising and signaling objects may 200 need to be standardized, all PCCs may need to be upgraded with new 201 software, and new interoperability problems may need to be resolved, 202 etc. 204 Within the context of the PCE architecture, it is therefore highly 205 desirable to find a way to introduce new path computation 206 capabilities without requiring modifying either the 207 discovery/communication protocols or PCC software. One way to achieve 208 this objective is to consider path selection constraints, their 209 relaxations and objective functions, as path computation request 210 specific policies. Furthermore that such policies may, on one hand, 211 be configured and managed by an operator as any other policies or, on 212 the other hand, may be interpreted in real time by PCCs and PCEs. 214 There are a number of advantages and useful by-products of such an 215 approach: 217 - New path computation capabilities may be introduced without 218 changing PCE-PCC communication and discovery protocols or PCC 219 software. Only the PCE module providing the path computation 220 capabilities (referred in this document as path computation 221 engine) needs to be updated. 223 - Existing constraints, objective functions and their relaxations 224 may be aggregated and otherwise associated together, thus, 225 producing new more complex ones that do not require change of 226 code even on PCEs supporting them. 228 - Different elements such as conditions, actions, variables, 229 etc. may be re-used by multiple constraints, diversities, and 230 optimizations. 232 - PCCs and PCEs need to handle other (that is, not request 233 specific) policies. Path computation related policies of all 234 types can be placed within the same policy repositories, can be 235 managed by the same policy management tools and can be 236 interpreted using the same mechanisms. Also policies need to be 237 supported by PCCs and PCEs independently from peculiarities of a 238 specific PCC-PCE communication protocol. Thus, introducing a new 239 (request specific) type of policies describing constraints and 240 other elements of a path computation request will be a natural 241 and relatively inexpensive addition to the policy-enabled path 242 computation architecture. 244 3.2. Representative Policy Scenarios 246 This section provides example scenarios of how policy may be applied 247 using the PCE policy framework within the PCE architecture context. 248 Actual networks may use one of the scenarios discussed, some 249 combination of the presented scenarios or other scenarios (not 250 discussed). This section should not be viewed as limiting other 251 applications of policy within the PCE architecture. 253 3.2.1. Scenario: Policy Configured Paths 255 A very simple usage scenario for PCE policy would be to use PCE to 256 centrally administer configured paths. Configured paths are composed 257 of strict and loose hops in the form of EROs (see [RFC3209]), and are 258 used by one or more LSPs. Typically such paths are configured at the 259 LSP ingress. In the context of policy-enabled path computation, an 260 alternate approach is possible. 262 In particular, service specific policies can be installed that will 263 provide configured path(s) for a specific service request. The 264 request may be identified based on service parameters such as end- 265 points, requested QoS or even a token that identifies the end-user. 266 The configured path(s) would then be used as input to PCE computation 267 process, which would return explicit routes by expanding of all 268 specified loose hops. 270 The described policies may be applied at either PCC or PCE, see 271 Figure 5. In the PCC case, the configured path would be processed at 272 the PCC and then passed to the PCE along with the PCE request, 273 probably in the form of (inclusion) constraints. When applied at the 274 PCE, the configured path would be used locally. Both cases require 275 some method to configure and manage policies. In the PCC case, the 276 real benefit would come when there is an automated policy 277 distribution mechanism. 279 Policy-configured paths may also be used in multiple PCE environments 280 (see Figures 7 and 8). For example, consider the case when there is 281 limited TE visibility and independent PCEs are used to determine 282 path(s) within each area of the TE visibility. In such a case, it may 283 not be possible (or desirable) to configure entire explicit path(s) 284 on a single PCE. However, it is possible to configure explicit 285 path(s) for each area of the TE visibility and each responsible PCE. 286 One by one, the PCEs would then map an incoming signaling request to 287 appropriate configured path(s). Note that to make such scenario work 288 it would likely be necessary to start and finish the configured paths 289 on TE domain boundary nodes. Clearly, consistent PC Policy 290 Repositories are also critical in this example. 292 3.2.2. Scenario: Provider Selection Policy 294 A potentially more interesting usage scenario is applying PC policies 295 in multi-domain multi-provider networks. There are numerous 296 interesting policy applications in such networks. A rudimentary 297 example is simple access control, that is, deciding which clients are 298 permitted to request inter-domain path computation. 300 A more complicated example is applying policy to determine which 301 domain or provider network will be used to support a particular PCE 302 request. Consider the topology presented in Figure 1. In this example 303 there are multiple transit networks available to provide a path from 304 a source domain to a destination domain. Furthermore, each transit 305 network may have one or more options for reaching a particular 306 domain. Each domain will need to select which of the multiple 307 available paths will be used to satisfy a particular PCE request. 309 Clearly, TE reachability, availability and optimality are the basic 310 criterions for path selection, however, policies can provide an 311 important added consideration in the decision process. For example, 312 transit network A may be more expensive and provide lower delay or 313 loss than transit network C. Likewise, a transit network may wish to 314 treat PCE requests from its own customers differently than requests 315 from other providers. In both cases, computation based on traffic 316 engineering databases will result in multiple transit networks that 317 provide reachability, and policies can be used to govern which PCE 318 requests get better service. 320 +----------------+ 321 |Transit Domain A| +----------------+ 322 +----------------+ |Transit Domain D| 323 +------+ +----------------+ +----------------+ +------+ 324 |Source| |Transit Domain B| +----------------+ |Target| 325 |Domain| +----------------+ |Transit Domain E| |Domain| 326 +------+ +----------------+ +----------------+ +------+ 327 |Transit Domain C| +----------------+ 328 +----------------+ |Transit Domain F| 329 +----------------+ 331 Figure 1: Multi-domain network with multiple transit options 333 There are multiple options for differentiating which PCE requests use 334 a particular transit domain and get a particular (better or worse) 335 level of service. For example, a PCE in the source domain may use 336 user and request specific policies to determine the level of service 337 to provide. A PCE in the source domain may also use domain specific 338 policies to choose which transit domains are acceptable. A PCE in a 339 transit domain may use request specific policies to determine if a 340 request is from a direct customer or another provider, and then use 341 domain specific policies to identify how the request should be 342 processed. 344 3.2.3. Scenario: Policy Based Constraints 346 Another usage scenario is the use of policy to provide new 347 constraints in a PCE request. Consider an LSR with a policy enabled 348 PCC, as shown in Figure 3, which receives a service request via 349 signaling, including over a NNI or UNI reference point, or receives a 350 configuration request over a management interface to establish a 351 service. In either case the path(s) needed to support the service are 352 not explicitly specified in the message/request, and hence path 353 computation is needed. 355 In this case, the PCC may apply user or service specific policies to 356 decide how the path selection process should be constrained, that is, 357 which constraints, diversities, optimizations and relaxations should 358 be applied in order for the service LSP(s) to have a likelihood to be 359 successfully established and provide necessary QoS and resilience 360 against network failures. When deciding on the set of constraints the 361 PCC uses as an input all information it knows about the user and 362 service, such as the contents of the received message, port ID over 363 which message was received, associated VPN ID, signaling/reference 364 point type, request time, etc. Once the constraints and other 365 parameters of the required path computation are determined, the PCC 366 generates a path computation request which includes the request- 367 specific policies that describe the determined set of constraints, 368 optimizations, and other parameters that indicate how the request is 369 to be considered in the path computation process. 371 The PCC may also apply server specific policies for each of the known 372 (i.e., discovered or configured) PCEs in order to select which PCE to 373 use. The PCC may also use server specific policies to form the 374 request to match the PCE's capabilities so that the request will not 375 be rejected and has a higher likelihood of being satisfied in an 376 efficient way. An example of a request modification as the result of 377 a server specific policy is removing a constraint not supported by 378 the PCE. Once the policy processing is completed at the PCC, and the 379 path computation request resulting from the original service request 380 is updated by the policy processing, the request is sent to the PCE. 382 The PCE that receives the request validates and otherwise processes 383 the request, applying the policies found in the request as well as 384 any policies that are available at the PCE, e.g., client and domain 385 specific polices. As a result of the policy processing, the PCE may 386 decide to reject the request. It also may decide to respond with one 387 or several pre-computed paths if user or client specific polices 388 instruct the PCE to do so. If the PCE decides to satisfy the request 389 by performing a path computation, it determines if it needs the 390 cooperation of other PCEs and defines parameters for path 391 computations to be performed locally and remotely. After that, the 392 PCE instructs a co-located path computation engine to perform the 393 local path computation(s) and, if necessary, sends path computation 394 requests to one or more other PCEs. It then waits for the responses 395 from the local path computation engine and, when used, the remote 396 PCE. It then combines the resulting paths and sends the result back 397 to the requesting PCC. The response may indicate policies describing 398 the resulting paths, their characteristics (summary cost, expected 399 end-to-end delay, etc.) as well as additional information related to 400 the request, e.g., which of constraints were honored, which were 401 dismissed and which were relaxed and in what way. 403 The PCC processes the response and instructs the LSR to encode the 404 received path(s) into the outgoing signaling message(s). 406 4. Requirements 408 The following requirements must be addressed by mechanisms and 409 protocols that enable policy-based control over path computation 410 requests and decisions: 412 - (G)MPLS path computation-specific 413 The mechanisms must meet the policy-based control requirements 414 specific to the problem of path computation using RSVP-TE as the 415 signaling protocol on MPLS and GMPLS LSRs. 417 - Support for non (G)MPLS PCCs 418 The mechanisms must be sufficiently generic to support 419 non-(G)MPLS (LSR) clients such as an NMS, or network planner, 420 etc. 422 - Support for many policies 423 The mechanisms must include support for many policies and policy 424 configurations. In general, the determination and configuration 425 of viable policies are the responsibility of the service 426 provider. 428 - Provision for monitoring and accounting information 429 The mechanisms must include support for monitoring policy state, 430 and provide access information. In particular, mechanisms must 431 provide usage and access information that may be used for 432 accounting purposes. 434 - Fault tolerance and recovery 435 The mechanisms must include provisions for fault tolerance and 436 recovery from failure cases such as failure of PCC/PCE PDPs, 437 disruption in communication that separate a PCC/PCE PDP from its 438 associated PCC/PCE PEPs. 440 - Support for policy-ignorant nodes 441 The mechanisms should not be mandatory for every node in a 442 network. Policy based path computation control may be enforced at 443 a subset of nodes, for example, on boundary nodes within an 444 administrative domain. These policy-capable nodes will function 445 as trusted nodes from the point of view of the policy-ignorant 446 nodes in that administrative domain. Alternatively, policy may be 447 applied solely on PCEs with all PCCs being policy-ignorant nodes. 449 - Scalability 450 One of the important requirements for the mechanisms is 451 scalability. The mechanisms must scale at least to the same 452 extent that RSVP-TE signaling scales in terms of accommodating 453 multiple LSPs and network nodes in the path of an LSP. There are 454 several sensitive areas in terms of scalability of policy based 455 path computation control. First, not every policy aware node in 456 an infrastructure should be expected to contact a remote 457 PDP. This would cause potentially long delays in verifying 458 requests. Additionally, the policy control architecture must 459 scale at least as well as RSVP-TE protocol based on factors such 460 as the size of RSVP-TE messages, the time required for the 461 network to service an RSVP-TE request, local processing time 462 required per node, and local memory consumed per node. These 463 scaling considerations are of particular importance during 464 re-routing of a set of LSPs. 466 - Security and denial of service considerations 467 The policy control architecture, protocols and mechanisms must be 468 secure as far as the following aspects are concerned: 470 o First, the mechanisms proposed must minimize theft and denial 471 of service threats. 473 o Second, it must be ensured that the entities (such as PEPs 474 and PDPs) involved in policy control can verify each other's 475 identity and establish necessary trust before communicating. 477 - Inter-AS and inter-area requirements 478 There are several inter-AS policy related requirements discussed 479 in [RFC4216] and [INTERAS-PCEP], and inter-area policy related 480 requirements discussed in [PCECP-IA-REQ]. These requirements 481 must be addressed by policy-enabled PCE mechanisms and protocols. 483 It should be noted that this document only outlines the communication 484 elements and mechanisms needed to allow a wide variety of possible 485 policies to be applied for path computation control. It does not 486 include any discussion of any specific policy behavior. Nor does it 487 define or require use of specific policies. 489 5. Path Computation Policy Information Model (PCPIM) 491 The Policy Core Information Model (PCIM) introduced in [RFC3060] and 492 expanded in [RFC3460] presents the object-oriented information model 493 for representing general policy information. 495 This model defines two hierarchies of object classes: 497 - structural classes representing policy information and control of 498 policies 500 - association classes that indicate how instances of the structural 501 classes are related to each other. 503 These classes can be mapped to various concrete implementations, for 504 example, to a directory that uses LDAPv3 as its access protocol. 506 Figure 2 shows an abstract from the class inheritance hierarchy for 507 PCIM. 509 ManagedElement (abstract) 510 | 511 +--Policy (abstract) 512 | | 513 | +---PolicySet (abstract) 514 | | | 515 | | +---PolicyGroup 516 | | | 517 | | +---PolicyRule 518 | | 519 | +---PolicyCondition (abstract) 520 | | | 521 | | +---PolicyTimePeriodCondition 522 | | | 523 | | +---VendorPolicyCondition 524 | | | 525 | | +---SimplePolicyCondition 526 | | | 527 | | +---CompoundPolicyCondition 528 | | | 529 | | +---CompoundFilterCondition 530 | | 531 | +---PolicyAction (abstract) 532 | | | 533 | | +---VendorPolicyAction 534 | | | 535 | | +---SimplePolicyAction 536 | | | 537 | | +---CompoundPolicyAction 538 | | 539 | +---PolicyVariable (abstract) 540 | | | 541 | | +---PolicyExplicitVariable 542 | | | 543 | | +---PolicyImplicitVariable 544 | | | 545 | | +---(subtree of more specific classes) 546 | | 547 | +---PolicyValue (abstract) 548 | | 549 | +---(subtree of more specific classes) 550 | 552 Figure 2: PCIM Class Inheritance 554 The policy classes and associations defined in PCIM are sufficiently 555 generic to allow them to represent policies related to anything. 557 Policy models for application-specific areas such as the Path 558 Computation Service may extend the PCIM in several ways. The 559 preferred way is to use the PolicyGroup, PolicyRule, and 560 PolicyTimePeriodCondition classes directly as a foundation for 561 representing and communicating policy information. Then, specific 562 subclasses derived from PolicyCondition and PolicyAction can capture 563 application-specific definitions of conditions and actions of 564 policies. Two subclasses, VendorPolicyCondition and 565 VendorPolicyAction, are also defined to provide a standard extension 566 mechanism for vendor-specific extensions to the Policy Core 567 Information Model. 569 Policy Quality of Service Information Model [RFC3644] further extends 570 the PCIM to represent QoS policy information for large-scale policy 571 domains. New classes introduced in this document describing QoS and 572 RSVP related variables, conditions and actions can be used as a 573 foundation for the PCPIM. 575 Detailed description of the PCPIM will be provided in a separate 576 documents. 578 6. Policy-Enabled Path Computation Framework Components 580 The following components are defined as part of the framework to 581 support policy-enabled path computation: 583 - PC Policy Repository 584 A database from which PC policies are available in the form of 585 instances of PCPIM classes. PC Policies are configured and 586 managed by PC Policy Management Tools. 588 - PCE Policy Decision Point (PCE-PDP) 589 A logical entity capable of retrieving relevant path computation 590 policies from one or more Policy Repositories and delivering the 591 information to associated PCE-PEP(s); 593 - PCE Policy Enforcement Point (PCE-PEP) 594 A logical entity capable of issuing device specific Path 595 Computation Engine configuration requests for the purpose of 596 enforcing the policies 598 - PCC Policy Decision Point (PCC-PDP) 599 A logical entity capable of retrieving relevant path computation 600 policies from one or more Policy Repositories and delivering the 601 information to associated PCC-PEP(s; 603 - PCC Policy Enforcement Point (PCC-PEP) 604 A logical entity capable of issuing device specific Path 605 Computation Service User configuration requests for the purpose 606 of enforcing the policies. 608 From the policy perspective a PCC is logically decomposed into two 609 parts: PCC-PDP and PCC-PEP. When present, a PCC-PEP is co-located 610 with a Path Computation Service User entity that requires remote path 611 computation (for example, the GMPLS control plane of an LSR). The 612 PCC-PEP and PCC-PDP may be physically co-located (as per [RFC2748]) 613 or separated. In the later case they talk to each other via such 614 protocols as COPS and/or COPS-PR [RFC3084]. 616 Likewise, a PCE is logically decomposed into two parts: PCE-PEP and 617 PCE-PDP. When present, PCE-PEP is co-located with a Path Computation 618 Engine entity that actually provides the Path Computation Service 619 (that is, runs path computation algorithms). PCE-PEP and PCE-PDP may 620 be physically co-located or separated. In the later case they 621 communicate using such protocols as COPS and/or COPS-PR. 623 PCC-PDP/PCE-PDP may be co-located with, or separated from, an 624 associated PC Policy Repository. In the latter case, the PDPs use 625 some access protocol (for example, LDAPv3 or SNMP). The task of PDPs 626 is to retrieve policies from the repository(ies) and convey them to 627 respective PEPs either in unsolicited way or upon the PEPs requests. 629 A PCC-PEP may receive policy information not only from PCC-PDPs(s) 630 but also from PCE-PEP(s) via PCC-PCE communication and/or PCE 631 discovery protocols. Likewise, a PCE-PEP may receive policy 632 information not only from PCE-PDPs(s) but also from PCC-PEP(s) via 633 PCC-PCE communication protocol. 635 Any given policy can be interpreted (that is, translated into a 636 sequence of concrete device specific configuration requests) either 637 on a PDP or on the associated PEP or partly on the PDP and partly on 638 the PEP. 640 Generally speaking, the task of the PCC-PEP is to select the PCE and 641 build path computation requests applying service specific policies 642 provided by the PCC-PDP. The task of the PCE-PEP is to control path 643 computations by applying request-specific policies found in the 644 requests as well as client-specific and domain-specific policies 645 supplied by the PCE-PDP. 647 7. Policy Component Configurations 649 7.1. PCC-PCE Configurations 651 The PCE policy architecture supports policy being applied at a PCC 652 and at a PCE. While the architecture supports policy being applied at 653 both, there is no requirement for policy to always be applied at 654 both, or even at either. The use of policy in a network, on PCCs and 655 on PCEs, is a specific network design choice. Some networks may 656 choose to apply policy only at PCCs (Figure 3), some at PCEs (Figure 657 4), and others at both PCCs and PCEs (Figure 5). Regardless of where 658 policy is applied it must be applied in a consistent fashion in order 659 to achieve the intended results. 661 ........................ 662 . . 663 . PC Policy Management . 664 . . 665 ........................ 666 . 667 . 668 --------- Policy ---------------------- 669 | PCC-PDP |<--------- | PC Policy Repository | 670 --------- ---------------------- 671 ^ 672 | e.g., COPS 673 v 674 --------- --------- 675 | PCC-PEP |<------------------------------------------->| PCE | 676 --------- PCC-PCE Communication Protocol --------- 678 Figure 3: Policies are applied on PCC only 680 Along with supporting flexibility in where policy may be applied, the 681 PCE architecture is also flexible in terms of where specific types of 682 policies may be applied. Also the PCE architecture allows for the 683 application of only a subset of policy types. [PCE-ARCH] defines 684 several PC policy types. Each of these may be applied at either a PCC 685 or a PCE or both. Clearly when policy is only applied at PCCs or at 686 PCEs, all PC policy types used in the network must be applied at 687 those locations. 689 ........................ 690 . . 691 . PC Policy Management . 692 . . 693 ........................ 694 . 695 . 696 ---------------------- Policy --------- 697 | PC Policy Repository | -------->| PCE-PDP | 698 ---------------------- --------- 699 ^ 700 e.g., COPS | 701 v 702 --------- --------- 703 | PCC |<------------------------------------------->| PCE-PEP | 704 --------- PCC-PCE Communication Protocol --------- 706 Figure 4: Policies are applied on PCE only 708 In the case where policy is only applied at a PCE, it is expected 709 that the PCC will pass to the PCE all information about the service 710 that it can gather in the path computation request (most likely in 711 the form of PCPIM policy variables). The PCE is expected to 712 understand this information and apply appropriate policies while 713 defining the actual parameters of the path computation to be 714 performed. Note that in this scenario the PCC cannot apply server- 715 specific or any other policies, and PCE selection is static. 717 When applying policy at both PCC and PCE, it is necessary to select 718 which types of policies are applied at each. In such configurations, 719 it is likely that the application of policy types will be distributed 720 across PCC and PCE rather than applying all of them at both. For 721 example, user specific and server specific policies may be applied at 722 a PCC, request and client specific policies may be applied at a PCE, 723 while domain specific policies may be applied at both the PCC and 724 PCE. 726 In the case when policy is only applied at a PCC, the PCC must apply 727 all the types of required policies, for example user, service, server 728 and domain-specific policies. The PCC uses the policies to construct 729 a path computation request that appropriately represents the applied 730 policies. The request will necessarily be limited to the set of 731 "basic" (that is, non-policy capable) constraints explicitly defined 732 by the PCC-PCE communication protocol in use. 734 7.2. Policy Repositories 736 Within the policy-enabled path computation framework policy 737 repositories may be used in a single or multiple PC policy repository 738 configuration: 740 o) Single PC Policy Repository 742 In this configuration there is a single PC Policy Repository shared 743 between PCCs and PCEs. 745 ........................ 746 . . 747 . PC Policy Management . 748 . . 749 ........................ 750 . 751 . 752 --------- Policy a ---------------------- Policy b --------- 753 | PCC-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP | 754 --------- ---------------------- --------- 755 ^ ^ 756 | e.g., COPS e.g., COPS | 757 v v 758 --------- --------- 759 | PCC-PEP |<------------------------------------------->| PCE-PEP | 760 --------- PCC-PCE Communication Protocol --------- 762 Figure 5: Single PCC/PCE Policy Repository 764 o) Multiple PC Policy Repositories 766 The repositories in this case may be fully or partially synchronized 767 by some discovery/ synchronization management protocol or may be 768 completely independent. Note that the situation when PC Policy 769 Repository A exactly matches PC Policy Repository B, results in the 770 single PC Policy Repository configuration case. 772 -------------- -------------- 773 | PC Policy | | PC Policy | 774 ---| Repository A | | Repository B |--- 775 | -------------- -------------- | 776 | | 777 | Policy a Policy b | 778 | | 779 v v 780 --------- --------- 781 | PCC-PDP | | PCE-PDP | 782 --------- --------- 783 ^ ^ 784 | e.g., COPS e.g., COPS | 785 v v 786 --------- --------- 787 | PCC-PEP |<------------------------------------------->| PCE-PEP | 788 --------- PCC-PCE Communication Protocol --------- 790 Figure 6: Multiple PCE/PCC Policy Repositories 792 7.3. Cooperating PCE Configurations 794 The previous section shows the relationship between PCCs and PCEs. A 795 parallel relationship exists between cooperating PCEs, and, in fact, 796 this relationship can be viewed as the same as the relationship 797 between PCCs and PCEs. The one notable difference is that there will 798 be cases where having a shared PC Policy Repository will not be 799 desirable, for example, when the PCEs are managed by different 800 entities. Note that in this case it still remains necessary for the 801 policies to be consistent across the domains in order to identify 802 usable paths. The other notable difference is that a PCE, while 803 processing a path computation request, may need to apply requestor- 804 specific (that is, client-specific) policies in order to modify the 805 request before sending it to other cooperating PCE(s). This 806 relationship is particularly important as the PCE Architecture allows 807 for configuration where all PCCs are not policy-enabled. 809 The following are example configurations. These examples do not 810 represent an exhaustive list and other configurations are expected. 812 o) Single Policy Repository 814 In this configuration there is a single PC Policy repository shared 815 between PCEs. This configuration is likely to be useful within a 816 single administrative domain where multiple PCEs are provided for 817 redundancy or load distribution purposes. 819 ........................ 820 . . 821 . PC Policy Management . 822 . . 823 ........................ 824 . 825 . 826 --------- Policy a ---------------------- Policy b --------- 827 | PCE-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP | 828 --------- ---------------------- --------- 829 ^ ^ 830 | e.g., COPS e.g., COPS | 831 v v 832 --------- --------- 833 | PCE-PEP |<------------------------------------------->| PCE-PEP | 834 --------- PCE-PCE Communication Protocol --------- 836 Figure 7: Single PCC Policy Repository 838 o) Multiple Policy Repositories 840 The repositories in this case may be fully or partially synchronized 841 by some discovery/synchronization management protocol(s) or may be 842 completely independent. In the multi-domain case it is expected that 843 the repositories will be distinct, providing, however. consistent 844 policies. 846 -------------- -------------- 847 | PC Policy | | PC Policy | 848 ---| Repository A | | Repository B |--- 849 | -------------- -------------- | 850 | | 851 | Policy a Policy b | 852 | | 853 v v 854 --------- --------- 855 | PCE-PDP | | PCE-PDP | 856 --------- --------- 857 ^ ^ 858 | e.g., COPS e.g., COPS | 859 v v 860 --------- --------- 861 | PCE-PEP |<------------------------------------------->| PCE-PEP | 862 --------- PCC-PCE Communication Protocol --------- 864 Figure 8: Multiple PCC Policy Repositories 866 7.4. Policy Configuration Management 868 The management of path computation policy information used by PCCs 869 and PCEs is largely out of scope of the described framework. The 870 framework assumes that such information is installed, removed and 871 otherwise managed using typical policy management techniques. Policy 872 Repositories may be populated and managed via static configuration, 873 standard and proprietary policy management tools, or even dynamically 874 via policy management/discovery protocols and applications. 876 8. Inter-Component Communication 878 8.1. Policy Communication 880 Flexibility in the application of policy types is imperative from the 881 architecture perspective. However, this commodity implies added 882 complexity on the part of the PCE related communication protocols. 884 One added complexity is that PCE communication protocols must carry 885 certain information to support various policy types that may be 886 applied. For example, in the case where policy is only applied at a 887 PCE, a PCC-PCE request must carry sufficient information for the PCE 888 to apply service or user specific policies. This does imply that a 889 PCC must have sufficient understanding of what policies can be 890 applied at the PCE. Such information may be obtained via local 891 configuration, static coding or even via a PCE discovery mechanism. 892 The PCC must also have sufficient understanding to properly encode 893 the required information for each policy type. 895 Another added complexity is that PCE communication protocols must 896 also be able to carry information that may result from a policy 897 decision. For example, user or service specific policy applied at a 898 PCC may result in policy related information that must be carried 899 along with the request for use by a PCE. This complexity is 900 particularly important as it may be used to introduce new path 901 computation parameters (e.g. constraints, objection functions, etc.) 902 without modification of the core PCC and PCE. This communication will 903 likely simply require the PCE communication protocols to support 904 opaque policy related information elements. 906 A final added complexity is that PCE communication protocols must 907 also be able to support updated or unsolicited responses from a PCE. 908 For example, changes in PCE policy may force a change to a previously 909 provided path. Such updated or unsolicited responses may contain 910 information that the PCC must act on, and may contain policy 911 information that must be provided to a PCC. 913 PCC-PEP and PCE-PEP or a pair of PCE-PEPs communicate via a request- 914 response type PCC-PCE Communication Protocol. This document makes no 915 assumptions as to what exact protocol is used to support this 916 communication. This document does assume that the semantics of a 917 path computation request are sufficiently abstract and general, and 918 support both PCE-PCC and PCE-PCE communication. 920 A path computation request at minimum should include: 921 o One or several source addresses; 922 o One or several destination addresses; 923 o Computation type (P2P, P2MP, MP2P, etc.); 924 o Number of required paths; 925 o Zero or more policy descriptors in the following format: 926 , 927 , , ,..., 928 , , ,..., 929 ... 930 , , ,..., 932 A successful path computation response, at minimum, should include 933 the list of computed paths and may include policies (in the form of 934 policy descriptors as in path computation request, see above) for use 935 in evaluating and otherwise applying the computed paths. 937 PCC-PCE Communication Protocol provides transport for policy 938 information and should not understand nor make any assumptions about 939 the semantics of policies specified in path computation requests and 940 responses. 942 Note: This document explicitly allows for (but does not require) the 943 PCC to decide that all necessary constraints, objective functions, 944 etc. pertinent to the computation of paths for the service in 945 question are to be determined by the PCE performing the computation. 946 In this case the PCC will use a set of policies (more precisely, 947 PCPIM policy variables) describing the service specific information. 948 These policies may be placed within the path computation request and 949 delivered to the PCE via a PCC-PCE communication protocol. The PCE 950 (more precisely, PCE-PEP) is expected to understand this information 951 and use it to determine the constraints and optimization functions 952 applying local policies (that is, policies locally configured or 953 provided by the associated PCE-PDP(s)). 955 8.2. PCE Discovery Policy Considerations 957 Dynamic PCE discovery allows for PCCs and PCEs to automatically 958 discover a set of PCEs (including information required for the PCE 959 selection). It also allows for PCCs and PCEs to dynamically detect 960 new PCEs or any modification of PCEs information. Policy can be 961 applied in two ways in this context: 963 1. Restricting the scope of information distribution for the 964 mandatory set of information (in particular the PCE presence 965 and location). 967 2. Restricting the type and nature of the optional information 968 distributed by the discovery protocol. The latter is also 969 subject to policy since the PCE architecture allows for 970 distributing this information using either PCE discovery 971 protocol(s) or PCC-PCE communication protocol(s). One important 972 policy decision in this context is the nature of the information 973 to be distributed, especially, when this information is not 974 strictly speaking a "discovery" information, rather, the PCE 975 state changes. Client-specific and domain-specific policies may 976 be applied when deciding whether this information should be 977 distributed and to which clients of the path computation service 978 (that is, which PCCs and/or PCEs) 980 Another place where policy applies is at the administrative 981 boundaries. In multi-domain networks multiple PCEs will communicate 982 with each other and across administrative boundaries. In such cases, 983 domain-specific polices would be applied to 1) filter the information 984 exchanged between peering PCEs during the discovery process (to the 985 bare minimum in most cases if at all allowed by the security policy) 986 and 2) limit the content of information being passed in path 987 computation request and responses. 989 9. Path Computation Sequence of Events 991 This section presents representative scenarios; other scenarios are 992 also possible. 994 9.1. Policy-enabled PCC, Policy-enabled PCE 996 When a GMPLS LSR receives a Setup (RSVP Path) message from an 997 upstream LSR, the LSR may decide to use a remote Path Computation 998 Entity. The following sequence of events occurs in this case: 1000 - A PCC-PEP co-located with the LSR applies the service specific 1001 policies to select a PCE for the service path computation as 1002 well as to build the path computation request (that is, to 1003 select a list of policies, their variables, conditions and 1004 actions expressing constraints, diversities, objective functions 1005 and relaxation strategies appropriate for the service path 1006 computation). The policies may be: 1008 a) Statically configured on the PCC-PEP; 1010 b) Communicated to the PCC-PEP by a remote or local PCC-PDP 1011 via protocol such as COPS either pro-actively (most of the 1012 cases) or upon an explicit request by the PCC-PEP in case when 1013 some specifics of the new service have not been covered yet by 1014 the policies so far known to the PCC-PEP) 1016 The input for the decision process on the PCC-PEP is the 1017 information found in the signaling message as well as any other 1018 service specific information such as port ID over which the message 1019 was received, associated VPN ID, the reference point type (UNI, E- 1020 NNI, etc.) and so forth. After the path computation request is 1021 built it is sent directly to the PCE-PEP using the PCC-PCE 1022 Communication Protocol. 1024 - PCE-PEP validates and otherwise processes the request applying 1025 the policies found in the request as well as client and domain 1026 specific polices. The latter, again, may be either statically 1027 configured on the PCE-PEP or provided by the associated local or 1028 remote PCE-PDP via a protocol such as COPS. The outcome of the 1029 decision process is the following information: 1031 a) Whether the request should be satisfied, rejected or 1032 dismissed. 1034 b) The sets of sources and destinations for which paths should 1035 be locally computed. 1037 c) The set of constraints, diversities, optimization functions 1038 and relaxations to be considered in each of locally performed 1039 path computation. 1041 d) The address of the next-in-chain PCE. 1043 e) The path computation request to be sent to the 1044 next-in-chain PCE. 1046 The PCE-PEP instructs a co-located path computation engine to 1047 perform the local path computation(s) and, if necessary, sends the 1048 path computation request to the next-in-chain PCE using a PCC-PCE 1049 Communication Protocol. Then it waits for the responses from the 1050 local path computation engine and the remote PCE, combines the 1051 resulting paths and sends them back to the PCC-PEP using the PCC- 1052 PCE Communication Protocol. The response contains the resulting 1053 paths as well as policies describing some additional information 1054 (for example, which of constraints were honored, which were 1055 dismissed and which were relaxed and in what way) 1057 - PCC-PEP instructs the signaling sub-system of the GMPLS LSR to 1058 encode the received path(s) into the outgoing Setup message(s). 1060 9.2. Policy-ignorant PCC, Policy-enabled PCE 1062 This case parallels the previous example, but the user and service 1063 specific policies should be applied at the PCE as the PCC is policy 1064 ignorant. Again, when a GMPLS LSR has received a Setup (RSVP Path) 1065 message from an upstream LSR, the LSR may decide to use a non co- 1066 located Path Computation Entity. The following sequence of events 1067 occurs in this case: 1069 - The PCC constructs a PCE request using information found in the 1070 signaling/provisioning message as well as any other service 1071 specific information such as port ID over which the message was 1072 received, associated VPN ID, the reference point type (UNI, E- 1073 NNI, etc.) and so forth. This information is encoded in the 1074 request in the form of policy variables. After the request is 1075 built it is sent directly to the PCE-PEP using a PCC-PCE 1076 Communication Protocol. 1078 - PCE-PEP validates and otherwise processes the request 1079 interpreting the policy variables found in the request and 1080 applying user, service- and also client- and domain- specific 1081 polices to build the actual path computation request. The 1082 policies, again, may be either statically configured on the 1083 PCE-PEP or provided by the associated local or remote PCE-PDP via 1084 a protocol such as COPS. The outcome of the decision process is 1085 the following information: 1087 a) Whether the request should be satisfied, rejected or 1088 dismissed. 1090 b) The sets of sources and destinations for which paths should 1091 be locally computed. 1093 c) The set of constraints, diversities, optimization functions 1094 and relaxations to be considered in each of locally performed 1095 path computation. 1097 d) The address of the next-in-chain PCE. 1099 e) The path computation request to be sent to the next-in- 1100 chain PCE. 1102 The PCE-PEP instructs a co-located path computation engine to 1103 perform the local path computation(s) and, if necessary, sends the 1104 path computation request to the next-in-chain PCE using the PCC-PCE 1105 Communication Protocol. Then it waits for the responses from the 1106 local path computation engine and the remote PCE, combines the 1107 resulting paths and sends them back to the PCC-PEP using the PCC- 1108 PCE Communication Protocol. The response contains the resulting 1109 paths as well as policies describing some additional information 1110 (for example, which of constraints were honored, which were 1111 dismissed and which were relaxed and in what way) 1113 - PCC-PEP instructs the signaling sub-system of the GMPLS LSR to 1114 encode the received path(s) into the outgoing Setup message(s). 1116 10. Introduction of New Constraints 1118 An important aspect of the policy-enable path computation framework 1119 discussed above is the ability to introduce new constraints with 1120 minimal impact. In particular, only those components and mechanisms 1121 that will use a new constraint need to change in order to support a 1122 new constraints. Importantly, those components and mechanisms that 1123 will not use a new constraint must not require change for a new 1124 constraint to be utilized. For example, the PCE communication 1125 protocols must not require any changes to support a new constraint. 1126 Likewise, PCC and PCEs that will not process a new constraint must 1127 not require any modification. 1129 Consider the case where a PCE has been upgraded with software 1130 supporting optical physical impairment constraint, such as 1131 Polarization Mode Dispersion (PMD), that previously was not supported 1132 in the domain. In this case, one or more new policies will be 1133 installed in the PC Policy Repository (associated with the PCE) 1134 defining the constraint (rules that determine application criteria, 1135 set of policy variables, conditions, actions, etc.) and its 1136 relaxation strategy(ies). The new policies will be also propagated 1137 into other PC Policy Repositories within the domain via discovery and 1138 synchronization protocols or via local configuration. PCE-PDPs and 1139 PCC-PDPs will then retrieve the corresponding policies from the 1140 repository(ies). From then on PCC-PDPs will instruct associated PCC- 1141 PEPs to add the new policy information into path computation requests 1142 for services with certain parameters (for example, for services 1143 provisioned in the OCh layer). 1145 It is important to note that policy-enabled path computation model 1146 naturally solves the PCE capability discovery issues. Suppose a PCE 1147 working in a single PC Policy Repository configuration starts to 1148 support a new constraint. Once a corresponding policy installed in 1149 the repository, it automatically becomes available for all repository 1150 users, that is, PCCs. In the multi-repository case some policy 1151 synchronization must be provided, however, this problem is one of the 1152 management plane which is solved already. 1154 11. Security Considerations 1156 This document adds to the policy security considerations mentioned in 1157 [PCE-ARCH]. In particular it is now necessary to consider the 1158 security of policy information maintained in PC Policy Repositories 1159 and policy related transactions. The most notable issues, some of 1160 which are also listed in [PCE-ARCH], are: 1162 - Unauthorized access to the PC Policy Repositories; 1164 - Interception of policy information when it is retrieved from 1165 the repositories and/or transported from PDPs to PEPs; 1167 - Interception of policy related information in path computation 1168 requests and responses; 1170 o Impersonation of user and client identities; 1172 o Falsification of policy information and/or PCE capabilities; 1174 o Denial of service attacks on policy related communication 1175 mechanisms. 1177 As with [PCE-ARCH], it is expected that PCE solutions will address 1178 these issues in detail. 1180 12. Acknowledgements 1182 We would like to thank Bela Berde for fruitful discussions on PBM 1183 and Policy-driven path computation. 1185 13. IANA Considerations 1187 None. 1189 14. References 1191 14.1. Normative References 1193 [PCE-ARCH] Farrel, A., Vasseur, JP., Ash, J., "Path Computation 1194 Element (PCE) Architecture", April 2006. 1196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1197 Requirement Levels," BCP 14, RFC 2119, March 1997. 1199 [RFC2753] R. Yavatkar, D. Pendarakis, R. Guerin, A Framework for 1200 Policy Based Admission Control, RFC 2753, January 2000. 1202 [RFC2748] D. Durham, et al., The COPS (Common Open Policy Service) 1203 protocol, RFC 2748, IETF, January 2000. 1205 [RFC3060] B. Moore, et al., Policy Information Model Version1 1206 Specification, RFC 3060, February 2001. 1208 [RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP 1209 Tunnels", RFC 3209, December 2001. 1211 [RFC3460] Moore, B. Ed., "Policy Core Information Model (PCIM) 1212 Extensions", RFC 3460, January 2003. 1214 [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label 1215 Switching (GMPLS) Signaling Resource ReserVation 1216 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 1217 3473, January 2003. 1219 [RFC3644] Y. Snir, et al., Policy Quality of Service (QoS) 1220 Information Model, RFC 3644, November 2003. 1222 [RFC4216] Zhang, R., Vasseur, J-P., Eds., "MPLS Inter-Autonomous 1223 System (AS) Traffic Engineering (TE) Requirements", 1224 RFC4216, November 2005. 1226 [INTERAS-PCEP] Bitar, N., Zhang, R., Kumaki, K., Eds., "Inter-AS 1227 Requirements for the Path Computation Element 1228 Communication Protocol (PCECP)", February 2006. 1230 [PCECP-IA-REQ] Le Roux, J-L., Ed., "PCE Communication Protocol 1231 (PCECP) Specific Requirements for Inter-Area 1232 (G)MPLS Traffic Engineering", February 2006. 1234 14.2. Informative References 1236 [DMTF] Common Information Model (CIM) Schema, version 2.x. 1237 Distributed Management Task Force, Inc. The components 1238 of the CIM v2.x schema are available via links on the 1239 following DMTF web page: 1240 http://www.dmtf.org/standards/standard_cim.php. 1242 [RFC3031] Rosen, E,. Viswanathan, V. Callon, R., "Multiprotocol 1243 Label Switching Architecture", RFC 3031, January 2001. 1245 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 1246 K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. 1247 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 1248 RFC 3084, February 2001. 1250 [RFC3198] Westerinen, A., et al., "Terminology for Policy-Based 1251 Management", RFC 3198, November 2001. 1253 [RFC3630] Katz, D., Kompella, K., Yeung., D., "Traffic Engineering 1254 (TE) Extensions to OSPF Version 2", RFC 3630, September 1255 2003. 1257 15. Authors' Addresses 1259 Igor Bryskin 1260 Movaz Networks, Inc. 1261 7926 Jones Branch Drive 1262 Suite 615 1263 McLean, VA 22102 1264 Email: ibryskin@movaz.com 1266 Dimitri Papadimitriou (Alcatel) 1267 Fr. Wellesplein 1, 1268 B-2018 Antwerpen, Belgium 1269 Phone: +32 3 240-8491 1270 Email: dimitri.papadimitriou@alcatel.be 1271 Lou Berger 1272 LabN Consulting, LLC 1273 Phone: +1 301 468 9228 1274 Email: lberger@labn.net 1276 16. Full Copyright Statement 1278 Copyright (C) The Internet Society (2006). This document is subject 1279 to the rights, licenses and restrictions contained in BCP 78, and 1280 except as set forth therein, the authors retain all their rights. 1282 This document and the information contained herein are provided on an 1283 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1284 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1285 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1286 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1287 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1288 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1290 17. Intellectual Property 1292 The IETF takes no position regarding the validity or scope of any 1293 Intellectual Property Rights or other rights that might be claimed to 1294 pertain to the implementation or use of the technology described in 1295 this document or the extent to which any license under such rights 1296 might or might not be available; nor does it represent that it has 1297 made any independent effort to identify any such rights. Information 1298 on the procedures with respect to rights in RFC documents can be 1299 found in BCP 78 and BCP 79. 1301 Copies of IPR disclosures made to the IETF Secretariat and any 1302 assurances of licenses to be made available, or the result of an 1303 attempt made to obtain a general license or permission for the use of 1304 such proprietary rights by implementers or users of this 1305 specification can be obtained from the IETF on-line IPR repository at 1306 http://www.ietf.org/ipr. 1308 The IETF invites any interested party to bring to its attention any 1309 copyrights, patents or patent applications, or other proprietary 1310 rights that may cover technology that may be required to implement 1311 this standard. Please address the information to the IETF at ietf- 1312 ipr@ietf.org. 1314 Generated on: Thu Jun 22 19:34:07 EDT 2006