idnits 2.17.1 draft-ietf-policy-framework-pfdl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 95 instances of lines with control characters in the document. ** The abstract seems to contain references ([TERMS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'PLYMDL' is mentioned on line 181, but not defined Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force John Strassner 2 INTERNET DRAFT Stephen Schleimer 3 17 November 1998 Cisco Systems 5 Policy Framework Definition Language 6 draft-ietf-policy-framework-pfdl-00.txt 8 Status of Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.ietf.org (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 Abstract 27 Recently, the IETF has developed protocols that classify packets in 28 order to treat certain classes or flows of packets in a particular 29 way compared to other classes or flows of packets. The successful 30 wide-scale deployment of these protocols depends on the ability to 31 administer and distribute consistent policy information to different 32 types of network devices as well as hosts and servers that participate 33 in policy decision making, administration, distribution and control. 34 There is a clear need to develop a scalable framework for policy 35 administration and distribution that will enable interoperability 36 among multiple devices and device types that must work together to 37 achieve a consistent implementation of policy. 38 This document defines a language, called the Policy Framework 39 Definition Language (PFDL), that maps requirements for services to be 40 provided by the network as defined in a business specification (e.g., 41 an SLA) to a common vendor- and device-independent intermediate form. 42 This enables policy information and specifications to be shared among 43 the heterogeneous components that comprise the policy framework, and 44 allows multiple vendors to use multiple devices to implement that 45 framework. The PFDL is the common 'currency' that is exchanged between 46 these heterogeneous components to enable them all to perform their 47 function in providing, securing, distributing, and administering 48 policy. The PFDL becomes the way to ensure that multiple vendors 49 interpret the policy the same way while enabling vendors to provide 50 value-added services. 52 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 54 Definition of Key Word Usage 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document 58 are to be interpreted as described in RFC 2119 [TERMS]. These words 59 will be capitalized to ensure that their intent in this context is 60 easily discernible. 62 Table of Contents 64 Status of this memo 65 Abstract 67 1. Introduction 69 2. Difference Between the PFDL and Other Languages 71 3. The Structure of Policies in the PFDL 72 3.1 Policy Component Hierarchy 73 3.1.1 The ComplexPolicy class 74 3.1.2 The SimplePolicy class 75 3.1.3 The PolicyRule class 76 3.1.4 The PolicyCondition class hierarchy 77 3.1.5 The PolicyAction class 78 3.2 Policy Conflict Detection 79 3.2.1 Types of Policy Conflicts 80 3.2.2 Intra-Policy Conflicts 81 3.2.3 Inter-Policy Conflicts 82 3.3 Service and Usage Policies 83 3.3.1 Service Policies 84 3.3.2 Usage Policies 85 3.4 Collective Aspects of Policy 86 3.4.1 Roles 87 3.4.2 Groups 89 4. The Grammar of the PFDL 90 92 5. Examples of Using the PFDL 94 6. Security Considerations 96 7. Acknowledgements 98 8. References 100 9. Author's Addresses 102 APPENDICES 103 Appendix A: PFDL Syntax in BNF 105 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 107 1. Introduction and Motivation 109 A policy is a named object that represents an aggregation of Policy 110 Rules. The policy describes the overall business function(s) to be 111 accomplished, while the set of policy rules defines how those business 112 functions will be met. A policy rule defines a sequence of actions to 113 be initiated when a corresponding set of conditions is satisfied. It 114 should be noted that a condition may be negated (e.g., NOT (user IN 115 GoldSLAGroup) ). Therefore, this policy condition is satisfied when the 116 specified user is NOT a member of the GoldSLAGroup. 118 Policies are the link between a high-level business specification of 119 desired services and low-level device configurations that provide those 120 services. The Policy Framework Working Group will define a secure 121 framework for policy administration, representation and distribution 122 for multiple devices and device types. This includes devices whose 123 primary job is to enforce the policy (e.g., a network element) as well 124 as other devices that have one or more of the following roles: policy 125 storage, distribution, decision-making, conflict detection, conflict 126 resolution, administration, and management. 128 A framework that is comprised of heterogeneous components requires a 129 common definition of policy. Furthermore, policy MUST be able to be 130 represented and managed in an unambiguous, interoperable manner within 131 a single network administrator's domain. Here, interoperability means 132 providing a vendor- and device-independent specification of what the 133 device configuration must do in order to provide the desired services. 134 The Policy Framework Definition Language (PFDL) quantifies this link as 135 a formal grammar. The purpose of the language is to translate from a 136 business specification, such as those found in a Service Level 137 Agreement, to a common vendor- and device-independent intermediate 138 form. This enables policy information and specifications to be shared 139 among the heterogeneous components that comprise the policy framework, 140 and allows multiple vendors to use multiple devices to implement that 141 framework. The PFDL is the common "currency" that is exchanged between 142 these heterogeneous components to enable them all to perform their 143 function in providing, securing, distributing, and administering 144 policy. The PFDL becomes the way to ensure that multiple vendors 145 interpret the policy the same way while enabling vendors to provide 146 value-added services. 148 The PFDL will first address the needs of expressing QoS policies for 149 the Differentiated Services, Integrated Services, RAP, and ISSLL 150 Working Groups. The design will be iterated as necessary while the 151 Policy Framework itself matures, and then further iterated to ensure 152 that the needs of detailed schemata are fulfilled. 153 This draft represents the initial design of the PFDL. 155 2. Difference Between the PFDL and Other Languages 156 < to be supplied > 158 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 160 3. The Structure of Policies in the PFDL 162 In addition to the requirements listed in Section 1 above, the Policy 163 Framework architecture must be scalable, interoperable and reusable. 164 Here, scalability refers to the ability to build reusable arbitrarily 165 complex policies from a set of simple ones. Interoperability means that 166 the PFDL must be expressed in a way that enables essential information 167 to be communicated between different vendors' policy management systems 168 and the devices of different vendors that are controlled by the policy 169 management systems of different vendors. Specifically, a policy 170 management system should be able to be constructed from multiple 171 vendors, and it should be able to convey policy information to multiple 172 vendors' devices. 174 This requires a canonical definition of the structure of a policy. 175 Reusability means that each component of a policy should be reusable by 176 other policies. 178 3.1 Policy Component Hierarchy 180 The design of the PFDL is based on satisfying the Policy Information 181 Model being designed in the DMTF [PLYMDL]. The class and relationship 182 hierarchies of the Policy Information Model help define the structure 183 of the PFDL grammar. Accordingly, this section will provide a brief 184 overview of the components that define a policy in the Policy 185 Information Model that require specific constructs to be defined in the 186 PFDL. 188 3.1.1 The ComplexPolicy class 190 A ComplexPolicy can contain one or more SimplePolicies. This enables 191 reusability at the policy level. For example, when a user logs on to 192 the network, many different policies must be combined. Some of the 193 different policies that could be assigned to a user include: 194 - Security policies to enable proper access to network resources, as 195 well as possible accounting and auditing functions 196 - A DHCP lease policy that allocates an IP Address depending on who 197 the user is, what services the user is contracted for (which in 198 turn can depend on the role of the user), how the user is 199 logging in (e.g., Ethernet vs. PPP), and other factors 200 - QoS policies that get activated when the user logs on as well as 201 other QoS policies that get activated on demand 203 A ComplexPolicy is modeled as an aggregation of SimplePolicies. This 204 represents reusability at the highest (policy) level. The PFDL MUST be 205 able to express the aggregation of simple policies into a more complex 206 policy. Both of these concepts must be able to be identified as named 207 elements. 209 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 211 3.1.2 The SimplePolicy class 213 A SimplePolicy can contain one or more PolicyRules. Each SimplePolicy 214 (a.k.a., a PolicyRule class) contains a SET of PolicyConditions and a 215 SET of PolicyActions. 217 The reason for this is that a PolicyRule is itself domain-specific. 218 There are PolicyRules that define security mechanisms (e.g., 219 authentication methods and ACL settings), QoS mechanisms (e.g., PHBs 220 that will manage traffic), and other mechanisms for other related 221 services. Each of these has its own definitions that are specific to 222 its domain of knowledge, requiring a set of domain-specific conditions 223 and actions. However, at a more abstract level, certain policies need 224 one or more of these policy rules to be aggregated in order to provide 225 the service(s) requested by a client. 227 For example, when a user logs on, the Policy Information Model can 228 describe the binding between the user and the services that a network 229 provides by aggregating a set of policy rules. This might consist of an 230 overall Security Policy that governs how the user will be authenticated 231 and what services the user is authorized to utilize based on a number 232 of factors (time of day, method of login, etc.). There might be a set 233 of QoS policies that get activated based on the user's SLA. There might 234 be a DHCP Lease Policy that controls what dynamic IP address the user 235 is assigned. There might be separate accounting and auditing policies 236 that get triggered on an as-needed basis. 238 It is essential that these diverse policy rules get aggregated into a 239 single consistent policy that can be associated with the user. The PFDL 240 MUST be able to specify and support the aggregation of multiple policy 241 rules into a single policy class. Furthermore, it must be able to treat 242 policy rules and policy classes as discrete named objects. 244 The concepts of order and priority are also needed. For example, assume 245 that a Policy is comprised of multiple PolicyRules, where one of the 246 PolicyRules expresses security restrictions. If the conditions of the 247 security policy rule are not satisfied, then it is irrelevant if the 248 conditions of the other policy rules are satisfied - the actions of all 249 policy rules will not be executed. Thus, the concept of rule ordering 250 is needed. Visually: 251 IF SecurityPolicyRule is satisfied THEN 252 IF DHCPLeasePolicy is satisfied THEN 253 Execute QoSPolicies 254 Execute AuditingPolicies 255 ENDIF 256 ENDIF 258 Similarly, rule priority is a useful concept. For example, this 259 provides one mechanism for resolving policy conflicts. Therefore, the 260 PFDL MUST be able to express relational and logical operators, along 261 with priority and ordering concepts. 263 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 265 3.1.3 The PolicyRule class 267 The PolicyRule class expresses a set of conditions that, when 268 satisfied, triggers a set of actions to be performed. A set of 269 conditions is used as part of a canonical template within each 270 policy knowledge domain. That is, security, QoS, DHCP, IPSEC, and other 271 policy knowledge domains will in general have their own specific 272 templates that define a particular set of conditions and an associated 273 actions that must be executed if those conditions are satisfied. A 274 "canonical template" is prescribed for interoperability reasons. It is 275 a fact that multiple vendors will be supplying multiple components as 276 part of any general policy architecture. Therefore, a common 277 communication methodology is needed. An extensible, canonical 278 definition of what constitutes the conditions and actions of a given 279 knowledge domain is offered as the solution to this interoperability 280 requirement. Therefore, the PFDL MUST support modeling a set of 281 conditions and a corresponding set of actions as an extensible 282 template. 284 Note that in addition to the above, a set of actions could be executed 285 if the set of conditions are not satisfied. However, this can be 286 modeled as a separate policy rule. This is preferred to complicating 287 the model and the resulting grammar. The PFDL MUST be able to model a 288 policy rule as an extensible template. The template consists of a set 289 of conditions that, when satisfied, triggers the execution of an 290 associated set of actions. 292 3.1.4 The PolicyCondition class hierarchy 294 A policy condition, in the context of the Policy Framework Working 295 Group, is defined as testing one or more aspects of users of the 296 network and/or traffic flowing through the network, in order to see if 297 either the correct policy state can be maintained, or if a newly 298 desired policy state can be achieved. 300 A PolicyRule is comprised of one or more policy conditions. Each policy 301 condition is represented by a PolicyConditionList. For simplicity, if 302 there are multiple PolicyConditionLists within a given PolicyRule, this 303 version of the PFDL requires that the PolicyConditionLists are 304 logically ORed together. 306 A PolicyConditionList aggregates one or more PolicyConditionStatements. 307 For simplicity, this version of this draft requires that each of the 308 PolicyConditionStatements within a given PolicyConditionList are 309 logically ANDed together. 311 A PolicyConditionStatement consists of two parts, called a 312 PolicyConditionCategory and a PolicyConditionValue. A 313 PolicyConditionStatement defines a relation between a 314 PolicyConditionCategory and a PolicyConditionValue. 316 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 318 PolicyConditionCategories are predefined elements that are specific 319 to a particular knowledge domain. They form the structure of the 320 condition half of the policy rule template. For example, concepts like 321 user, location, application type, and service are all categories of 322 conditions that can be tested for a QoS policy, and hence are QoS 323 PolicyConditionCategories. 325 PolicyConditionValues represent the value that a given 326 PolicyConditionCategory can take. Some of the limits and other general 327 parameters of a PolicyConditionValue are pre-defied (e.g., a valid 328 network address must be entered), but only to enforce validation of a 329 specific value to be tested. PolicyConditionValues are the means to 330 represent user- and application-specific values of the category of 331 elements that are to be tested as part of this policy rule. 332 The PFDL MUST support the representation and structuring of policy 333 conditions as defined in this section. 335 3.1.5 The PolicyAction class hierarchy 337 The PolicyAction class is in reality a list of one or more policy 338 action statements. These policy action statement may be executed either 339 in any order (default case) or in a prescribed order, through the use 340 of specially defined attributes. 342 A policy action, in the context of the Policy Framework Working Group, 343 is defined as the changing of the configuration of one or more network 344 elements in order to achieve a desired policy state. This (new) policy 345 state provides one or more (new) behaviors. 347 A PolicyRule is comprised of one or more policy actions. Each policy 348 action is represented by a PolicyActionList. In contrast with 349 PolicyConditionLists, the PolicyActionLists are not by default ORed 350 together. In fact, the default relationship between a set of 351 PolicyActionLists is that they are all executed in ANY order. To 352 accommodate special situations, facilities exist for imposing an 353 ordering of the PolicyActionLists as well as conditional execution of 354 one or more PolicyActionLists based on the outcome (e.g., success or 355 failure) of a previously executed PolicyActionList. 357 A PolicyActionList aggregates one or more PolicyActionStatements. The 358 PolicyActionStatements within a given PolicyActionList are by default 359 executed in ANY order. However, facilities exist for imposing an 360 ordering of the PolicyActionStatements within a given PolicyActionList 361 as well as conditional execution of one or more PolicyActionStatements 362 based on the outcome (e.g., success or failure) of a previously 363 executed PolicyActionStatement. 365 A PolicyActionStatement is comprised of two parts, a 366 PolicyActionCategory and a PolicyActionValue. A PolicyActionStatement 367 defines a relation between a PolicyActionCategory and a 368 PolicyActionValue. However, the PolicyActionValue is dependent on the 369 type of PolicyActionCategory. Therefore, the PFDL combines these. 371 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 373 The PolicyActionCategory defines a canonical set of operations or 374 treatments that can be given to traffic flowing into and out of a 375 network element (e.g., deny, change code point, etc.) in a vendor- and 376 device-independent manner. The PolicyActionValue specifies the type of 377 mechanism to be used to provide the specified operation or treatment. 378 PolicyActionCategories are predefined elements that are specific to a 379 particular knowledge domain. They form the structure of the action half 380 of the policy rule template. For example, concepts like providing a 381 specific service for a particular application or class of traffic are 382 categories of actions that can be performed for a QoS policy, and hence 383 are QoS PolicyActionCategories. 385 A PolicyActionValue represents the value that a given 386 PolicyActionCategory can take. Some of the limits and other general 387 parameters of a PolicyActionValue are pre-defied (e.g., a valid network 388 address must be entered), but only to enforce validation of a specific 389 action to be performed. PolicyActionValues are the means to represent 390 user- and application-specific values of the category of services that 391 are to be provided by a specified network element as part of this 392 policy rule. 394 The PFDL MUST support the representation and structuring of policy 395 actions as defined in this section. 397 3.2 Policy Conflict Detection 399 Policy conflict detection is crucial to the design of a scalable and 400 deployable policy framework. The concept of policy detection is 401 actually fairly straightforward. However, the implementation of policy 402 conflict detection can be quite complicated in the general case. 403 Therefore, this proposal explicitly limits the power and flexibility of 404 the PFDL in order to ensure that conflict detection and resolution is 405 both doable and implementable. 407 3.2.1 Types of Policy Conflicts 409 There are two fundamental types of policy conflicts: those caused by 410 within a policy (either a SimplePolicy or a ComplexPolicy) and those 411 that cause a conflicting action to be taken in the network. These are 412 referred to as Intra- and Inter-Policy conflicts. 414 3.2.2 Intra-Policy Conflicts 416 An intra-policy conflict occurs when the conditions of two or more 417 policies can be simultaneously satisfied, but the actions of at least 418 one of the policies can not be simultaneously executed. This implies 419 several things: 420 - one or more policy rules of each of the policies is satisfied by 421 the same request 422 - each condition of each of the conflicting policy rules is 423 satisfied by the same request 425 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 427 - one or more actions specified by one policy conflict with one or 428 more actions specified by the other policy 430 Intra-policy conflicts can be resolved in a number of different ways. 431 The simplest is to change the conditions and/or actions of one of the 432 policies so that it no longer conflicts with the other policies. 433 However, if the policies must remain inherently conflicting, then there 434 are a number of ways to resolve the conflict on an individual event 435 basis, including the following: 437 - apply a "match-first" criteria, wherein conflicts are resolved by 438 matching the first policy that is found 439 - apply a priority order criteria, wherein conflicts are resolved 440 by finding all policy rules which match a given event and 441 selecting only the rule with the highest priority 442 - use additional metadata to determine which rule or rules should 443 be applied. The difference between this and straight priority is 444 that priority is inherently linear, whereas metadata enables non- 445 linear solutions, such as branching, to be used. 447 The PFDL MUST support facilities to resolve conflicts. 449 3.2.3 Inter-Policy Conflicts 451 An inter-policy conflict is defined as two or more policies that, when 452 applied to the network, result in conflicting configuration commands 453 and/or mechanisms to be specified for one or more network devices. It 454 is important to note that in this case, the two (or more) conflicting 455 policies do not conflict when compared to each other, but do conflict 456 when applied to a specific network device or devices. For example, two 457 policies could specify conflicting configurations on a given interface, 458 or specify that a certain number of queues be used in one network 459 device and a different number of queues be used in another network 460 device for the same traffic flow. 462 The PFDL must support constructs that enable such conflicts to be 463 resolved. 465 3.3 Service and Usage Policies 467 There are two different types of policies. They are called Service 468 Policies and Usage Policies. It is not mandatory for the PFDL to 469 support explicit identification of whether a policy is categorized as a 470 service or a usage policy - this is really more for the convenience of 471 an associated UI and for the implementation of a Policy Server. 472 However, the PFDL should not prevent the optional specification of 473 whether a policy is categorized as a service or usage policy. 475 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 477 3.3.1 Service Policies 479 Service policies describe the creation of services in the network. They 480 organize the facilities that the network provides into services that 481 may be used later to satisfy the requirements of users of the network. 482 For example, creating various QoS service classes (VoiceTransport, 483 VideoTransport, ..., BestEffort) is done using service policies. This 484 is accomplished, for example, by establishing the PHBs needed on 485 backbone interfaces over which the traffic to be afforded the specific 486 service is to flow. 488 The application of a service policy results in the creation of one or 489 more named objects that represents network services that are available 490 for usage policies. 492 3.3.2 Usage Policies 494 Usage policies describe how to allocate the services created by Service 495 policies to requestors of services. Usage policies describe particular 496 mechanism(s) employed to either maintain the current state of the 497 object, or to transition an object from one state to a new state, in 498 order to utilize the specified services. 500 Usage policies associate services that are provided by the network to 501 clients of the network (e.g., users and applications). This can include 502 services provided indirectly (e.g., mark packets of this type with this 503 DS value) as well as directly (use this set of reservation parameters 504 for this class of traffic). 506 Usage policy actions are specifically limited to associating a service 507 with a particular PolicyActionCategory. For example, all users in the 508 QuarterEndFinance group are assigned Gold Service for the SAP 509 application under the following conditions. 511 Put another way, service policies describe what the network is capable 512 of providing, and usage policies describe how to configure the network 513 in order to take advantage of one or more services that the network 514 provides. 516 3.4 Collective Aspects of Policy 518 An essential attribute of policy is its collective nature. That is, 519 policies are created in order to control many possibly heterogeneous 520 objects of the system that are under the control of a policy management 521 infrastructure. For example, when we create a particular PHB, we want 522 to be able to apply it to all the interfaces to which it is 523 appropriate. 525 Two mechanisms are provided for the collective aspects of policy: roles 526 and groups. 528 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 530 3.4.1 Roles 532 A role is a label. A role indicates a function that an interface or 533 device in the network serves. For example, an interface in the core of 534 the network connecting to another interface in the core of the network 535 provides "backbone" services (it aggregates a large number of flows; it 536 is very high speed; etc). We assign to this interface the role 537 "BackBone". When we create a policy appropriate to interfaces serving a 538 backbone role, we assign the role "BackBone" to that policy. 540 Another important use of roles is to explicitly differentiate the 541 functions provided by a device. Continuing the above example, an "Edge" 542 role could be defined that describes the various services provided by 543 interfaces at the edge of the network (e.g., filtering, traffic 544 shaping, rate limiting, etc.). These services together describe the 545 functionality of an edge interface, but also serve to differentiate it 546 from the functionality of a core interface. 548 Roles enable an administrator to group the interfaces of multiple 549 devices into common groups. This enables the administrator to apply the 550 same policy to each of these interfaces collectively, as opposed to 551 individually. 553 A role may be associated with, at most, a single Policy (where a single 554 Policy may be as complex as necessary. Policies associated with a role 555 are specifically intended to apply to interfaces or devices that are 556 assigned the role. 558 An interface may be assigned multiple roles. When an interface is 559 assigned multiple roles, the policies designated by those roles are 560 intended to apply to that interface. Roles may be parameterized. This 561 is to enable the definition of more complex policies that define 562 configurations that contain values that depend on the combination of 563 type of interface, media being used, protocol being used, and other 564 factors. For example, a policy might be applied to all Frame Relay 565 interfaces. Depending on the actual network topology, the types of 566 congestion experienced in these interfaces might be different. The 567 parameterized policy offers a way to group these Frame Relay interfaces 568 together (to simplify administration) while providing an inherent 569 flexibility to accommodate the particular semantics of interfaces that 570 are identified by this role. 572 For example, some kind of conditional expression associated with a Role 573 which partitions the space of interfaces. Those interfaces included by 574 the conditional would take the role; those interfaces not included by 575 the conditional would not take the role. 577 When there are several roles assigned to an interface, inter-policy 578 conflicts may occur. They are resolved as described in section 3.2.2. 580 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 582 3.4.2 Groups 584 Grouping is a fundamental concept of aggregation. In most systems, a 585 group is a named object that contains individual objects as well as 586 possibly additional (sub-)groups of objects. The key point here is that 587 group membership is statically determined. 589 Unfortunately, networks are inherently dynamic in nature. This means 590 that the ability to "group" objects whose membership is determined 591 dynamically (e.g., a s a function of the state of the system) is 592 required. We will call this a "Dynamic Group". The most important 593 characteristic of a Dynamic Group is that its membership is determined 594 dynamically when a reference to the Dynamic Group is evaluated. 596 Dynamic Group objects can therefore represent either individual objects 597 or other groupings of objects. For example, a Dynamic Group ranging 598 over users may be used to limit which users on a certain set of 599 interfaces have a certain kind of QoS assigned to packets they 600 generate. 602 A Dynamic Group is only used as a value part of a condition of a 603 policy. If a PolicyConditionValue uses a grouping construct, then that 604 policy is satisfied if the object specified in the 605 PolicyConditionCategory satisfies the relationship specified in the 606 policy between the object in the PolicyConditionCatgegory and the 607 membership of the Dynamic Group specified in the PolicyConditionValue. 608 For example, suppose that a logon is in progress. Further suppose that 609 a policy tests for users who are engineers belonging to a group that is 610 to receive Gold QoS. Then, at the instant of the testing of the 611 condition, the set of user objects that the Dynamic Group specifies 612 (people that are entitled to receive Gold QoS) is determined. 613 If the object representing the user logging in is in the set specified 614 by the Dynamic Group, then this condition of the policy is satisfied. 616 The objects of a Dynamic Group are always determined by the range of 617 objects that the PolicyConditionCategory can specify. For example, 618 there are several ways in which the type can specify 619 the objects that it contains. These same methods can be used by other 620 types of PolicyConditionCategories, but the different semantics of each 621 type of PolicyConditionCategory result in different memberships being 622 built for PolicyConditionCategory. 624 There are several ways in which a Dynamic Group can specify the objects 625 It designates: by characterization, by enumeration, or by a combination 626 of the two. A Dynamic Group uses characterization in order to be able 627 to explicitly define acceptable values for the attributes of the 628 object. For example, suppose that a object has the 629 attributes name, job title, and supervisor. A group, LucasEngineers, 630 might be characterized as follows: 632 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 634 Group over named LucasEngineers: 635 Job Title = "engineer", 636 Supervisor = "Luca". 638 Then, a condition might be written as follows: 640 IN LucasEngineers 642 This condition would be satisfied in the user designated by the 643 object being tested in the above had a supervisor 644 attribute named "Luca" and job title attribute named "engineer". 646 A Dynamic Group may also specify the objects that are its members using 647 enumeration. That is, the individual objects that the Dynamic Group is 648 to specify may simply be explicitly listed. For example, a Dynamic 649 Group of type can refer to the objects it contains, 650 (e.g., LucasEngineers) by explicitly listing its members as opposed to 651 characterizing attributes or behaviors of those objects. If the 652 membership of the LucasEngineers Dynamic Group was explicitly defined, 653 it might look as follows: 655 {, , , } 657 where each of the bracketed entities refers to a user object. 659 Finally, a group may specify the object it designates by both 660 characterization and enumeration. The above examples could easily be 661 combined to yield such a group. 663 4. The Grammar of the PFDL 665 667 5. Examples of Using the PFDL 669 671 6. Security Considerations 673 Security and denial of service considerations are not explicitly 674 considered in this memo, as they are appropriate for the underlying 675 policy architecture. However, the policy architecture must be secure 676 as far as the following aspects are concerned. First, the mechanisms 677 proposed under the framework must minimize theft and denial of service 678 threats. Second, it must be ensured that the entities (such as PEPs and 679 PDPs) involved in policy control can verify each other's identity and 680 establish necessary trust before communicating. 682 7. Acknowledegments 684 Many thanks to the useful discussions and suggestions from the Internet 685 Community at large but especially to . 687 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 689 8. References 691 [TERMS] S. Bradner, "Key words for use in RFCs to Indicate 692 Requirement Levels", Internet RFC 2119, March 1997. 694 696 9. Authors' Addresses 698 John Strassner 699 Cisco Systems 700 170 West Tasman Drive, Building 1 701 San Jose, CA 95134 702 Phone: +1-408-527-1069 703 Fax: +1-408-527-1722 704 E-mail: johns@cisco.com 706 Stephen Schleimer 707 Cisco Systems 708 170 West Tasman Drive, Building D 709 San Jose, CA 95134 710 Phone: +1-408-527-3291 711 Fax: +1-408-???-???? 712 E-mail: sschlmr@cisco.com 714 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 716 Appendix A: BNF of the PFDL 718 719 ::= []+ 721 722 ::= []+ 723 | ':' []+ 725 726 ::= 'IF' 727 'THEN' 729 /* still have to put in priority */ 730 ::= ]* 732 733 ::= 734 ['AND' ]* 736 737 ::= 738 | 'NOT' 740 741 ::= 742 | 743 | 744 | 745 | 746 | 747 | 748 | 749 | 751 752 ::= USER_CATEGORY_REFERENCE 753 755 /* the values for are all either email addresses 756 or a Distinguished Name */ 757 /* the following are all DNs */ 758 ::= 759 | 760 | /* "division" */ 761 | 763 764 ::= APPLICATION_CATEGORY_REFERENCE 765 767 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 769 770 ::= 771 | 'SOURCE:' 772 | 'DESTINATION:' 774 775 ::= DEVICE_CATEGORY_REFERENCE 776 778 779 ::= 780 | 781 | 783 784 ::= INTERFACE_CATEGORY_REFERENCE 785 787 788 ::= 790 791 ::= PROTOCOL_CATEGORY_REFERENCE 792 794 795 ::= []* 796 | []* 798 799 ::= ADDRESS_CATEGORY_REFERENCE 800 802 803 ::= 'SOURCE:' 804 | 'DESTINATION:' 805 | 'BOTH:' 807 808 ::= TRAFFIC_CATEGORY_REFERENCE 809 811 812 ::= 813 | 814 | 815 | 816 | 818 819 ::= SLA_CATEGORY_REFERENCE 820 822 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 824 825 ::= 'SLA NAME:' SLA_VALUE []* 827 828 ::= TIME_CATEGORY_REFERENCE 829 831 832 ::= 833 | 835 836 ::= 837 | 839 840 ::= 'IN' 841 | 'NOT IN' 842 | 'EQUALS' 843 | 'NOT EQUALS' 844 | 'GREATER THAN' 845 | 'GREATER THAN OR EQUAL TO' 846 | 'LESS THAN' 847 | 'LESS THAN OR EQUAL TO' 849 850 ::= []+ 852 853 ::= [] [] 855 856 ::= 'PERMIT' 857 | 'DENY' 858 | 'REMARK PACKET' 859 | 'START USING' 860 | 'STOP USING' 861 | 'Table Definition' 863 864 ::= '{' "}" 866 867 ::= 'RED_THRESHOLDS' 868 | 'TAIL_DROP' 869 | ... 871 872 ::= '{' '}' 874 875 ::= INTEGER 877 INTERNET DRAFT draft-ietf-policy-framework-pfdl-00.txt 17 Nov 98 879 880 ::= '{' INTEGER* '}' 882 883 ::= '{' * '}' 885 886 ::= '{' * '}' 887 | '{' * '}' 889 890 ::= INTEGER 891 | ':' INTEGER 893 894 ::= INTEGER 896 897 ::= INTEGER