idnits 2.17.1 draft-ietf-policy-pcim-ext-00.txt: -(1554): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1774): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1777): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1932): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1935): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 7 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 19) being 60 lines 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 814 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1638 has weird spacing: '...irrored bool...' -- 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) -- Looks like a reference, but probably isn't: 'FirstMatching' on line 1730 -- Looks like a reference, but probably isn't: 'AllMatching' on line 1729 -- Looks like a reference, but probably isn't: 'PCIM' on line 2643 == Unused Reference: '2' is defined on line 3165, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 3172, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2028 (ref. '2') (Obsoleted by RFC 9281) -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-05) exists of draft-ietf-policy-qos-info-model-02 == Outdated reference: A later version (-06) exists of draft-ietf-ipsp-config-policy-model-02 -- Possible downref: Normative reference to a draft: ref. '7' ** Obsolete normative reference: RFC 2234 (ref. '8') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2373 (ref. '10') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2252 (ref. '11') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Policy Framework Working Group B. Moore 2 INTERNET-DRAFT L. Rafalow 3 Category: Standards Track IBM 4 Y. Ramberg 5 Y. Snir 6 J. Strassner 7 A. Westerinen 8 Cisco Systems 9 R. Chadha 10 Telcordia Technologies 11 M. Brunner 12 NEC 13 R. Cohen 14 Ntear LLC 15 February, 2001 17 Policy Core Information Model Extensions 19 20 Friday, February 23, 2001, 11:07 AM 22 Status of this Memo 24 This document is an Internet-Draft and is in full conformance with all 25 provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering Task 28 Force (IETF), its areas, and its working groups. Note that other groups 29 may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months and 32 may be updated, replaced, or obsoleted by other documents at any time. 33 It is inappropriate to use Internet-Drafts as reference material or to 34 cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright Notice 44 Copyright (C) The Internet Society (2001). All Rights Reserved. 46 Abstract 48 This document proposes a number of changes to the Policy Core Information 49 Model (PCIM, RFC 3060). These changes include both extensions of PCIM 50 into areas that it did not previously cover, and changes to the existing 51 PCIM classes and associations. Both sets of changes are done in a way 52 that, to the extent possible, preserves interoperability with 53 implementations of the original PCIM model. 55 Table of Contents 57 1. Introduction......................................................4 58 2. Overview of the Changes...........................................4 59 2.1. How to Change an Information Model...........................4 60 2.2. List of Changes to the Model.................................5 61 2.2.1. Changes to PolicyRepository................................5 62 2.2.2. Additional Associations and Additional Reusable Elements...5 63 2.2.3. Priorities and Decision Strategies.........................5 64 2.2.4. Policy Roles...............................................6 65 2.2.5. CompoundPolicyConditions and CompoundPolicyActions.........6 66 2.2.6. Variables and Values.......................................7 67 2.2.7. Packet Filtering...........................................7 68 3. The Updated Class and Association Class Hierarchies...............7 69 4. Areas of Extension to PCIM.......................................11 70 4.1. Scope of Policies: Domain Policies and Device Policies.....11 71 4.2. Reusable Policy Elements....................................12 72 4.3. Policy Sets.................................................13 73 4.4. Nested Policy Rules.........................................13 74 4.4.1. Usage Rules for Nested Rules..............................13 75 4.4.2. Motivation................................................14 76 4.4.3. Usage Example.............................................15 77 4.5. Priorities and Decision Strategies..........................16 78 4.5.1. Structuring Decision Strategies...........................17 79 4.5.2. Deterministic Decisions...................................18 80 4.5.3. Multiple PolicySet Trees For a Resource...................19 81 4.6. Policy Roles................................................19 82 4.6.1. Comparison of Roles in PCIM with Roles in snmpconf........19 83 4.6.2. Addition of PolicyRoleCollection to PCIMe.................20 84 4.6.3. Roles for PolicyGroups....................................21 85 4.7. Compound Policy Conditions and Compound Policy Actions......22 86 4.7.1. Compound Policy Conditions................................23 87 4.7.2. Compound Policy Actions...................................23 88 4.8. Variables and Values........................................25 89 4.8.1. Simple Policy Conditions..................................25 90 4.8.2. Using Simple Policy Conditions............................26 91 4.8.3. The Simple Condition Operator.............................27 92 4.8.4. SimplePolicyActions.......................................28 93 4.8.5. Policy Variables..........................................30 94 4.8.6. Explicitly Bound Policy Variables.........................30 95 4.8.7. Implicitly Bound Policy Variables.........................31 96 4.8.8. Structure and Usage of Pre-Defined Variables..............32 97 4.8.9. Rationale for Modeling Implicit Variables as Classes......33 98 4.8.10. Policy Values............................................34 99 4.9. Packet Filtering............................................34 100 5. Class Definitions................................................36 101 5.1. The Abstract Class "PolicySet"..............................36 102 5.2. Updates to PCIM's Class "PolicyGroup".......................37 103 5.3. Updates to PCIM's Class "PolicyRule"........................37 104 5.4. The Class "SimplePolicyCondition"...........................38 105 5.5. The Class "CompoundPolicyCondition".........................38 106 5.6. The Class "CompoundFilterCondition".........................39 107 5.7. The Class "SimplePolicyAction"..............................39 108 5.8. The Class "CompoundPolicyAction"............................40 109 5.9. The Abstract Class "PolicyVariable".........................41 110 5.10. The Class "PolicyExplicitVariable".........................41 111 5.10.1. The Single-Valued Property "ModelClass"..................42 112 5.10.2. The Single-Valued Property ModelProperty.................42 113 5.11. The Abstract Class "PolicyImplicitVariable"................42 114 5.11.1. The Multi-Valued Property "ValueTypes"...................42 115 5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe..43 116 5.12.1. The Class "PolicySourceIPVariable".......................43 117 5.12.2. The Class "PolicyDestinationIPVariable"..................43 118 5.12.3. The Class "PolicySourcePortVariable".....................43 119 5.12.4. The Class "PolicyDestinationPortVariable"................44 120 5.12.5. The Class "PolicyIPProtocolVariable".....................44 121 5.12.6. The Class "PolicyIPVersionVariable"......................44 122 5.12.7. The Class "PolicyIPToSVariable"..........................44 123 5.12.8. The Class "PolicyDSCPVariable"...........................45 124 5.12.9. The Class "PolicySourceMACVariable"......................45 125 5.12.10. The Class "PolicyDestinationMACVariable"................45 126 5.12.11. The Class "PolicyVLANVariable"..........................45 127 5.12.12. The Class "PolicyCoSVariable"...........................46 128 5.12.13. The Class "PolicyEthertypeVariable".....................46 129 5.12.14. The Class "PolicySourceSAPVariable".....................46 130 5.12.15. The Class "PolicyDestinationSAPVariable"................46 131 5.12.16. The Class "PolicySNAPVariable"..........................47 132 5.12.17. The Class "PolicyFlowDirectionVariable".................47 133 5.13. The Abstract Class "PolicyValue"...........................47 134 5.14. Subclasses of "PolicyValue" Specified in PCIMe.............48 135 5.14.1. The Class "PolicyIPv4AddrValue"..........................48 136 5.14.2. The Class "PolicyIPv6AddrValue...........................49 137 5.14.3. The Class "PolicyMACAddrValue"...........................50 138 5.14.4. The Class "PolicyStringValue"............................50 139 5.14.5. The Class "PolicyBitStringValue".........................51 140 5.14.6. The Class "PolicyIntegerValue"...........................51 141 5.14.7. The Class "PolicyBooleanValue"...........................52 142 5.15. The Class "PolicyRoleCollection"...........................53 143 5.15.1. The Single-Valued Property "PolicyRole"..................53 144 5.16. The Class "ReusablePolicyContainer"........................53 145 5.17. Deprecation of PCIM's Class "PolicyRepository".............53 146 6. Association and Aggregation Definitions..........................54 147 6.1. The Abstract Aggregation "PolicySetComponent"...............54 148 6.2. Update to PCIM's Aggregation "PolicyGroupInPolicyGroup".....54 149 6.3. Update to PCIM's Aggregation "PolicyRuleInPolicyGroup"......55 150 6.4. The Aggregation "PolicyGroupInPolicyRule"...................55 151 6.5. The Aggregation "PolicyRuleInPolicyRule"....................56 152 6.6. The Abstract Aggregation "CompoundedPolicyCondition"........56 153 6.7. Update to PCIM's Aggregation "PolicyConditionInPolicyRule"..57 154 6.8. The Aggregation "PolicyConditionInPolicyCondition"..........57 155 6.9. The Abstract Aggregation "CompoundedPolicyAction"...........57 156 6.10. Update to PCIM's Aggregation "PolicyActionInPolicyRule"....57 157 6.11. The Aggregation "PolicyActionInPolicyAction"...............58 158 6.12. The Aggregation "PolicyVariableInSimplePolicyCondition"....58 159 6.13. The Aggregation "PolicyValueInSimplePolicyCondition".......59 160 6.14. The Aggregation "PolicyVariableInSimplePolicyAction".......59 161 6.15. The Aggregation "PolicyValueInSimplePolicyAction"..........60 162 6.16. The Association "ReusablePolicy"...........................61 163 6.17. Deprecate PCIM's "PolicyConditionInPolicyRepository".......61 164 6.18. Deprecate PCIM's "PolicyActionInPolicyRepository"..........61 165 6.19. The Association PolicyValueConstraintInVariable............61 166 6.20. The Aggregation "PolicyContainerInPolicyContainer".........62 167 6.21. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"......62 168 6.22. The Aggregation "ElementInPolicyRoleCollection"............63 169 6.22.1. The Weak Association "PolicyRoleCollectionInSystem"......63 170 7. Intellectual Property............................................64 171 8. Acknowledgements.................................................64 172 9. Security Considerations..........................................64 173 10. References......................................................64 174 11. Authors' Addresses..............................................65 175 12. Full Copyright Statement........................................67 176 13. Appendix A: Open Issues.........................................67 178 1. Introduction 180 This document (PCIM Extensions, abbreviated here to PCIMe) proposes a 181 number of changes to the Policy Core Information Model (PCIM, RFC 3060 182 [3]). These changes include both extensions of PCIM into areas that it 183 did not previously cover, and changes to the existing PCIM classes and 184 associations. Both sets of changes are done in a way that, to the extent 185 possible, preserves interoperability with implementations of the original 186 PCIM model. 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in RFC 2119, reference [1]. 192 2. Overview of the Changes 194 2.1. How to Change an Information Model 196 The Policy Core Information Model is closely aligned with the DMTF's CIM 197 Core Policy model. Since there is no separately documented set of rules 198 for specifying IETF information models such as PCIM, it is reasonable to 199 look to the CIM specifications for guidance on how to modify and extend 200 the model. Among the CIM rules for changing an information model are the 201 following. Note that everything said here about "classes" applies to 202 association classes (including aggregations) as well as to non- 203 association classes. 205 o Properties may be added to existing classes. 206 o Classes, and individual properties, may be marked as DEPRECATED. 207 If there is a replacement feature for the deprecated class or 208 property, it is identified explicitly. Otherwise the notation "No 209 value" is used. In this document, the notation "DEPRECATED FOR 210 " is used to indicate that a feature has been 211 deprecated, and to identify its replacement feature. 212 o Classes may be inserted into the inheritance hierarchy above 213 existing classes, and properties from the existing classes may 214 then be "pulled up" into the new classes. The net effect is that 215 the existing classes have exactly the same properties they had 216 before, but the properties are inherited rather than defined 217 explicitly in the classes. 218 o New subclasses may be defined below existing classes. 220 2.2. List of Changes to the Model 222 The following subsections provide a very brief overview of the changes to 223 PCIM being proposed in PCIMe. 225 2.2.1. Changes to PolicyRepository 227 Because of the potential for confusion with the Policy Framework 228 component Policy Repository (from the four-box picture: Policy Management 229 Tool, Policy Repository, PDP, PEP), "PolicyRepository" is a bad name for 230 the PCIM class representing a container of reusable policy elements. 231 Thus the class PolicyRepository is being replaced with the class 232 ReusablePolicyContainer. To accomplish this change, it is necessary to 233 deprecate the PCIM class PolicyRepository and its three associations, and 234 replace them with a new class ReusablePolicyContainer and new 235 associations. 237 As a separate change, the associations for ReusablePolicyContainer are 238 being broadened, to allow a ReusablePolicyContainer to contain any 239 reusable policy elements. In PCIM, the only associations defined for a 240 PolicyRepository were for it to contain reusable policy conditions and 241 policy actions. 243 2.2.2. Additional Associations and Additional Reusable Elements 245 The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule aggregations are 246 being imported from QPIM. These associations make it possible to define 247 larger "chunks" of reusable policy to place in a ReusablePolicyContainer. 248 These aggregations also introduce new semantics representing the 249 contextual implications of having one PolicyRule executing within the 250 scope of another PolicyRule. 252 2.2.3. Priorities and Decision Strategies 254 Drawing from both QPIM and ICIM, the Priority property is being 255 deprecated in PolicyRule, and placed instead on the aggregations 256 PolicyRuleInPolicyGroup, PolicyGroupInPolicyGroup, 257 PolicyGroupInPolicyRule, and PolicyRuleInPolicyRule. (This is 258 accomplished by placing the Priority property on the abstract aggregation 259 PolicySetComponent, from which these four aggregations are derived.) The 260 QPIM rules for resolving relative priorities across nested PolicyGroups 261 and PolicyRules are being incorporated into PCIMe as well. With the 262 removal of the Priority property from PolicyRule, a new modeling 263 dependency is introduced: in order to prioritize a PolicyRule relative to 264 other PolicyRules, the rules must be placed in either a common 265 PolicyGroup or a common PolicyRule. 267 In the absence of any clear, general criterion for detecting policy 268 conflicts, the PCIM restriction stating that priorities are relevant only 269 in the case of conflicts is being removed. In its place, a 270 PolicyDecisionStrategy property is being added to the PolicyGroup and 271 PolicyRule classes, to allow the policy administrator to select one of 272 two behaviors with respect to rule evaluation: either perform the actions 273 for all PolicyRules whose conditions evaluate to TRUE, or perform the 274 actions only for the highest-priority PolicyRule whose conditions 275 evaluate to TRUE. (Once again this is accomplished by placing the 276 PolicyDecisionStrategy property in an abstract class PolicySet, from 277 which PolicyGroup and PolicyRule are derived.) The QPIM rules for 278 applying decision strategies to a nested set of PolicyGroups and 279 PolicyRules are also being imported. 281 2.2.4. Policy Roles 283 The concept of policy roles is added to PolicyGroups (being present 284 already in the PolicyRule class). This is accomplished via a new 285 superclass for both PolicyRules and PolicyGroups - PolicySets. For 286 nested PolicyRules and PolicyGroups, any roles associated with the outer 287 rule or group are automatically "inherited" by the nested one. 288 Additional roles may be added at the level of the nested rule or group. 290 It was also observed that there was no mechanism in PCIM for assigning 291 roles to resources. For example, while it was possible to associate a 292 PolicyRule with the role "FrameRelay&&WAN", there was no way to indicate 293 which interfaces matched this criterion. A new PolicyRoleCollection 294 class is defined in PCIMe, representing the collection of resources 295 associated with a particular role. The linkage between a PolicyRule or 296 PolicyGroup and a set of resources is then represented by an instance of 297 PolicyRoleCollection. Equivalent values should be defined in entries in 298 the PolicyRoles property, inherited by PolicyRules and PolicyGroups from 299 PolicySet, and in the PolicyRole property in PolicyRoleCollection. 301 2.2.5. CompoundPolicyConditions and CompoundPolicyActions 303 The concept of a CompoundPolicyCondition is also being imported into 304 PCIMe from QPIM, and broadened to include a parallel 305 CompoundPolicyAction. In both cases the idea is to create reusable 306 "chunks" of policy that can exist as named elements in a 307 ReusablePolicyContainer. The "Compound" classes and their associations 308 incorporate the condition and action semantics that PCIM defined at the 309 PolicyRule level: DNF/CNF for conditions, and ordering for actions. 311 Compound conditions and actions are defined to work with any component 312 conditions and actions. In other words, while the components may be 313 instances, respectively, of SimplePolicyCondition and SimplePolicyAction 314 (discussed immediately below), they need not be. 316 2.2.6. Variables and Values 318 The SimplePolicyCondition / PolicyVariable / PolicyValue structure is 319 being imported into PCIMe from QPIM. A list of PCIMe-level variables is 320 defined, as well as a list of PCIMe-level values. Other variables and 321 values may, if necessary, be defined in submodels of PCIMe. 323 A corresponding SimplePolicyAction / PolicyVariable / PolicyValue 324 structure is also defined. While the semantics of a 325 SimplePolicyCondition are "variable matches value", a SimplePolicyAction 326 has the semantics "set variable to value". 328 2.2.7. Packet Filtering 330 For packet filtering done in the context of a PolicyCondition, a set of 331 PolicyVariables and PolicyValues are defined, corresponding to the fields 332 in an IP packet header plus the most common Layer 2 frame header fields. 333 It is expected that policy conditions that filter on these header fields 334 will be expressed in terms of CompoundPolicyConditions built up from 335 SimplePolicyConditions that use these variables and values. An 336 additional PolicyVariable, PacketDirection, is also defined, to indicate 337 whether a packet being filtered is traveling inbound or outbound on an 338 interface. 340 For packet filtering in other contexts (specifically, for the packet 341 classifier filters modeled in QDDIM), these variables and values need not 342 be used. Filter classes derived from the CIM FilterEntryBase class 343 hierarchy may still be used in these contexts. 345 3. The Updated Class and Association Class Hierarchies 347 The following figure shows the class inheritance hierarchy for PCIMe. 348 Changes from the PCIM hierarchy are noted parenthetically. 350 ManagedElement (abstract) 351 | 352 +--Policy (abstract) 353 | | 354 | +---PolicySet (abstract -- new - 4.3) 355 | | | 356 | | +---PolicyGroup (moved - 4.3) 357 | | | 358 | | +---PolicyRule (moved - 4.3) 359 | | 360 | +---PolicyCondition (abstract) 361 | | | 362 | | +---PolicyTimePeriodCondition 363 | | | 364 | | +---VendorPolicyCondition 365 | | | 366 | | +---SimplePolicyCondition (new - 4.8.1) 367 | | | 368 | | +---CompoundPolicyCondition (new - 4.7.1) 369 | | | 370 | | +---CompoundFilterCondition (new - 4.9) 371 | | 372 | +---PolicyAction (abstract) 373 | | | 374 | | +---VendorPolicyAction 375 | | | 376 | | +---SimplePolicyAction (new - 4.8.4) 377 | | | 378 | | +---CompoundPolicyAction (new - 4.7.2) 379 | | 380 | +---PolicyVariable (abstract -- new - 4.8.5) 381 | | | 382 | | +---PolicyExplicitVariable (new - 4.8.6) 383 | | | 384 | | +---PolicyImplicitVariable (abstract -- new - 4.8.7) 385 | | | 386 | | +---(subtree of more specific classes -- new - 5.12) 387 | | 388 | +---PolicyValue (abstract -- new - 4.8.10) 389 | | 390 | +---(subtree of more specific classes -- new - 5.14) 391 | 392 +--Collection (abstract -- newly referenced) 393 | 394 +--PolicyRoleCollection (new - 4.6.2) 395 (continued on following page) 396 (continued from previous page) 397 ManagedElement(abstract) 398 | 399 +--ManagedSystemElement (abstract) 400 | 401 +--LogicalElement (abstract) 402 | 403 +--System (abstract) 404 | 405 +--AdminDomain (abstract) 406 | 407 +---ReusablePolicyContainer (new - 4.2) 408 | 409 +---PolicyRepository (deprecated - 4.2) 411 Figure 1. Class Inheritance Hierarchy for PCIMe 412 The following figure shows the association class hierarchy for PCIMe. As 413 before, changes from PCIM are noted parenthetically. 415 [unrooted] 416 | 417 +---PolicyComponent (abstract) 418 | | 419 | +---PolicySetComponent (abstract -- new - 4.3) 420 | | | 421 | | +---PolicyGroupInPolicyGroup (moved - 4.3) 422 | | | 423 | | +---PolicyRuleInPolicyGroup (moved - 4.3) 424 | | | 425 | | +---PolicyGroupInPolicyRule (new - 4.3) 426 | | | 427 | | +---PolicyRuleInPolicyRule (new - 4.3) 428 | | 429 | +---CompoundedPolicyCondition (abstract -- new - 4.7.1) 430 | | | 431 | | +---PolicyConditionInPolicyRule (moved - 4.7.1) 432 | | | 433 | | +---PolicyConditionInPolicyCondition (new - 4.7.1) 434 | | 435 | +---PolicyRuleValidityPeriod 436 | | 437 | +---CompoundedPolicyAction (abstract -- new - 4.7.2) 438 | | | 439 | | +---PolicyActionInPolicyRule (moved - 4.7.2) 440 | | | 441 | | +---PolicyActionInPolicyAction (new - 4.7.2) 442 | | 443 | +---PolicyVariableInSimplePolicyCondition (new - 4.8.2) 444 | | 445 | +---PolicyValueInSimplePolicyCondition (new - 4.8.2) 446 | | 447 | +---PolicyVariableInSimplePolicyAction (new - 4.8.4) 448 | | 449 | +---PolicyValueInSimplePolicyAction (new - 4.8.4) 451 (continued on following page) 452 (continued from previous page) 453 [unrooted] 454 | 455 +---Dependency (abstract) 456 | | 457 | +---PolicyInSystem (abstract) 458 | | | 459 | | +---PolicyGroupInSystem 460 | | | 461 | | +---PolicyRuleInSystem 462 | | | 463 | | +---ReusablePolicy (new - 4.2) 464 | | | 465 | | +---PolicyConditionInPolicyRepository (deprecated - 4.2) 466 | | | 467 | | +---PolicyActionInPolicyRepository (deprecated - 4.2) 468 | | 469 | +---PolicyValueConstraintInVariable (new - 4.8) 470 | | 471 | +---PolicyRoleCollectionInSystem (new - 4.6.2) 472 | 473 +---Component (abstract) 474 | | 475 | +---SystemComponent 476 | | 477 | +---PolicyContainerInPolicyContainer (new - 4.2) 478 | | 479 | +---PolicyRepositoryInPolicyRepository (deprecated - 4.2) 480 | 481 +---MemberOfCollection (newly referenced) 482 | 483 +--- ElementInPolicyRoleCollection (new - 4.6.2) 485 Figure 2. Association Class Inheritance Hierarchy for PCIMe 487 In addition to these changes that show up at the class and association 488 class level, there are other changes from PCIM involving individual class 489 properties. In some cases new properties are introduced into existing 490 classes, and in other cases existing properties are deprecated (without 491 deprecating the classes that contain them). 493 4. Areas of Extension to PCIM 495 The following subsections describe each of the areas for which PCIM 496 extensions are being defined. 498 4.1. Scope of Policies: Domain Policies and Device Policies 500 Policies vary in level of abstraction, from the business-level expression 501 of service level agreements (SLAs) to the specification of a set of rules 502 that apply to devices in a network. Those latter policies can, 503 themselves, be classified into at least two groups: those policies 504 consumed by a Policy Decision Point (PDP) that specify the rules for an 505 administrative and functional domain, and those policies consumed by a 506 Policy Enforcement Point (PEP) that specify the device-specific rules for 507 a functional domain. The higher-level rules consumed by a PDP may have 508 late binding variables unspecified, or specified by a classification, 509 whereas the device-level rules are likely to have fewer unresolved 510 bindings. 512 There is a relationship between these levels of policy specification that 513 is out of scope for this standards effort, but that is necessary in the 514 development and deployment of a usable policy-based configuration system. 515 An SLA-level policy transformation to the domain-level policy may be 516 thought of as analogous to a visual builder that takes human input and 517 develops a programmatic rule specification. The relationship between the 518 domain-level policy and the device-level policy may be thought of as 519 analogous to that of a compiler and linkage editor that translates the 520 rules into specific instructions that can be executed on a specific type 521 of platform. 523 The policy core information model may be used to specify rules at any and 524 all of these levels of abstraction. However, at different levels of 525 abstraction, different mechanisms may be more or less appropriate. 527 4.2. Reusable Policy Elements 529 In PCIM, a distinction was drawn between reusable PolicyConditions and 530 PolicyActions and rule-specific ones. The PolicyRepository class was 531 also defined, to serve as a container for these reusable elements. The 532 name "PolicyRepository" has proven to be an unfortunate choice for the 533 class that serves as a container for reusable policy elements. This term 534 is already used in documents like the Policy Framework, to denote the 535 location from which the PEP retrieves all policy specifications, and into 536 which the Policy Management Tool places all policy specifications. 537 Consequently, the PolicyRepository class is being deprecated, in favor of 538 a new class ReusablePolicyContainer. 540 When a class is deprecated, any associations that refer to it must also 541 be deprecated. So replacements are needed for the two associations 542 PolicyConditionInPolicyRepository and PolicyActionInPolicyRepository, as 543 well as for the aggregation PolicyRepositoryInPolicyRepository. In 544 addition to renaming the PolicyRepository class to 545 ReusablePolicyContainer, however, PCIMe is also broadening the types of 546 policy elements that can be reusable. Consequently, rather than 547 providing one-for-one replacements for the two associations, a single 548 higher-level association ReusablePolicy is defined. This new association 549 allows any policy element (that is, an instance of any subclass of the 550 abstract class Policy) to be placed in a ReusablePolicyContainer. 552 Summarizing, the following changes in Sections 5 and 6 are the result of 553 this item: 555 o The class ReusablePolicyContainer is defined. 556 o PCIM's PolicyRepository class is deprecated. 557 o The association ReusablePolicy is defined. 558 o PCIM's PolicyConditionInPolicyRepository association is deprecated. 559 o PCIM's PolicyActionInPolicyRepository association is deprecated. 560 o The aggregation PolicyContainerInPolicyContainer is defined. 561 o PCIM's PolicyRepositoryInPolicyRepository aggregation is deprecated. 563 4.3. Policy Sets 565 A "policy" can be thought of as a coherent set of rules to administer, 566 manage, and control access to network resources (PolTerm, reference 567 [12]). The structuring of these coherent sets of rules into subsets is 568 enhanced in this document. In section 4.4, we discuss the new options 569 for the nesting of policy rules. 571 A new abstract class, PolicySet, is introduced to provide an abstraction 572 for a set of rules. It is derived from Policy, and it is inserted into 573 the inheritance hierarchy above both PolicyGroup and PolicyRule. This 574 reflects the additional structure flexibility and semantic capability of 575 both subclasses. 577 Two properties are defined in PolicySet: PolicyDecisionStrategy and 578 PolicyRoles. PolicyDecisionStrategy is added to PolicySet to define the 579 evaluation relationship between the rules in the policy set. See section 580 4.5 for more information. PolicyRoles is added to PolicySet to name the 581 retrieval sets. See section 4.6 for more information. 583 Along with the definition of the PolicySet class, a new abstract 584 aggregation class is defined that will also be discussed in the following 585 sections. PolicySetComponent is defined as a subclass of 586 PolicyComponent; it provides the containment relationship for a 587 PolicySet. PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup are 588 modified to subclass from PolicySetComponent. PolicyGroupInPolicyRule 589 and PolicyRuleInPolicyRule, discussed in the next section, are also 590 defined as subclasses of PolicySetComponent. 592 4.4. Nested Policy Rules 594 As previously discussed, policy is described by a set of policy rules 595 that may be grouped into subsets. In this section we introduce the 596 notion of nested rules, or the ability to define rules within rules. 597 Nested rules are also called sub-rules, and we use both terms in this 598 document interchangeably. Two new aggregations are defined for this 599 purpose: PolicyRuleInPolicyRule and PolicyGroupInPolicyRule. 601 4.4.1. Usage Rules for Nested Rules 603 The relationship between rules and sub-rules is defined as follows: 605 o The parent rule's condition clause is a pre-condition for 606 evaluation of all nested rules. If the parent rule's condition 607 clause evaluates to FALSE, all sub-rules SHALL be skipped and 608 their condition clauses SHALL NOT be evaluated. 609 o If the parent rule's condition evaluates to TRUE, the set of sub- 610 rules SHALL BE executed according to the decision strategy and 611 priorities as discussed in Section 4.5. 612 o If the parent rule's condition evaluates to TRUE, the parent 613 rule's set of actions is executed BEFORE the evaluation and 614 execution of the sub-rules. The parent rule's actions are not to 615 be confused with default actions. A default action is one that is 616 to be executed only if none of the more specific sub-rules are 617 executed. If a default action needs to be specified, it needs to 618 be defined as an action that is part of a catchall sub-rule 619 associated with the parent rule. The association linking the 620 default action(s) in this special sub-rule should have the lowest 621 priority relative to all other sub-rule associations: 623 if precondition then parent rule's action 624 if condA then actA 625 if condB then ActB 626 if True then default action 628 Default actions have meaning when FirstMatching decision 629 strategies are in effect (see section 4.5). 631 o Policy rules have an implicit context in which they are executed. 632 For example, the context of a policy rule could be all packets 633 running on an interface or set of interfaces on which the rule is 634 applied. Similarly, a parent rule provides a context to all of 635 its sub-rules. The context of the sub-rules is the restriction of 636 the context of the parent rule to the set of cases that match the 637 parent rule's condition clause. 639 4.4.2. Motivation 641 The motivation for introducing nested rules includes enhancing the 642 definition of Policy, defining and reusing context hierarchies, 643 optimizing how a rule is evaluated, and providing finer-grained control 644 over condition evaluation. 646 Rule nesting enhances Policy readability, expressiveness and reusability. 647 The ability to nest policy rules and form sub-rules is important for 648 manageability and scalability, as it enables complex policy rules to be 649 constructed from multiple simpler policy rules. These enhancements ease 650 the policy management tools' task, allowing policy rules to be expressed 651 in a way closer to how humans think. 653 Sub-rules enable the policy designer to define a hierarchy of rules. 654 This hierarchy has the property that sub-rules can be scoped by their 655 parent rules. This scoping, or context of evaluation and execution, is a 656 powerful tool in enabling the policy designer to obtain the fine-grained 657 control needed to appropriately manage resources for certain 658 applications. The example in the following section demonstrates that 659 expressing relative bandwidth allocation rules can be done very naturally 660 using a hierarchical rule structure. 662 Rule nesting can be used to optimize the way policy rules are evaluated 663 and executed. Once the parent rule's condition clause is evaluated to 664 FALSE, all sub-rules are skipped, optimizing the number of lookups 665 required. Note that this is not the prime reason for rule nesting, but 666 rather a side benefit. Optimization of rule execution can be done in the 667 PDP or in the PEP by dedicated code. This is similar to the relation 668 between a high level programming language like C and machine code. An 669 optimizer can create a more efficient machine code than any optimization 670 done by the programmer within the source code. Nevertheless, if the PEP 671 or PDP does not do optimization, the administrator writing the policy can 672 optimize the policy rules for execution using rule nesting. 674 In a model where condition evaluation may have side effects, nesting 675 rules allow control of condition evaluation, as sub-rule conditions SHALL 676 NOT be evaluated if the condition of the parent rule evaluates to FALSE. 678 Nested rules are not designed for policy repository retrieval 679 optimization. It is assumed that all rules and groups that are assigned 680 to a role are retrieved by the PDP or PEP from the policy repository and 681 enforced. Optimizing the number of rules retrieved should be done by 682 clever selection of roles. 684 4.4.3. Usage Example 686 This section provides a usage example that aims to clarify the motivation 687 for the definition of rule nesting and the use of the relative context. 688 Consider the following example, where a set of rules is used to specify 689 the minimal bandwidth allocations on an interface. The policy reads: 691 On any interface on which these rules apply, allocate at 692 least 30% of the interface bandwidth to UDP flows, and at 693 least 40% of the interface bandwidth to TCP flows. 695 This single rule is translated to a set of two rules: 697 If (IP protocol is UDP) THEN Set MinBW to 30% (1) 698 If (IP protocol is TCP) THEN Set MinBW to 40% (2) 700 Now, let's add some sub-rules to further differentiate how bandwidth 701 should be allocated to specific UDP and TCP applications (indentation 702 indicates rule nesting): 704 If (IP protocol is UDP) THEN Set MinBW to 30% (1) 705 If (protocol is TFTP) THEN Set MinBW to 10% (1a) 706 If (protocol is NFS) THEN Set MinBW to 40% (1b) 707 If (IP protocol is TCP) THEN Set MinBW to 40% (2) 708 If (protocol is HTTP) THEN Set MinBW to 20% (2a) 709 If (protocol is FTP) THEN Set MinBW to 30% (2b) 710 This means that for UDP flows, TFTP should be allocated 10% of the 711 bandwidth while NFS should be allocated 40%. For TCP flows, HTTP should 712 be allocated 20% of the bandwidth while FTP should be allocated 30%. 714 The context of each of the two high-level rules (those marked (1) and (2) 715 above) is all flows running on an interface. The two sub-rules of the 716 UDP rule, marked (1a) and (1b) above specify a more granular context: 717 within UDP flows, TFTP should be allocated 10% of the bandwidth while NFS 718 should be allocated 40%. The context of these sub-rules is therefore UDP 719 flows only. Similar functionality applies for the hierarchy of rules 720 treating TCP flows. 722 A context hierarchy enhances reusability. The rules that divide 723 bandwidth between TFTP and NFS can be re-used and associated to rules 724 that allocate different percentages of the bandwidth for different 725 interfaces (or even for the same interface, but under different 726 conditions) for UDP. 728 4.5. Priorities and Decision Strategies 730 A "decision strategy" is used to specify the evaluation method for the 731 policies in a PolicySet. Two decision strategies are defined: 732 "FirstMatching" and "AllMatching." The FirstMatching strategy is used to 733 cause the evaluation of the rules in a set such that the actions of only 734 the first rule that matches are enforced on a given examination of the 735 PolicySet. The AllMatching strategy is used to cause the evaluation of 736 all rules in a set; for all of the rules that match, the actions are 737 enforced. (Strawman: Implementations MUST support the FirstMatching 738 decision strategy; implementations MAY support the AllMatching decision 739 strategy.) 741 As previously discussed, the PolicySet subclasses are PolicyGroup and 742 PolicyRule, and either subclass may contain PolicySets of either 743 subclass. Loops, including the degenerate case of a PolicySet that 744 contains itself, are not allowed when PolicySets contain other 745 PolicySets. The containment relationship is specified using the 746 PolicySetComponent subclasses: PolicyGroupInPolicyGroup, 747 PolicyRuleInPolicyGroup, PolicyGroupInPolicyRule and 748 PolicyRuleInPolicyRule. 750 The order of evaluation within a PolicySet is established by the Priority 751 property of the PolicySetComponent aggregation. Instances of the 752 subclasses of PolicySetComponent specify the relative priority of the 753 contained policy groups and rules within the containing group or rule. 754 The use of PCIM's PolicyRule.Priority property is deprecated in favor of 755 this new property. The separation of the priority property from the rule 756 has two advantages. First, it generalizes the concept of priority, so it 757 can be used for both groups and rules; and, second, it places the 758 priority on the relationship between the parent policy set and the 759 subordinate policy group or rule. The assignment of a priority value, 760 then, becomes much easier in that the value is used only in relationship 761 to other priorities in the same set. 763 Together, the PolicySet.PolicyDecisionStrategy and 764 PolicySetComponent.Priority determine the processing for the rules 765 contained in a PolicySet. As before, the larger priority value 766 represents the higher priority. Unlike the earlier definition, 767 PolicySetComponent.Priority MUST have a unique value when compared with 768 others defined for the aggregating PolicySet. Thus, the evaluation of 769 rules within a set is deterministically specified. 771 For a FirstMatching decision strategy, the order of evaluation, then, is 772 high to low priority. The first rule (i.e., the one with the highest 773 priority) in the set that evaluates to True, is the only rule whose 774 actions are enforced for a particular evaluation pass through the 775 PolicySet. 777 For an AllMatching decision strategy, the order of evaluation is also 778 from high priority to low priority; however, all of the matching rules 779 are executed. Although higher priority rules are evaluated first, lower 780 priority rules may get the "last word." So, for example, if two rules 781 both evaluate to True, and the higher priority rule sets the DSCP to 3 782 and the lower priority rule sets the DSCP to 4, the lower priority rule 783 will be evaluated later and, therefore, will "win," in this example, 784 setting the DSCP to 4. Thus, conflicts between rules are resolved by 785 this evaluation order. 787 4.5.1. Structuring Decision Strategies 789 When policy sets are nested, as shown in Figure 3, the decision 790 strategies may be nested arbitrarily. In this example, the evaluation 791 order for the nested rules is 1A, 1B1, 1X2, 1B3, 1C, 1C1, 1X2 and 1C3. 792 (Note that PolicyRule 1X2 is included in both PolicyGroup 1B and 793 PolicyRule 1C, but with different priorities.) Of course, the evaluation 794 order is also dependent on which rules, if any, match. 796 PolicyGroup 1: FirstMatching 797 | 798 +-- Pri=6 -- PolicyRule 1A 799 | 800 +-- Pri=5 -- PolicyGroup 1B: AllMatching 801 | | 802 | +-- Pri=5 -- PolicyGroup 1B1: AllMatching 803 | | | 804 | | +---- etc. 805 | | 806 | +-- Pri=4 -- PolicyRule 1X2 807 | | 808 | +-- Pri=3 -- PolicyRule 1B3: FirstMatching 809 | | 810 | +---- etc. 811 | 812 +-- Pri=4 -- PolicyRule 1C: FirstMatching 813 | 814 +-- Pri=4 -- PolicyRule 1C1 815 | 816 +-- Pri=3 -- PolicyRule 1X2 817 | 818 +-- Pri=2 -- PolicyRule 1C3 820 Figure 3. Nested PolicySets with Different Decision Strategies 822 o Because PolicyGroup 1 has a FirstMatching decision strategy, if 823 the conditions of PolicyRule 1A match, its actions are enforced 824 and the evaluation stops. 826 o If it does not match, PolicyGroup 1B is evaluated using an 827 AllMatching strategy. Since PolicyGroup 1B1 also has an 828 AllMatching strategy all of the rules and groups of rules 829 contained in PolicyGroup 1B1 are evaluated and enforced as 830 appropriate. PolicyRule 1X2 and PolicyRule 1B3 are also evaluated 831 and enforced as appropriate. If any of the sub-rules in the 832 subtrees of PolicyGroup 1B evaluate to True, then PolicyRule 1C is 833 not evaluated because the FirstMatching strategy of PolicyGroup 1 834 has been satisfied. 836 o If neither PolicyRule 1A nor PolicyGroup 1B yield a match, then 837 PolicyRule 1C is evaluated. Since it is first matching, rules 838 1C1, 1X2, and 1C3 are evaluated until the first match, if any. 840 4.5.2. Deterministic Decisions 842 As mentioned above, we propose that Priority values are to be unique 843 within a containing PolicySet. Although there are certainly cases where 844 rules need not have a unique priority value (i.e., where evaluation and 845 execution order is not important), it is believed that the flexibility 846 gained by this capability is not sufficiently beneficial to justify the 847 possible variations in implementation behavior and the resulting 848 confusion that might occur. 850 Therefore, all PolicySetComponent.Priority values MUST be unique among 851 the values in the aggregating PolicySet. Each PolicySet, then, has a 852 deterministic behavior based upon the decision strategy and uniquely 853 defined order of evaluation. 855 4.5.3. Multiple PolicySet Trees For a Resource 857 As shown in the example in Figure 3, PolicySet trees are defined by the 858 PolicySet subclass instances and the PolicySetComponent subclass 859 aggregation instances between them. Each PolicySet tree has a defined 860 set of decision strategies and evaluation orders. However, a given 861 resource may have multiple, disjoint PolicySet trees; we need a join 862 algorithm that describes the decision strategy and evaluation order among 863 the top-level (called "unrooted") PolicySet instances. (Note that an 864 unrooted PolicySet instance may only be unrooted in a given context.) 866 <> 868 4.6. Policy Roles 870 A policy role is defined in [12] as "an administratively specified 871 characteristic of a managed element (for example, an interface). It is a 872 selector for policy rules and PRovisioning Classes (PRCs), to determine 873 the applicability of the rule/PRC to a particular managed element." 875 In PCIMe, PolicyRoles is defined as a property of PolicySet, which is 876 inherited by both PolicyRules and PolicyGroups. In this draft, we also 877 add PolicyRole as the identifying name of a collection of resources 878 (PolicyRoleCollection), where each element in the collection has the 879 specified role characteristic. 881 4.6.1. Comparison of Roles in PCIM with Roles in snmpconf 883 In the Configuration Management with SNMP (snmpconf) working group's 884 Policy Based Management MIB [13], policy rules are of the form 886 if then 888 where is a set of conditions that are used to determine 889 whether or not the policy applies to an object instance. The policy 890 filter can perform comparison operations on SNMP variables already 891 defined in MIBS (e.g., "ifType == ethernet"). 893 The policy management MIB defined in [13] defines a Role table that 894 enables one to associate Roles with elements, where roles have the same 895 semantics as in PCIM. Then, since the policyFilter in a policy allows one 896 to define conditions based on the comparison of the values of SNMP 897 variables, one can filter elements based on their roles as defined in the 898 Role group. 900 This approach differs from that adopted in PCIM in the following ways. 901 First, in PCIM, a set of role(s) is associated with a policy rule as the 902 values of the PolicyRoles property of a policy rule. The semantics of 903 role(s) are then expected to be implemented by the PDP (i.e. policies are 904 applied to the elements with the appropriate roles). In [draft-ietf- 905 snmpconf-pm-04], however, no special processing is required for realizing 906 the semantics of roles; roles are treated just as any other SNMP 907 variables and comparisons of role values can be included in the policy 908 filter of a policy rule. 910 Secondly, in PCIM, there is no formally defined way of associating a role 911 with an object instance, whereas in [13] this is done via the use of the 912 Role tables (pmRoleESTable and pmRoleSETable). The Role tables associate 913 Role values with elements. 915 4.6.2. Addition of PolicyRoleCollection to PCIMe 917 In order to remedy the latter shortcoming in PCIM (i.e. the lack of a way 918 of associating a role with an object instance), we define a new class 919 PolicyRoleCollection that subclasses from the CIM Collection class. 920 Resources that share a common role belong to a PolicyRoleCollection 921 instance. Membership in this collection is indicated using the 922 aggregation ElementInPolicyRoleCollection. The resource's role is 923 specified in the PolicyRole property of the PolicyRoleCollection class. 925 A PolicyRoleCollection always exists in the context of a system. As was 926 done in PCIM for PolicyRules and PolicyGroups, this is captured by an 927 association, PolicyRoleCollectionInSystem. Remember that in PCIM, a 928 System is a base class for describing network devices and administrative 929 domains. 931 When associating a PolicyRoleCollection with a System, this should be 932 done consistently with the system that scopes the policy rules/groups 933 that are applied to the resources in that collection. A 934 PolicyRoleCollection is associated with the same system as the applicable 935 PolicyRules and/or PolicyGroups, or to a System higher in the tree formed 936 by the SystemComponent association. When a PEP belongs to multiple 937 Systems (i.e., AdminDomains), and scoping by a single domain is 938 impractical, two alternatives exist. One is to arbitrarily limit domain 939 membership to one System/AdminDomain. The other option is to define a 940 more global AdminDomain that simply includes the others, and/or that 941 spans the business or enterprise. 943 As an example, suppose that there are 20 traffic trunks in a network, and 944 that an administrator would like to assign three of them to provide 945 "gold" service. Also, the administrator has defined several policy rules 946 which specify how the "gold" service is delivered. For these rules, the 947 PolicyRoles property (inherited from PolicySet) is set to "Gold Service". 949 In order to associate three traffic trunks with "gold" service, an 950 instance of the PolicyRoleCollection class is created and its PolicyRole 951 property is also set to "Gold Service". Following this, the 952 administrator associates three traffic trunks with the new instance of 953 PolicyRoleCollection via the ElementInPolicyRoleCollection aggregation. 954 This enables a PDP to determine that the "Gold Service" policy rules 955 apply to the three aggregated traffic trunks. 957 Note that roles are used to optimize policy retrieval. It is not 958 mandatory to implement roles or, if they have been implemented, to group 959 elements in a PolicyRoleCollection. However, if roles are used, then 960 either the collection approach should be implemented, or elements should 961 be capable of reporting their "pre-programmed" roles (as is done in 962 COPS). 964 4.6.3. Roles for PolicyGroups 966 In PCIM, role(s) are only associated with policy rules. However, it may 967 be desirable to associate role(s) with groups of policy rules. For 968 example, a network administrator may want to define a group of rules that 969 apply only to Ethernet interfaces. A policy group can be defined with a 970 role-combination="Ethernet", and all the relevant policy rules can be 971 placed in this policy group. (Note that in PCIMe, role(s) are made 972 available to PolicyGroups as well as to PolicyRules by moving PCIM's 973 PolicyRoles property up from PolicyRule to the new abstract class 974 PolicySet. The property is then inherited by both PolicyGroup and 975 PolicyRule.) Then every policy rule in this policy group implicitly 976 inherits this role-combination from the containing policy group. A 977 similar implicit inheritance applies to nested policy groups. 979 Note that there is no explicit copying of role(s) from container to 980 contained entity. Obviously, this implicit inheritance of role(s) leads 981 to the possibility of defining inconsistent role(s) (as explained in the 982 example below); the handling of such inconsistencies is beyond the scope 983 of PCIMe. 985 As an example, suppose that there is a PolicyGroup PG1 that contains 986 three PolicyRules, PR1, PR2, and PR3. Assume that PG1 has the roles 987 "Ethernet" and "Fast". Also, assume that the contained policy rules have 988 the role(s) shown below: 990 +------------------------------+ 991 | PolicyGroup PG1 | 992 | PolicyRoles = Ethernet, Fast | 993 +------------------------------+ 994 | 995 | +------------------------+ 996 | | PolicyRule PR1 | 997 |--------| PolicyRoles = Ethernet | 998 | +------------------------+ 999 | 1000 | +--------------------------+ 1001 | | PolicyRule PR2 | 1002 |--------| PolicyRoles = | 1003 | +--------------------------+ 1004 | 1005 | +------------------------+ 1006 | | PolicyRule PR3 | 1007 |--------| PolicyRoles = Slow | 1008 +------------------------+ 1010 Figure 4. Inheritance of Roles 1012 In this example, the PolicyRoles property value for PR1 is consistent 1013 with the value in PG1, and in fact, did not need to be redefined. The 1014 value of PolicyRoles for PR2 is undefined. Its roles are implicitly 1015 inherited from PG1. Lastly, the value of PolicyRoles for PR3 is "Slow". 1016 This appears to be in conflict with the role, "Fast," defined in PG1. 1017 However, whether these roles are actually in conflict is not clear. In 1018 one scenario, the policy administrator may have wanted only "Fast"- 1019 "Ethernet" rules in the policy group. In another scenario, the 1020 administrator may be indicating that PR3 applies to all "Ethernet" 1021 interfaces regardless of whether they are "Fast" or "Slow." Only in the 1022 former scenario (only "Fast"-"Ethernet" rules in the policy group) is 1023 there a role conflict. 1025 Note that it is possible to override implicitly inherited roles via 1026 appropriate conditions on a PolicyRule. For example, suppose that PR3 1027 above had defined the following conditions: 1029 (interface is not "Fast") and (interface is "Slow") 1031 This results in unambiguous semantics for PR3. 1033 4.7. Compound Policy Conditions and Compound Policy Actions 1035 Compound policy conditions and compound policy actions are introduced to 1036 provide additional reusable "chunks" of policy. 1038 4.7.1. Compound Policy Conditions 1040 A CompoundPolicyCondition is a PolicyCondition representing a Boolean 1041 combination of simpler conditions. The conditions being combined may be 1042 SimplePolicyConditions (discussed below in section 4.7), but the utility 1043 of reusable combinations of policy conditions is not necessarily limited 1044 to the case where the component conditions are simple ones. 1046 The PCIM extensions to introduce compound policy conditions are 1047 relatively straightforward. Since the purpose of the extension is to 1048 apply the DNF / CNF logic from PCIM's PolicyConditionInPolicyRule 1049 aggregation to a compound condition that aggregates simpler conditions, 1050 the following changes are required: 1052 o Create a new aggregation PolicyConditionInPolicyCondition, with the 1053 same GroupNumber and ConditionNegated properties as 1054 PolicyConditionInPolicyRule. The cleanest way to do this is to 1055 move the properties up to a new abstract aggregation superclass 1056 CompoundedPolicyCondition, from which the existing aggregation 1057 PolicyConditionInPolicyRule and a new aggregation 1058 PolicyConditionInPolicyCondition are derived. For now there is no 1059 need to re-document the properties themselves, since they are 1060 already documented in PCIM as part of the definition of the 1061 PolicyConditionInPolicyRule aggregation. 1062 o It is also necessary to define a concrete subclass 1063 CompoundPolicyCondition of PolicyCondition, to introduce the 1064 ConditionListType property. This property has the same function, 1065 and works in exactly the same way, as the corresponding property 1066 currently defined in PCIM for the PolicyRule class. 1068 The class and property definitions for representing compound policy 1069 conditions are below, in Section 5. 1071 4.7.2. Compound Policy Actions 1073 A compound action is a convenient construct to represent a sequence of 1074 actions to be applied as a single atomic action within a policy rule. In 1075 many cases, actions are related to each other and should be looked upon 1076 as sub-actions of one "logical" action. An example of such a logical 1077 action is "shape & mark" (i.e., shape a certain stream to a set of 1078 predefined bandwidth characteristics and then mark these packets with a 1079 certain DSCP value). This logical action is actually composed of two 1080 different QoS actions, which should be performed in a well-defined order 1081 and as a complete set. 1083 The CompoundPolicyAction construct allows one to create a logical 1084 relationship between a number of actions, and to define the activation 1085 logic associated with this logical action. 1087 The CompoundPolicyAction construct allows the reusability of these 1088 complex actions, by storing them in a ReusablePolicyContainer and reusing 1089 them in different policy rules. Note that a compound action may also be 1090 aggregated by another compound action. 1092 As was the case with CompoundPolicyCondition, the PCIM extensions to 1093 introduce compound policy actions are relatively straightforward. This 1094 time the goal is to apply the property ActionOrder from PCIM's 1095 PolicyActionInPolicyRule aggregation to a compound action that aggregates 1096 simpler actions. The following changes are required: 1098 o Create a new aggregation PolicyActionInPolicyAction, with the same 1099 ActionOrder property as PolicyActionInPolicyRule. The cleanest way 1100 to do this is to move the property up to a new abstract aggregation 1101 superclass CompoundedPolicyAction, from which the existing 1102 aggregation PolicyActionInPolicyRule and a new aggregation 1103 PolicyActionInPolicyAction are derived. For now there is no need 1104 to re-document the ActionOrder property itself, since it is already 1105 documented in PCIM as part of the definition of the 1106 PolicyActionInPolicyRule aggregation. 1107 o It is also necessary to define a concrete subclass 1108 CompoundPolicyAction of PolicyAction, to introduce the 1109 SequencedActions property. This property has the same function, 1110 and works in exactly the same way, as the corresponding property 1111 currently defined in PCIM for the PolicyRule class. 1112 o Finally, a new property ExecutionStrategy is needed for both the 1113 PCIM class PolicyRule and the new class CompoundPolicyAction. This 1114 property allows the policy administrator to specify how the PEP 1115 should behave in the case where there are multiple actions 1116 aggregated by a PolicyRule or by a CompoundPolicyAction. 1118 The class and property definitions for representing compound policy 1119 actions are below, in Section 5. 1121 Compound actions allow the definition of logically complex policy rules 1122 and action behavior. The following example illustrates two advantages of 1123 using compound actions. 1125 A QoS policy domain may include a rule that defines the following 1126 behavior: 1128 If (CONDITION) Then Do: 1129 "Shape traffic to and Set DSCP to EF (high priority traffic); 1130 if can�t shape than Set DSCP to BE (best effort)." 1132 This rule can be realized by defining two CompoundPolicyAction instances, 1133 A and B. Two sub-actions are grouped into CompoundPolicyAction A: 1135 Shape traffic to 1136 Mark to EF (DSCP). 1138 The ExecutionStrategy property of CompoundPolicyAction A would be defined 1139 as "Mandatory Do all". This means that if shaping or marking cannot both 1140 be done, then nothing should be done. 1142 A second action, CompoundPolicyAction B, would hold the Mark to BE sub- 1143 action. 1145 CompoundPolicyAction A and CompoundPolicyAction B would be aggregated 1146 into the policy rule using the PolicyActionInPolicyRule aggregation. The 1147 CompoundPolicyAction A will be ordered for execution before the 1148 CompoundPolicyAction B. The PolicyRule's ExecutionStrategy property 1149 would be set to "Do until success". In this way, CompoundPolicyAction A 1150 will be enforced on all PEPs that support shaping, while 1151 CompoundPolicyAction B will be enforced otherwise. 1153 4.8. Variables and Values 1155 The following subsections introduce several related concepts, including 1156 PolicyVariables and PolicyValues (and their numerous subclasses), 1157 SimplePolicyConditions, and SimplePolicyActions. 1159 4.8.1. Simple Policy Conditions 1161 The SimplePolicyCondition class models elementary Boolean conditional 1162 expressions of the form: "If ( MATCH )". The "If" 1163 clause and the "MATCH" are implied in the formal notation. The 1164 relationship is always 'MATCH' and is interpreted based on the variable 1165 and the value. Section 4.8.3 explains the semantics of the operator and 1166 how to extend them. Arbitrarily complex Boolean expressions can be 1167 formed by chaining together any number of simple conditions using 1168 relational operators. Individual simple conditions can be negated as 1169 well. Arbitrarily complex Boolean expressions are modeled by the class 1170 CompoundPolicyCondition (described in section 4.7.1). 1172 For example, the expression "If SourcePort == 80" can be modeled by a 1173 simple condition. In this example, 'SourcePort' is a variable, '==' is 1174 the relational operator denoting the equality relationship (which is 1175 generalized by PCIMe to a "match" relationship), and '80' is an integer 1176 value. The complete interpretation of a simple condition depends on the 1177 binding of the variable. Section 4.8.5 describes variables and their 1178 binding rules. 1180 The SimplePolicyCondition class refines the basic structure of the 1181 PolicyCondition class defined in PCIM by using the pair and 1182 to form the condition. Note that the operator between the 1183 variable and the value is always implied in PCIMe: it is not a part of 1184 the formal notation. 1186 The variable specifies the attribute of an object that should be matched 1187 when evaluating the condition. For example, for a QoS derivation, this 1188 object could represent the flow that is being conditioned. A set of 1189 predefined variables that cover network attributes that are commonly used 1190 for filtering is introduced here in PCIMe to encourage interoperability. 1191 This list covers layer 3 IP attributes such as IP network addresses, 1192 protocols and ports, as well as a set of layer 2 attributes (e.g., MAC 1193 addresses). 1195 The PCIMe defines a single operator, "match", as explained in section 1196 4.8.3. 1198 The bound variable is matched against a value to produce the Boolean 1199 result. For example, in the condition "If the source IP address of the 1200 flow belongs to the 10.1.x.x subnet", a source IP address variable is 1201 matched against a 10.1.x.x subnet value. The operator specifies the type 1202 of relation between the variable and the value evaluated in the 1203 condition. 1205 4.8.2. Using Simple Policy Conditions 1207 Simple conditions can be used in policy rules directly, or as building 1208 blocks for creating compound policy conditions. 1210 Simple condition composition MUST enforce the following data-type 1211 conformance rule: The ValueTypes property of the variable must be 1212 compatible with the type of the value class used. The simplest (and 1213 friendliest, from a user point-of-view) is to equate the type of the 1214 value class with the name of the class. By ensuring that the ValueTypes 1215 property of the variable matches the name of the value class used, we 1216 know that the variable and value instance values are compatible with each 1217 other. 1219 Composing a simple condition requires that an instance of the class 1220 SimplePolicyCondition be created, and that instances of the variable and 1221 value classes that it uses also exist. Note that the variable and/or 1222 value instances may already exist as reusable objects in an appropriate 1223 ReusablePolicyContainer. 1225 Two aggregations are used in order to create the pair , 1226 . The aggregation PolicyVariableInSimplePolicyCondition relates a 1227 SimplePolicyCondition to a single variable instance. Similarly, the 1228 aggregation PolicyValueInSimplePolicyCondition relates a 1229 SimplePolicyCondition to a single value instance. Both aggregations are 1230 defined in this document. 1232 Figure 5 depicts a SimplePolicyCondition with its associated variable and 1233 value. 1235 +-----------------------+ 1236 | SimplePolicyCondition | 1237 +-----------------------+ 1238 * @ 1239 * @ 1240 +------------------+ * @ +---------------+ 1241 | (PolicyVariable) |*** @@@| (PolicyValue) | 1242 +------------------+ +---------------+ 1243 # # 1244 # ooo # 1245 # # 1246 +---------------+ +---------------+ 1247 | (PolicyValue) | ooo | (PolicyValue) | 1248 +---------------+ +---------------+ 1250 Aggregation Legend: 1251 **** PolicyVariableInSimplePolicyCondition 1252 @@@@ PolicyValueInSimplePolicyCondition 1253 #### PolicyValueConstraintInVariable 1255 Figure 5. SimplePolicyCondition 1257 Note: The class names in parenthesis denote subclasses. The named 1258 classes in the figure are abstract and cannot, therefore, be 1259 instantiated. 1261 4.8.3. The Simple Condition Operator 1263 A simple condition models an elementary Boolean expression conditional 1264 clause of the form "If variable MATCHes value". However, the formal 1265 notation of the SimplePolicyCondition, together with its associations, 1266 models only a pair, {variable, value}. The "If" term and the "MATCH" 1267 operator are not directly modeled -- they are implied. 1269 The implied MATCH operator carries an overloaded semantics. For example, 1270 in the simple condition "If DestinationPort MATCH '80'" the 1271 interpretation of the MATCH operator is equality (the 'equal' operator). 1272 Clearly, a different interpretation is needed in the following cases: 1274 o "If DestinationPort MATCH {'80', '8080'}" -- operator is 'IS SET 1275 MEMBER' 1277 o "If DestinationPort MATCH {'1 to 255'}" -- operator is 'IN INTEGER 1278 RANGE' 1280 o "If SourceIPAddress MATCH 'MyCompany.com'" -- operator is 'IP 1281 ADDRESS AS RESOLVED BY DNS' 1283 The examples above illustrate the implicit, context dependant nature of 1284 the interpretation of the MATCH operator. The interpretation depends on 1285 the actual variable and value instances in the simple condition. PCIMe 1286 does not contain text to explicitly detail the possible interpretations 1287 of MATCH operations. The interpretation is always derived from the value 1288 instance associated with the simple condition. Text accompanying the 1289 value class definition SHOULD be used as a guideline for interpreting the 1290 semantics of the MATCH relationship. 1292 The PolicyValueConstraintInVariable association specifies additional 1293 constraints on the possible values that can be matched with a variable 1294 within a simple condition. Using this association a source or 1295 destination port can be constrained to be matched against integer values 1296 in the range 0-65535. A source or destination IP address can be 1297 constrained to be matched against a specified list of IPv4 address 1298 values, etc. In order to check whether a value X can be used with a 1299 variable A constrained by value Y, the following conformance test should 1300 be made. If all events for which the SimplePolicyCondition (A match X) 1301 evaluates to TRUE also evaluate to TRUE for the SimplePolicyCondition (A 1302 match Y), than X conforms to the constraint Y. If multiple values Y1, 1303 Y2, ..., Yn constrain a variable, then the conformance test involves 1304 checking against the condition (A match Y1) OR (A match Y2) OR ... OR (A 1305 match Yn). 1307 4.8.4. SimplePolicyActions 1309 The SimplePolicyAction class models the elementary set operation. "SET 1310 TO ". The set operator MUST overwrite an old value of 1311 the variable. 1313 For example, the action "set DSCP to EF" can be modeled by a simple 1314 action. In this example, 'DSCP' is an implicit variable referring to the 1315 IP packet header DSCP field. 'EF' is an integer or bit string value (6 1316 bits). The complete interpretation of a simple action depends on the 1317 binding of the variable. Section [4.8.4] describes variables and their 1318 binding rules for conditions. 1320 The SimplePolicyAction class refines the basic structure of the 1321 PolicyAction class defined in PCIM, by specifying the contents of the 1322 action using the pair to form the action. The 1323 variable specifies the attribute of an object that has passed the 1324 condition by evaluating to true. This means the binding of the variable 1325 is delayed until the condition evaluates to true for one or more objects. 1326 The value of the object's attribute is set to . 1328 SimplePolicyActions can be used in policy rules directly, or as building 1329 blocks for creating CompoundPolicyActions. 1331 SimplePolicyAction execution MUST enforce the following data type 1332 conformance and translation rule: The ValueTypes property of the variable 1333 must be compatible with the type of the value class used. The following 1334 table shows the compatibility and transformation rules. 'ND' means the 1335 transformation is not defined. 1337 +------------------------------------------------------------------+ 1338 |variable | value type | 1339 |type | | 1340 +------------------------------------------------------------------+ 1341 | |String |Integer|BitString| IPv4Addr | IPv6Addr |MACAddr| 1342 +------------------------------------------------------------------+ 1343 | String | X |to text| [0|1] | A.B.C.D | dotted | X:X.. | 1344 +------------------------------------------------------------------+ 1345 | Integer |"atoi" | X |BinaryVal| 32bit int| ND | ND | 1346 +------------------------------------------------------------------+ 1347 | BitString|convert|convert| X | ND | ND | ND | 1348 +------------------------------------------------------------------+ 1349 | IPv4Addr |convert|convert| ND | X | ND | ND 1350 +------------------------------------------------------------------+ 1351 | IPv6Addr |convert| ND | ND | v4 format| X | ND | 1352 +------------------------------------------------------------------+ 1353 | MACAddr | ND | ND | ND | ND | ND | X | 1354 +------------------------------------------------------------------+ 1356 Composing a simple action requires that an instance of the class 1357 SimplePolicyAction be created, and that instances of the variable and 1358 value classes that it uses also exist. Note that the variable and/or 1359 value instances may already exist as reusable objects in an appropriate 1360 ReusablePolicyContainer. 1362 Two aggregations are used in order to create the pair . 1363 The aggregation PolicyVariableInSimplePolicyAction relates a 1364 SimplePolicyAction to a single variable instance. Similarly, the 1365 aggregation PolicyValueInSimplePolicyAction relates a SimplePolicyAction 1366 to a single value instance. Both aggregations are defined in this 1367 document. 1369 Figure 6 depicts a SimplePolicyAction with its associated variable and 1370 value. 1372 +-----------------------+ 1373 | SimplePolicyAction | 1374 | | 1375 +-----------------------+ 1376 * @ 1377 * @ 1378 +------------------+ * @ +---------------+ 1379 | (PolicyVariable) |*** @@@| (PolicyValue) | 1380 +------------------+ +---------------+ 1381 # # 1382 # ooo # 1383 # # 1384 +---------------+ +---------------+ 1385 | (PolicyValue) | ooo | (PolicyValue) | 1386 +---------------+ +---------------+ 1388 Aggregation Legend: 1389 **** PolicyVariableInSimplePolicyAction 1390 @@@@ PolicyValueInSimplePolicyAction 1391 #### PolicyValueConstraintInVariable 1393 Figure 6. SimplePolicyAction 1395 4.8.5. Policy Variables 1397 A variable generically represents information that changes (or "varies"), 1398 and that is set or evaluated by software. In policy, conditions and 1399 actions can abstract information as "policy variables" to be evaluated in 1400 logical expressions, or set by actions. 1402 PCIMe defines two types of PolicyVariables, a PolicyImplicitVariable and 1403 a PolicyExplicitVariable. The semantic difference between these classes 1404 is based on modeling context. Explicit variables are bound to exact 1405 model constructs, while implicit variables are defined and evaluated 1406 outside of a model, in a more subjective context. For example, one can 1407 imagine a PolicyCondition testing for a CIM ManagedSystemElement's Status 1408 property set to "Error." The Status property is an explicitly defined 1409 PolicyVariable (i.e., it is defined in the context of the CIM Schema and 1410 evaluated in the context of a specific instance). On the other hand, 1411 network packets are not explicitly modeled or instantiated, since there 1412 is no perceived value (at this time) in managing at the packet level. 1413 Therefore, a PolicyCondition can make no explicit reference to a model 1414 construct that represents a network packet's source address. In this 1415 case, an implicit PolicyVariable is defined to allow evaluation of a 1416 packet's source address. 1418 4.8.6. Explicitly Bound Policy Variables 1420 Explicitly bound policy variables indicate the class and property names 1421 of the model construct to be evaluated or set. The CIM Schema defines 1422 and constrains "appropriate" values for the variable (i.e., model 1423 property) using data types and other information such as class/property 1424 qualifiers. 1426 A PolicyExplicitVariable is "explicit" because its model semantics are 1427 exactly defined. It is NOT explicit due to an exact binding to a 1428 particular object. If PolicyExplicitVariable is only tied to instances 1429 (either via association or by a object identification property in the 1430 class itself), then we are forcing element-specific rules. On the other 1431 hand, if we only specify the object's model context (class and property 1432 name), but leave the binding to the policy framework (for example, using 1433 policy roles), then greater flexibility results for either general or 1434 element-specific rules. 1436 For example, an element-specific rule is obtained by a condition 1437 (variable/operator/value triplet) that defines, for example, CIM 1438 LogicalDevice DeviceID="12345". Alternately, if a PolicyRule's 1439 PolicyRoles is "edge device" and your condition (variable/operator/value 1440 triplet) is Status="Error", then a general rule results for all edge 1441 devices in error. 1443 Refer to Section 5.10 for the formal definition of the class 1444 PolicyExplicitVariable. 1446 4.8.7. Implicitly Bound Policy Variables 1448 Implicitly bound policy variables define the data type and semantics of a 1449 variable. This determines how the variable is bound to a value in a 1450 condition clause. Further instructions are provided for specifying data 1451 type and/or value constraints for implicitly bound variables. 1453 Implicitly bound variables can be interpreted by different sub-models to 1454 mean different things, depending on the particular context in which they 1455 are used. For example, an implicitly bound variable named "SourceIP" may 1456 be interpreted by a QoS policy information model to denote the source 1457 address field in the IP header of a packet if a device is configured to 1458 select certain packets for particular treatment. The same variable may 1459 be bound to the sender address delivered by a RSVP PATH message for a 1460 decision by a policy server. It is incumbent upon the particular domain- 1461 specific information model to provide full and unambiguous interpretation 1462 details (binding rules, type and value constraints) for the implicitly 1463 bound variables it uses. 1465 PCIMe introduces an abstract class, PolicyImplicitVariable, to model 1466 implicitly bound variables. This class is derived from the abstract 1467 class PolicyVariable also defined in PCIMe. Each of the implicitly bound 1468 variables introduced by PCIMe (and those that are introduced by domain- 1469 specific sub-models) MUST be derived from the PolicyImplicitVariable 1470 class. The rationale for using this mechanism for modeling is explained 1471 below in Section 4.8.9. 1473 A domain-specific policy information model that extends PCIMe may define 1474 additional implicitly bound variables either by deriving them directly 1475 from the class PolicyImplicitVariable, or by further refining an existing 1476 variable class such as SourcePort. When refining a class such as 1477 SourcePort, existing binding rules, type or value constraints may be 1478 narrowed. 1480 4.8.8. Structure and Usage of Pre-Defined Variables 1482 A class derived from PolicyImplicitVariable to model a particular 1483 implicitly bound variable SHOULD be constructed so that its name depicts 1484 the meaning of the variable. For example, a class defined to model the 1485 source port of a TCP/UDP flow SHOULD be named 'SourcePort'. 1487 PCIMe defines one association and one general-purpose mechanism that 1488 together characterize each of the implicitly bound variables that it 1489 introduces: 1491 1. The PolicyValueConstraintInVariable association defines the set of 1492 value classes that could be matched to this variable. 1494 2. The list of constraints on the values that the PolicyVariable can 1495 hold (i.e., values that the variable must match) are defined by 1496 the appropriate properties of an associated PolicyValue class. 1498 In the example presented above, a PolicyImplicitVariable represents the 1499 SourcePort of incoming traffic. The ValueTypes property of an instance 1500 of this class will hold the class name PolicyIntegerValue. This by 1501 itself constrains the data type of the SourcePort instance to be an 1502 integer. However, we can further constrain the particular values that 1503 the SourcePort variable can hold by entering valid ranges in the 1504 IntegerList property of the PolicyIntegerValue instance (0 - 65535 in 1505 this document). 1507 The combination of the VariableName and the 1508 PolicyValueConstraintInVariable association provide a consistent and 1509 extensible set of metadata that define the semantics of variables that 1510 are used to form policy conditions. Since the 1511 PolicyValueConstraintInVariable association points to another class, any 1512 of the properties in the PolicyValue class can be used to constrain 1513 values that the PolicyImplicitVariable can hold. For example: 1515 o The ValueTypes property can be used to ensure that only proper 1516 classes are used in the expression. For example, the SourcePort 1517 variable will not be allowed to ever be of type 1518 PolicyIPv4AddrValue, since source ports have different semantics 1519 than IP addresses and may not be matched. However, integer value 1520 types are allowed as the property ValueTypes holds the string 1521 "PolicyIntegerValue", which is the class name for integer values. 1523 o The PolicyValueConstraintInVariable association also ensures that 1524 variable-specific semantics are enforced (e.g., the SourcePort 1525 variable may include a constraint association to a value object 1526 defining a specific integer range that should be matched). 1528 4.8.9. Rationale for Modeling Implicit Variables as Classes 1530 An implicitly bound variable can be modeled in one of several ways, 1531 including a single class with an enumerator for each individual implicitly 1532 bound variable and an abstract class extended for each individual variable. 1533 The reasons for using a class inheritance mechanism for specifying 1534 individual implicitly bound variables are these: 1536 1. It is easy to extend. A domain-specific information model can 1537 easily extend the PolicyImplicitVariable class or its subclasses 1538 to define domain-specific and context-specific variables. For 1539 example, a domain-specific QoS policy information model may 1540 introduce an implicitly bound variable class to model applications 1541 by deriving a qosApplicationVariable class from the 1542 PolicyImplicitVariable abstract class. 1544 2. Introduction of a single structural class for implicitly bound 1545 variables would have to include an enumerator property that 1546 contains all possible individual implicitly bound variables. This 1547 means that a domain-specific information model wishing to 1548 introduce an implicitly bound variable must extend the enumerator 1549 itself. This results in multiple definitions of the same class, 1550 differing in the values available in the enumerator class. One 1551 definition, in this document, would include the common implicitly 1552 bound variables' names, while a second definition, in the domain- 1553 specific information model document, may include additional values 1554 ('qosApplicationVariable' in the example above). It wouldn�t even 1555 be obvious to the application developer that multiple class 1556 definitions existed. It would be harder still for the application 1557 developer to actually find the correct class to use. 1559 3. In addition, an enumerator-based definition would require each 1560 additional value to be registered with IANA to ascertain adherence 1561 to standards. This would make the process cumbersome. 1563 4. A possible argument against the inheritance mechanism would cite 1564 the fact that this approach results in an explosion of class 1565 definitions compared to an enumerator class, which only introduces 1566 a single class. While, by itself, this is not a strike against 1567 the approach, it may be argued that data models implemented, which 1568 are mapped to this information model, may be more difficult to 1569 optimize for applications. This argument is rejected on the 1570 grounds that application optimization is of lesser value for an 1571 information model than clarity and ease of extension. In 1572 addition, it is hard to claim that the inheritance model places an 1573 absolute burden on the optimization. For example, a data model 1574 may still use enumeration to denote instances of pre-defined 1575 variables and claim PCIMe compliance, as long as the data moel can 1576 be mapped correctly to the definitions specified in this document. 1577 Furthermore, the very nature of implicitly bound variables is to 1578 be interpreted in context. This means that unless an additional 1579 variable is required by a sub-model (in which case both approaches 1580 result in some overhead), there's an upper limit on the class 1581 explosion. After all, once properly documented, no need exists 1582 for a sub-model to add a class definition. The implementation 1583 needs only to cite and use the PCIMe variable, but impose the 1584 documented context-dependent semantics. 1586 4.8.10. Policy Values 1588 The abstract class PolicyValue is used for modeling values and constants 1589 used in policy conditions. Different value types are derived from this 1590 class, to represent the various attributes required. Extensions of the 1591 abstract class PolicyValue, defined in this document, provide a list of 1592 values for representing basic network attributes. Values can be used to 1593 represent constants as named values. Named values can be kept in a 1594 reusable policy container to be reused by multiple conditions. Examples 1595 of constants include well-known ports, well-known protocols, server 1596 addresses, and other similar concepts. 1598 The PolicyValue subclasses define three basic types of values: scalars, 1599 ranges and sets. For example, a well-known port number could be defined 1600 using the PolicyIntegerValue class, defining a single value (80 for 1601 HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively. 1602 For details, please see the class definition for each value type in 1603 Section 5.12 of this document. 1605 PCIMe defines the following subclasses of the abstract class PolicyValue: 1607 Classes for general use: 1609 - PolicyStringValue, 1610 - PolicyIntegerValue, 1611 - PolicyBitStringValue 1612 - PolicyBooleanValue. 1614 Classes for layer 3 Network values: 1616 - PolicyIPv4AddrValue, 1617 - PolicyIPv6AddrValue. 1619 Classes for layer 2 Network values: 1621 - PolicyMACAddrValue. 1623 For details, please see the class definition section of each class in 1624 Section 5.14 of this document. 1626 4.9. Packet Filtering 1628 In addition to filling in the holes in the overall Policy infrastructure, 1629 PCIMe proposes a single mechanism for expressing packet filters in policy 1630 conditions. This is being done in response to concerns that even though 1631 the initial "wave" of submodels derived from PCIM were all filtering on 1632 IP packets, each was doing it in a slightly different way. PCIMe 1633 proposes a common way to express IP packet filters. The following figure 1634 illustrates how packet-filtering conditions are expressed in PCIMe. 1636 +---------------------------------+ 1637 | CompoundFilterCondition | 1638 | - IsMirrored boolean | 1639 | - ConditionListType (DNF|CNF) | 1640 +---------------------------------+ 1641 + + + 1642 + + + 1643 + + + 1644 SimplePC SimplePC SimplePC 1645 * @ * @ * @ 1646 * @ * @ * @ 1647 * @ * @ * @ 1648 FlowDirection "In" SrcIP DstIP 1650 Aggregation Legend: 1651 ++++ PolicyConditionInPolicyCondition 1652 **** PolicyVariableInSimplePolicyCondition 1653 @@@@ PolicyValueInSimplePolicyCondition 1655 Figure 7. Packet Filtering in Policy Conditions 1657 In Figure 7, each SimplePolicyCondition represents a single field to be 1658 filtered on: Source IP address, Destination IP address, Source port, etc. 1659 An additional SimplePolicyCondition indicates the direction that a packet 1660 is traveling on an interface: inbound or outbound. Because of the 1661 FlowDirection condition, care must be taken in aggregating a set of 1662 SimplePolicyConditions into a CompoundFilterCondition. Otherwise, the 1663 resulting CompoundPolicyCondition may match all inbound packets, or all 1664 outbound packets, when this is probably not what was intended. 1666 Individual SimplePolicyConditions may be negated when they are aggregated 1667 by a CompoundFilterCondition. 1669 CompoundFilterCondition is a subclass of CompoundPolicyCondition. It 1670 introduces one additional property, the Boolean property IsMirrored. The 1671 purpose of this property is to allow a single CompoundFilterCondition to 1672 match packets traveling in both directions on a higher-level connection 1673 such as a TCP session. When this property is TRUE, additional packets 1674 match a filter, beyond those that would ordinarily match it. An example 1675 will illustrate how this property works. 1677 Suppose we have a CompoundFilterCondition that aggregates the following 1678 three filters, which are ANDed together: 1680 o FlowDirection = "In" 1681 o Source IP = 9.1.1.1 1682 o Source Port = 80 1683 Regardless of whether IsMirrored is TRUE or FALSE, inbound packets will 1684 match this CompoundFilterCondition if their Source IP address = 9.1.1.1 1685 and their Source port = 80. If IsMirrored is TRUE, however, an outbound 1686 packet will also match the CompoundFilterCondition if its Destination IP 1687 address = 9.1.1.1 and its Destination port = 80. 1689 IsMirrored "flips" the following Source/Destination packet header fields: 1691 o FlowDirection "In" / FlowDirection "Out" 1692 o Source IP address / Destination IP address 1693 o Source port / Destination port 1694 o Source MAC address / Destination MAC address 1695 o Source [layer-2] SAP / Destination [layer-2] SAP. 1697 5. Class Definitions 1699 The following definitions supplement those in PCIM itself. PCIM 1700 definitions that are not DEPRECATED here are still current parts of the 1701 overall Policy Core Information Model. 1703 5.1. The Abstract Class "PolicySet" 1705 PolicySet is an abstract class that may group policies into a structured 1706 set of policies. 1708 NAME PolicySet 1709 DESCRIPTION An abstract class that represents a set of policies 1710 that form a coherent set. The set of contained 1711 policies has a common decision strategy and a common 1712 set of policy roles. Subclasses include PolicyGroup 1713 and PolicyRule. 1714 DERIVED FROM Policy 1715 ABSTRACT TRUE 1716 PROPERTIES PolicyDecisionStrategy 1717 PolicyRoles 1719 The PolicyDecisionStrategy property specifies the evaluation method for 1720 policy groups and rules contained within the policy set. 1722 NAME PolicyDecisionStrategy 1723 DESCRIPTION The evaluation method used for policies contained in 1724 the PolicySet. FirstMatching enforces the actions of 1725 the first rule that evaluates to TRUE; AllMatching 1726 enforces the actions of all rules that evaluate to 1727 TRUE. 1728 SYNTAX uint16 1729 VALUES 1 [FirstMatching], 2 [AllMatching] 1730 DEFAULT VALUE 1 [FirstMatching] 1732 The definition of PolicyRoles is unchanged from PCIM. It is, however, 1733 moved from the class Policy up to the superclass PolicySet. 1735 5.2. Updates to PCIM's Class "PolicyGroup" 1737 The PolicyGroup class is modified to be derived from PolicySet. 1739 NAME PolicyGroup 1740 DESCRIPTION A container for a set of related PolicyRules and 1741 PolicyGroups. 1742 DERIVED FROM PolicySet 1743 ABSTRACT FALSE 1744 PROPERTIES (none) 1746 5.3. Updates to PCIM's Class "PolicyRule" 1748 The PolicyRule class is modified to be derived from PolicySet, and to 1749 deprecate the use of Priority in the rule. PolicyRoles is now inherited 1750 from the parent class PolicySet. Finally, a new property 1751 ExecutionStrategy is introduced, paralleling the property of the same 1752 name in the class CompoundPolicyAction. 1754 NAME PolicyRule 1755 DESCRIPTION The central class for representing the "If Condition 1756 then Action" semantics associated with a policy rule. 1757 DERIVED FROM PolicySet 1758 ABSTRACT FALSE 1759 PROPERTIES Enabled 1760 ConditionListType 1761 RuleUsage 1762 Priority DEPRECATED FOR PolicySetComponent.Priority 1763 Mandatory 1764 SequencedActions 1765 ExecutionStrategy 1767 The property ExecutionStrategy defines the execution strategy to be used 1768 upon the sequenced actions aggregated by this PolicyRule. (An equivalent 1769 ExecutionStrategy property is also defined for the CompoundPolicyAction 1770 class, to provide the same indication for the sequenced actions 1771 aggregated by a CompoundPolicyAction.) This draft defines four execution 1772 strategies: 1774 Mandatory Do all � execute ALL actions that are part of the modeled 1775 set. If one or more of the actions cannot be 1776 executed, none of the actions should be executed. 1777 Do until success � execute actions according to predefined order, until 1778 successful execution of a single action. 1779 Do All - execute ALL actions which are part of the modeled 1780 set, according to their predefined order. Continue 1781 doing this, even if one or more of the actions 1782 fails. 1783 Do until Failure - execute actions according to predefined order, until 1784 the first failure in execution of a single sub- 1785 action. 1787 The property definition is as follows: 1789 NAME ExecutionStrategy 1790 DESCRIPTION An enumeration indicating how to interpret the action 1791 ordering for the actions aggregated by this 1792 PolicyRule. 1793 SYNTAX uint16 (ENUM, {1=Mandatory Do All, 2=Do Until Success, 1794 3=Do All, 4=Do Until Failure} ) 1795 DEFAULT VALUE Do All (3) 1797 5.4. The Class "SimplePolicyCondition" 1799 A simple policy condition is composed of an ordered triplet: 1801 MATCH 1803 No formal modeling of the MATCH operator is provided. The 'match' 1804 relationship is implied. Such simple conditions are evaluated by 1805 answering the question: 1807 Does match ? 1809 The 'match' relationship is to be interpreted by analyzing the variable 1810 and value instances associated with the simple condition. 1812 Simple conditions are building blocks for more complex Boolean 1813 Conditions, modeled by the CompoundPolicyCondition class. 1815 The SimplePolicyCondition class is derived from the PolicyCondition class 1816 defined in PCIM. 1818 A variable and a value must be associated with a simple condition to make 1819 it a meaningful condition, using, respectively, the aggregations 1820 PolicyVariableInSimplePolicyCondition and 1821 PolicyValueInSimplePolicyCondition. 1823 The class definition is as follows: 1825 NAME SimplePolicyCondition 1826 DERIVED FROM PolicyCondition 1827 ABSTRACT False 1828 PROPERTIES (none) 1830 5.5. The Class "CompoundPolicyCondition" 1832 This class represents a compound policy condition, formed by aggregation 1833 of simpler policy conditions. 1835 NAME CompoundPolicyCondition 1836 DESCRIPTION A subclass of PolicyCondition that introduces the 1837 ConditionListType property, used for assigning DNF / 1838 CNF semantics to subordinate policy conditions. 1839 DERIVED FROM PolicyCondition 1840 ABSTRACT FALSE 1841 PROPERTIES ConditionListType 1843 The ConditionListType property is used to specify whether the list of 1844 policy conditions associated with this compound policy condition is in 1845 disjunctive normal form (DNF) or conjunctive normal form (CNF). If this 1846 property is not present, the list type defaults to DNF. The property 1847 definition is as follows: 1849 NAME ConditionListType 1850 DESCRIPTION Indicates whether the list of policy conditions 1851 associated with this policy rule is in disjunctive 1852 normal form (DNF) or conjunctive normal form (CNF). 1853 SYNTAX uint16 1854 VALUES DNF(1), CNF(2) 1855 DEFAULT VALUE DNF(1) 1857 5.6. The Class "CompoundFilterCondition" 1859 This subclass of CompoundPolicyCondition introduces one additional 1860 property, the boolean IsMirrored. This property turns on or off the 1861 "flipping" of corresponding source and destination fields in a filter 1862 specification. 1864 NAME CompoundFilterCondition 1865 DESCRIPTION A subclass of CompoundPolicyCondition that introduces 1866 the IsMirrored property. 1867 DERIVED FROM CompoundPolicyCondition 1868 ABSTRACT FALSE 1869 PROPERTIES IsMirrored 1871 The IsMirrored property indicates whether packets that "mirror" a 1872 compound filter condition should be treated as matching the filter. The 1873 property definition is as follows: 1875 NAME IsMirrored 1876 DESCRIPTION Indicates whether packets that mirror the specified 1877 filter are to be treated as matching the filter. 1878 SYNTAX boolean 1879 DEFAULT VALUE FALSE 1881 5.7. The Class "SimplePolicyAction" 1883 The SimplePolicyAction class models the elementary set operation. "SET 1884 TO ". The set operator MUST overwrite an old value of 1885 the variable. 1887 Two aggregations are used in order to create the pair . 1888 The aggregation PolicyVariableInSimplePolicyAction relates a 1889 SimplePolicyAction to a single variable instance. Similarly, the 1890 aggregation PolicyValueInSimplePolicyAction relates a SimplePolicyAction 1891 to a single value instance. Both aggregations are defined in this 1892 document. 1894 NAME SimplePolicyAction 1895 DESCRIPTION A subclass of PolicyAction that introduces the notion 1896 of "SET variable TO value". 1897 DERIVED FROM PolicyAction 1898 ABSTRACT FALSE 1899 PROPERTIES (none) 1901 5.8. The Class "CompoundPolicyAction" 1903 The CompoundPolicyAction class is used to represent an expression 1904 consisting of an ordered sequence of action terms. Each action term is 1905 represented as a subclass of the PolicyAction class, defined in [PCIM]. 1906 Compound actions are constructed by associating dependent action terms 1907 together using the PolicyActionInPolicyAction aggregation. 1909 The class definition is as follows: 1911 NAME CompoundPolicyAction 1912 DESCRIPTION A class for representing sequenced action terms. Each 1913 action term is defined to be a subclass of the 1914 PolicyAction class. 1915 DERIVED FROM PolicyAction 1916 ABSTRACT FALSE 1917 PROPERTIES SequencedActions 1918 ExecutionStrategy 1920 This is a concrete class, and is therefore directly instantiable. 1922 The Property SequencedActions is identical to the SequencedActions 1923 property defined in PCIM for the class PolicyRule. 1925 The property ExecutionStrategy defines the execution strategy to be used 1926 upon the sequenced actions associated with this compound action. (An 1927 equivalent ExecutionStrategy property is also defined for the PolicyRule 1928 class, to provide the same indication for the sequenced actions 1929 associated with a PolicyRule.) This draft defines four execution 1930 strategies: 1932 Mandatory Do all � execute ALL actions that are part of the modeled 1933 set. If one or more of the sub-actions cannot be 1934 executed, none of the actions should be executed. 1935 Do until success � execute actions according to predefined order, until 1936 successful execution of a single sub-action. 1937 Do All - execute ALL actions which are part of the modeled 1938 set, according to their predefined order. Continue 1939 doing this, even if one or more of the sub-actions 1940 fails. 1942 Do until Failure - execute actions according to predefined order, until 1943 the first failure in execution of a single sub- 1944 action. 1946 The property definition is as follows: 1948 NAME ExecutionStrategy 1949 DESCRIPTION An enumeration indicating how to interpret the action 1950 ordering for the actions aggregated by this 1951 CompoundPolicyAction. 1952 SYNTAX uint16 (ENUM, {1=Mandatory Do All, 2=Do Until Success, 1953 3=Do All, 4=Do Until Failure} ) 1954 DEFAULT VALUE Do All (3) 1956 5.9. The Abstract Class "PolicyVariable" 1958 Variables are used for building individual conditions. The variable 1959 specifies the property of a flow or an event that should be matched when 1960 evaluating the condition. However, not every combination of a variable 1961 and a value creates a meaningful condition. For example, a source IP 1962 address variable can not be matched against a value that specifies a port 1963 number. A given variable selects the set of matchable value types. 1965 A variable can have constraints that limit the set of values within a 1966 particular value type that can be matched against it in a condition. For 1967 example, a source-port variable limits the set of values to represent 1968 integers to the range of 0-65535. Integers outside this range cannot be 1969 matched to the source-port variable, even though they are of the correct 1970 data type. Constraints for a given variable are indicated through the 1971 PolicyValueConstraintInVariable association. 1973 The PolicyVariable is an abstract class. Implicit and explicit context 1974 variable classes are defined as sub classes of the PolicyVariable class. 1975 A set of implicit variables is defined in this document as well. 1977 The class definition is as follows: 1979 NAME PolicyVariable 1980 DERIVED FROM Policy 1981 ABSTRACT TRUE 1982 PROPERTIES (none) 1984 5.10. The Class "PolicyExplicitVariable" 1986 Explicitly defined policy variables are evaluated within the context of 1987 the CIM Schema and its modeling constructs. The PolicyExplicitVariable 1988 class indicates the exact model property to be evaluated or manipulated. 1990 The class definition is as follows: 1992 NAME PolicyExplicitVariable 1993 DERIVED FROM PolicyVariable 1994 ABSTRACT False 1995 PROPERTIES ModelClass, ModelProperty 1997 5.10.1. The Single-Valued Property "ModelClass" 1999 This property is a string specifying the class name whose property is 2000 evaluated or set as a PolicyVariable. The property is defined as 2001 follows: 2003 NAME ModelClass 2004 SYNTAX String 2006 5.10.2. The Single-Valued Property ModelProperty 2008 This property is a string specifying the property name, within the 2009 ModelClass, which is evaluated or set as a PolicyVariable. The property 2010 is defined as follows: 2012 NAME ModelProperty 2013 SYNTAX String 2015 5.11. The Abstract Class "PolicyImplicitVariable" 2017 Implicitly defined policy variables are evaluated outside of the context 2018 of the CIM Schema and its modeling constructs. Subclasses specify the 2019 data type and semantics of the PolicyVariables. 2021 Interpretation and evaluation of a PolicyImplicitVariable can vary, 2022 depending on the particular context in which it is used. For example, a 2023 "SourceIP" address may denote the source address field of an IP packet 2024 header, or the sender address delivered by an RSVP PATH message. 2026 The class definition is as follows: 2028 NAME PolicyImplicitVariable 2029 DERIVED FROM PolicyVariable 2030 ABSTRACT True 2031 PROPERTIES ValueTypes[ ] 2033 5.11.1. The Multi-Valued Property "ValueTypes" 2035 This property is a set of strings specifying an unordered list of 2036 possible value/data types that can be used in simple conditions and 2037 actions, with this variable. The value types are specified by their 2038 class names (subclasses of PolicyValue such as PolicyStringValue). The 2039 list of class names enables an application to search on a specific name, 2040 as well as to ensure that the data type of the variable is of the correct 2041 type. 2043 The list of default ValueTypes for each subclass of 2044 PolicyImplicitVariable is specified within that variable's definition. 2046 The property is defined as follows: 2048 NAME ValueTypes 2049 SYNTAX String 2051 5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe 2053 The following subclasses of PolicyImplicitVariable are defined in PCIMe. 2055 5.12.1. The Class "PolicySourceIPVariable" 2057 NAME PolicySourceIPVariable 2058 DESCRIPTION The source IP address. 2060 ALLOWED VALUE TYPES: 2061 - PolicyIPv4AddrValue 2062 - PolicyIPv6AddrValue 2064 DERIVED FROM PolicyImplicitVariable 2065 ABSTRACT FALSE 2066 PROPERTIES (none) 2068 5.12.2. The Class "PolicyDestinationIPVariable" 2070 NAME PolicyDestinationIPVariable 2071 DESCRIPTION The destination IP address. 2073 ALLOWED VALUE TYPES: 2074 - PolicyIPv4AddrValue 2075 - PolicyIPv6AddrValue 2077 DERIVED FROM PolicyImplicitVariable 2078 ABSTRACT FALSE 2079 PROPERTIES (none) 2081 5.12.3. The Class "PolicySourcePortVariable" 2083 NAME PolicySourcePortVariable 2084 DESCRIPTION Ports are defined as the abstraction that transport 2085 protocols use to distinguish among multiple 2086 destinations within a given host computer. For TCP 2087 and UDP flows, the PolicySourcePortVariable is 2088 logically bound to the source port field. 2090 ALLOWED VALUE TYPES: 2091 - PolicyIntegerValue 2092 - PolicyBitStringValue 2094 DERIVED FROM PolicyImplicitVariable 2095 ABSTRACT FALSE 2096 PROPERTIES (none) 2097 5.12.4. The Class "PolicyDestinationPortVariable" 2099 NAME PolicyDestinationPortVariable 2100 DESCRIPTION Ports are defined as the abstraction that transport 2101 protocols use to distinguish among multiple 2102 destinations within a given host computer. For TCP 2103 and UDP flows, the PolicyDestinationPortVariable is 2104 logically bound to the destination port field. 2106 ALLOWED VALUE TYPES: 2107 - PolicyIntegerValue 2108 - PolicyBitStringValue 2110 DERIVED FROM PolicyImplicitVariable 2111 ABSTRACT FALSE 2112 PROPERTIES (none) 2114 5.12.5. The Class "PolicyIPProtocolVariable" 2116 NAME PolicyIPProtocolVariable 2117 DESCRIPTION The IP protocol number. 2119 ALLOWED VALUE TYPES: 2120 - PolicyIntegerValue 2121 - PolicyBitStringValue 2123 DERIVED FROM PolicyImplicitVariable 2124 ABSTRACT FALSE 2125 PROPERTIES (none) 2127 5.12.6. The Class "PolicyIPVersionVariable" 2129 NAME PolicyIPVersionVariable 2130 DESCRIPTION The IP version number. The well-known values are 4 2131 and 6. 2133 ALLOWED VALUE TYPES: 2134 - PolicyIntegerValue 2135 - PolicyBitStringValue 2137 DERIVED FROM PolicyImplicitVariable 2138 ABSTRACT FALSE 2139 PROPERTIES (none) 2141 5.12.7. The Class "PolicyIPToSVariable" 2143 NAME PolicyIPToSVariable 2144 DESCRIPTION The IP TOS octet. 2146 ALLOWED VALUE TYPES: 2147 - PolicyIntegerValue 2148 - PolicyBitStringValue 2149 DERIVED FROM PolicyImplicitVariable 2150 ABSTRACT FALSE 2151 PROPERTIES (none) 2153 5.12.8. The Class "PolicyDSCPVariable" 2155 NAME PolicyDSCPVariable 2156 DESCRIPTION The 6 bit Differentiated Service Code Point. 2158 ALLOWED VALUE TYPES: 2159 - PolicyIntegerValue 2160 - PolicyBitStringValue 2162 DERIVED FROM PolicyImplicitVariable 2163 ABSTRACT FALSE 2164 PROPERTIES (none) 2166 5.12.9. The Class "PolicySourceMACVariable" 2168 NAME PolicySourceMACVariable 2169 DESCRIPTION The source MAC address. 2171 ALLOWED VALUE TYPES: 2172 - PolicyMACAddrValue 2174 DERIVED FROM PolicyImplicitVariable 2175 ABSTRACT FALSE 2176 PROPERTIES (none) 2178 5.12.10. The Class "PolicyDestinationMACVariable" 2180 NAME PolicyDestinationMACVariable 2181 DESCRIPTION The destination MAC address. 2183 ALLOWED VALUE TYPES: 2184 - PolicyMACAddrValue 2186 DERIVED FROM PolicyImplicitVariable 2187 ABSTRACT FALSE 2188 PROPERTIES (none) 2190 5.12.11. The Class "PolicyVLANVariable" 2192 NAME PolicyVLANVariable 2193 DESCRIPTION The virtual Bridged Local Area Network Identifier, a 2194 12-bit field as defined in the IEEE 802.1q standard. 2196 ALLOWED VALUE TYPES: 2197 - PolicyIntegerValue 2198 - PolicyBitStringValue 2199 DERIVED FROM PolicyImplicitVariable 2200 ABSTRACT FALSE 2201 PROPERTIES (none) 2203 5.12.12. The Class "PolicyCoSVariable" 2205 NAME PolicyCoSVariable 2206 DESCRIPTION Class of Service, a 3-bit field, used in the layer 2 2207 header to select the forwarding treatment. Bound to 2208 the IEEE 802.1q user-priority field. 2210 ALLOWED VALUE TYPES: 2211 - PolicyIntegerValue 2212 - PolicyBitStringValue 2214 DERIVED FROM PolicyImplicitVariable 2215 ABSTRACT FALSE 2216 PROPERTIES (none) 2218 5.12.13. The Class "PolicyEthertypeVariable" 2220 NAME PolicyEthertypeVariable 2221 DESCRIPTION The Ethertype protocol number of Ethernet frames. 2223 ALLOWED VALUE TYPES: 2224 - PolicyIntegerValue 2225 - PolicyBitStringValue 2227 DERIVED FROM PolicyImplicitVariable 2228 ABSTRACT FALSE 2229 PROPERTIES (none) 2231 5.12.14. The Class "PolicySourceSAPVariable" 2233 NAME PolicySourceSAPVariable 2234 DESCRIPTION The Source SAP number. 2236 ALLOWED VALUE TYPES: 2237 - PolicyIntegerValue 2238 - PolicyBitStringValue 2240 DERIVED FROM PolicyImplicitVariable 2241 ABSTRACT FALSE 2242 PROPERTIES (none) 2244 5.12.15. The Class "PolicyDestinationSAPVariable" 2246 NAME PolicyDestinationSAPVariable 2247 DESCRIPTION The Destination SAP number. 2249 ALLOWED VALUE TYPES: 2250 - PolicyIntegerValue 2251 - PolicyBitStringValue 2253 DERIVED FROM PolicyImplicitVariable 2254 ABSTRACT FALSE 2255 PROPERTIES (none) 2257 5.12.16. The Class "PolicySNAPVariable" 2259 NAME PolicySNAPVariable 2260 DESCRIPTION The protocol number over a SNAP SAP encapsulation. 2262 ALLOWED VALUE TYPES: 2263 - PolicyIntegerValue 2264 - PolicyBitStringValue 2266 DERIVED FROM PolicyImplicitVariable 2267 ABSTRACT FALSE 2268 PROPERTIES (none) 2270 5.12.17. The Class "PolicyFlowDirectionVariable" 2272 NAME PolicyFlowDirectionVariable 2273 DESCRIPTION The direction of a flow relative to a network element. 2274 Direction may be "IN" and/or "OUT". 2276 ALLOWED VALUE TYPES: 2277 - PolicyStringValue 2279 DERIVED FROM PolicyImplicitVariable 2280 ABSTRACT FALSE 2281 PROPERTIES (none) 2283 To match on both inbound and outbound flows, the associated 2284 PolicyStringValue object has two entries in its StringList property: "IN" 2285 and "OUT". 2287 5.13. The Abstract Class "PolicyValue" 2289 This is an abstract class that serves as the base class for all 2290 subclasses that are used to define value objects in the PCIMe. It is 2291 used for defining values and constants used in policy conditions. The 2292 class definition is as follows: 2294 NAME PolicyValue 2295 DERIVED FROM Policy 2296 ABSTRACT True 2297 PROPERTIES (none) 2298 5.14. Subclasses of "PolicyValue" Specified in PCIMe 2300 The following subsections contain the PolicyValue subclasses defined in 2301 PCIMe. Additional subclasses may be defined in models derived from 2302 PCIMe. 2304 5.14.1. The Class "PolicyIPv4AddrValue" 2306 This class is used to provide a list of IPv4Addresses, hostnames and 2307 address range values to be matched against in a policy condition. The 2308 class definition is as follows: 2310 NAME PolicyIPv4AddrValue 2311 DERIVED FROM PolicyValue 2312 ABSTRACT False 2313 PROPERTIES IPv4AddrList[ ] 2315 The IPv4AddrList property provides an unordered list of strings, each 2316 specifying a single IPv4 address, a hostname, or a range of IPv4 2317 addresses, according to the ABNF definition [8] of an IPv4 address, as 2318 specified below: 2320 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 2321 IPv4prefix = IPv4address "/" 1*2DIGIT 2322 IPv4range = IPv4address"-"IPv4address 2323 IPv4maskedaddress = IPv4address","IPv4address 2324 Hostname (as defined in [9]) 2326 In the above definition, each string entry is either: 2328 1. A single Ipv4address in dot notation, as defined above. Example: 2329 121.1.1.2 2331 2. An IPv4prefix address range, as defined above, specified by an 2332 address and a prefix length, separated by "/". Example: 2333 2.3.128.0/15 2335 3. An IPv4range address range defined above, specified by a starting 2336 address in dot notation and an ending address in dot notation, 2337 separated by "-". The range includes all addresses between the 2338 range's starting and ending addresses, including these two 2339 addresses. Example: 1.1.22.1-1.1.22.5 2341 4. An IPv4maskedaddress address range, as defined above, specified by 2342 an address and mask. The address and mask are represented in dot 2343 notation, separated by a comma ",". The masked address appears 2344 before the comma, and the mask appears after the comma. Example: 2345 2.3.128.0,255.255.248.0. 2347 5. A single Hostname. The Hostname format follows the guidelines and 2348 restrictions specified in [9]. Example: www.bigcompany.com. 2350 The property definition is as follows: 2352 NAME IPv4AddrList 2353 SYNTAX String 2354 FORMAT IPv4address | IPv4prefix | IPv4range | 2355 IPv4maskedaddress | hostname 2357 5.14.2. The Class "PolicyIPv6AddrValue 2359 This class is used to define a list of IPv6 addresses, hostnames, and 2360 address range values. The class definition is as follows: 2362 NAME PolicyIPv6AddrValue 2363 DERIVED FROM PolicyValue 2364 ABSTRACT False 2365 PROPERTIES IPv6AddrList[ ] 2367 The property IPv6AddrList provides an unordered list of strings, each 2368 specifying an IPv6 address, a hostname, or a range of IPv6 addresses. 2369 IPv6 address format definition uses the standard address format defined 2370 in [10]. The ABNF definition [8] as specified in [10] is: 2372 IPv6address = hexpart [ ":" IPv4address ] 2373 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 2374 IPv6prefix = hexpart "/" 1*2DIGIT 2375 hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] 2376 hexseq = hex4 *( ":" hex4) 2377 hex4 = 1*4HEXDIG 2378 IPv6range = IPv6address"-"IPv6address 2379 IPv6maskedaddress = IPv6address","IPv6address 2380 Hostname (as defines in [NAMES]) 2382 Each string entry is either: 2384 1. A single IPv6address as defined above. 2386 2. A single Hostname. Hostname format follows guidelines and 2387 restrictions specified in [9]. 2389 3. An IPv6range address range, specified by a starting address in dot 2390 notation and an ending address in dot notation, separated by "-". 2391 The range includes all addresses between the range's starting and 2392 ending addresses, including these two addresses. 2394 4. An IPv4maskedaddress address range defined above specified by an 2395 address and mask. The address and mask are represented in dot 2396 notation separated by a comma ",". 2398 5. A single IPv6prefix as defined above. 2400 5.14.3. The Class "PolicyMACAddrValue" 2402 This class is used to define a list of MAC addresses and MAC address 2403 range values. The class definition is as follows: 2405 NAME PolicyMACAddrValue 2406 DERIVED FROM PolicyValue 2407 ABSTRACT False 2408 PROPERTIES MACAddrList[ ] 2410 The property MACAddrList provides an unordered list of strings, each 2411 specifying a MAC address or a range of MAC addresses. The 802 MAC 2412 address canonical format is used. The ABNF definition [8] is: 2414 MACaddress = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG 2415 MACmaskedaddress = MACaddress","MACaddress 2417 Each string entry is either: 2419 1. A single MAC address. Example: 0000:00A5:0000 2421 2. A MACmaskedaddress address range defined specified by an address 2422 and mask. The mask specifies the relevant bits in the address. 2423 Example: 0000:00A5:0000,FFFF:FFFF:0000 defines a range of MAC 2424 addresses in which the first four octets are equal to 0000:00A5. 2426 The property definition is as follows: 2428 NAME MACAddrList 2429 SYNTAX String 2430 FORMAT MACaddress | MACmaskedaddress 2432 5.14.4. The Class "PolicyStringValue" 2434 This class is used to represent a single string value, or a set of string 2435 values. Each value can have wildcards. The class definition is as 2436 follows: 2438 NAME PolicyStringValue 2439 DERIVED FROM PolicyValue 2440 ABSTRACT False 2441 PROPERTIES StringList[ ] 2443 The property StringList provides an unordered list of strings, each 2444 representing a single string with wildcards. The asterisk character "*" 2445 is used as a wildcard, and represents an arbitrary substring replacement. 2446 For example, the value "abc*def" matches the string "abcxyzdef", and the 2447 value "abc*def*" matches the string "abcxxxdefyyyzzz". The syntax 2448 definition is identical to the substring assertion syntax defined in 2449 [11]. If the asterisk character is required as part of the string value 2450 itself, it MUST be quoted as described in section 4.3 of [11]. 2452 The property definition is as follows: 2454 NAME StringList 2455 SYNTAX String 2457 5.14.5. The Class "PolicyBitStringValue" 2459 This class is used to represent a single bit string value, or a set of 2460 bit string values. The class definition is as follows: 2462 NAME PolicyBitStringValue 2463 DERIVED FROM PolicyValue 2464 ABSTRACT False 2465 PROPERTIES BitStringList[ ] 2467 The property BitStringList provides an unordered list of strings, each 2468 representing a single bit string or a set of bit strings. The number of 2469 bits specified SHOULD equal the number of bits of the expected variable. 2470 For example, for a one-octet variable, 8 bits should be specified. If 2471 the variable does not have a fixed length, the bit string should be 2472 matched against the variable's most significant bit string. The formal 2473 definition of a bit string is: 2475 binary-digit = "0" / "1" 2476 bitString = 1*binary-digit 2477 maskedBitString = bitString","bitString 2479 Each string entry is either: 2481 1. A single bit string. Example: 00111010 2483 2. A range of bit strings specified using a bit string and a bit 2484 mask. The bit string and mask fields have the same number of bits 2485 specified. The mask bit string specifies the significant bits in 2486 the bit string value. For example, 110110, 100110 and 110111 2487 would match the maskedBitString 100110,101110 but 100100 would 2488 not. 2490 The property definition is as follows: 2492 NAME BitStringList 2493 SYNTAX String 2494 FORMAT bitString | maskedBitString 2496 5.14.6. The Class "PolicyIntegerValue" 2498 This class provides a list of integer and integer range values. Integers 2499 of arbitrary sizes can be represented. The class definition is as 2500 follows: 2502 NAME PolicyIntegerValue 2503 DERIVED FROM PolicyValue 2504 ABSTRACT False 2505 PROPERTIES IntegerList[ ] 2507 The property IntegerList provides an unordered list of integers and 2508 integer range values, represented as strings. The format of this 2509 property takes one of the following forms: 2511 1. An integer value. 2513 2. A range of integers. The range is specified by a starting integer 2514 and an ending integer, separated by '-'. The starting integer 2515 MUST be less than or equal to the ending integer. The range 2516 includes all integers between the starting and ending integers, 2517 including these two integers. Care must be taken in reading 2518 integer ranges involving negative integers, since the unary minus 2519 and the range indicator are the same character '-'. 2521 To represent a range of integers that is not bounded, the reserved words 2522 -INFINITY and/or INFINITY can be used in place of the starting and ending 2523 integers. 2525 The ABNF definition [8] is: 2527 integer = [-]1*DIGIT | "INFINITY" | "-INFINITY" 2528 integerrange = integer"-"integer 2530 Using ranges, the operators greater-than, greater-than-or-equal-to, less- 2531 than, and less-than-or-equal-to can be expressed. For example, "X is- 2532 greater-than 5" (where X is an integer) can be translated to "X matches 2533 6-INFINITY". This enables the match condition semantics of the operator 2534 for the SimplePolicyCondition class to be kept simple (i.e., just the 2535 value "match"). 2537 The property definition is as follows: 2539 NAME IntegerList 2540 SYNTAX String 2541 FORMAT integer | integerrange 2543 5.14.7. The Class "PolicyBooleanValue" 2545 This class is used to represent a Boolean (TRUE/FALSE) value. The class 2546 definition is as follows: 2548 NAME PolicyBooleanValue 2549 DERIVED FROM PolicyValue 2550 ABSTRACT False 2551 PROPERTIES BooleanValue 2553 The property definition is as follows: 2555 NAME BooleanValue 2556 SYNTAX boolean 2558 5.15. The Class "PolicyRoleCollection" 2560 This class represents a collection of managed elements that share a 2561 common role. The PolicyRoleCollection always exists in the context of a 2562 system, specified using the PolicyRoleCollectionInSystem association. 2563 The value of the PolicyRole property in this class specifies the role, 2564 and can be matched with the value(s) in the PolicyRoles array in 2565 PolicyRules and PolicyGroups. ManagedElements that share the role 2566 defined in this collection are aggregated into the collection via the 2567 association ElementInPolicyRoleCollection. 2569 NAME PolicyRoleCollection 2570 DESCRIPTION A subclass of the CIM Collection class used to group 2571 together managed elements that share a role. 2572 DERIVED FROM Collection 2573 ABSTRACT FALSE 2574 PROPERTIES PolicyRole 2576 5.15.1. The Single-Valued Property "PolicyRole" 2578 This property represents the role associated with a PolicyRoleCollection. 2579 The property definition is as follows: 2581 NAME PolicyRole 2582 DESCRIPTION A string representing the role associated with a 2583 PolicyRoleCollection. 2584 SYNTAX string 2586 5.16. The Class "ReusablePolicyContainer" 2588 The new class ReusablePolicyContainer is defined as follows: 2590 NAME ReusablePolicyContainer 2591 DESCRIPTION A class representing an administratively defined 2592 container for reusable policy-related information. 2593 This class does not introduce any additional 2594 properties beyond those in its superclass AdminDomain. 2595 It does, however, participate in a number of unique 2596 associations. 2597 DERIVED FROM AdminDomain 2598 ABSTRACT FALSE 2599 PROPERTIES (none) 2601 5.17. Deprecation of PCIM's Class "PolicyRepository" 2603 The class definition of PolicyRepository (from PCIM) is updated as 2604 follows, with an indication that the class has been deprecated. Note 2605 that when an element of the model is deprecated, its replacement element 2606 is identified explicitly. 2608 NAME PolicyRepository 2609 DEPRECATED FOR ReusablePolicyContainer 2610 DESCRIPTION A class representing an administratively defined 2611 container for reusable policy-related information. 2612 This class does not introduce any additional 2613 properties beyond those in its superclass AdminDomain. 2614 It does, however, participate in a number of unique 2615 associations. 2616 DERIVED FROM AdminDomain 2617 ABSTRACT FALSE 2618 PROPERTIES (none) 2620 6. Association and Aggregation Definitions 2622 The following definitions supplement those in PCIM itself. PCIM 2623 definitions that are not DEPRECATED here are still current parts of the 2624 overall Policy Core Information Model. 2626 6.1. The Abstract Aggregation "PolicySetComponent" 2628 PolicySetComponent is a new abstract aggregation class that collects 2629 instances of PolicySet subclasses (PolicyGroups and PolicyRules) into 2630 coherent sets of policies. 2632 NAME PolicySetComponent 2633 DESCRIPTION An abstract class representing the components of a 2634 policy set that have the same decision strategy, and 2635 are prioritized within the set. 2636 DERIVED FROM PolicyComponent 2637 ABSTRACT TRUE 2638 PROPERTIES GroupComponent[ref PolicySet[0..n]] 2639 PartComponent[ref PolicySet[0..n]] 2640 Priority 2642 The definition of the Priority property is unchanged from its previous 2643 definition in [PCIM]. 2645 NAME Priority 2646 DESCRIPTION A non-negative integer for prioritizing this PolicySet 2647 component relative to other components of the same 2648 PolicySet. A larger value indicates a higher 2649 priority. 2650 SYNTAX uint16 2651 DEFAULT VALUE 0 2653 6.2. Update to PCIM's Aggregation "PolicyGroupInPolicyGroup" 2655 The PolicyGroupInPolicyGroup aggregation class is modified to be derived 2656 from PolicySetComponent. 2658 NAME PolicyGroupInPolicyGroup 2659 DESCRIPTION A class representing the aggregation of PolicyGroups 2660 by a higher-level PolicyGroup. 2661 DERIVED FROM PolicySetComponent 2662 ABSTRACT FALSE 2663 PROPERTIES GroupComponent[ref PolicyGroup[0..n]] 2664 PartComponent[ref PolicyGroup[0..n]] 2666 6.3. Update to PCIM's Aggregation "PolicyRuleInPolicyGroup" 2668 The PolicyRuleInPolicyGroup aggregation class is modified to be derived 2669 from PolicySetComponent. 2671 NAME PolicyRuleInPolicyGroup 2672 DESCRIPTION A class representing the aggregation of PolicyRules by 2673 a PolicyGroup. 2674 DERIVED FROM PolicySetComponent 2675 ABSTRACT FALSE 2676 PROPERTIES GroupComponent[ref PolicyGroup[0..n]] 2677 PartComponent[ref PolicyRule[0..n]] 2679 6.4. The Aggregation "PolicyGroupInPolicyRule" 2681 A policy rule may aggregate one or more policy groups, via the 2682 PolicyGroupInPolicyRule aggregation. Grouping of policy groups and their 2683 subclasses into a policy rule is for administrative convenience, 2684 scalability and manageability, as it enables more complex policies to be 2685 constructed from multiple simpler policies. 2687 Policy rules do not have to contain policy groups. In addition, a policy 2688 group may also be used by itself, without belonging to a policy rule, and 2689 policy rules may be individually aggregated by other policy rules by the 2690 PolicyRuleInPolicyRule aggregation. Note that it is assumed that this 2691 aggregation is used to form directed acyclic graphs and NOT ring 2692 structures. 2694 The class definition for this aggregation is as follows: 2696 NAME PolicyGroupInPolicyRule 2697 DERIVED FROM PolicySetComponent 2698 ABSTRACT False 2699 PROPERTIES GroupComponent[ref PolicyRule[0..n]] 2700 PartComponent[ref PolicyGroup[0..n]] 2702 The reference property "GroupComponent" is inherited from 2703 PolicySetComponent, and overridden to become an object reference to a 2704 PolicyRule that contains one or more PolicyGroups. Note that for any 2705 single instance of the aggregation class PolicyGroupInPolicyRule, this 2706 property (like all reference properties) is single-valued. The [0..n] 2707 cardinality indicates that there may be 0, 1 or more than one PolicyRules 2708 that contain any given PolicyGroup. 2710 The reference property "PartComponent" is inherited from 2711 PolicySetComponent, and overridden to become an object reference to a 2712 PolicyGroup contained by one or more PolicyRules. Note that for any 2713 single instance of the aggregation class PolicyGroupInPolicyRule, this 2714 property (like all reference properties) is single-valued. The [0..n] 2715 cardinality indicates that a given PolicyRule may contain 0, 1, or more 2716 than one PolicyGroup. 2718 6.5. The Aggregation "PolicyRuleInPolicyRule" 2720 A policy rule may aggregate one or more policy rules, via the 2721 PolicyRuleInPolicyRule aggregation. The ability to nest policy rules and 2722 form sub-rules is important for manageability and scalability, as it 2723 enables complex policy rules to be constructed from multiple simpler 2724 policy rules. 2726 A policy rule does not have to contain sub-rules. A policy rule may 2727 contain a group of sub-rules using the PolicyGroupInPolicyRule 2728 aggregation. Note that it is assumed that this aggregation is used to 2729 form directed a-cyclic graphs and NOT ring structures. 2731 The class definition for this aggregation is as follows: 2733 NAME PolicyRuleInPolicyRule 2734 DERIVED FROM PolicySetComponent 2735 ABSTRACT False 2736 PROPERTIES GroupComponent[ref PolicyRule[0..n]] 2737 PartComponent[ref PolicyRule[0..n]] 2739 The reference property "GroupComponent" is inherited from 2740 PolicySetComponent, and overridden to become an object reference to a 2741 PolicyRule that contains one or more PolicyRules. Each contained 2742 PolicyRule can be conceptualized as a sub-rule of the containing 2743 PolicyRule. This nesting can be done to any desired level. However, the 2744 deeper the nesting, the more complex the results of the decisions taken 2745 by the nested rules. 2747 Note that for any single instance of the aggregation class 2748 PolicyRuleInPolicyRule, this property is single-valued. The [0..n] 2749 cardinality indicates that there may be 0, 1 or more than one 2750 PolicyRules that contain any given PolicyRule. 2752 The reference property "PartComponent" is inherited from 2753 PolicySetComponent, and overridden to become an object reference to a 2754 PolicyRule contained by a PolicyRule. Note that for any single instance 2755 of the aggregation class PolicyRuleInPolicyRule, this property is single- 2756 valued. The [0..n] cardinality indicates that a given PolicyRule may 2757 contain 0, 1, or more than one other PolicyRules. 2759 6.6. The Abstract Aggregation "CompoundedPolicyCondition" 2761 NAME CompoundedPolicyCondition 2762 DESCRIPTION A class representing the aggregation of 2763 PolicyConditions by an aggregating instance. 2764 DERIVED FROM PolicyComponent 2765 ABSTRACT TRUE 2766 PROPERTIES PartComponent[ref PolicyCondition[0..n]] 2767 GroupNumber 2768 ConditionNegated 2770 6.7. Update to PCIM's Aggregation "PolicyConditionInPolicyRule" 2772 The PCIM aggregation "PolicyConditionInPolicyRule" is updated, to make it 2773 a subclass of the new abstract aggregation CompoundedPolicyCondition. 2774 The properties GroupNumber and ConditionNegated are now inherited, rather 2775 than specified explicitly as they were in PCIM. 2777 NAME PolicyConditionInPolicyRule 2778 DESCRIPTION A class representing the aggregation of 2779 PolicyConditions by a PolicyRule. 2780 DERIVED FROM CompoundedPolicyCondition 2781 ABSTRACT FALSE 2782 PROPERTIES GroupComponent[ref PolicyRule[0..n]] 2784 6.8. The Aggregation "PolicyConditionInPolicyCondition" 2786 A second subclass of CompoundedPolicyCondition is defined, representing 2787 the compounding of policy conditions into a higher-level policy 2788 condition. 2790 NAME PolicyConditionInPolicyCondition 2791 DESCRIPTION A class representing the aggregation of 2792 PolicyConditions by another PolicyCondition. 2793 DERIVED FROM CompoundedPolicyCondition 2794 ABSTRACT FALSE 2795 PROPERTIES GroupComponent[ref PolicyCondition[0..n]] 2797 6.9. The Abstract Aggregation "CompoundedPolicyAction" 2799 NAME CompoundedPolicyAction 2800 DESCRIPTION A class representing the aggregation of PolicyActions 2801 by an aggregating instance. 2802 DERIVED FROM PolicyComponent 2803 ABSTRACT TRUE 2804 PROPERTIES PartComponent[ref PolicyAction[0..n]] 2805 ActionOrder 2807 6.10. Update to PCIM's Aggregation "PolicyActionInPolicyRule" 2809 The PCIM aggregation "PolicyActionInPolicyRule" is updated, to make it a 2810 subclass of the new abstract aggregation CompoundedPolicyAction. The 2811 property ActionOrder is now inherited, rather than specified explicitly 2812 as it was in PCIM. 2814 NAME PolicyActionInPolicyRule 2815 DESCRIPTION A class representing the aggregation of PolicyActions 2816 by a PolicyRule. 2817 DERIVED FROM CompoundedPolicyAction 2818 ABSTRACT FALSE 2819 PROPERTIES GroupComponent[ref PolicyRule[0..n]] 2821 6.11. The Aggregation "PolicyActionInPolicyAction" 2823 A second subclass of CompoundedPolicyAction is defined, representing the 2824 compounding of policy actions into a higher-level policy action. 2826 NAME PolicyActionInPolicyAction 2827 DESCRIPTION A class representing the aggregation of PolicyActions 2828 by another PolicyAction. 2829 DERIVED FROM CompoundedPolicyAction 2830 ABSTRACT FALSE 2831 PROPERTIES GroupComponent[ref PolicyAction[0..n]] 2833 6.12. The Aggregation "PolicyVariableInSimplePolicyCondition" 2835 A simple policy condition is represented as an ordered triplet {variable, 2836 operator, value}. This aggregation provides the linkage between a 2837 SimplePolicyCondition instance and a single PolicyVariable. The 2838 aggregation PolicyValueInSimplePolicyCondition links the 2839 SimplePolicyCondition to a single PolicyValue. The Operator property of 2840 SimplePolicyCondition represents the third element of the triplet, the 2841 operator. 2843 The class definition for this aggregation is as follows: 2845 NAME PolicyVariableInSimplePolicyCondition 2846 DERIVED FROM PolicyComponent 2847 ABSTRACT False 2848 PROPERTIES GroupComponent[ref SimplePolicyCondition[0..n]] 2849 PartComponent[ref PolicyVariable[1..1] ] 2851 The reference property "GroupComponent" is inherited from 2852 PolicyComponent, and overridden to become an object reference to a 2853 SimplePolicyCondition that contains exactly one PolicyVariable. Note 2854 that for any single instance of the aggregation class 2855 PolicyVariableInSimplePolicyCondition, this property is single-valued. 2856 The [0..n] cardinality indicates that there may be 0, 1, or more 2857 SimplePolicyCondition objects that contain any given policy variable 2858 object. 2860 The reference property "PartComponent" is inherited from PolicyComponent, 2861 and overridden to become an object reference to a PolicyVariable that is 2862 defined within the scope of a SimplePolicyCondition. Note that for any 2863 single instance of the association class 2864 PolicyVariableInSimplePolicyCondition, this property (like all reference 2865 properties) is single-valued. The [1..1] cardinality indicates that a 2866 SimplePolicyCondition must have exactly one policy variable defined 2867 within its scope in order to be meaningful. 2869 6.13. The Aggregation "PolicyValueInSimplePolicyCondition" 2871 A simple policy condition is represented as an ordered triplet {variable, 2872 operator, value}. This aggregation provides the linkage between a 2873 SimplePolicyCondition instance and a single PolicyValue. The aggregation 2874 PolicyVariableInSimplePolicyCondition links the SimplePolicyCondition to 2875 a single PolicyVariable. The Operator property of SimplePolicyCondition 2876 represents the third element of the triplet, the operator. 2878 The class definition for this aggregation is as follows: 2880 NAME PolicyValueInSimplePolicyCondition 2881 DERIVED FROM PolicyComponent 2882 ABSTRACT False 2883 PROPERTIES GroupComponent[ref SimplePolicyCondition[0..n]] 2884 PartComponent[ref PolicyValue[1..1] ] 2886 The reference property "GroupComponent" is inherited from 2887 PolicyComponent, and overridden to become an object reference to a 2888 SimplePolicyCondition that contains exactly one PolicyValue. Note that 2889 for any single instance of the aggregation class 2890 PolicyValueInSimplePolicyCondition, this property is single-valued. The 2891 [0..n] cardinality indicates that there may be 0, 1, or more 2892 SimplePolicyCondition objects that contain any given policy value object. 2894 The reference property "PartComponent" is inherited from PolicyComponent, 2895 and overridden to become an object reference to a PolicyValue that is 2896 defined within the scope of a SimplePolicyCondition. Note that for any 2897 single instance of the association class 2898 PolicyValueInSimplePolicyCondition, this property (like all reference 2899 properties) is single-valued. The [1..1] cardinality indicates that a 2900 SimplePolicyCondition must have exactly one policy value defined within 2901 its scope in order to be meaningful. 2903 6.14. The Aggregation "PolicyVariableInSimplePolicyAction" 2905 A simple policy action is represented as a pair {variable, value}. This 2906 aggregation provides the linkage between a SimplePolicyAction instance 2907 and a single PolicyVariable. The aggregation 2908 PolicyValueInSimplePolicyAction links the SimplePolicyAction to a single 2909 PolicyValue. 2911 The class definition for this aggregation is as follows: 2913 NAME PolicyVariableInSimplePolicyAction 2914 DERIVED FROM PolicyComponent 2915 ABSTRACT False 2916 PROPERTIES GroupComponent[ref SimplePolicyAction[0..n]] 2917 PartComponent[ref PolicyVariable[1..1] ] 2919 The reference property "GroupComponent" is inherited from 2920 PolicyComponent, and overridden to become an object reference to a 2921 SimplePolicyAction that contains exactly one PolicyVariable. Note that 2922 for any single instance of the aggregation class 2923 PolicyVariableInSimplePolicyAction, this property is single-valued. The 2924 [0..n] cardinality indicates that there may be 0, 1, or more 2925 SimplePolicyAction objects that contain any given policy variable object. 2927 The reference property "PartComponent" is inherited from PolicyComponent, 2928 and overridden to become an object reference to a PolicyVariable that is 2929 defined within the scope of a SimplePolicyAction. Note that for any 2930 single instance of the association class 2931 PolicyVariableInSimplePolicyAction, this property (like all reference 2932 properties) is single-valued. The [1..1] cardinality indicates that a 2933 SimplePolicyAction must have exactly one policy variable defined within 2934 its scope in order to be meaningful. 2936 6.15. The Aggregation "PolicyValueInSimplePolicyAction" 2938 A simple policy action is represented as a pair {variable, value}. This 2939 aggregation provides the linkage between a SimplePolicyAction instance 2940 and a single PolicyValue. The aggregation 2941 PolicyVariableInSimplePolicyAction links the SimplePolicyAction to a 2942 single PolicyVariable. 2944 The class definition for this aggregation is as follows: 2946 NAME PolicyValueInSimplePolicyAction 2947 DERIVED FROM PolicyComponent 2948 ABSTRACT False 2949 PROPERTIES GroupComponent[ref SimplePolicyAction[0..n]] 2950 PartComponent[ref PolicyValue[1..1] ] 2952 The reference property "GroupComponent" is inherited from 2953 PolicyComponent, and overridden to become an object reference to a 2954 SimplePolicyAction that contains exactly one PolicyValue. Note that for 2955 any single instance of the aggregation class 2956 PolicyValueInSimplePolicyAction, this property is single-valued. The 2957 [0..n] cardinality indicates that there may be 0, 1, or more 2958 SimplePolicyAction objects that contain any given policy value object. 2960 The reference property "PartComponent" is inherited from PolicyComponent, 2961 and overridden to become an object reference to a PolicyValue that is 2962 defined within the scope of a SimplePolicyAction. Note that for any 2963 single instance of the association class PolicyValueInSimplePolicyAction, 2964 this property (like all reference properties) is single-valued. The 2965 [1..1] cardinality indicates that a SimplePolicyAction must have exactly 2966 one policy value defined within its scope in order to be meaningful. 2968 6.16. The Association "ReusablePolicy" 2970 The association ReusablePolicy makes it possible to include any subclass 2971 of the abstract class "Policy" in a ReusablePolicyContainer. 2973 NAME ReusablePolicy 2974 DESCRIPTION A class representing the inclusion of a reusable 2975 policy element in a ReusablePolicyContainer. Reusable 2976 elements may be PolicyGroups, PolicyRules, 2977 PolicyConditions, PolicyActions, PolicyVariables, 2978 PolicyValues, or instances of any other subclasses of 2979 the abstract class Policy. 2980 DERIVED FROM PolicyInSystem 2981 ABSTRACT FALSE 2982 PROPERTIES Antecedent[ref ReusablePolicyContainer[0..1]] 2984 6.17. Deprecate PCIM's "PolicyConditionInPolicyRepository" 2986 NAME PolicyConditionInPolicyRepository 2987 DEPRECATED FOR ReusablePolicy 2988 DESCRIPTION A class representing the inclusion of a reusable 2989 PolicyCondition in a PolicyRepository. 2990 DERIVED FROM PolicyInSystem 2991 ABSTRACT FALSE 2992 PROPERTIES Antecedent[ref PolicyRepository[0..1]] 2993 Dependent[ref PolicyCondition[0..n]] 2995 6.18. Deprecate PCIM's "PolicyActionInPolicyRepository" 2997 NAME PolicyActionInPolicyRepository 2998 DEPRECATED FOR ReusablePolicy 2999 DESCRIPTION A class representing the inclusion of a reusable 3000 PolicyAction in a PolicyRepository. 3001 DERIVED FROM PolicyInSystem 3002 ABSTRACT FALSE 3003 PROPERTIES Antecedent[ref PolicyRepository[0..1]] 3004 Dependent[ref PolicyAction[0..n]] 3006 6.19. The Association PolicyValueConstraintInVariable 3008 This association links a PolicyValue object to a PolicyVariable object, 3009 modeling specific value constraints. Using this association, a variable 3010 (instance) may be constrained to be bound-to/assigned only a set of 3011 allowed values. For example, modeling an enumerated source port 3012 variable, one creates an instance of the PolicySourcePortVariable class 3013 and associates it with the set of values (integers) representing the 3014 allowed enumeration, using appropriate number of instances of the 3015 PolicyValueConstraintInVariable association. 3017 Note that a single variable instance may be constrained by any number of 3018 values and a single value may be used to constrain any number of 3019 variables. These relationships are manifested by the n-to-m cardinality 3020 of the association. 3022 The class definition for the association is as follows: 3024 NAME PolicyValueConstraintInVariable 3025 DESCRIPTION A class representing the association of a constraints 3026 object to a variable object. 3027 DERIVED FROM Dependency 3028 ABSTRACT FALSE 3029 PROPERTIES Antecedent [ref PolicyVariable[0..n]] 3030 Dependent [ref PolicyValue [0..n]] 3032 The reference property Antecedent is inherited from Dependency. Its type 3033 and cardinality are overridden to provide the semantics of a variable 3034 optionally having value constraints. The [0..n] cardinality indicates 3035 that any number of variables may be constrained by a given value. 3037 The reference property "Dependent" is inherited from Dependency, and 3038 overridden to become an object reference to a PolicyValue that is used to 3039 constrain the values that a particular PolicyVariable can have. The 3040 [0..n] cardinality indicates that a given policy variable may have 0, 1 3041 or more than one PolicyValues defined to model the constraints on the 3042 values that the policy variable can take. 3044 6.20. The Aggregation "PolicyContainerInPolicyContainer" 3046 The aggregation PolicyContainerInPolicyContainer provides for nesting of 3047 one ReusablePolicyContainer inside another one. 3049 NAME PolicyContainerInPolicyContainer 3050 DESCRIPTION A class representing the aggregation of 3051 ReusablePolicyContainers by a higher-level 3052 ReusablePolicyContainer. 3053 DERIVED FROM SystemComponent 3054 ABSTRACT FALSE 3055 PROPERTIES GroupComponent[ref ReusablePolicyContainer [0..n]] 3056 PartComponent[ref ReusablePolicyContainer [0..n]] 3058 6.21. Deprecate PCIM's "PolicyRepositoryInPolicyRepository" 3060 NAME PolicyRepositoryInPolicyRepository 3061 DEPRECATED FOR PolicyContainerInPolicyContainer 3062 DESCRIPTION A class representing the aggregation of 3063 PolicyRepositories by a higher-level PolicyRepository. 3064 DERIVED FROM SystemComponent 3065 ABSTRACT FALSE 3066 PROPERTIES GroupComponent[ref PolicyRepository[0..n]] 3067 PartComponent[ref PolicyRepository[0..n]] 3069 6.22. The Aggregation "ElementInPolicyRoleCollection" 3071 The following aggregation is used to associate ManagedElements with a 3072 PolicyRoleCollection object that represents a role played by these 3073 ManagedElements. 3075 NAME ElementInPolicyRoleCollection 3076 DESCRIPTION A class representing the inclusion of a ManagedElement 3077 in a collection, specified as having a given role. 3078 All the managed elements in the collection share the 3079 same role. 3080 DERIVED FROM MemberOfCollection 3081 ABSTRACT FALSE 3082 PROPERTIES Collection[ref PolicyRoleCollection [0..n]] 3083 Member[ref ManagedElement [0..n]] 3085 6.22.1. The Weak Association "PolicyRoleCollectionInSystem" 3087 A PolicyRoleCollection is defined within the scope of a System. This 3088 association links a PolicyRoleCollection to the System in whose scope it 3089 is defined. 3091 When associating a PolicyRoleCollection with a System, this should be 3092 done consistently with the system that scopes the policy rules/groups 3093 that are applied to the resources in that collection. A 3094 PolicyRoleCollection is associated with the same system as the applicable 3095 PolicyRules and/or PolicyGroups, or to a System higher in the tree formed 3096 by the SystemComponent association. 3098 The class definition for the association is as follows: 3100 NAME PolicyRoleCollectionInSystem 3101 DESCRIPTION A class representing the fact that a 3102 PolicyRoleCollection is defined within the scope of a 3103 System. 3104 DERIVED FROM Dependency 3105 ABSTRACT FALSE 3106 PROPERTIES Antecedent[ref System[1..1]] 3107 Dependent[ref PolicyRoleCollection[weak]] 3109 The reference property Antecedent is inherited from Dependency, and 3110 overridden to restrict its cardinality to [1..1]. It serves as an object 3111 reference to a System that provides a scope for one or more 3112 PolicyRoleCollections. Since this is a weak association, the cardinality 3113 for this object reference is always 1, that is, a PolicyRoleCollection is 3114 always defined within the scope of exactly one System. 3116 The reference property Dependent is inherited from Dependency, and 3117 overridden to become an object reference to a PolicyRoleCollection 3118 defined within the scope of a System. Note that for any single instance 3119 of the association class PolicyRoleCollectionInSystem, this property 3120 (like all Reference properties) is single-valued. The [0..n] cardinality 3121 indicates that a given System may have 0, 1, or more than one 3122 PolicyRoleCollections defined within its scope. 3124 7. Intellectual Property 3126 The IETF takes no position regarding the validity or scope of any 3127 intellectual property or other rights that might be claimed to pertain to 3128 the implementation or use of the technology described in this document or 3129 the extent to which any license under such rights might or might not be 3130 available; neither does it represent that it has made any effort to 3131 identify any such rights. Information on the IETF's procedures with 3132 respect to rights in standards-track and standards-related documentation 3133 can be found in BCP-11. 3135 Copies of claims of rights made available for publication and any 3136 assurances of licenses to be made available, or the result of an attempt 3137 made to obtain a general license or permission for the use of such 3138 proprietary rights by implementers or users of this specification can be 3139 obtained from the IETF Secretariat. 3141 The IETF invites any interested party to bring to its attention any 3142 copyrights, patents or patent applications, or other proprietary rights 3143 which may cover technology that may be required to practice this 3144 standard. Please address the information to the IETF Executive Director. 3146 8. Acknowledgements 3148 The starting point for this document was PCIM itself [3], and the first 3149 three submodels derived from it [5], [6], [7]. The authors of these 3150 documents created the extensions to PCIM, and asked the questions about 3151 PCIM, that are reflected in PCIMe. 3153 9. Security Considerations 3155 The Policy Core Information Model (PCIM) [3] describes the general 3156 security considerations related to the general core policy model. The 3157 extensions defined in this document do not introduce any additional 3158 considerations related to security. 3160 10. References 3162 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3163 Levels", BCP 14, RFC 2119, March 1997. 3165 [2] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 3166 Standards Process", BCP 11, RFC 2028, October 1996. 3168 [3] Strassner, J., and E. Ellesson, B. Moore, A. Westerinen, "Policy Core 3169 Information Model -- Version 1 Specification", RFC 3060, February 3170 2001. 3172 [4] Distributed Management Task Force, Inc., "DMTF Technologies: CIM 3173 Standards � CIM Schema: Version 2.5", available via links on the 3174 following DMTF web page: http://www.dmtf.org/spec/cim_schema_v25.html. 3176 [5] Snir, Y., and Y. Ramberg, J. Strassner, R. Cohen, "Policy Framework 3177 QoS Information Model", work in progress, draft-ietf-policy-qos-info- 3178 model-02.txt, November 2000. 3180 [6] Jason, J., and L. Rafalow, E. Vyncke, "IPsec Configuration Policy 3181 Model", work in progress, draft-ietf-ipsp-config-policy-model-02.txt, 3182 March 2001. 3184 [7] Chadha, R., and M. Brunner, M. Yoshida, J. Quittek, G. Mykoniatis, A. 3185 Poylisher, R. Vaidyanathan, A. Kind, F. Reichmeyer, "Policy Framework 3186 MPLS Information Model for QoS and TE", work in progress, draft- 3187 chadha-policy-mpls-te-01.txt, December 2000. 3189 [8] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: 3190 ABNF", RFC 2234, November 1997. 3192 [9] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", 3193 RFC1035, November 1987. 3195 [10] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", 3196 RFC2373, July 1998. 3198 [11] M. Wahl, A. Coulbeck, "Lightweight Directory Access Protocol (v3): 3199 Attribute Syntax Definitions", RFC 2252. 3201 [12] A. Westerinen, et al., "Policy Terminology", , November 2000. 3204 [13] S. Waldbusser, and J. Saperia, T. Hongal, "Policy Based Management 3205 MIB", , November 2000. 3207 11. Authors' Addresses 3209 Bob Moore 3210 IBM Corporation, BRQA/502 3211 4205 S. Miami Blvd. 3212 Research Triangle Park, NC 27709 3213 Phone: +1 919-254-4436 3214 Fax: +1 919-254-6243 3215 E-mail: remoore@us.ibm.com 3217 Lee Rafalow 3218 IBM Corporation, BRQA/502 3219 4205 S. Miami Blvd. 3220 Research Triangle Park, NC 27709 3221 Phone: +1 919-254-4455 3222 Fax: +1 919-254-6243 3223 E-mail: rafalow@us.ibm.com 3225 Yoram Ramberg 3226 Cisco Systems 3227 4 Maskit Street 3228 Herzliya Pituach, Israel 46766 3229 Phone: +972-9-970-0081 3230 Fax: +972-9-970-0219 3231 E-mail: yramberg@cisco.com 3233 Yoram Snir 3234 Cisco Systems 3235 4 Maskit Street 3236 Herzliya Pituach, Israel 46766 3237 Phone: +972-9-970-0085 3238 Fax: +972-9-970-0366 3239 E-mail: ysnir@cisco.com 3241 John Strassner 3242 Cisco Systems 3243 Building 20 3244 725 Alder Drive 3245 Milpitas, CA 95035 3246 Phone: +1-408-527-1069 3247 Fax: +1-408-527-2477 3248 E-mail: johns@cisco.com 3250 Andrea Westerinen 3251 Cisco Systems 3252 Building 20 3253 725 Alder Drive 3254 Milpitas, CA 95035 3255 Phone: +1-408-853-8294 3256 Fax: +1-408-527-6351 3257 E-mail: andreaw@cisco.com 3259 Ritu Chadha 3260 Telcordia Technologies 3261 MCC 1J-218R 3262 445 South Street 3263 Morristown NJ 07960. 3264 Phone: +1-973-829-4869 3265 Fax: +1-973-829-5889 3266 E-mail: chadha@research.telcordia.com 3268 Marcus Brunner 3269 NEC Europe Ltd. 3270 C&C Research Laboratories 3271 Adenauerplatz 6 3272 D-69115 Heidelberg, Germany 3273 Phone: +49 (0)6221 9051129 3274 Fax: +49 (0)6221 9051155 3275 E-mail: brunner@ccrle.nec.de 3277 Ron Cohen 3278 Ntear LLC 3279 Phone: 3280 Fax: 3281 E-mail: ronc@ntear.com 3283 12. Full Copyright Statement 3285 Copyright (C) The Internet Society (2001). All Rights Reserved. 3287 This document and translations of it may be copied and furnished to 3288 others, and derivative works that comment on or otherwise explain it or 3289 assist in its implementation may be prepared, copied, published and 3290 distributed, in whole or in part, without restriction of any kind, 3291 provided that the above copyright notice and this paragraph are included 3292 on all such copies and derivative works. However, this document itself 3293 may not be modified in any way, such as by removing the copyright notice 3294 or references to the Internet Society or other Internet organizations, 3295 except as needed for the purpose of developing Internet standards in 3296 which case the procedures for copyrights defined in the Internet 3297 Standards process must be followed, or as required to translate it into 3298 languages other than English. 3300 The limited permissions granted above are perpetual and will not be 3301 revoked by the Internet Society or its successors or assigns. 3303 This document and the information contained herein is provided on an "AS 3304 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 3305 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 3306 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 3307 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 3308 FITNESS FOR A PARTICULAR PURPOSE. 3310 13. Appendix A: Open Issues 3312 The PCIMe authors do not all agree with everything included in the -00 3313 draft of the document. Input is solicited from the working group as a 3314 whole on the following open issues: 3316 1. Unrestricted use of DNF/CNF for CompoundPolicyConditions. 3317 Alternative: for the conditions aggregated by a 3318 CompoundPolicyCondition, allow only ANDing, with negation of 3319 individual conditions. Note that this is sufficient to build 3320 multi-field packet filters from single-field 3321 SimplePolicyConditions. 3323 2. For a PolicyVariable in a SimplePolicyCondition, restrict the set 3324 of possible values both via associated PolicyValue objects (tied 3325 in with the PolicyValueConstraintInVariable association) and via 3326 the ValueTypes property in the PolicyVariable class. Alternative: 3327 restrict values only via associated PolicyValue objects. 3329 3. Transactional semantics, including rollback, for the 3330 ExecutionStrategy property in PolicyRule and in 3331 CompoundPolicyAction. Alternative: have only 'Do until success' 3332 and 'Do all'. 3334 4. Stating that CompoundFilterConditions are the preferred way to do 3335 packet filtering in a PolicyCondition. Alternative: make 3336 CompoundFilterConditions and FilterEntries available to submodels, 3337 with no stated (or implied) preference. 3339 5. Prohibiting equal values for Priority within a PolicySet. 3340 Alternative: allow equal values, with resulting indeterminacy in 3341 PEP behavior. 3343 6. Modeling a SimplePolicyAction with just a related PolicyVariable 3344 and PolicyValue -- the "set" or "apply" operation is implicit. 3345 Alternative: include an Operation property in SimplePolicyAction, 3346 similar to the Operation property in SimplePolicyCondition. 3348 7. Representation of PolicyValues: should values like IPv4 addresses 3349 be represented only as strings (as in LDAP), or natively (e.g., an 3350 IPv4 address would be a four-octet field) with mappings to other 3351 representations such as strings? 3353 8. The nesting of rules and groups within rules introduces 3354 significant change and complexity in the model. This nesting 3355 introduces program state (procedural language) into the model 3356 (heretofore a declarative model) as well as implicit hierarchical 3357 contexts on which the rules operate. These require a much more 3358 sophisticated rule-evaluation engine than in the past. 3360 Alternative: Maintain the declarative model, by prohibiting 3361 program state in rule evaluation (i.e., no rules within rules). 3363 9. Need to specify a join algorithm for disjoint rule sets. 3365 10. Clarify PolicyImplicitVariables. 3367 11. Clarify PolicyExplicitVariables.