idnits 2.17.1 draft-bryskin-pce-policy-enabled-path-comp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1241. ** 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 == Line 679 has weird spacing: '...olicies and P...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2006) is 6609 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PCE-ARCH' is mentioned on line 1120, but not defined == Missing Reference: 'RFC3630' is mentioned on line 87, but not defined == Missing Reference: 'RFC3031' is mentioned on line 89, but not defined == Missing Reference: 'RFC3198' is mentioned on line 98, but not defined == Missing Reference: 'RFC3460' is mentioned on line 462, but not defined == Unused Reference: 'RFC2205' is defined on line 1136, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 1155, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 1167, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 1170, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2753 ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) Summary: 7 errors (**), 0 flaws (~~), 12 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: Standards Track Dimitri Papadimitriou (Alcatel) 3 Expiration Date: September 2006 Lou Berger (LabN Consulting, LLC) 5 March 2006 7 Policy-Enabled Path Computation Framework 9 draft-bryskin-pce-policy-enabled-path-comp-01.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 configuration 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 Scenario ............................ 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 .............................................. 9 55 5 Path Computation Policy Information Model (PCPIM) ......... 11 56 6 Policy Enabled Path Computation Framework Components ...... 13 57 7 Policy Component Configurations ........................... 14 58 7.1 PCC-PCE Configurations .................................... 14 59 7.2 Policy Repositories ....................................... 16 60 7.3 Cooperating PCE Configurations ............................ 18 61 7.4 Policy Configuration Management ........................... 19 62 8 Inter-Component Communication ............................. 19 63 8.1 Policy Communication ..................................... 19 64 8.2 PCE Discovery Policy Considerations ....................... 21 65 9 Path Computation Sequence of Events ....................... 22 66 9.1 Policy-enabled PCC, Policy-enabled PCE .................... 22 67 9.2 Policy-ignorant PCC, Policy-enabled PCE ................... 23 68 10 Introduction of New Constraints ........................... 24 69 11 Security Considerations ................................... 25 70 12 Acknowledgements .......................................... 26 71 13 IANA Considerations ....................................... 26 72 14 References ................................................ 26 73 14.1 Normative References ...................................... 26 74 14.2 Informative References .................................... 27 75 15 Authors' Addresses ........................................ 27 76 16 Full Copyright Statement .................................. 28 77 17 Intellectual Property ..................................... 28 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 PCCIM: Path Computation Core Information Model 97 QPIM: QoS Policy Information Model, see [RFC3644]. 98 PBM: Policy-based Management, see [RFC3198]. 99 PEP: Policy Enforcement Points, see [RFC2753]. 100 PDP: Policy Decision Points, see [RFC2753]. 101 COPS: Common Open Policy Service, see [RFC2748]. 102 COPS-PR: COPS Usage for Policy Provisioning, see [RFC3084]. 104 2. Introduction 106 The PCE architecture is introduced in [PCE-ARCH]. This document 107 describes the impact policy on the PCE architecture and provides 108 additional details on and context for policy within the PCE 109 Architecture. 111 Policy-based Management (PBM) enables network administrators to 112 operate in a high-level manner through rule-based policies; the 113 latter are translated automatically into individual device 114 configuration directives, aiming at controlling a network as a whole. 115 Two IETF Working Groups have considered policy networking in the 116 past: The Resource Allocation Protocol working group and the Policy 117 Framework working group. 119 A framework for policy-based admission control [RFC2753] was defined 120 and a protocol for use between Policy Enforcement Points (PEP) and 121 Policy Decision Points (PDP) was specified: Common Open Policy 122 Service (COPS) [RFC2748]. This document uses the terms PEP and PDP to 123 refer to the functions defined in the COPS context. This document 124 makes no assumptions nor requires that the actual COPS protocol be 125 used. 127 The IETF has also produced a general framework for representing, 128 managing, sharing, and reusing policies in a vendor independent, 129 interoperable, and scalable manner. It has also defined an extensible 130 information model for representing policies, called the Policy Core 131 Information Model (PCIM) [RFC3060], and an extension to this model to 132 address the need for QoS management, called the QoS Policy 133 Information Model (QPIM) [RFC3644]. However, additional mechanisms 134 are needed in order to specify policies related to the path 135 computation logic as well as its control. 137 3. Background 139 This section provides some general background on the use of policy 140 within the PCE architecture. It presents representative reasons 141 behind the use of policy, as well as some sample policy usage 142 scenarios. This information is intended to provide context for the 143 presented policy framework. This section does not attempt to present 144 an exhaustive list of rational or scenarios. 146 3.1. Motivations 148 The PCE architecture is introduced in [PCE-ARCH]. It includes policy 149 as an integral part of the PCE architecture. This section presents 150 some of the rational for this inclusion. 152 Network operators require a certain level of flexibility to shape on 153 the TE path computation process, so that the process could be aligned 154 with their business and operational needs. One motivation of this 155 document is to introduce a policy element into the PCE Architecture 156 and outline a framework that could provide such flexibility. 158 Many aspects of the path computation could be governed by policies. 159 For example, a PCC could use policies configured by the operator to 160 decide which optimizations, constraints, diversities and their 161 relaxation strategies to request while computing path(s) for a 162 particular service. Depending on SLAs, TE and cost/performance ratio 163 goals, path computation requests could be built differently for 164 different services. Service A, for instance, may require two SRLG- 165 disjoint paths for building end-to-end recovery scheme, while for 166 service B link-disjoint paths may be sufficient. Service A may need 167 paths with minimal end-to-end delay, while service B may be looking 168 for shortest (minimal-cost) paths. Different constraint relaxation 169 strategies could be applied while computing paths for service A and 170 for service B, and so forth. 172 Likewise, a PCE could apply policies to decide on which algorithms to 173 use while performing path computations requested from a particular 174 PCC or for a particular domain; whether to seek for cooperation of 175 other PCEs to satisfy a particular request or handle it on its own 176 (possibly responding with non explicit paths); how the request should 177 be modified before being sent to other member(s) of a group of 178 cooperating PCEs, etc. 180 Additional motivation for supporting policy within the PCE 181 architecture could be described as follows. Traditionally path 182 computation entity used to be an intrinsic part of an LSR's control 183 plane always co-located with the LSR's signaling and routing 184 subsystems. Such architectural approach allowed for unlimited 185 flexibility in providing various path computation enhancements: 186 adding new types of constraints, diversities and their relaxation 187 strategies, adopting new objective functions and optimization 188 criterions, etc. All what had to be done was to upgrade the control 189 plane software of only this particular LSR (and no other LSRs or any 190 other network elements). With non co-located PCEs the introduction of 191 new PCE capabilities became more complicated: it won't be enough for 192 a PCE to upgrade its own software. In order to take advantage of the 193 PCE's new capabilities, new advertising and signaling objects need to 194 be standardized, all PCCs need to be upgraded with new software, new 195 interoperability problems need to be resolved, etc. It would be 196 highly desirable to find a way of introducing new path computation 197 capabilities that requires modifying neither the 198 discovery/communication protocols nor PCC software. One way to 199 achieve this objective is to consider path selection constraints, 200 their relaxations and objective functions as path computation request 201 specific policies that, on one hand, could be configured and managed 202 by an operator as any other policies and, on the other, hand could be 203 interpreted in real time by PCCs and PCEs. 205 There is a number of advantages and useful by-products of such 206 approach: 208 - New path computation capabilities could be introduced with changing 209 neither PCE-PCC communication and discovery protocols nor PCC 210 software. Only the PCE module providing the path computation 211 capabilities (referred in this document as path computation engine) 212 needs to be updated 214 - Existing constraints, objective functions and their relaxations 215 could be aggregated and otherwise associated together, thus, 216 producing new more complex ones that do not require change of code 217 even on PCEs supporting them 218 - Different elements such as conditions, actions, variables, etc. 219 could be re-used by multiple constraints/diversities/optimizations 221 - PCCs and PCEs need to handle other (that is, not request specific) 222 policies. Path computation related policies of all types could be 223 placed within the same policy repositories, could be managed by the 224 same policy management tools and could be interpreted using the same 225 mechanisms. Also the policies need to be supported by PCCs and PCEs 226 independently from peculiarities of a PCC-PCE communication protocol 227 in use. Thus, introducing a new (request specific) type of policies 228 describing constraints and other elements of a path computation 229 request seems to be a natural and relatively inexpensive addition to 230 the policy enabled path computation architecture. 232 3.2. Representative Policy Scenario 234 This section provides example scenarios of how policy may be applied 235 using the PCE policy framework within the PCE architecture context. 236 Actual networks may use one of the scenarios discussed, some 237 combination of the presented scenarios or other scenarios (not 238 discussed). This section should not be viewed as limiting other 239 applications of policy within the PCE architecture. 241 3.2.1. Scenario: Policy Configured Paths 243 A very simple usage scenario for PCE policy would be to use PCE to 244 centrally administer configured paths. Configured paths are composed 245 of strict and loose hops in the form of EROs (see [RFC3209]), and are 246 used by one or more LSPs. Typically such paths are configured at the 247 LSP ingress. In the context of the policy enabled path computation 248 framework an alternate approach is possible. 250 Specifically, service specific policies could be installed that will 251 provide configured path(s) for a specific service request. The 252 request could be identified based on service parameters such as end 253 points, requested QoS or even a token that identifies the end-user. 254 The configured path(s) would then be used as input to PCE computation 255 process, which would return explicit routes by expanding of all 256 specified loose hops. 258 The described policies could be applied at either PCC or PCE, see 259 Figure 5. In the PCC case, the configured path would be processed at 260 the PCC and then passed to the PCE along with the PCE request, 261 probably in the form of (inclusion) constraints. When applied at the 262 PCE, the configured path would be used locally. Both cases require 263 some method to configure and manage policies. In the PCC case, the 264 real benefit would come when there is an automated policy 265 distribution mechanism. 267 Policy-configured paths could also be used in multiple PCE 268 environments (see Figures 7 and 8). For example, consider the case 269 when there is a limited TE visibility and multiple PCEs are used to 270 determine path(s) within each area of the TE visibility. In such 271 case it may not be possible (or desirable) to configure entire 272 explicit path(s) on a single PCE. However, it is possible to 273 configure explicit path(s) for each area of the TE visibility with 274 each responsible PCE. One by one the PCEs would then map an incoming 275 signaling request to appropriate configured path(s). Note that to 276 make such scenario work it would likely be necessary to start and 277 finish the configured paths on TE domain boundary nodes. Clearly, 278 consistent PC Policy Repositories are also critical in this example. 280 3.2.2. Scenario: Provider Selection Policy 282 A more interesting usage scenario is applying PC policies in multi- 283 domain multi-provider networks. There are numerous interesting policy 284 applications in such networks. A rudimentary example is simple 285 access control, that is, deciding which clients are permitted to 286 request inter-domain path computation. 288 A more interesting example is applying policy to determine which 289 domain or provider network will be used to support a particular PCE 290 request. Consider a topology presented on Figure 1. In this example 291 there are multiple transit networks available to provide a path from 292 a source domain to a destination domain. Furthermore, each transit 293 network may have one or more options for reaching a particular 294 domain. Each domain may need to decide on which of the multiple 295 available paths to be used in order to satisfy a particular PCE 296 request. 298 Clearly, TE reachability, availability and optimality are the basic 299 criterions for the path selection, however, policies could provide an 300 important flexibility in the decision process. For example, transit 301 network A may be more expensive and provide lower delay or loss than 302 transit network C. Likewise, a transit network may wish to treat PCE 303 requests from its own customers differently than requests from other 304 providers. In both cases computation based on traffic engineering 305 databases will result in multiple transit networks that provide 306 reachability, and policies could be used to govern which PCE requests 307 get the better service. 309 +----------------+ 310 |Transit Domain A| +----------------+ 311 +----------------+ |Transit Domain D| 312 +------+ +----------------+ +----------------+ +------+ 313 |Source| |Transit Domain B| +----------------+ |Target| 314 |Domain| +----------------+ |Transit Domain E| |Domain| 315 +------+ +----------------+ +----------------+ +------+ 316 |Transit Domain C| +----------------+ 317 +----------------+ |Transit Domain F| 318 +----------------+ 320 Figure 1: Multi-domain network with multiple transit options 322 There are multiple options for differentiating which PCE requests use 323 a particular transit domain and get a particular (better or worse) 324 level of service. For example, the source domain may use user and 325 request specific policies to determine the level of service to 326 provide and use domain specific policies to choose which transit 327 domains are acceptable. A transit domain may use request specific 328 policies to determine if a request is from a direct customer or 329 another provider and then use domain specific policies to identify 330 how the request should be processed. 332 3.2.3. Scenario: Policy Based Constraints 334 Another usage scenario is to use policy to provide additional 335 constraints for PCE request. Consider an LSR with a policy enabled 336 PCC, as shown in Figure 3, which receives a signaling message via 337 signaling, including over a NNI or UNI reference point, or receives 338 configuration request over a management interface to establish a 339 service. The path(s) for LSP(s) that are needed to support the 340 service are not explicitly specified in the message/request; hence 341 path computation is needed. 343 In this case, the PCC may apply user or service specific policies to 344 decide how the path selection process should be constrained, that is, 345 which constraints, diversities, optimizations and relaxations should 346 be applied in order for the service LSP(s) to have a likelihood to be 347 successfully established and provide necessary QoS and resilience 348 against network failures. When deciding on the set of constraints 349 the PCC uses as an input all information it knows about the user and 350 service, including the contents of the received message, port ID over 351 which message was received, associated VPN ID, signaling/reference 352 point type, request time, etc. Once the constraints and other 353 parameters of the required path computation are determined, the PCC 354 generates a path computation request which includes the request- 355 specific policies that describe the determined set of constraints, 356 optimizations, and other parameters that indicate how the request is 357 to be considered in the path computation process. 359 The PCC may also apply server specific policies for each of known 360 (i.e., discovered or configured) PCE in order to select which PCE to 361 use. The PCC may also use server specific policies to form the 362 request to match the PCE's capabilities so that the request will not 363 be rejected and has a higher likelihood of being satisfied in an 364 efficient way. An example of the request modification as a result of 365 a server specific policy is removing a constraint not supported by 366 the PCE. Once the policy processing is completed at the PCC, and the 367 path computation request resulting from the original service request 368 is updated by the policy processing, the request is sent to the PCE. 370 The PCE that receives the request validates and otherwise processes 371 the request applying the policies found in the request as well as any 372 policies that are available at the PCE, e.g., client and domain 373 specific polices. As a result of the policy processing the PCE may 374 decide to reject the request. It also may decide to respond with one 375 or several pre-computed paths if user or client specific polices 376 instruct the PCE to do so. If the PCE decides to satisfy the request 377 by performing a path computation, it determines if it needs the 378 cooperation of other PCEs and defines parameters for path 379 computations to be performed locally and remotely. After that the 380 PCE instructs a co-located path computation engine to perform the 381 local path computation(s) and, if necessary, sends path computation 382 request(s) to one or more other PCEs. It then waits for the 383 responses from the local path computation engine and, when used, the 384 remote PCE. It then combines the resulting paths and sends them back 385 to the requesting PCC. The response may indicate policies describing 386 the resulting paths, their characteristics (summary cost, expected 387 end-to-end delay, etc.) as well as additional information related to 388 the request, e.g., which of constraints were honored, which were 389 dismissed and which were relaxed and in what way. 391 The PCC processes the response and instructs the LSR to encode the 392 received path(s) into the outgoing signaling message(s). 394 4. Requirements 396 The following requirements need to be addressed while designing and 397 developing mechanisms and protocols that enable policy-based control 398 over path computation request/decision. Note that this document only 399 outlines the communication elements and mechanisms needed to allow a 400 wide variety of possible policies to be applied for path computation 401 control, but it does not include any discussion of any specific 402 policy behavior. Nor does it require use of specific policies. 404 - GMPLS path computation-specific: the mechanisms must be designed to 405 meet the policy-based control requirements specific to the problem of 406 path computation using RSVP-TE as the signaling protocol on MPLS LSR, 407 GMPLS LSR, but not limited to this as the mechanisms should work just 408 as well for other types of PCCs such as NMS, network planner, etc. 410 - Support for many policies: the mechanisms designed must include 411 support for many policies and policy configurations. In general, the 412 determination and configuration of viable policies are the 413 responsibility of the service provider. 415 - Provision for Monitoring and Accounting Information: The mechanisms 416 must include support for monitoring policy state, and provide access 417 information. In particular, mechanisms must be included to provide 418 usage and access information that may be used for accounting 419 purposes. 421 - Fault tolerance and recovery: The mechanisms designed on the basis 422 of this framework must include provisions for fault tolerance and 423 recovery from failure cases such as failure of PCC/PCE PDPs, 424 disruption in communication that separate a PCC/PCE PDP from its 425 associated PCC/PCE PEPs. 427 - Support for policy-ignorant nodes: Support for the mechanisms 428 described in this document should not be mandatory for every node in 429 a network. Policy based path computation control could be enforced at 430 a subset of nodes, for example, on boundary nodes within an 431 administrative domain. These policy-capable nodes would function as 432 trusted nodes from the point of view of the policy-ignorant nodes in 433 that administrative domain. Alternatively, policy may be applied 434 solely on PCEs with all PCCs being policy-ignorant nodes. 436 - Scalability: One of the important requirements for the mechanisms 437 designed for policy control is scalability. The mechanisms must scale 438 at least to the same extent that RSVP-TE signaling scales in terms of 439 accommodating multiple LSPs and network nodes in the path of an LSP. 440 There are several sensitive areas in terms of scalability of policy 441 based path computation control. First, not every policy aware node in 442 an infrastructure should be expected to contact a remote PDP. This 443 would cause potentially long delays in verifying requests. 444 Additionally, the policy control architecture must scale at least as 445 well as RSVP-TE protocol based on factors such as the size of RSVP-TE 446 messages, the time required for the network to service an RSVP-TE 447 request, local processing time required per node, and local memory 448 consumed per node. These scaling considerations are of particular 449 importance during re-routing of a set of LSPs. 451 - Security and denial of service considerations: The policy control 452 architecture must be secure as far as the following aspects are 453 concerned. First, the mechanisms proposed must minimize theft and 454 denial of service threats. Second, it must be ensured that the 455 entities (such as PEPs and PDPs) involved in policy control can 456 verify each other's identity and establish necessary trust before 457 communicating. 459 5. Path Computation Policy Information Model (PCPIM) 461 The Policy Core Information Model (PCIM) introduced in [RFC3060] and 462 expanded in [RFC3460] presents the object-oriented information model 463 for representing general policy information. 465 This model defines two hierarchies of object classes: 467 - structural classes representing policy information and control of 468 policies 470 - association classes that indicate how instances of the structural 471 classes are related to each other. 473 These classes could be mapped to various concrete implementations, 474 for example, to a directory that uses LDAPv3 as its access protocol. 476 Figure 2 shows an abstract from the class inheritance hierarchy for 477 PCIM. 479 ManagedElement (abstract) 480 | 481 +--Policy (abstract) 482 | | 483 | +---PolicySet (abstract) 484 | | | 485 | | +---PolicyGroup 486 | | | 487 | | +---PolicyRule 488 | | 489 | +---PolicyCondition (abstract) 490 | | | 491 | | +---PolicyTimePeriodCondition 492 | | | 493 | | +---VendorPolicyCondition 494 | | | 495 | | +---SimplePolicyCondition 496 | | | 497 | | +---CompoundPolicyCondition 498 | | | 499 | | +---CompoundFilterCondition 500 | | 501 | +---PolicyAction (abstract) 502 | | | 503 | | +---VendorPolicyAction 504 | | | 505 | | +---SimplePolicyAction 506 | | | 507 | | +---CompoundPolicyAction 508 | | 509 | +---PolicyVariable (abstract) 510 | | | 511 | | +---PolicyExplicitVariable 512 | | | 513 | | +---PolicyImplicitVariable 514 | | | 515 | | +---(subtree of more specific classes) 516 | | 517 | +---PolicyValue (abstract) 518 | | 519 | +---(subtree of more specific classes) 520 | 522 Figure 2: PCIM Class Inheritance 524 The policy classes and associations defined in PCIM are sufficiently 525 generic to allow them to represent policies related to anything. 527 Policy models for application-specific areas such as the Path 528 Computation Service may extend the PCIM in several ways. The 529 preferred way is to use the PolicyGroup, PolicyRule, and 530 PolicyTimePeriodCondition classes directly as a foundation for 531 representing and communicating policy information. Then, specific 532 subclasses derived from PolicyCondition and PolicyAction can capture 533 application-specific definitions of conditions and actions of 534 policies. Two subclasses, VendorPolicyCondition and 535 VendorPolicyAction, are also defined to provide a standard extension 536 mechanism for vendor-specific extensions to the Policy Core 537 Information Model. 539 Policy Quality of Service Information Model [RFC3644] further extends 540 the PCIM to represent QoS policy information for large-scale policy 541 domains. New classes introduced in this document describing QoS and 542 RSVP related variables, conditions and actions could be used as a 543 foundation for the PCPIM. 545 Detailed description of the PCPIM will be provided in one of the 546 companion documents 548 6. Policy Enabled Path Computation Framework Components 550 The following components are defined: 552 PC Policy Repository: a database from which PC policies are available 553 in the form of instances of PCPIM classes. PC Policies are configured 554 and managed by PC Policy Management Tools. 556 PCE Policy Decision Point (PCE-PDP): a logical entity capable of 557 retrieving relevant path computation policies from one or more Policy 558 Repositories and delivering the information to associated PCE-PEP(s); 560 PCE Policy Enforcement Point (PCE-PEP): a logical entity capable of 561 issuing device specific Path Computation Engine configuration 562 requests for the purpose of enforcing the policies 564 PCC Policy Decision Point (PCC-PDP): a logical entity capable of 565 retrieving relevant path computation policies from one or more Policy 566 Repositories and delivering the information to associated PCC-PEP(s; 568 PCC Policy Enforcement Point (PCC-PEP): a logical entity capable of 569 issuing device specific Path Computation Service User configuration 570 requests for the purpose of enforcing the policies. 572 From the policy perspective a PCC is logically decomposed into two 573 parts: PCC-PDP and PCC-PEP. When present, a PCC-PEP is co-located 574 with a Path Computation Service User - entity that requires remote 575 path computation (for example, the GMPLS control plane of an LSR). 576 The PCC-PEP and PCC-PDP could be physically co-located (as per 577 [RFC2748]) or separated. In the later case they talk to each other 578 via such protocols as COPS and/or COPS-PR [RFC3084]. 580 Likewise, a PCE is logically decomposed into two parts: PCE-PEP and 581 PCE- PDP. When present, PCE-PEP is co-located with a Path Computation 582 Engine - entity that actually provides the Path Computation Service 583 (that is, runs path computation algorithms). PCE-PEP and PCE-PDP 584 could be physically co-located or separated. In the later case they 585 communicate using such protocols as COPS and/or COPS-PR. 587 PCC-PDP/PCE-PDP could be co-located with or separated from the 588 associated PC Policy Repository. In the latter case the PDPs use some 589 access protocol (for example, LDAPv3 or SNMP). The task of PDPs is to 590 retrieve policies from the repository(ies) and convey them to 591 respective PEPs either in unsolicited way or upon the PEPs requests. 593 A PCC-PEP may receive policy information not only from PCC-PDPs(s) 594 but also from PCE-PEP(s) via PCC-PCE communication and/or PCE 595 discovery protocols. Likewise, a PCE-PEP may receive policy 596 information not only from PCE-PDPs(s) but also from PCC-PEP(s) via 597 PCC-PCE communication protocol. 599 Any given policy could be interpreted (that is, translated into a 600 sequence of concrete device specific configuration requests) either 601 on a PDP or on the associated PEP or partly on the PDP and partly on 602 the PEP. 604 Generally speaking, the task of the PCC-PEP is to select the PCE and 605 build path computation requests applying service specific policies 606 provided by the PCC-PDP. The task of the PCE-PEP is to control path 607 computations by applying request-specific policies found in the 608 requests as well as client- and domain-specific policies supplied by 609 the PCE-PDP. 611 7. Policy Component Configurations 613 7.1. PCC-PCE Configurations 615 The PCE policy architecture supports policy being applied at a PCC 616 and at a PCE. While the architecture supports policy being applied 617 at both, there is no requirement for policy to always being applied 618 at both or even at either. The use of policy in a network - on PCCs 619 and on PCEs - is a specific network design choice. Some networks may 620 choose to apply policy only at PCCs (Figure 3), some at PCEs (Figure 621 4), and others at PCCs and PCEs (Figure 5). Regardless of how policy 622 is applied it must be applied in a consistent fashion in order to 623 achieve the results intended. 625 ........................ 626 . . 627 . PC Policy Management . 628 . . 629 ........................ 630 . 631 . 632 --------- Policy ---------------------- 633 | PCC-PDP |<--------- | PC Policy Repository | 634 --------- ---------------------- 635 ^ 636 | e.g., COPS 637 v 638 --------- --------- 639 | PCC-PEP |<------------------------------------------->| PCE | 640 --------- PCC-PCE Communication Protocol --------- 642 Figure 3: Policies are applied on PCC only 644 Along with supporting flexibility in where policy may be applied, the 645 PCE architecture is also flexible in terms of where specific types of 646 policies may be applied. Also the PCE architecture allows for the 647 application of only a subset of policy types. [PCE-ARCH] defines 648 several PC policy types. Each of these may be applied at either a 649 PCC or a PCE or both. Clearly when policy is only applied at PCCs or 650 at PCEs, all PC policy types used in the network must be applied at 651 those locations. 653 ........................ 654 . . 655 . PC Policy Management . 656 . . 657 ........................ 658 . 659 . 660 ---------------------- Policy --------- 661 | PC Policy Repository | -------->| PCE-PDP | 662 ---------------------- --------- 663 ^ 664 e.g., COPS | 665 v 666 --------- --------- 667 | PCC |<------------------------------------------->| PCE-PEP | 668 --------- PCC-PCE Communication Protocol --------- 670 Figure 4: Policies are applied on PCE only 672 In the case when policy is only applied at a PCE, it is expected that 673 the PCC will pass to the PCE all information about the service that 674 it could gather in the path computation request (most likely in the 675 form of PCPIM policy variables). The PCE is expected to understand 676 this information and apply appropriate policies while defining the 677 actual parameters of the path computation to be performed. Note that 678 in this scenario the PCC cannot apply server-specific or any other 679 policies and PCE selection is static. 681 When applying policy at both PCC and PCE, it is necessary to select 682 which types of policies are applied at each. In such configurations, 683 it is likely that the application of policy types will be distributed 684 across PCC and PCE rather than applying all of them at both. For 685 example, user specific and server specific policies may be applied at 686 PCC, request and client specific policies may be applied at PCE, 687 while domain specific policies may be applied at both PCC and PCE. 689 In the case when policy is only applied at a PCC, the PCC must apply 690 all the types of required policies, for example user, service, server 691 and domain-specific policies. The PCC uses the policies to construct 692 a path computation request that appropriately represents the applied 693 policies. The request will necessarily be limited to the set of 694 "basic" (that is, non-policy capable) constraints explicitly defined 695 by the PCC-PCE communication protocol in use. 697 7.2. Policy Repositories 699 There could be configurations with: 701 o) Single PC Policy Repository 703 In this configuration there is a single PC Policy Repository shared 704 between PCCs and PCEs. 706 ........................ 707 . . 708 . PC Policy Management . 709 . . 710 ........................ 711 . 712 . 713 --------- Policy a ---------------------- Policy b --------- 714 | PCC-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP | 715 --------- ---------------------- --------- 716 ^ ^ 717 | e.g., COPS e.g., COPS | 718 v v 719 --------- --------- 720 | PCC-PEP |<------------------------------------------->| PCE-PEP | 721 --------- PCC-PCE Communication Protocol --------- 723 Figure 5: Single PCC/PCE Policy Repository 725 o) Multiple PC Policy Repositories 727 The repositories in this case could be fully or partially 728 synchronized by some discovery/ synchronization management protocol 729 or could be completely independent. Note that the situation when PC 730 Policy Repository A exactly matches PC Policy Repository B, results 731 in the single PC Policy Repository configuration case. 733 -------------- -------------- 734 | PC Policy | | PC Policy | 735 ---| Repository A | | Repository B |--- 736 | -------------- -------------- | 737 | | 738 | Policy a Policy b | 739 | | 740 v v 741 --------- --------- 742 | PCC-PDP | | PCE-PDP | 743 --------- --------- 744 ^ ^ 745 | e.g., COPS e.g., COPS | 746 v v 747 --------- --------- 748 | PCC-PEP |<------------------------------------------->| PCE-PEP | 749 --------- PCC-PCE Communication Protocol --------- 751 Figure 6: Multiple PCE/PCC Policy Repositories 753 7.3. Cooperating PCE Configurations 755 The previous section shows the relationship between PCCs and PCEs. A 756 parallel relationship exists between cooperating PCEs, and, in fact, 757 this relationship can be viewed as the same as the relationship 758 between PCCs and PCEs. The one notable difference is that there will 759 be cases where having a shared PC Policy Repository will not be 760 desirable, for example, when the PCEs are managed by different 761 entities. Note that in this case it still remains necessary for the 762 policies to be consistent across the domains in order to identify 763 usable paths. The other notable difference is that a PCE, while 764 processing a path computation request, may need to apply requestor- 765 (that is, client-) specific policies in order to modify the request 766 before sending it to other cooperating PCE(s). This relationship is 767 particularly important as the PCE Architecture allows for 768 configuration where all PCCs are not policy enabled. 770 The following are example configurations. These examples do not 771 represent an exhaustive list and other configurations are expected. 773 o) Single Policy Repository 775 In this configuration there is a single PC Policy repository shared 776 between PCEs. This configuration is likely to be useful within a 777 single administrative domain where multiple PCEs are provided for 778 redundancy or load distribution purposes. 780 ........................ 781 . . 782 . PC Policy Management . 783 . . 784 ........................ 785 . 786 . 787 --------- Policy a ---------------------- Policy b --------- 788 | PCE-PDP |<--------- | PC Policy Repository | -------->| PCE-PDP | 789 --------- ---------------------- --------- 790 ^ ^ 791 | e.g., COPS e.g., COPS | 792 v v 793 --------- --------- 794 | PCE-PEP |<------------------------------------------->| PCE-PEP | 795 --------- PCE-PCE Communication Protocol --------- 797 Figure 7: Single PCC Policy Repository 799 o) Multiple Policy Repositories 800 The repositories in this case could be fully or partially 801 synchronized by some discovery/synchronization management protocol(s) 802 or could be completely independent. In the multi-domain case it is 803 expected that the repositories will be distinct, providing, however. 804 consistent policies. 806 -------------- -------------- 807 | PC Policy | | PC Policy | 808 ---| Repository A | | Repository B |--- 809 | -------------- -------------- | 810 | | 811 | Policy a Policy b | 812 | | 813 v v 814 --------- --------- 815 | PCE-PDP | | PCE-PDP | 816 --------- --------- 817 ^ ^ 818 | e.g., COPS e.g., COPS | 819 v v 820 --------- --------- 821 | PCE-PEP |<------------------------------------------->| PCE-PEP | 822 --------- PCC-PCE Communication Protocol --------- 824 Figure 8: Multiple PCC Policy Repositories 826 7.4. Policy Configuration Management 828 The management of path computation policy information used by PCCs 829 and PCEs is largely out of scope of the described framework. The 830 framework assumes that such information is installed, removed and 831 otherwise managed using typical policy management techniques. Policy 832 Repositories could be populated and managed via static configuration, 833 standard and proprietary policy management tools, or even dynamically 834 via policy management/discovery protocols and applications. 836 8. Inter-Component Communication 838 8.1. Policy Communication 840 Flexibility in the application of policy types is imperative from the 841 architecture perspective. However, this commodity implies added 842 complexity on the part of the PCE related communication protocols. 844 The first added complexity is that the PCE communication protocols 845 must carry certain information to support various policy types that 846 may be applied. For example, in the case where policy is only 847 applied at a PCE, a PCC-PCE request must carry sufficient information 848 for the PCE to apply service or user specific policies. This does 849 imply that a PCC must have sufficient understanding of what policies 850 could be applied at the PCE. Such information may be obtained via 851 local configuration, static coding or even via a PCE discovery 852 mechanism. The PCC must also have sufficient understanding to 853 properly encode the required information for each policy type. 855 The second added complexity is that the PCE communication protocols 856 must also be able to carry information that may result from a policy 857 decision. For example, user or service specific policy applied at a 858 PCC may result in policy related information that must be carried 859 along with the request for use by a PCE. This complexity is 860 particularly important as it may be used to introduce new path 861 computation parameters (e.g. constraints, objection functions, etc.) 862 without modification of the core PCC and PCE. This communication 863 will likely simply require the PCE communication protocols to support 864 opaque policy related information elements. 866 The final added complexity is that the PCE communication protocols 867 must also be able to support updated or unsolicited responses from a 868 PCE. For example, changes in PCE policy may force a change to a 869 previously provided path. Such updated or unsolicited responses may 870 contain information that the PCC must act on, and may contain policy 871 information that must be provided to a PCC. 873 PCC-PEP and PCE-PEP or a pair of PCE-PEPs communicate via a request- 874 response type PCC-PCE Communication Protocol. This document makes no 875 assumptions as to what exactly protocol is used to support this 876 communication. This document does assume that the semantics of a 877 path computation request are sufficiently abstract and general, and 878 support both PCE-PCC and PCE-PCE communication. 880 A path computation request at minimum should include: 881 o One or several source addresses; 882 o One or several destination addresses; 883 o Computation type (P2P, P2MP, MP2P, etc.); 884 o Number of required paths; 885 o Zero or more policy descriptors in the following format: 886 , 887 , , ,..., 888 , , ,..., 889 ... 890 , , ,..., 892 A successful path computation response at minimum should include the 893 list of computed paths and may include policies (in the form of 894 policy descriptors as in path computation request, see above) helping 895 evaluate and otherwise use the computed paths. 897 PCC-PCE Communication Protocol provides transport for policy 898 information and should not understand nor make any assumptions about 899 the semantics of policies specified in path computation requests and 900 responses. 902 Note: This document explicitly allows for (but does not require) the 903 PCC to decide that all necessary constraints, objective functions, 904 etc. pertinent for the computation of paths for the service in 905 question are to be determined by the PCE performing the computation. 906 In this case the PCC will use a set of policies (more precisely, 907 PCPIM policy variables) describing the above mentioned service 908 specific information. These policies could be placed within the path 909 computation request and delivered to the PCE via a PCC-PCE 910 communication protocol. The PCE (more precisely, PCE-PEP) is expected 911 to understand this information and use it to determine the 912 constraints and optimization functions applying local policies (that 913 is, policies locally configured or provided by the associated PCE- 914 PDP(s)). 916 8.2. PCE Discovery Policy Considerations 918 Dynamic PCE discovery allows for PCCs and PCEs to automatically 919 discover a set of PCEs (including information required for the PCE 920 selection). It also allows for PCCs and PCEs to dynamically detect 921 new PCEs or any modification of PCEs information. Policy can be 922 applied in two ways in this context: 924 1. Restricting the scope of information distribution for the 925 mandatory set of information (in particular the PCE presence and 926 location). 928 2. Restricting the type and nature of the optional information 929 distributed by the discovery protocol. The latter is also subject to 930 policy since the PCE architecture allows for distributing this 931 information using either PCE discovery protocol(s) or PCC-PCE 932 communication protocol(s). One important policy decision in this 933 context is the nature of the information to be distributed, 934 especially, when this information is not strictly speaking a 935 "discovery" information, rather, the PCE state changes. Client- and 936 domain- specific policies could be applied when deciding whether this 937 information should be distributed and to which clients of the path 938 computation service (that is, which PCCs and/or PCEs) 940 Another place where policing applies is at the administrative 941 boundaries. In multi-domain networks multiple PCEs would have to 942 communicate one each other and cross an administrative boundary. In 943 such cases domain-specific polices would be applied to 1) filter the 944 information exchanged between peering PCEs during the discovery 945 process (to the bare minimum in most cases if at all allowed by the 946 security policy) and 2) limit the content of information being passed 947 in path computation request/responses. 949 9. Path Computation Sequence of Events 951 This section presents representative scenarios; other scenarios are 952 also possible. 954 9.1. Policy-enabled PCC, Policy-enabled PCE 956 When a GMPLS LSR receives a Setup (RSVP Path) message from an 957 upstream LSR, the LSR may decide to use a remote Path Computation 958 Entity. The following sequence of events occurs in this case: 960 - A PCC-PEP co-located with the LSR applies the service specific 961 policies to select a PCE for the service path computation as well as 962 to build the path computation request (that is, to select a list of 963 policies, their variables, conditions and actions expressing 964 constraints, diversities, objective functions and relaxation 965 strategies appropriate for the service path computation). The 966 policies could be: 968 a) Statically configured on the PCC-PEP; 970 b) Communicated to the PCC-PEP by a remote or local PCC-PDP via 971 protocol such as COPS either pro-actively (most of the cases) or upon 972 an explicit request by the PCC-PEP in case when some specifics of the 973 new service have not been covered yet by the policies so far known to 974 the PCC-PEP) 976 The input for the decision process on the PCC-PEP is the information 977 found in the signaling message as well as any other service specific 978 information such as port ID over which the message was received, 979 associated VPN ID, the reference point type (UNI, E-NNI, etc.) and so 980 forth. After the path computation request is built it is sent 981 directly to the PCE- PEP using the PCC-PCE Communication Protocol. 983 - PCE-PEP validates and otherwise processes the request applying the 984 policies found in the request as well as client and domain specific 985 polices. The latter, again, could be either statically configured on 986 the PCE-PEP or provided by the associated local or remote PCE-PDP via 987 a protocol such as COPS. The outcome of the decision process is the 988 following information: 990 a) Whether the request should be satisfied, rejected or dismissed. 992 b) The sets of sources and destinations for which paths should be 993 locally computed. 995 c) The set of constraints, diversities, optimization functions and 996 relaxations to be considered in each of locally performed path 997 computation. 999 d) The address of the next-in-chain PCE. 1001 e) The path computation request to be sent to the next-in-chain 1002 PCE. 1004 The PCE-PEP instructs a co-located path computation engine to perform 1005 the local path computation(s) and, if necessary, sends the path 1006 computation request to the next-in-chain PCE using a PCC-PCE 1007 Communication Protocol. Then it waits for the responses from the 1008 local path computation engine and the remote PCE, combines the 1009 resulting paths and sends them back to the PCC-PEP using the PCC-PCE 1010 Communication Protocol. The response contains the resulting paths as 1011 well as policies describing some additional information (for example, 1012 which of constraints were honored, which were dismissed and which 1013 were relaxed and in what way) 1015 - PCC-PEP instructs the signaling sub-system of the GMPLS LSR to 1016 encode the received path(s) into the outgoing Setup message(s). 1018 9.2. Policy-ignorant PCC, Policy-enabled PCE 1020 This case parallels the previous example, but the user and service 1021 specific policies should be applied at the PCE as the PCC is policy 1022 ignorant. Again, when a GMPLS LSR has received a Setup (RSVP Path) 1023 message from an upstream LSR, the LSR may decide to use a non co- 1024 located Path Computation Entity. The following sequence of events 1025 occurs in this case: 1027 - The PCC constructs a PCE request using information found in the 1028 signaling/provisioning message as well as any other service specific 1029 information such as port ID over which the message was received, 1030 associated VPN ID, the reference point type (UNI, E- NNI, etc.) and 1031 so forth. This information is encoded in the request in the form of 1032 policy variables. After the request is built it is sent directly to 1033 the PCE-PEP using a PCC-PCE Communication Protocol. 1035 - PCE-PEP validates and otherwise processes the request interpreting 1036 the policy variables found in the request and applying user, service- 1037 and also client- and domain- specific polices to build the actual 1038 path computation request . The policies, again, could be either 1039 statically configured on the PCE-PEP or provided by the associated 1040 local or remote PCE-PDP via a protocol such as COPS. The outcome of 1041 the decision process is the following information: 1043 a) Whether the request should be satisfied, rejected or dismissed. 1045 b) The sets of sources and destinations for which paths should be 1046 locally computed. 1048 c) The set of constraints, diversities, optimization functions and 1049 relaxations to be considered in each of locally performed path 1050 computation. 1052 d) The address of the next-in-chain PCE. 1054 e) The path computation request to be sent to the next-in- chain PCE. 1056 The PCE-PEP instructs a co-located path computation engine to perform 1057 the local path computation(s) and, if necessary, sends the path 1058 computation request to the next-in-chain PCE using the PCC-PCE 1059 Communication Protocol. Then it waits for the responses from the 1060 local path computation engine and the remote PCE, combines the 1061 resulting paths and sends them back to the PCC-PEP using the PCC-PCE 1062 Communication Protocol. The response contains the resulting paths as 1063 well as policies describing some additional information (for example, 1064 which of constraints were honored, which were dismissed and which 1065 were relaxed and in what way) 1067 - PCC-PEP instructs the signaling sub-system of the GMPLS LSR to 1068 encode the received path(s) into the outgoing Setup message(s). 1070 10. Introduction of New Constraints 1072 Let us assume that a PCE has been upgraded with software supporting 1073 optical physical impairment constraint such as Polarization Mode 1074 Dispersion (PMD) that previously has not been supported in the 1075 domain. In this case one or more new policies will be installed in 1076 the PC Policy Repository (associated with the PCE) defining the 1077 constraint (rules that determine application criteria, set of policy 1078 variables, conditions, actions, etc.) and its relaxation 1079 strategy(ies). The new policies will be also propagated into other PC 1080 Policy Repositories within the domain via discovery/ synchronization 1081 protocols or via local configuration. PCE- and PCC- PDPs will then 1082 retrieve the corresponding policies from the repository(ies). From 1083 then on PCC-PDPs will instruct associated PCC- PEPs to add the new 1084 policy information into path computation requests for services with 1085 certain parameters (for example, for services provisioned in the OCh 1086 layer). 1088 It is important to note that policy enabled path computation model 1089 naturally solves the PCE capability discovery issues. Suppose a PCE 1090 working in a single PC Policy Repository configuration starts to 1091 support a new constraint. Once a corresponding policy installed in 1092 the repository, it automatically becomes available for all repository 1093 users, that is, PCCs. In the multi-repository case some policy 1094 synchronization must be provided, however, this problem is one of the 1095 management plane which is solved already. 1097 11. Security Considerations 1099 This document adds to the policy security considerations mentioned in 1100 [PCE-ARCH]. In particular it is now necessary to consider the 1101 security of policy information maintained in PC Policy Repositories 1102 and policy related transactions. The most notable issues, some of 1103 which are also listed in [PCE-ARCH], are: 1105 - Unauthorized access to the PC Policy Repositories; 1107 - Interception of policy information when it is retrieved from the 1108 repositories and/or transported from PDPs to PEPs; 1110 - Interception of policy related information in path computation 1111 requests and responses; 1113 o Impersonation of user and client identities; 1115 o Falsification of policy information and/or PCE capabilities; 1117 o Denial of service attacks on policy related communication 1118 mechanisms. 1120 As with [PCE-ARCH], it is expected that PCE solutions will address 1121 these issues in detail. 1123 12. Acknowledgements 1125 We would like to thank Bela Berde for fruitful discussions on PBM 1126 and Policy-driven path computation. 1128 13. IANA Considerations 1130 None. 1132 14. References 1134 14.1. Normative References 1136 [RFC2205] Braden, R., et al., "Resource ReSerVation Protocol 1137 (RSVP) - Version 1, Functional Specification", RFC 2205, 1138 September 1997. 1140 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1141 Requirement Levels," BCP 14, RFC 2119, March 1997. 1143 [RFC2753] R. Yavatkar, D. Pendarakis, R. Guerin, A Framework for 1144 Policy Based Admission Control, RFC 2753, January 2000. 1146 [RFC2748] D. Durham, et al., The COPS (Common Open Policy Service) 1147 protocol, RFC 2748, IETF, January 2000. 1149 [RFC3060] B. Moore, et al., Policy Information Model Version1 1150 Specification, RFC 3060, February 2001. 1152 [RFC3209] Awduche, D., et al., "Extensions to RSVP for LSP 1153 Tunnels", RFC 3209, December 2001. 1155 [RFC3471] Berger, L., et al., Generalized Multi-Protocol Label 1156 Switching (GMPLS) Signaling Functional Description, RFC 1157 3471, January 2003. 1159 [RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label 1160 Switching (GMPLS) Signaling Resource ReserVation 1161 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 1162 3473, January 2003. 1164 [RFC3644] Y. Snir, et al., Policy Quality of Service (QoS) 1165 Information Model, RFC 3644, November 2003. 1167 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 1168 3667, February 2004. 1170 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 1171 Technology", BCP 79, RFC 3668, February 2004. 1173 14.2. Informative References 1175 [DMTF] Common Information Model (CIM) Schema, version 2.x. 1176 Distributed Management Task Force, Inc. The components 1177 of the CIM v2.x schema are available via links on the 1178 following DMTF web page: 1179 http://www.dmtf.org/standards/standard_cim.php. 1181 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 1182 K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. 1183 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 1184 RFC 3084, February 2001. 1186 15. Authors' Addresses 1188 Igor Bryskin 1189 Movaz Networks, Inc. 1190 7926 Jones Branch Drive 1191 Suite 615 1192 McLean, VA - 22102 1193 Email: ibryskin@movaz.com 1195 Dimitri Papadimitriou (Alcatel) 1196 Fr. Wellesplein 1, 1197 B-2018 Antwerpen, Belgium 1198 Phone: +32 3 240-8491 1199 Email: dimitri.papadimitriou@alcatel.be 1201 Lou Berger 1202 LabN Consulting, LLC 1203 Email: lberger@labn.net 1205 16. Full Copyright Statement 1207 Copyright (C) The Internet Society (2006). This document is subject 1208 to the rights, licenses and restrictions contained in BCP 78, and 1209 except as set forth therein, the authors retain all their rights. 1211 This document and the information contained herein are provided on an 1212 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1213 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1214 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1215 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1216 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1217 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1219 17. Intellectual Property 1221 The IETF takes no position regarding the validity or scope of any 1222 Intellectual Property Rights or other rights that might be claimed to 1223 pertain to the implementation or use of the technology described in 1224 this document or the extent to which any license under such rights 1225 might or might not be available; nor does it represent that it has 1226 made any independent effort to identify any such rights. Information 1227 on the procedures with respect to rights in RFC documents can be 1228 found in BCP 78 and BCP 79. 1230 Copies of IPR disclosures made to the IETF Secretariat and any 1231 assurances of licenses to be made available, or the result of an 1232 attempt made to obtain a general license or permission for the use of 1233 such proprietary rights by implementers or users of this 1234 specification can be obtained from the IETF on-line IPR repository at 1235 http://www.ietf.org/ipr. 1237 The IETF invites any interested party to bring to its attention any 1238 copyrights, patents or patent applications, or other proprietary 1239 rights that may cover technology that may be required to implement 1240 this standard. Please address the information to the IETF at ietf- 1241 ipr@ietf.org. 1243 Generated on: Mar 4 08:48:09 EST 2006