idnits 2.17.1 draft-ietf-policy-pcim-ext-07.txt: -(729): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1749): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2035): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2190): 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 5 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 22) 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 1146 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 1496 has weird spacing: '...alue of this...' == Line 1837 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: 'PolicyIntegerValue' on line 1450 == Missing Reference: '300' is mentioned on line 1450, but not defined -- Looks like a reference, but probably isn't: 'FirstMatching' on line 1991 -- Looks like a reference, but probably isn't: 'AllMatching' on line 1990 -- Looks like a reference, but probably isn't: 'PCIM' on line 3422 == Unused Reference: '2' is defined on line 4026, 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-04 == Outdated reference: A later version (-06) exists of draft-ietf-ipsp-config-policy-model-04 -- 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) ** Downref: Normative reference to an Informational RFC: RFC 3198 (ref. '12') -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 11 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 Updates: 3060 IBM 4 Category: Standards Track Y. Ramberg 5 Y. Snir 6 A. Westerinen 7 Cisco Systems 8 R. Chadha 9 Telcordia Technologies 10 M. Brunner 11 NEC 12 R. Cohen 13 Ntear LLC 14 J. Strassner 15 INTELLLIDEN, Inc. 16 February, 2002 18 Policy Core Information Model Extensions 20 21 Wednesday, February 27, 2002, 8:58 AM 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with all 26 provisions of Section 10 of RFC2026. 28 Internet-Drafts are working documents of the Internet Engineering Task 29 Force (IETF), its areas, and its working groups. Note that other groups 30 may also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months and 33 may be updated, replaced, or obsoleted by other documents at any time. 34 It is inappropriate to use Internet-Drafts as reference material or to 35 cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright Notice 45 Copyright (C) The Internet Society (2002). All Rights Reserved. 47 Abstract 49 This document proposes a number of changes to the Policy Core Information 50 Model (PCIM, RFC 3060). These changes include both extensions of PCIM 51 into areas that it did not previously cover, and changes to the existing 52 PCIM classes and associations. Both sets of changes are done in a way 53 that, to the extent possible, preserves interoperability with 54 implementations of the original PCIM model. 56 Table of Contents 58 1. Introduction......................................................5 59 2. Overview of the Changes...........................................5 60 2.1. How to Change an Information Model...........................5 61 2.2. List of Changes to the Model.................................6 62 2.2.1. Changes to PolicyRepository................................6 63 2.2.2. Additional Associations and Additional Reusable Elements...6 64 2.2.3. Priorities and Decision Strategies.........................6 65 2.2.4. Policy Roles...............................................7 66 2.2.5. CompoundPolicyConditions and CompoundPolicyActions.........7 67 2.2.6. Variables and Values.......................................7 68 2.2.7. Domain-Level Packet Filtering..............................8 69 2.2.8. Device-Level Packet Filtering..............................8 70 3. The Updated Class and Association Class Hierarchies...............8 71 4. Areas of Extension to PCIM.......................................12 72 4.1. Policy Scope................................................13 73 4.1.1. Levels of Abstraction: Domain- and Device-Level Policies..13 74 4.1.2. Administrative and Functional Scopes......................13 75 4.2. Reusable Policy Elements....................................14 76 4.3. Policy Sets.................................................15 77 4.4. Nested Policy Rules.........................................15 78 4.4.1. Usage Rules for Nested Rules..............................15 79 4.4.2. Motivation................................................16 80 4.5. Priorities and Decision Strategies..........................17 81 4.5.1. Structuring Decision Strategies...........................18 82 4.5.2. Side Effects..............................................19 83 4.5.3. Multiple PolicySet Trees For a Resource...................20 84 4.5.4. Deterministic Decisions...................................21 85 4.6. Policy Roles................................................22 86 4.6.1. Comparison of Roles in PCIM with Roles in snmpconf........22 87 4.6.2. Addition of PolicyRoleCollection to PCIMe.................22 88 4.6.3. Roles for PolicyGroups....................................23 89 4.7. Compound Policy Conditions and Compound Policy Actions......25 90 4.7.1. Compound Policy Conditions................................25 91 4.7.2. Compound Policy Actions...................................25 92 4.8. Variables and Values........................................26 93 4.8.1. Simple Policy Conditions..................................26 94 4.8.2. Using Simple Policy Conditions............................27 95 4.8.3. The Simple Condition Operator.............................28 96 4.8.4. SimplePolicyActions.......................................31 97 4.8.5. Policy Variables..........................................32 98 4.8.6. Explicitly Bound Policy Variables.........................33 99 4.8.7. Implicitly Bound Policy Variables.........................34 100 4.8.8. Structure and Usage of Pre-Defined Variables..............35 101 4.8.9. Rationale for Modeling Implicit Variables as Classes......36 102 4.8.10. Policy Values............................................37 103 4.9. Packet Filtering............................................37 104 4.9.1. Domain-Level Packet Filters...............................38 105 4.9.2. Device-Level Packet Filters...............................39 106 4.10. Conformance to PCIM and PCIMe..............................39 107 5. Class Definitions................................................40 108 5.1. The Abstract Class "PolicySet"..............................40 109 5.2. Update PCIM's Class "PolicyGroup"...........................41 110 5.3. Update PCIM's Class "PolicyRule"............................41 111 5.4. The Class "SimplePolicyCondition"...........................42 112 5.5. The Class "CompoundPolicyCondition".........................43 113 5.6. The Class "CompoundFilterCondition".........................43 114 5.7. The Class "SimplePolicyAction"..............................44 115 5.8. The Class "CompoundPolicyAction"............................44 116 5.9. The Abstract Class "PolicyVariable".........................46 117 5.10. The Class "PolicyExplicitVariable".........................46 118 5.10.1. The Single-Valued Property "ModelClass"..................46 119 5.10.2. The Single-Valued Property ModelProperty.................47 120 5.11. The Abstract Class "PolicyImplicitVariable"................47 121 5.11.1. The Multi-Valued Property "ValueTypes"...................47 122 5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe..48 123 5.12.1. The Class "PolicySourceIPv4Variable".....................48 124 5.12.2. The Class "PolicySourceIPv6Variable".....................48 125 5.12.3. The Class "PolicyDestinationIPv4Variable"................48 126 5.12.4. The Class "PolicyDestinationIPv6Variable"................48 127 5.12.5. The Class "PolicySourcePortVariable".....................49 128 5.12.6. The Class "PolicyDestinationPortVariable"................49 129 5.12.7. The Class "PolicyIPProtocolVariable".....................50 130 5.12.8. The Class "PolicyIPVersionVariable"......................50 131 5.12.9. The Class "PolicyIPToSVariable"..........................50 132 5.12.10. The Class "PolicyDSCPVariable"..........................50 133 5.12.11. The Class "PolicyFlowIdVariable"........................51 134 5.12.12. The Class "PolicySourceMACVariable".....................51 135 5.12.13. The Class "PolicyDestinationMACVariable"................51 136 5.12.14. The Class "PolicyVLANVariable"..........................51 137 5.12.15. The Class "PolicyCoSVariable"...........................52 138 5.12.16. The Class "PolicyEthertypeVariable".....................52 139 5.12.17. The Class "PolicySourceSAPVariable".....................52 140 5.12.18. The Class "PolicyDestinationSAPVariable"................52 141 5.12.19. The Class "PolicySNAPOUIVariable".......................53 142 5.12.20. The Class "PolicySNAPTypeVariable"......................53 143 5.12.21. The Class "PolicyFlowDirectionVariable".................54 144 5.13. The Abstract Class "PolicyValue"...........................54 145 5.14. Subclasses of "PolicyValue" Specified in PCIMe.............54 146 5.14.1. The Class "PolicyIPv4AddrValue"..........................54 147 5.14.2. The Class "PolicyIPv6AddrValue...........................55 148 5.14.3. The Class "PolicyMACAddrValue"...........................56 149 5.14.4. The Class "PolicyStringValue"............................57 150 5.14.5. The Class "PolicyBitStringValue".........................57 151 5.14.6. The Class "PolicyIntegerValue"...........................58 152 5.14.7. The Class "PolicyBooleanValue"...........................59 153 5.15. The Class "PolicyRoleCollection"...........................59 154 5.15.1. The Single-Valued Property "PolicyRole"..................60 155 5.16. The Class "ReusablePolicyContainer"........................60 156 5.17. Deprecate PCIM's Class "PolicyRepository"..................60 157 5.18. The Abstract Class "FilterEntryBase".......................61 158 5.19. The Class "IpHeadersFilter"................................61 159 5.19.1. The Property HdrIpVersion................................61 160 5.19.2. The Property HdrSrcAddress...............................62 161 5.19.3. The Property HdrSrcAddressEndOfRange.....................62 162 5.19.4. The Property HdrSrcMask..................................62 163 5.19.5. The Property HdrDestAddress..............................63 164 5.19.6. The Property HdrDestAddressEndOfRange....................63 165 5.19.7. The Property HdrDestMask.................................63 166 5.19.8. The Property HdrProtocolID...............................63 167 5.19.9. The Property HdrSrcPortStart.............................64 168 5.19.10. The Property HdrSrcPortEnd..............................64 169 5.19.11. The Property HdrDestPortStart...........................64 170 5.19.12. The Property HdrDestPortEnd.............................65 171 5.19.13. The Property HdrDSCP....................................65 172 5.19.14. The Property HdrFlowLabel...............................65 173 5.20. The Class "8021Filter".....................................65 174 5.20.1. The Property 8021HdrSrcMACAddr...........................66 175 5.20.2. The Property 8021HdrSrcMACMask...........................66 176 5.20.3. The Property 8021HdrDestMACAddr..........................66 177 5.20.4. The Property 8021HdrDestMACMask..........................66 178 5.20.5. The Property 8021HdrProtocolID...........................67 179 5.20.6. The Property 8021HdrPriorityValue........................67 180 5.20.7. The Property 8021HdrVLANID...............................67 181 5.21. The Class FilterList.......................................67 182 5.21.1. The Property Direction...................................68 183 6. Association and Aggregation Definitions..........................68 184 6.1. The Aggregation "PolicySetComponent"........................68 185 6.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup".....69 186 6.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"......69 187 6.4. The Abstract Association "PolicySetInSystem"................70 188 6.5. Update PCIM's Weak Association "PolicyGroupInSystem"........70 189 6.6. Update PCIM's Weak Association "PolicyRuleInSystem".........71 190 6.7. The Abstract Aggregation "PolicyConditionStructure".........71 191 6.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule".....72 192 6.9. The Aggregation "PolicyConditionInPolicyCondition"..........72 193 6.10. The Abstract Aggregation "PolicyActionStructure"...........72 194 6.11. Update PCIM's Aggregation "PolicyActionInPolicyRule".......72 195 6.12. The Aggregation "PolicyActionInPolicyAction"...............73 196 6.13. The Aggregation "PolicyVariableInSimplePolicyCondition"....73 197 6.14. The Aggregation "PolicyValueInSimplePolicyCondition".......74 198 6.15. The Aggregation "PolicyVariableInSimplePolicyAction".......74 199 6.16. The Aggregation "PolicyValueInSimplePolicyAction"..........75 200 6.17. The Association "ReusablePolicy"...........................76 201 6.18. Deprecate PCIM's "PolicyConditionInPolicyRepository".......76 202 6.19. Deprecate PCIM's "PolicyActionInPolicyRepository"..........76 203 6.20. The Association ExpectedPolicyValuesForVariable............76 204 6.21. The Aggregation "ContainedDomain"..........................77 205 6.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"......77 206 6.23. The Aggregation "EntriesInFilterList"......................78 207 6.23.1. The Reference GroupComponent.............................78 208 6.23.2. The Reference PartComponent..............................78 209 6.23.3. The Property EntrySequence...............................79 210 6.24. The Aggregation "ElementInPolicyRoleCollection"............79 211 6.25. The Weak Association "PolicyRoleCollectionInSystem"........79 212 7. Intellectual Property............................................80 213 8. Acknowledgements.................................................80 214 9. Security Considerations..........................................80 215 10. References......................................................81 216 11. Authors' Addresses..............................................82 217 12. Full Copyright Statement........................................83 218 13. Appendix A: Closed Issues.......................................84 220 1. Introduction 222 This document (PCIM Extensions, abbreviated here to PCIMe) proposes a 223 number of changes to the Policy Core Information Model (PCIM, RFC 3060 224 [3]). These changes include both extensions of PCIM into areas that it 225 did not previously cover, and changes to the existing PCIM classes and 226 associations. Both sets of changes are done in a way that, to the extent 227 possible, preserves interoperability with implementations of the original 228 PCIM model. 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 232 document are to be interpreted as described in RFC 2119, reference [1]. 234 2. Overview of the Changes 236 2.1. How to Change an Information Model 238 The Policy Core Information Model is closely aligned with the DMTF's CIM 239 Core Policy model. Since there is no separately documented set of rules 240 for specifying IETF information models such as PCIM, it is reasonable to 241 look to the CIM specifications for guidance on how to modify and extend 242 the model. Among the CIM rules for changing an information model are the 243 following. Note that everything said here about "classes" applies to 244 association classes (including aggregations) as well as to non- 245 association classes. 247 o Properties may be added to existing classes. 248 o Classes, and individual properties, may be marked as DEPRECATED. 249 If there is a replacement feature for the deprecated class or 250 property, it is identified explicitly. Otherwise the notation "No 251 value" is used. In this document, the notation "DEPRECATED FOR 252 " is used to indicate that a feature has been 253 deprecated, and to identify its replacement feature. 254 o Classes may be inserted into the inheritance hierarchy above 255 existing classes, and properties from the existing classes may 256 then be "pulled up" into the new classes. The net effect is that 257 the existing classes have exactly the same properties they had 258 before, but the properties are inherited rather than defined 259 explicitly in the classes. 260 o New subclasses may be defined below existing classes. 262 2.2. List of Changes to the Model 264 The following subsections provide a very brief overview of the changes to 265 PCIM defined in PCIMe. In several cases, the origin of the change is 266 noted, as QPIM [5], ICPM [6], or QDDIM [14]. 268 2.2.1. Changes to PolicyRepository 270 Because of the potential for confusion with the Policy Framework 271 component Policy Repository (from the four-box picture: Policy Management 272 Tool, Policy Repository, PDP, PEP), "PolicyRepository" is a bad name for 273 the PCIM class representing a container of reusable policy elements. 274 Thus the class PolicyRepository is being replaced with the class 275 ReusablePolicyContainer. To accomplish this change, it is necessary to 276 deprecate the PCIM class PolicyRepository and its three associations, and 277 replace them with a new class ReusablePolicyContainer and new 278 associations. 280 As a separate change, the associations for ReusablePolicyContainer are 281 being broadened, to allow a ReusablePolicyContainer to contain any 282 reusable policy elements. In PCIM, the only associations defined for a 283 PolicyRepository were for it to contain reusable policy conditions and 284 policy actions. 286 2.2.2. Additional Associations and Additional Reusable Elements 288 The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule aggregations have, 289 in effect, been imported from QPIM. ("In effect" because these two 290 aggregations, as well as PCIM'e two aggregations PolicyGroupInPolicyGroup 291 and PolicyRuleInPolicyGroup, are all being combined into a single 292 aggregation PolicySetComponent.) These aggregations make it possible to 293 define larger "chunks" of reusable policy to place in a 294 ReusablePolicyContainer. These aggregations also introduce new semantics 295 representing the contextual implications of having one PolicyRule 296 executing within the scope of another PolicyRule. 298 2.2.3. Priorities and Decision Strategies 300 Drawing from both QPIM and ICPM, the Priority property has been 301 deprecated in PolicyRule, and placed instead on the aggregation 302 PolicySetComponent. The QPIM rules for resolving relative priorities 303 across nested PolicyGroups and PolicyRules have been incorporated into 304 PCIMe as well. With the removal of the Priority property from 305 PolicyRule, a new modeling dependency is introduced. In order to 306 prioritize a PolicyRule/PolicyGroup relative to other 307 PolicyRules/PolicyGroups, the elements being prioritized must all reside 308 in one of three places: in a common PolicyGroup, in a common PolicyRule, 309 or in a common System. 311 In the absence of any clear, general criterion for detecting policy 312 conflicts, the PCIM restriction stating that priorities are relevant only 313 in the case of conflicts is being removed. In its place, a 314 PolicyDecisionStrategy property has been added to the PolicyGroup and 315 PolicyRule classes. This property allows policy administrator to select 316 one of two behaviors with respect to rule evaluation: either perform the 317 actions for all PolicyRules whose conditions evaluate to TRUE, or perform 318 the actions only for the highest-priority PolicyRule whose conditions 319 evaluate to TRUE. (This is accomplished by placing the 320 PolicyDecisionStrategy property in an abstract class PolicySet, from 321 which PolicyGroup and PolicyRule are derived.) The QPIM rules for 322 applying decision strategies to a nested set of PolicyGroups and 323 PolicyRules have also been imported. 325 2.2.4. Policy Roles 327 The concept of policy roles is added to PolicyGroups (being present 328 already in the PolicyRule class). This is accomplished via a new 329 superclass for both PolicyRules and PolicyGroups - PolicySet. For nested 330 PolicyRules and PolicyGroups, any roles associated with the outer rule or 331 group are automatically "inherited" by the nested one. Additional roles 332 may be added at the level of a nested rule or group. 334 It was also observed that there is no mechanism in PCIM for assigning 335 roles to resources. For example, while it is possible in PCIM to 336 associate a PolicyRule with the role "FrameRelay&&WAN", there is no way 337 to indicate which interfaces match this criterion. A new 338 PolicyRoleCollection class has been defined in PCIMe, representing the 339 collection of resources associated with a particular role. The linkage 340 between a PolicyRule or PolicyGroup and a set of resources is then 341 represented by an instance of PolicyRoleCollection. Equivalent values 342 should be defined in the PolicyRoles property of PolicyRules and 343 PolicyGroups, and in the PolicyRole property in PolicyRoleCollection. 345 2.2.5. CompoundPolicyConditions and CompoundPolicyActions 347 The concept of a CompoundPolicyCondition has also been imported into 348 PCIMe from QPIM, and broadened to include a parallel 349 CompoundPolicyAction. In both cases the idea is to create reusable 350 "chunks" of policy that can exist as named elements in a 351 ReusablePolicyContainer. The "Compound" classes and their associations 352 incorporate the condition and action semantics that PCIM defined at the 353 PolicyRule level: DNF/CNF for conditions, and ordering for actions. 355 Compound conditions and actions are defined to work with any component 356 conditions and actions. In other words, while the components may be 357 instances, respectively, of SimplePolicyCondition and SimplePolicyAction 358 (discussed immediately below), they need not be. 360 2.2.6. Variables and Values 362 The SimplePolicyCondition / PolicyVariable / PolicyValue structure has 363 been imported into PCIMe from QPIM. A list of PCIMe-level variables is 364 defined, as well as a list of PCIMe-level values. Other variables and 365 values may, if necessary, be defined in submodels of PCIMe. For example, 366 QPIM defines a set of implicit variables corresponding to fields in RSVP 367 flows. 369 A corresponding SimplePolicyAction / PolicyVariable / PolicyValue 370 structure is also defined. While the semantics of a 371 SimplePolicyCondition are "variable matches value", a SimplePolicyAction 372 has the semantics "set variable to value". 374 2.2.7. Domain-Level Packet Filtering 376 For packet filtering specified at the domain level, a set of 377 PolicyVariables and PolicyValues are defined, corresponding to the fields 378 in an IP packet header plus the most common Layer 2 frame header fields. 379 It is expected that domain-level policy conditions that filter on these 380 header fields will be expressed in terms of CompoundPolicyConditions 381 built up from SimplePolicyConditions that use these variables and values. 382 An additional PolicyVariable, PacketDirection, is also defined, to 383 indicate whether a packet being filtered is traveling inbound or outbound 384 on an interface. 386 2.2.8. Device-Level Packet Filtering 388 For packet filtering expressed at the device level, including the packet 389 classifier filters modeled in QDDIM, the variables and values discussed 390 in Section 2.2.7 need not be used. Filter classes derived from the CIM 391 FilterEntryBase class hierarchy are available for use in these contexts. 392 These latter classes have two important differences from the domain-level 393 classes: 395 o They support specification of filters for all of the fields in a 396 particular protocol header in a single object instance. With the 397 domain-level classes, separate instances are needed for each 398 header field. 399 o They provide native representations for the filter values, as 400 opposed to the string representation used by the domain-level 401 classes. 403 Device-level filter classes for the IP-related headers (IP, UDP, and TCP) 404 and the 802 MAC headers are defined, respectively, in sections 5.19 and 405 5.20. 407 3. The Updated Class and Association Class Hierarchies 409 The following figure shows the class inheritance hierarchy for PCIMe. 410 Changes from the PCIM hierarchy are noted parenthetically. 412 ManagedElement (abstract) 413 | 414 +--Policy (abstract) 415 | | 416 | +---PolicySet (abstract -- new - 4.3) 417 | | | 418 | | +---PolicyGroup (moved - 4.3) 419 | | | 420 | | +---PolicyRule (moved - 4.3) 421 | | 422 | +---PolicyCondition (abstract) 423 | | | 424 | | +---PolicyTimePeriodCondition 425 | | | 426 | | +---VendorPolicyCondition 427 | | | 428 | | +---SimplePolicyCondition (new - 4.8.1) 429 | | | 430 | | +---CompoundPolicyCondition (new - 4.7.1) 431 | | | 432 | | +---CompoundFilterCondition (new - 4.9) 433 | | 434 | +---PolicyAction (abstract) 435 | | | 436 | | +---VendorPolicyAction 437 | | | 438 | | +---SimplePolicyAction (new - 4.8.4) 439 | | | 440 | | +---CompoundPolicyAction (new - 4.7.2) 441 | | 442 | +---PolicyVariable (abstract -- new - 4.8.5) 443 | | | 444 | | +---PolicyExplicitVariable (new - 4.8.6) 445 | | | 446 | | +---PolicyImplicitVariable (abstract -- new - 4.8.7) 447 | | | 448 | | +---(subtree of more specific classes -- new - 5.12) 449 | | 450 | +---PolicyValue (abstract -- new - 4.8.10) 451 | | 452 | +---(subtree of more specific classes -- new - 5.14) 453 | 454 +--Collection (abstract -- newly referenced) 455 | | 456 | +--PolicyRoleCollection (new - 4.6.2) 457 (continued on following page) 458 (continued from previous page) 459 ManagedElement(abstract) 460 | 461 +--ManagedSystemElement (abstract) 462 | 463 +--LogicalElement (abstract) 464 | 465 +--System (abstract) 466 | | 467 | +--AdminDomain (abstract) 468 | | 469 | +---ReusablePolicyContainer (new - 4.2) 470 | | 471 | +---PolicyRepository (deprecated - 4.2) 472 | 473 +--FilterEntryBase (abstract -- new - 5.18) 474 | | 475 | +--IpHeadersFilter (new - 5.19) 476 | | 477 | +--8021Filter (new - 5.20) 478 | 479 +--FilterList (new - 5.21) 481 Figure 1. Class Inheritance Hierarchy for PCIMe 482 The following figure shows the association class hierarchy for PCIMe. As 483 before, changes from PCIM are noted parenthetically. 485 [unrooted] 486 | 487 +---PolicyComponent (abstract) 488 | | 489 | +---PolicySetComponent (new - 4.3) 490 | | 491 | +---PolicyGroupInPolicyGroup (deprecated - 4.3) 492 | | 493 | +---PolicyRuleInPolicyGroup (deprecated - 4.3) 494 | | 495 | +---PolicyConditionStructure (abstract -- new - 4.7.1) 496 | | | 497 | | +---PolicyConditionInPolicyRule (moved - 4.7.1) 498 | | | 499 | | +---PolicyConditionInPolicyCondition (new - 4.7.1) 500 | | 501 | +---PolicyRuleValidityPeriod 502 | | 503 | +---PolicyActionStructure (abstract -- new - 4.7.2) 504 | | | 505 | | +---PolicyActionInPolicyRule (moved - 4.7.2) 506 | | | 507 | | +---PolicyActionInPolicyAction (new - 4.7.2) 508 | | 509 | +---PolicyVariableInSimplePolicyCondition (new - 4.8.2) 510 | | 511 | +---PolicyValueInSimplePolicyCondition (new - 4.8.2) 512 | | 513 | +---PolicyVariableInSimplePolicyAction (new - 4.8.4) 514 | | 515 | +---PolicyValueInSimplePolicyAction (new - 4.8.4) 517 (continued on following page) 518 (continued from previous page) 519 [unrooted] 520 | 521 +---Dependency (abstract) 522 | | 523 | +---PolicyInSystem (abstract) 524 | | | 525 | | +---PolicySetInSystem (abstract, new - 4.3) 526 | | | | 527 | | | +---PolicyGroupInSystem 528 | | | | 529 | | | +---PolicyRuleInSystem 530 | | | 531 | | +---ReusablePolicy (new - 4.2) 532 | | | 533 | | +---PolicyConditionInPolicyRepository (deprecated - 4.2) 534 | | | 535 | | +---PolicyActionInPolicyRepository (deprecated - 4.2) 536 | | 537 | +---ExpectedPolicyValuesForVariable (new - 4.8) 538 | | 539 | +---PolicyRoleCollectionInSystem (new - 4.6.2) 540 | 541 +---Component (abstract) 542 | | 543 | +---SystemComponent 544 | | | 545 | | +---ContainedDomain (new - 4.2) 546 | | | 547 | | +---PolicyRepositoryInPolicyRepository (deprecated - 4.2) 548 | | 549 | +---EntriesInFilterList (new - 6.23) 550 | 551 +---MemberOfCollection (newly referenced) 552 | 553 +--- ElementInPolicyRoleCollection (new - 4.6.2) 555 Figure 2. Association Class Inheritance Hierarchy for PCIMe 557 In addition to these changes that show up at the class and association 558 class level, there are other changes from PCIM involving individual class 559 properties. In some cases new properties are introduced into existing 560 classes, and in other cases existing properties are deprecated (without 561 deprecating the classes that contain them). 563 4. Areas of Extension to PCIM 565 The following subsections describe each of the areas for which PCIM 566 extensions are being defined. 568 4.1. Policy Scope 570 Policy scopes may be thought of in two dimensions: 1) the level of 571 abstraction of the policy specification and 2) the applicability of 572 policies to a set of managed resources. 574 4.1.1. Levels of Abstraction: Domain- and Device-Level Policies 576 Policies vary in level of abstraction, from the business-level expression 577 of service level agreements (SLAs) to the specification of a set of rules 578 that apply to devices in a network. Those latter policies can, 579 themselves, be classified into at least two groups: those policies 580 consumed by a Policy Decision Point (PDP) that specify the rules for an 581 administrative and functional domain, and those policies consumed by a 582 Policy Enforcement Point (PEP) that specify the device-specific rules for 583 a functional domain. The higher-level rules consumed by a PDP, called 584 domain-level policies, may have late binding variables unspecified, or 585 specified by a classification, whereas the device-level rules are likely 586 to have fewer unresolved bindings. 588 There is a relationship between these levels of policy specification that 589 is out of scope for this standards effort, but that is necessary in the 590 development and deployment of a usable policy-based configuration system. 591 An SLA-level policy transformation to the domain-level policy may be 592 thought of as analogous to a visual builder that takes human input and 593 develops a programmatic rule specification. The relationship between the 594 domain-level policy and the device-level policy may be thought of as 595 analogous to that of a compiler and linkage editor that translates the 596 rules into specific instructions that can be executed on a specific type 597 of platform. 599 PCIM and PCIMe may be used to specify rules at any and all of these 600 levels of abstraction. However, at different levels of abstraction, 601 different mechanisms may be more or less appropriate. 603 4.1.2. Administrative and Functional Scopes 605 Administrative scopes for policy are represented in PCIM and in these 606 extensions to PCIM as System subclass instances. Typically, a domain- 607 level policy would be scoped by an AdminDomain instance (or by a 608 hierarchy of AdminDomain instances) whereas a device-level policy might 609 be scoped by a System instance that represents the PEP (e.g., an instance 610 of ComputerSystem, see CIM [4]). In addition to collecting policies into 611 an administrative domain, these System classes may also aggregate the 612 resources to which the policies apply. 614 Functional scopes (sometimes referred to as functional domains) are 615 generally defined by the submodels derived from PCIM and PCIMe, and 616 correspond to the service or services to which the policies apply. So, 617 for example, Quality of Service may be thought of as a functional scope, 618 or Diffserv and Intserv may each be thought of as functional scopes. 619 These scoping decisions are represented by the structure of the submodels 620 derived from PCIM and PCIMe, and may be reflected in the number and types 621 of PEP policy client(s), services, and the interaction between policies. 622 Policies in different functional scopes are organized into disjoint sets 623 of policy rules. Different functional domains may share some roles, some 624 conditions, and even some actions. The rules from different functional 625 domains may even be enforced at the same managed resource, but for the 626 purposes of policy evaluation they are separate. See section 4.5.3 for 627 more information. 629 The functional scopes MAY be reflected in administrative scopes. That 630 is, deployments of policy may have different administrative scopes for 631 different functional scopes, but there is no requirement to do so. 633 4.2. Reusable Policy Elements 635 In PCIM, a distinction was drawn between reusable PolicyConditions and 636 PolicyActions and rule-specific ones. The PolicyRepository class was 637 also defined, to serve as a container for these reusable elements. The 638 name "PolicyRepository" has proven to be an unfortunate choice for the 639 class that serves as a container for reusable policy elements. This term 640 is already used in documents like the Policy Framework, to denote the 641 location from which the PDP retrieves all policy specifications, and into 642 which the Policy Management Tool places all policy specifications. 643 Consequently, the PolicyRepository class is being deprecated, in favor of 644 a new class ReusablePolicyContainer. 646 When a class is deprecated, any associations that refer to it must also 647 be deprecated. So replacements are needed for the two associations 648 PolicyConditionInPolicyRepository and PolicyActionInPolicyRepository, as 649 well as for the aggregation PolicyRepositoryInPolicyRepository. In 650 addition to renaming the PolicyRepository class to 651 ReusablePolicyContainer, however, PCIMe is also broadening the types of 652 policy elements that can be reusable. Consequently, rather than 653 providing one-for-one replacements for the two associations, a single 654 higher-level association ReusablePolicy is defined. This new association 655 allows any policy element (that is, an instance of any subclass of the 656 abstract class Policy) to be placed in a ReusablePolicyContainer. 658 Summarizing, the following changes in Sections 5 and 6 are the result of 659 this item: 661 o The class ReusablePolicyContainer is defined. 662 o PCIM's PolicyRepository class is deprecated. 663 o The association ReusablePolicy is defined. 664 o PCIM's PolicyConditionInPolicyRepository association is deprecated. 665 o PCIM's PolicyActionInPolicyRepository association is deprecated. 666 o The aggregation ContainedDomain is defined. 667 o PCIM's PolicyRepositoryInPolicyRepository aggregation is deprecated. 669 4.3. Policy Sets 671 A "policy" can be thought of as a coherent set of rules to administer, 672 manage, and control access to network resources ("Policy Terminology", 673 reference [12]). The structuring of these coherent sets of rules into 674 subsets is enhanced in this document. In Section 4.4, we discuss the new 675 options for the nesting of policy rules. 677 A new abstract class, PolicySet, is introduced to provide an abstraction 678 for a set of rules. It is derived from Policy, and it is inserted into 679 the inheritance hierarchy above both PolicyGroup and PolicyRule. This 680 reflects the additional structural flexibility and semantic capability of 681 both subclasses. 683 Two properties are defined in PolicySet: PolicyDecisionStrategy and 684 PolicyRoles. The PolicyDecisionStrategy property is included in 685 PolicySet to define the evaluation relationship among the rules in the 686 policy set. See Section 4.5 for more information. The PolicyRoles 687 property is included in PolicySet to characterize the resources to which 688 the PolicySet applies. See Section 4.6 for more information. 690 Along with the definition of the PolicySet class, a new concrete 691 aggregation class is defined that will also be discussed in the following 692 sections. PolicySetComponent is defined as a subclass of 693 PolicyComponent; it provides the containment relationship for a PolicySet 694 in a PolicySet. PolicySetComponent replaces the two PCIM aggregations 695 PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup, so these two 696 aggregations are deprecated. 698 A PolicySet's relationship to an AdminDomain or other administrative 699 scoping system (for example, a ComputerSystem) is represented by the 700 PolicySetInSystem abstract association. This new association is derived 701 from PolicyInSystem, and the PolicyGroupInSystem and PolicyRuleInSystem 702 associations are now derived from PolicySetInSystem instead of directly 703 from PolicyInSystem. The PolicySetInSystem.Priority property is 704 discussed in Section 4.5.3. 706 4.4. Nested Policy Rules 708 As previously discussed, policy is described by a set of policy rules 709 that may be grouped into subsets. In this section we introduce the 710 notion of nested rules, or the ability to define rules within rules. 711 Nested rules are also called sub-rules, and we use both terms in this 712 document interchangeably. The aggregation PolicySetComponent is used to 713 represent the nesting of a policy rule in another policy rule. 715 4.4.1. Usage Rules for Nested Rules 717 The relationship between rules and sub-rules is defined as follows: 719 o The parent rule's condition clause is a condition for evaluation 720 of all nested rules; that is, the conditions of the parent are 721 logically ANDed to the conditions of the sub-rules. If the parent 722 rule's condition clause evaluates to FALSE, sub-rules MAY be 723 skipped since they also evaluate to FALSE. 724 o If the parent rule's condition evaluates to TRUE, the set of sub- 725 rules SHALL BE evaluated according to the decision strategy and 726 priorities as discussed in Section 4.5. 727 o If the parent rule's condition evaluates to TRUE, the parent 728 rule's set of actions is executed BEFORE execution of the sub- 729 rules� actions. The parent rule's actions are not to be confused 730 with default actions. A default action is one that is to be 731 executed only if none of the more specific sub-rules are executed. 732 If a default action needs to be specified, it needs to be defined 733 as an action that is part of a catchall sub-rule associated with 734 the parent rule. The association linking the default action(s) in 735 this special sub-rule should have the lowest priority relative to 736 all other sub-rule associations: 738 if parent-condition then parent rule's action 739 if condA then actA 740 if condB then ActB 741 if True then default action 743 Such a default action functions as a default when FirstMatching 744 decision strategies are in effect (see section 4.5). If 745 AllMatching applies, the "default" action is always performed. 747 o Policy rules have a context in which they are executed. The rule 748 engine evaluates and applies the policy rules in the context of 749 the managed resource(s) that are identified by the policy roles 750 (or by an explicit association). Submodels MAY add additional 751 context to policy rules based on rule structure; any such 752 additional context is defined by the semantics of the action 753 classes of the submodel. 755 4.4.2. Motivation 757 Rule nesting enhances Policy readability, expressiveness and reusability. 758 The ability to nest policy rules and form sub-rules is important for 759 manageability and scalability, as it enables complex policy rules to be 760 constructed from multiple simpler policy rules. These enhancements ease 761 the policy management tools' task, allowing policy rules to be expressed 762 in a way closer to how humans think. 764 Although rule nesting can be used to suggest optimizations in the way 765 policy rules are evaluated, as discussed in section 4.5.2 "Side Effects," 766 nesting does not specify nor does it require any particular order of 767 evaluation of conditions. Optimization of rule evaluation can be done in 768 the PDP or in the PEP by dedicated code. This is similar to the relation 769 between a high level programming language like C and machine code. An 770 optimizer can create a more efficient machine code than any optimization 771 done by the programmer within the source code. Nevertheless, if the PEP 772 or PDP does not do optimization, the administrator writing the policy may 773 be able to influence the evaluation of the policy rules for execution 774 using rule nesting. 776 Nested rules are not designed for policy repository retrieval 777 optimization. It is assumed that all rules and groups that are assigned 778 to a role are retrieved by the PDP or PEP from the policy repository and 779 enforced. Optimizing the number of rules retrieved should be done by 780 clever selection of roles. 782 4.5. Priorities and Decision Strategies 784 A "decision strategy" is used to specify the evaluation method for the 785 policies in a PolicySet. Two decision strategies are defined: 786 "FirstMatching" and "AllMatching." The FirstMatching strategy is used to 787 cause the evaluation of the rules in a set such that the only actions 788 enforced on a given examination of the PolicySet are those for the first 789 rule (that is, the rule with the highest priority) that has its 790 conditions evaluate to TRUE. The AllMatching strategy is used to cause 791 the evaluation of all rules in a set; for all of the rules whose 792 conditions evaluate to TRUE, the actions are enforced. Implementations 793 MUST support the FirstMatching decision strategy; implementations MAY 794 support the AllMatching decision strategy. 796 As previously discussed, the PolicySet subclasses are PolicyGroup and 797 PolicyRule: either subclass may contain PolicySets of either subclass. 798 Loops, including the degenerate case of a PolicySet that contains itself, 799 are not allowed when PolicySets contain other PolicySets. The 800 containment relationship is specified using the PolicySetComponent 801 aggregation. 803 The relative priority within a PolicySet is established by the Priority 804 property of the PolicySetComponent aggregation of the contained 805 PolicyGroup and PolicyRule instances. The use of PCIM's 806 PolicyRule.Priority property is deprecated in favor of this new property. 807 The separation of the priority property from the rule has two advantages. 808 First, it generalizes the concept of priority, so that it can be used for 809 both groups and rules. Second, it places the priority on the 810 relationship between the parent policy set and the subordinate policy 811 group or rule. The assignment of a priority value then becomes much 812 easier, in that the value is used only in relationship to other 813 priorities in the same set. 815 Together, the PolicySet.PolicyDecisionStrategy and 816 PolicySetComponent.Priority determine the processing for the rules 817 contained in a PolicySet. As before, the larger priority value 818 represents the higher priority. Unlike the earlier definition, 819 PolicySetComponent.Priority MUST have a unique value when compared with 820 others defined for the same aggregating PolicySet. Thus, the evaluation 821 of rules within a set is deterministically specified. 823 For a FirstMatching decision strategy, the first rule (that is, the one 824 with the highest priority) in the set that evaluates to True, is the only 825 rule whose actions are enforced for a particular evaluation pass through 826 the PolicySet. 828 For an AllMatching decision strategy, all of the matching rules are 829 enforced. The relative priority of the rules is used to determine the 830 order in which the actions are to be executed by the enforcement point: 831 the actions of the higher priority rules are executed first. Since the 832 actions of higher priority rules are executed first, lower priority rules 833 that also match may get the "last word," and thus produce a counter- 834 intuitive result. So, for example, if two rules both evaluate to True, 835 and the higher priority rule sets the DSCP to 3 and the lower priority 836 rule sets the DSCP to 4, the action of the lower priority rule will be 837 executed later and, therefore, will "win," in this example, setting the 838 DSCP to 4. Thus, conflicts between rules are resolved by this execution 839 order. 841 An implementation of the rule engine need not provide the action 842 sequencing but the actions MUST be sequenced by the PEP or PDP on its 843 behalf. So, for example, the rule engine may provide an ordered list of 844 actions to be executed by the PEP and any required serialization is then 845 provided by the service configured by the rule engine. See section 4.5.2 846 for a discussion of side effects. 848 4.5.1. Structuring Decision Strategies 850 As discussed in Sections 4.3 and 4.4, PolicySet instances may be nested 851 arbitrarily. For a FirstMatching decision strategy on a PolicySet, any 852 contained PolicySet that matches satisfies the termination criteria for 853 the FirstMatching strategy. A PolicySet is considered to match if it is 854 a PolicyRule and its conditions evaluate to True, or if the PolicySet is 855 a PolicyGroup and at least one of its contained PolicyGroups or 856 PolicyRules match. The priority associated with contained PolicySets, 857 then, determines when to terminate rule evaluation in the structured set 858 of rules. 860 In the example shown in Figure 3, the relative priorities for the nested 861 rules, high to low, are 1A, 1B1, 1X2, 1B3, 1C, 1C1, 1X2 and 1C3. (Note 862 that PolicyRule 1X2 is included in both PolicyGroup 1B and PolicyRule 1C, 863 but with different priorities.) Of course, which rules are enforced is 864 also dependent on which rules, if any, match. 866 PolicyGroup 1: FirstMatching 867 | 868 +-- Pri=6 -- PolicyRule 1A 869 | 870 +-- Pri=5 -- PolicyGroup 1B: AllMatching 871 | | 872 | +-- Pri=5 -- PolicyGroup 1B1: AllMatching 873 | | | 874 | | +---- etc. 875 | | 876 | +-- Pri=4 -- PolicyRule 1X2 877 | | 878 | +-- Pri=3 -- PolicyRule 1B3: FirstMatching 879 | | 880 | +---- etc. 881 | 882 +-- Pri=4 -- PolicyRule 1C: FirstMatching 883 | 884 +-- Pri=4 -- PolicyRule 1C1 885 | 886 +-- Pri=3 -- PolicyRule 1X2 887 | 888 +-- Pri=2 -- PolicyRule 1C3 890 Figure 3. Nested PolicySets with Different Decision Strategies 892 o Because PolicyGroup 1 has a FirstMatching decision strategy, if 893 the conditions of PolicyRule 1A match, its actions are enforced 894 and the evaluation stops. 896 o If it does not match, PolicyGroup 1B is evaluated using an 897 AllMatching strategy. Since PolicyGroup 1B1 also has an 898 AllMatching strategy all of the rules and groups of rules 899 contained in PolicyGroup 1B1 are evaluated and enforced as 900 appropriate. PolicyRule 1X2 and PolicyRule 1B3 are also evaluated 901 and enforced as appropriate. If any of the sub-rules in the 902 subtrees of PolicyGroup 1B evaluate to True, then PolicyRule 1C is 903 not evaluated because the FirstMatching strategy of PolicyGroup 1 904 has been satisfied. 906 o If neither PolicyRule 1A nor PolicyGroup 1B yield a match, then 907 PolicyRule 1C is evaluated. Since it is first matching, rules 908 1C1, 1X2, and 1C3 are evaluated until the first match, if any. 910 4.5.2. Side Effects 912 Although evaluation of conditions is sometimes discussed as an ordered 913 set of operations, the rule engine need not be implemented as a 914 procedural language interpreter. Any side effects of condition evaluation 915 or the execution of actions MUST NOT affect the result of the evaluation 916 of other conditions evaluated by the rule engine in the same evaluation 917 pass. That is, an implementation of a rule engine MAY evaluate all 918 conditions in any order before applying the priority and determining 919 which actions are to be executed. 921 So, regardless of how a rule engine is implemented, it MUST NOT include 922 any side effects of condition evaluation in the evaluation of conditions 923 for either of the decision strategies. For both the AllMatching decision 924 strategy and for the nesting of rules within rules (either directly or 925 indirectly) where the actions of more than one rule may be enforced, any 926 side effects of the enforcement of actions MUST NOT be included in 927 condition evaluation on the same evaluation pass. 929 4.5.3. Multiple PolicySet Trees For a Resource 931 As shown in the example in Figure 3. , PolicySet trees are defined by the 932 PolicySet subclass instances and the PolicySetComponent aggregation 933 instances between them. Each PolicySet tree has a defined set of 934 decision strategies and evaluation priorities. In section 4.6 we discuss 935 some improvements in the use of PolicyRoles that cause the parent 936 PolicySet.PolicyRoles to be applied to all contained PolicySet instances. 937 However, a given resource may still have multiple, disjoint PolicySet 938 trees regardless of how they are collected. These top-level PolicySet 939 instances are called "unrooted" relative to the given resource. 941 So, a PolicySet instance is defined to be rooted or unrooted in the 942 context of a particular managed element; the relationship to the managed 943 element is usually established by the policy roles of the PolicySet 944 instance and of the managed element (see 4.6 "Policy Roles"). A 945 PolicySet instance is unrooted in that context if and only if there is no 946 PolicySetComponent association to a parent PolicySet that is also related 947 to the same managed element. These PolicySetComponent aggregations are 948 traversed up the tree without regard to how a PolicySet instance came to 949 be related with the ManagedElement. Figure 4. shows an example where 950 instance A has role A, instance B has role B and so on. In this example, 951 in the context of interface X, instances B, and C are unrooted and 952 instances D, E, and F are all rooted. In the context of interface Y, 953 instance A is unrooted and instances B, C, D, E and F are all rooted. 955 +---+ +-----------+ +-----------+ 956 | A | | I/F X | | I/F Y | 957 +---+ | has roles | | has roles | 958 / \ | B & C | | A & B | 959 / \ +-----------+ +-----------+ 960 +---+ +---+ 961 | B | | C | 962 +---+ +---+ 963 / \ \ 964 / \ \ 965 +---+ +---+ +---+ 966 | D | | E | | F | 967 +---+ +---+ +---+ 969 Figure 4. Unrooted PolicySet Instances 971 For those cases where there are multiple unrooted PolicySet instances 972 that apply to the same managed resource (i.e., not in a common 973 PolicySetComponent tree), the decision strategy among these disjoint 974 PolicySet instances is the FirstMatching strategy. The priority used 975 with this FirstMatching strategy is defined in the PolicySetInSystem 976 association. The PolicySetInSystem subclass instances are present for all 977 PolicySet instances (it is a required association) but the priority is 978 only used as a default for unrooted PolicySet instances in a given 979 ManagedElement context. 981 The FirstMatching strategy is used among all unrooted PolicySet instances 982 that apply to a given resource for a given functional domain. So, for 983 example, the PolicySet instances that are used for QoS policy and the 984 instances that are used for IKE policy, although they are disjoint, are 985 not joined in a FirstMatching decision strategy. Instead, they are 986 evaluated independently of one another. 988 4.5.4. Deterministic Decisions 990 As previously discussed, PolicySetComponent.Priority values MUST be 991 unique within a containing PolicySet and PolicySetInSystem.Priority 992 values MUST be unique for an associated System. Each PolicySet, then, has 993 a deterministic behavior based upon the decision strategy and uniquely 994 defined priority. 996 There are certainly cases where rules need not have a unique priority 997 value (i.e., where evaluation and execution priority is not important). 998 However, it is believed that the flexibility gained by this capability is 999 not sufficiently beneficial to justify the possible variations in 1000 implementation behavior and the resulting confusion that might occur. 1002 4.6. Policy Roles 1004 A policy role is defined in [12] as "an administratively specified 1005 characteristic of a managed element (for example, an interface). It is a 1006 selector for policy rules and PRovisioning Classes (PRCs), to determine 1007 the applicability of the rule/PRC to a particular managed element." 1009 In PCIMe, PolicyRoles is defined as a property of PolicySet, which is 1010 inherited by both PolicyRules and PolicyGroups. In this draft, we also 1011 add PolicyRole as the identifying name of a collection of resources 1012 (PolicyRoleCollection), where each element in the collection has the 1013 specified role characteristic. 1015 4.6.1. Comparison of Roles in PCIM with Roles in snmpconf 1017 In the Configuration Management with SNMP (snmpconf) working group's 1018 Policy Based Management MIB [13], policy rules are of the form 1020 if then 1022 where is a set of conditions that are used to determine 1023 whether or not the policy applies to an object instance. The policy 1024 filter can perform comparison operations on SNMP variables already 1025 defined in MIBS (e.g., "ifType == ethernet"). 1027 The policy management MIB defined in [13] defines a Role table that 1028 enables one to associate Roles with elements, where roles have the same 1029 semantics as in PCIM. Then, since the policyFilter in a policy allows one 1030 to define conditions based on the comparison of the values of SNMP 1031 variables, one can filter elements based on their roles as defined in the 1032 Role group. 1034 This approach differs from that adopted in PCIM in the following ways. 1035 First, in PCIM, a set of role(s) is associated with a policy rule as the 1036 values of the PolicyRoles property of a policy rule. The semantics of 1037 role(s) are then expected to be implemented by the PDP (i.e. policies are 1038 applied to the elements with the appropriate roles). In [13], however, 1039 no special processing is required for realizing the semantics of roles; 1040 roles are treated just as any other SNMP variables and comparisons of 1041 role values can be included in the policy filter of a policy rule. 1043 Secondly, in PCIM, there is no formally defined way of associating a role 1044 with an object instance, whereas in [13] this is done via the use of the 1045 Role tables (pmRoleESTable and pmRoleSETable). The Role tables associate 1046 Role values with elements. 1048 4.6.2. Addition of PolicyRoleCollection to PCIMe 1050 In order to remedy the latter shortcoming in PCIM (the lack of a way of 1051 associating a role with an object instance), PCIMe has a new class 1052 PolicyRoleCollection derived from the CIM Collection class. Resources 1053 that share a common role are aggregated by a PolicyRoleCollection 1054 instance, via the ElementInPolicyRoleCollection aggregation. The role is 1055 specified in the PolicyRole property of the aggregating 1056 PolicyRoleCollection instance. 1058 A PolicyRoleCollection always exists in the context of a system. As was 1059 done in PCIM for PolicyRules and PolicyGroups, an association, 1060 PolicyRoleCollectionInSystem, captures this relationship. Remember that 1061 in CIM, System is a base class for describing network devices and 1062 administrative domains. 1064 The association between a PolicyRoleCollection and a system should be 1065 consistent with the associations that scope the policy rules/groups that 1066 are applied to the resources in that collection. Specifically, a 1067 PolicyRoleCollection should be associated with the same System as the 1068 applicable PolicyRules and/or PolicyGroups, or to a System higher in the 1069 tree formed by the SystemComponent association. When a PEP belongs to 1070 multiple Systems (i.e., AdminDomains), and scoping by a single domain is 1071 impractical, two alternatives exist. One is to arbitrarily limit domain 1072 membership to one System/AdminDomain. The other option is to define a 1073 more global AdminDomain that simply includes the others, and/or that 1074 spans the business or enterprise. 1076 As an example, suppose that there are 20 traffic trunks in a network, and 1077 that an administrator would like to assign three of them to provide 1078 "gold" service. Also, the administrator has defined several policy rules 1079 which specify how the "gold" service is delivered. For these rules, the 1080 PolicyRoles property (inherited from PolicySet) is set to "Gold Service". 1082 In order to associate three traffic trunks with "gold" service, an 1083 instance of the PolicyRoleCollection class is created and its PolicyRole 1084 property is also set to "Gold Service". Following this, the 1085 administrator associates three traffic trunks with the new instance of 1086 PolicyRoleCollection via the ElementInPolicyRoleCollection aggregation. 1087 This enables a PDP to determine that the "Gold Service" policy rules 1088 apply to the three aggregated traffic trunks. 1090 Note that roles are used to optimize policy retrieval. It is not 1091 mandatory to implement roles or, if they have been implemented, to group 1092 elements in a PolicyRoleCollection. However, if roles are used, then 1093 either the collection approach should be implemented, or elements should 1094 be capable of reporting their "pre-programmed" roles (as is done in 1095 COPS). 1097 4.6.3. Roles for PolicyGroups 1099 In PCIM, role(s) are only associated with policy rules. However, it may 1100 be desirable to associate role(s) with groups of policy rules. For 1101 example, a network administrator may want to define a group of rules that 1102 apply only to Ethernet interfaces. A policy group can be defined with a 1103 role-combination="Ethernet", and all the relevant policy rules can be 1104 placed in this policy group. (Note that in PCIMe, role(s) are made 1105 available to PolicyGroups as well as to PolicyRules by moving PCIM's 1106 PolicyRoles property up from PolicyRule to the new abstract class 1107 PolicySet. The property is then inherited by both PolicyGroup and 1108 PolicyRule.) Then every policy rule in this policy group implicitly 1109 inherits this role-combination from the containing policy group. A 1110 similar implicit inheritance applies to nested policy groups. 1112 There is no explicit copying of role(s) from container to contained 1113 entity. Obviously, this implicit inheritance of role(s) leads to the 1114 possibility of defining inconsistent role(s) (as explained in the example 1115 below); the handling of such inconsistencies is beyond the scope of 1116 PCIMe. 1118 As an example, suppose that there is a PolicyGroup PG1 that contains 1119 three PolicyRules, PR1, PR2, and PR3. Assume that PG1 has the roles 1120 "Ethernet" and "Fast". Also, assume that the contained policy rules have 1121 the role(s) shown below: 1123 +------------------------------+ 1124 | PolicyGroup PG1 | 1125 | PolicyRoles = Ethernet, Fast | 1126 +------------------------------+ 1127 | 1128 | +------------------------+ 1129 | | PolicyRule PR1 | 1130 |--------| PolicyRoles = Ethernet | 1131 | +------------------------+ 1132 | 1133 | +--------------------------+ 1134 | | PolicyRule PR2 | 1135 |--------| PolicyRoles = | 1136 | +--------------------------+ 1137 | 1138 | +------------------------+ 1139 | | PolicyRule PR3 | 1140 |--------| PolicyRoles = Slow | 1141 +------------------------+ 1143 Figure 5. Inheritance of Roles 1145 In this example, the PolicyRoles property value for PR1 is consistent 1146 with the value in PG1, and in fact, did not need to be redefined. The 1147 value of PolicyRoles for PR2 is undefined. Its roles are implicitly 1148 inherited from PG1. Lastly, the value of PolicyRoles for PR3 is "Slow". 1149 This appears to be in conflict with the role, "Fast," defined in PG1. 1150 However, whether these roles are actually in conflict is not clear. In 1151 one scenario, the policy administrator may have wanted only "Fast"- 1152 "Ethernet" rules in the policy group. In another scenario, the 1153 administrator may be indicating that PR3 applies to all "Ethernet" 1154 interfaces regardless of whether they are "Fast" or "Slow." Only in the 1155 former scenario (only "Fast"-"Ethernet" rules in the policy group) is 1156 there a role conflict. 1158 Note that it is possible to override implicitly inherited roles via 1159 appropriate conditions on a PolicyRule. For example, suppose that PR3 1160 above had defined the following conditions: 1162 (interface is not "Fast") and (interface is "Slow") 1164 This results in unambiguous semantics for PR3. 1166 4.7. Compound Policy Conditions and Compound Policy Actions 1168 Compound policy conditions and compound policy actions are introduced to 1169 provide additional reusable "chunks" of policy. 1171 4.7.1. Compound Policy Conditions 1173 A CompoundPolicyCondition is a PolicyCondition representing a Boolean 1174 combination of simpler conditions. The conditions being combined may be 1175 SimplePolicyConditions (discussed below in section 4.7), but the utility 1176 of reusable combinations of policy conditions is not necessarily limited 1177 to the case where the component conditions are simple ones. 1179 The PCIM extensions to introduce compound policy conditions are 1180 relatively straightforward. Since the purpose of the extension is to 1181 apply the DNF / CNF logic from PCIM's PolicyConditionInPolicyRule 1182 aggregation to a compound condition that aggregates simpler conditions, 1183 the following changes are required: 1185 o Create a new aggregation PolicyConditionInPolicyCondition, with the 1186 same GroupNumber and ConditionNegated properties as 1187 PolicyConditionInPolicyRule. The cleanest way to do this is to 1188 move the properties up to a new abstract aggregation superclass 1189 PolicyConditionStructure, from which the existing aggregation 1190 PolicyConditionInPolicyRule and a new aggregation 1191 PolicyConditionInPolicyCondition are derived. For now there is no 1192 need to re-document the properties themselves, since they are 1193 already documented in PCIM as part of the definition of the 1194 PolicyConditionInPolicyRule aggregation. 1195 o It is also necessary to define a concrete subclass 1196 CompoundPolicyCondition of PolicyCondition, to introduce the 1197 ConditionListType property. This property has the same function, 1198 and works in exactly the same way, as the corresponding property 1199 currently defined in PCIM for the PolicyRule class. 1201 The class and property definitions for representing compound policy 1202 conditions are below, in Section 5. 1204 4.7.2. Compound Policy Actions 1206 A compound action is a convenient construct to represent a sequence of 1207 actions to be applied as a single atomic action within a policy rule. In 1208 many cases, actions are related to each other and should be looked upon 1209 as sub-actions of one "logical" action. An example of such a logical 1210 action is "shape & mark" (i.e., shape a certain stream to a set of 1211 predefined bandwidth characteristics and then mark these packets with a 1212 certain DSCP value). This logical action is actually composed of two 1213 different QoS actions, which should be performed in a well-defined order 1214 and as a complete set. 1216 The CompoundPolicyAction construct allows one to create a logical 1217 relationship between a number of actions, and to define the activation 1218 logic associated with this logical action. 1220 The CompoundPolicyAction construct allows the reusability of these 1221 complex actions, by storing them in a ReusablePolicyContainer and reusing 1222 them in different policy rules. Note that a compound action may also be 1223 aggregated by another compound action. 1225 As was the case with CompoundPolicyCondition, the PCIM extensions to 1226 introduce compound policy actions are relatively straightforward. This 1227 time the goal is to apply the property ActionOrder from PCIM's 1228 PolicyActionInPolicyRule aggregation to a compound action that aggregates 1229 simpler actions. The following changes are required: 1231 o Create a new aggregation PolicyActionInPolicyAction, with the same 1232 ActionOrder property as PolicyActionInPolicyRule. The cleanest way 1233 to do this is to move the property up to a new abstract aggregation 1234 superclass PolicyActionStructure, from which the existing 1235 aggregation PolicyActionInPolicyRule and a new aggregation 1236 PolicyActionInPolicyAction are derived. 1237 o It is also necessary to define a concrete subclass 1238 CompoundPolicyAction of PolicyAction, to introduce the 1239 SequencedActions property. This property has the same function, 1240 and works in exactly the same way, as the corresponding property 1241 currently defined in PCIM for the PolicyRule class. 1242 o Finally, a new property ExecutionStrategy is needed for both the 1243 PCIM class PolicyRule and the new class CompoundPolicyAction. This 1244 property allows the policy administrator to specify how the PEP 1245 should behave in the case where there are multiple actions 1246 aggregated by a PolicyRule or by a CompoundPolicyAction. 1248 The class and property definitions for representing compound policy 1249 actions are below, in Section 5. 1251 4.8. Variables and Values 1253 The following subsections introduce several related concepts, including 1254 PolicyVariables and PolicyValues (and their numerous subclasses), 1255 SimplePolicyConditions, and SimplePolicyActions. 1257 4.8.1. Simple Policy Conditions 1259 The SimplePolicyCondition class models elementary Boolean expressions of 1260 the form: "( MATCH )". The relationship 'MATCH', which 1261 is implicit in the model, is interpreted based on the variable and the 1262 value. Section 4.8.3 explains the semantics of the 'MATCH' operator. 1263 Arbitrarily complex Boolean expressions can be formed by chaining 1264 together any number of simple conditions using relational operators. 1265 Individual simple conditions can be negated as well. Arbitrarily complex 1266 Boolean expressions are modeled by the class CompoundPolicyCondition 1267 (described in Section 4.7.1). 1269 For example, the expression "SourcePort == 80" can be modeled by a simple 1270 condition. In this example, 'SourcePort' is a variable, '==' is the 1271 relational operator denoting the equality relationship (which is 1272 generalized by PCIMe to a "MATCH" relationship), and '80' is an integer 1273 value. The complete interpretation of a simple condition depends on the 1274 binding of the variable. Section 4.8.5 describes variables and their 1275 binding rules. 1277 The SimplePolicyCondition class refines the basic structure of the 1278 PolicyCondition class defined in PCIM by using the pair (, 1279 ) to form the condition. Note that the operator between the 1280 variable and the value is always implied in PCIMe: it is not a part of 1281 the formal notation. 1283 The variable specifies the attribute of an object that should be matched 1284 when evaluating the condition. For example, for a QoS model, this object 1285 could represent the flow that is being conditioned. A set of predefined 1286 variables that cover network attributes commonly used for filtering is 1287 introduced in PCIMe, to encourage interoperability. This list covers 1288 layer 3 IP attributes such as IP network addresses, protocols and ports, 1289 as well as a set of layer 2 attributes (e.g., MAC addresses). 1291 The bound variable is matched against a value to produce the Boolean 1292 result. For example, in the condition "The source IP address of the flow 1293 belongs to the 10.1.x.x subnet", a source IP address variable is matched 1294 against a 10.1.x.x subnet value. 1296 4.8.2. Using Simple Policy Conditions 1298 Simple conditions can be used in policy rules directly, or as building 1299 blocks for creating compound policy conditions. 1301 Simple condition composition MUST enforce the following data-type 1302 conformance rule: The ValueTypes property of the variable must be 1303 compatible with the type of the value class used. The simplest (and 1304 friendliest, from a user point-of-view) way to do this is to equate the 1305 type of the value class with the name of the class. By ensuring that the 1306 ValueTypes property of the variable matches the name of the value class 1307 used, we know that the variable and value instance values are compatible 1308 with each other. 1310 Composing a simple condition requires that an instance of the class 1311 SimplePolicyCondition be created, and that instances of the variable and 1312 value classes that it uses also exist. Note that the variable and/or 1313 value instances may already exist as reusable objects in an appropriate 1314 ReusablePolicyContainer. 1316 Two aggregations are used in order to create the pair (, 1317 ). The aggregation PolicyVariableInSimplePolicyCondition relates 1318 a SimplePolicyCondition to a single variable instance. Similarly, the 1319 aggregation PolicyValueInSimplePolicyCondition relates a 1320 SimplePolicyCondition to a single value instance. Both aggregations are 1321 defined in this document. 1323 Figure 6. depicts a SimplePolicyCondition with its associated variable 1324 and value. Also shown are two PolicyValue instances that identify the 1325 values that the variable can assume. 1327 +-----------------------+ 1328 | SimplePolicyCondition | 1329 +-----------------------+ 1330 * @ 1331 * @ 1332 +------------------+ * @ +---------------+ 1333 | (PolicyVariable) |*** @@@| (PolicyValue) | 1334 +------------------+ +---------------+ 1335 # # 1336 # ooo # 1337 # # 1338 +---------------+ +---------------+ 1339 | (PolicyValue) | ooo | (PolicyValue) | 1340 +---------------+ +---------------+ 1342 Aggregation Legend: 1343 **** PolicyVariableInSimplePolicyCondition 1344 @@@@ PolicyValueInSimplePolicyCondition 1345 #### ExpectedPolicyValuesForVariable 1347 Figure 6. SimplePolicyCondition 1349 Note: The class names in parenthesis denote subclasses. The classes 1350 named in the figure are abstract, and thus cannot themselves be 1351 instantiated. 1353 4.8.3. The Simple Condition Operator 1355 A simple condition models an elementary Boolean expression of the form 1356 "variable MATCHes value". However, the formal notation of the 1357 SimplePolicyCondition, together with its associations, models only a 1358 pair, (, ). The 'MATCH' operator is not directly 1359 modeled -- it is implied. Furthermore, this implied 'MATCH' operator 1360 carries overloaded semantics. 1362 For example, in the simple condition "DestinationPort MATCH '80'", the 1363 interpretation of the 'MATCH' operator is equality (the 'equal' 1364 operator). Clearly, a different interpretation is needed in the 1365 following cases: 1367 o "DestinationPort MATCH {'80', '8080'}" -- operator is 'IS SET 1368 MEMBER' 1370 o "DestinationPort MATCH {'1 to 255'}" -- operator is 'IN INTEGER 1371 RANGE' 1373 o "SourceIPAddress MATCH 'MyCompany.com'" -- operator is 'IP ADDRESS 1374 AS RESOLVED BY DNS' 1376 The examples above illustrate the implicit, context-dependant nature of 1377 the 'MATCH' operator. The interpretation depends on the actual variable 1378 and value instances in the simple condition. The interpretation is 1379 always derived from the bound variable and the value instance associated 1380 with the simple condition. Text accompanying the value class and 1381 implicit variable definition is used for interpreting the semantics of 1382 the 'MATCH' relationship. In the following list, we define generic 1383 (type-independent) matching. 1385 PolicyValues may be multi-fielded, where each field may contain a range 1386 of values. The same equally holds for PolicyVariables. Basically, we 1387 have to deal with single values (singleton), ranges ([lower bound .. 1388 upper bound]), and sets (a,b,c). So independent of the variable and 1389 value type, the following set of generic matching rules for the 'MATCH' 1390 operator are defined. 1392 o singleton matches singleton -> the matching rule is defined in the 1393 type 1395 o singleton matches range [lower bound .. upper bound] -> the 1396 matching evaluates to true, if the singleton matches the lower 1397 bound or the upper bound or a value in between 1399 o singleton matches set -> the matching evaluates to true, if the 1400 value of the singleton matches one of the components in the set, 1401 where a component may be a singleton or range again 1403 o ranges [A..B] matches singleton -> is true if A matches B matches 1404 singleton 1406 o range [A..B] matches range [X..Y] -> the matching evaluates to 1407 true, if all values of the range [A..B] are also in the range 1408 [X..Y]. For instance, [3..5] match [1..6] evaluates to true, 1409 whereas [3..5] match [4..6] evaluates to false. 1411 o range [A..B] matches set (a,b,c, ...) -> the matching evaluates to 1412 true, if all values in the range [A..B] are part of the set. For 1413 instance, range [2..3] match set ([1..2],3) evaluates to true, as 1414 well as range [2..3] match set (2,3), and range [2..3] match set 1415 ([1..2],[3..5]). 1417 o set (a,b,c, ...) match singleton -> is true if a match b match c 1418 match ... match singleton 1420 o set match range -> the matching evaluates to true, if all values 1421 in the set are part of the range. For example, set (2,3) match 1422 range [1..4] evaluates to true. 1424 o set (a,b,c,...) match set (x,y,z,...) -> the matching evaluates to 1425 true, if all values in the set (a,b,c,...) are part of the set 1426 (x,y,z,...). For example, set (1,2,3) match set (1,2,3,4) 1427 evaluates to true. Set (1,2,3) match set (1,2) evaluates to 1428 false. 1430 Variables may contain various types (section 5.11.1). When not stated 1431 otherwise, the type of the value bound to the variable at condition 1432 evaluation time and the value type of the PolicyValue instance need to be 1433 of the same type. If they differ, then the condition evaluates to FALSE. 1435 The ExpectedPolicyValuesForVariable association specifies an expected set 1436 of values that can be matched with a variable within a simple condition. 1437 Using this association, a source or destination port can be limited to 1438 the range 0-200, a source or destination IP address can be limited to a 1439 specified list of IPv4 address values, etc. 1441 +-----------------------+ 1442 | SimplePolicyCondition | 1443 +-----------------------+ 1444 * @ 1445 * @ 1446 * @ 1447 +-----------------------------------+ +--------------------------+ 1448 | Name=SmallSourcePorts | | Name=Port300 | 1449 | Class=PolicySourcePortVariable | | Class=PolicyIntegerValue | 1450 | ValueTypes=[PolicyIntegerValue] | | IntegerList = [300] | 1451 +-----------------------------------+ +--------------------------+ 1452 # 1453 # 1454 # 1455 +-------------------------+ 1456 |Name=SmallPortsValues | 1457 |Class=PolicyIntegerValue | 1458 |IntegerList=[1..200] | 1459 +-------------------------+ 1461 Aggregation Legend: 1462 **** PolicyVariableInSimplePolicyCondition 1463 @@@@ PolicyValueInSimplePolicyCondition 1464 #### ExpectedPolicyValuesForVariable 1466 Figure 7. An Invalid SimplePolicyCondition 1467 The ability to express these limitations appears in the model to support 1468 validation of a SimplePolicyCondition prior to its deployment to an 1469 enforcement point. A Policy Management Tool, for example SHOULD NOT 1470 accept the SimplePolicyCondition shown in Figure 7. If, however, a 1471 policy rule containing this condition does appear at an enforcement 1472 point, the expected values play no role in the determination of whether 1473 the condition evaluates to True or False. Thus in this example, the 1474 SimplePolicyCondition evaluates to True if the source port for the packet 1475 under consideration is 300, and it evaluates to False otherwise. 1477 4.8.4. SimplePolicyActions 1479 The SimplePolicyAction class models the elementary set operation. "SET 1480 TO ". The set operator MUST overwrite an old value of 1481 the variable. In the case where the variable to be updated is multi- 1482 valued, the only update operation defined is a complete replacement of 1483 all previous values with a new set. In other words, there are no Add or 1484 Remove [to/from the set of values] operations defined for 1485 SimplePolicyActions. 1487 For example, the action "set DSCP to EF" can be modeled by a simple 1488 action. In this example, 'DSCP' is an implicit variable referring to the 1489 IP packet header DSCP field. 'EF' is an integer or bit string value (6 1490 bits). The complete interpretation of a simple action depends on the 1491 binding of the variable. 1493 The SimplePolicyAction class refines the basic structure of the 1494 PolicyAction class defined in PCIM, by specifying the contents of the 1495 action using the (, ) pair to form the action. The 1496 variable specifies the attribute of an object. The value of this 1497 attribute is set to the value specified in . Selection of the 1498 object is a function of the type of variable involved. See Sections 1499 4.8.6 and 4.8.7, respectively, for details on object selection for 1500 explicitly bound and implicitly bound policy variables. 1502 SimplePolicyActions can be used in policy rules directly, or as building 1503 blocks for creating CompoundPolicyActions. 1505 The set operation is only valid if the list of types of the variable 1506 (ValueTypes property of PolicyImplicitVariable) includes the specified 1507 type of the value. Conversion of values from one representation into 1508 another is not defined. For example, a variable of IPv4Address type may 1509 not be set to a string containing a DNS name. Conversions are part of an 1510 implementation-specific mapping of the model. 1512 As was the case with SimplePolicyConditions, the role of expected values 1513 for the variables that appear in SimplePolicyActions is for validation, 1514 prior to the time when an action is executed. Expected values play no 1515 role in action execution. 1517 Composing a simple action requires that an instance of the class 1518 SimplePolicyAction be created, and that instances of the variable and 1519 value classes that it uses also exist. Note that the variable and/or 1520 value instances may already exist as reusable objects in an appropriate 1521 ReusablePolicyContainer. 1523 Two aggregations are used in order to create the pair (, 1524 ). The aggregation PolicyVariableInSimplePolicyAction relates a 1525 SimplePolicyAction to a single variable instance. Similarly, the 1526 aggregation PolicyValueInSimplePolicyAction relates a SimplePolicyAction 1527 to a single value instance. Both aggregations are defined in this 1528 document. 1530 Figure 8. depicts a SimplePolicyAction with its associated variable and 1531 value. 1533 +-----------------------+ 1534 | SimplePolicyAction | 1535 | | 1536 +-----------------------+ 1537 * @ 1538 * @ 1539 +------------------+ * @ +---------------+ 1540 | (PolicyVariable) |*** @@@| (PolicyValue) | 1541 +------------------+ +---------------+ 1542 # # 1543 # ooo # 1544 # # 1545 +---------------+ +---------------+ 1546 | (PolicyValue) | ooo | (PolicyValue) | 1547 +---------------+ +---------------+ 1549 Aggregation Legend: 1550 **** PolicyVariableInSimplePolicyAction 1551 @@@@ PolicyValueInSimplePolicyAction 1552 #### ExpectedPolicyValuesForVariable 1554 Figure 8. SimplePolicyAction 1556 4.8.5. Policy Variables 1558 A variable generically represents information that changes (or "varies"), 1559 and that is set or evaluated by software. In policy, conditions and 1560 actions can abstract information as "policy variables" to be evaluated in 1561 logical expressions, or set by actions. 1563 PCIMe defines two types of PolicyVariables, PolicyImplicitVariables and 1564 PolicyExplicitVariables. The semantic difference between these classes 1565 is based on modeling context. Explicit variables are bound to exact 1566 model constructs, while implicit variables are defined and evaluated 1567 outside of a model. For example, one can imagine a PolicyCondition 1568 testing whether a CIM ManagedSystemElement's Status property has the 1569 value "Error." The Status property is an explicitly defined 1570 PolicyVariable (i.e., it is defined in the context of the CIM Schema, and 1571 evaluated in the context of a specific instance). On the other hand, 1572 network packets are not explicitly modeled or instantiated, since there 1573 is no perceived value (at this time) in managing at the packet level. 1574 Therefore, a PolicyCondition can make no explicit reference to a model 1575 construct that represents a network packet's source address. In this 1576 case, an implicit PolicyVariable is defined, to allow evaluation or 1577 modification of a packet's source address. 1579 4.8.6. Explicitly Bound Policy Variables 1581 Explicitly bound policy variables indicate the class and property names 1582 of the model construct to be evaluated or set. The CIM Schema defines 1583 and constrains "appropriate" values for the variable (i.e., model 1584 property) using data types and other information such as class/property 1585 qualifiers. 1587 A PolicyExplicitVariable is "explicit" because its model semantics are 1588 exactly defined. It is NOT explicit due to an exact binding to a 1589 particular object instance. If PolicyExplicitVariables were tied to 1590 instances (either via associations or by an object identification 1591 property in the class itself), then we would be forcing element-specific 1592 rules. On the other hand, if we only specify the object's model context 1593 (class and property name), but leave the binding to the policy framework 1594 (for example, using policy roles), then greater flexibility results for 1595 either general or element-specific rules. 1597 For example, an element-specific rule is obtained by a condition 1598 ((, ) pair) that defines CIM LogicalDevice 1599 DeviceID="12345". Alternately, if a PolicyRule's PolicyRoles is "edge 1600 device" and the condition ((, ) pair) is Status="Error", 1601 then a general rule results for all edge devices in error. 1603 Currently, the only binding for a PolicyExplicitVariable defined in PCIMe 1604 is to the instances selected by policy roles. For each such instance, a 1605 SimplePolicyCondition that aggregates the PolicyExplicitVariable 1606 evaluates to True if and only if ALL of the following are true: 1608 o The instance selected is of the class identified by the variable's 1609 ModelClass property, or of a subclass of this class. 1610 o The instance selected has the property identified by the 1611 variable's ModelProperty property. 1612 o The value of this property in the instance matches the value 1613 specified in the PolicyValue aggregated by the condition. 1615 In all other cases, the SimplePolicyCondition evaluates to False. 1617 For the case where a SimplePolicyAction aggregates a 1618 PolicyExplicitVariable, the indicated property in the selected instance 1619 is set to the value represented by the PolicyValue that the 1620 SimplePolicyAction also aggregates. However, if the selected instance is 1621 not of the class identified by the variable's ModelClass property, or of 1622 a subclass of this class, then the action is not performed. In this case 1623 the SimplePolicyAction is not treated either as a successfully executed 1624 action (for the execution strategy Do Until Success) or as a failed 1625 action (for the execution strategy Do Until Failure). Instead, the 1626 remaining actions for the policy rule, if any, are executed as if this 1627 SimplePolicyAction were not present at all in the list of actions 1628 aggregated by the rule. 1630 Explicit variables would be more powerful if they could reach beyond the 1631 instances selected by policy roles, to related instances. However, to 1632 represent a policy rule involving such variables in any kind of general 1633 way requires something that starts to resemble very much a complete 1634 policy language. Clearly such a language is outside the scope of PCIMe, 1635 although it might be the subject of a future draft. 1637 By restricting much of the generality, it would be possible for explicit 1638 variables in PCIMe to reach slightly beyond a selected instance. For 1639 example, if a selected instance were related to exactly one instance of 1640 another class via a particular association class, and if the goal of the 1641 policy rule were both to test a property of this related instance and to 1642 set a property of that same instance, then it would be possible to 1643 represent the condition and action of the rule using 1644 PolicyExplicitVariables. Rather than handling this one specific case 1645 with explicit variables, though, it was decided to lump them with the 1646 more general case, and deal with them if and when a policy language is 1647 defined. 1649 Refer to Section 5.10 for the formal definition of the class 1650 PolicyExplicitVariable. 1652 4.8.7. Implicitly Bound Policy Variables 1654 Implicitly bound policy variables define the data type and semantics of a 1655 variable. This determines how the variable is bound to a value in a 1656 condition or an action. Further instructions are provided for specifying 1657 data type and/or value constraints for implicitly bound variables. 1659 PCIMe introduces an abstract class, PolicyImplicitVariable, to model 1660 implicitly bound variables. This class is derived from the abstract 1661 class PolicyVariable also defined in PCIMe. Each of the implicitly bound 1662 variables introduced by PCIMe (and those that are introduced by domain- 1663 specific sub-models) MUST be derived from the PolicyImplicitVariable 1664 class. The rationale for using this mechanism for modeling is explained 1665 below in Section 4.8.9. 1667 A domain-specific policy information model that extends PCIMe may define 1668 additional implicitly bound variables either by deriving them directly 1669 from the class PolicyImplicitVariable, or by further refining an existing 1670 variable class such as SourcePort. When refining a class such as 1671 SourcePort, existing binding rules, type or value constraints may be 1672 narrowed. 1674 4.8.8. Structure and Usage of Pre-Defined Variables 1676 A class derived from PolicyImplicitVariable to model a particular 1677 implicitly bound variable SHOULD be constructed so that its name depicts 1678 the meaning of the variable. For example, a class defined to model the 1679 source port of a TCP/UDP flow SHOULD have 'SourcePort' in its name. 1681 PCIMe defines one association and one general-purpose mechanism that 1682 together characterize each of the implicitly bound variables that it 1683 introduces: 1685 1. The ExpectedPolicyValuesForVariable association defines the set of 1686 value classes that could be matched to this variable. 1688 2. The list of constraints on the values that the PolicyVariable can 1689 hold (i.e., values that the variable must match) are defined by 1690 the appropriate properties of an associated PolicyValue class. 1692 In the example presented above, a PolicyImplicitVariable represents the 1693 SourcePort of incoming traffic. The ValueTypes property of an instance 1694 of this class will hold the class name PolicyIntegerValue. This by 1695 itself constrains the data type of the SourcePort instance to be an 1696 integer. However, we can further constrain the particular values that 1697 the SourcePort variable can hold by entering valid ranges in the 1698 IntegerList property of the PolicyIntegerValue instance (0 - 65535 in 1699 this document). 1701 The combination of the VariableName and the 1702 ExpectedPolicyValuesForVariable association provide a consistent and 1703 extensible set of metadata that define the semantics of variables that 1704 are used to form policy conditions. Since the 1705 ExpectedPolicyValuesForVariable association points to a PolicyValue 1706 instance, any of the values expressible in the PolicyValue class can be 1707 used to constrain values that the PolicyImplicitVariable can hold. For 1708 example: 1710 o The ValueTypes property can be used to ensure that only proper 1711 classes are used in the expression. For example, the SourcePort 1712 variable will not be allowed to ever be of type 1713 PolicyIPv4AddrValue, since source ports have different semantics 1714 than IP addresses and may not be matched. However, integer value 1715 types are allowed as the property ValueTypes holds the string 1716 "PolicyIntegerValue", which is the class name for integer values. 1718 o The ExpectedPolicyValuesForVariable association also ensures that 1719 variable-specific semantics are enforced (e.g., the SourcePort 1720 variable may include a constraint association to a value object 1721 defining a specific integer range that should be matched). 1723 4.8.9. Rationale for Modeling Implicit Variables as Classes 1725 An implicitly bound variable can be modeled in one of several ways, 1726 including a single class with an enumerator for each individual 1727 implicitly bound variable and an abstract class extended for each 1728 individual variable. The reasons for using a class inheritance mechanism 1729 for specifying individual implicitly bound variables are these: 1731 1. It is easy to extend. A domain-specific information model can 1732 easily extend the PolicyImplicitVariable class or its subclasses 1733 to define domain-specific and context-specific variables. For 1734 example, a domain-specific QoS policy information model may 1735 introduce an implicitly bound variable class to model applications 1736 by deriving a qosApplicationVariable class from the 1737 PolicyImplicitVariable abstract class. 1739 2. Introduction of a single structural class for implicitly bound 1740 variables would have to include an enumerator property that 1741 contains all possible individual implicitly bound variables. This 1742 means that a domain-specific information model wishing to 1743 introduce an implicitly bound variable must extend the enumerator 1744 itself. This results in multiple definitions of the same class, 1745 differing in the values available in the enumerator class. One 1746 definition, in this document, would include the common implicitly 1747 bound variables' names, while a second definition, in the domain- 1748 specific information model document, may include additional values 1749 ('qosApplicationVariable' in the example above). It wouldn�t even 1750 be obvious to the application developer that multiple class 1751 definitions existed. It would be harder still for the application 1752 developer to actually find the correct class to use. 1754 3. In addition, an enumerator-based definition would require each 1755 additional value to be registered with IANA to ascertain adherence 1756 to standards. This would make the process cumbersome. 1758 4. A possible argument against the inheritance mechanism would cite 1759 the fact that this approach results in an explosion of class 1760 definitions compared to an enumerator class, which only introduces 1761 a single class. While, by itself, this is not a strike against 1762 the approach, it may be argued that data models derived from this 1763 information model may be more difficult to optimize for 1764 applications. This argument is rejected on the grounds that 1765 application optimization is of lesser value for an information 1766 model than clarity and ease of extension. In addition, it is hard 1767 to claim that the inheritance model places an absolute burden on 1768 the optimization. For example, a data model may still use 1769 enumeration to denote instances of pre-defined variables and claim 1770 PCIMe compliance, as long as the data model can be mapped 1771 correctly to the definitions specified in this document. 1773 4.8.10. Policy Values 1775 The abstract class PolicyValue is used for modeling values and constants 1776 used in policy conditions. Different value types are derived from this 1777 class, to represent the various attributes required. Extensions of the 1778 abstract class PolicyValue, defined in this document, provide a list of 1779 values for basic network attributes. Values can be used to represent 1780 constants as named values. Named values can be kept in a reusable policy 1781 container to be reused by multiple conditions. Examples of constants 1782 include well-known ports, well-known protocols, server addresses, and 1783 other similar concepts. 1785 The PolicyValue subclasses define three basic types of values: scalars, 1786 ranges and sets. For example, a well-known port number could be defined 1787 using the PolicyIntegerValue class, defining a single value (80 for 1788 HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively. 1789 For details, please see the class definition for each value type in 1790 Section 5.14 of this document. 1792 PCIMe defines the following subclasses of the abstract class PolicyValue: 1794 Classes for general use: 1796 - PolicyStringValue, 1797 - PolicyIntegerValue, 1798 - PolicyBitStringValue 1799 - PolicyBooleanValue. 1801 Classes for layer 3 Network values: 1803 - PolicyIPv4AddrValue, 1804 - PolicyIPv6AddrValue. 1806 Classes for layer 2 Network values: 1808 - PolicyMACAddrValue. 1810 For details, please see the class definition section of each class in 1811 Section 5.14 of this document. 1813 4.9. Packet Filtering 1815 PCIMe contains two mechanisms for representing packet filters. The more 1816 general of these, termed here the domain-level model, expresses packet 1817 filters in terms of policy variables and policy values. The other 1818 mechanism, termed here the device-level model, expresses packet filters 1819 in a way that maps more directly to the packet fields to which the 1820 filters are being applied. While it is possible to map between these two 1821 representations of packet filters, no mapping is provided in PCIMe 1822 itself. 1824 4.9.1. Domain-Level Packet Filters 1826 In addition to filling in the holes in the overall Policy infrastructure, 1827 PCIMe proposes a single mechanism for expressing domain-level packet 1828 filters in policy conditions. This is being done in response to concerns 1829 that even though the initial "wave" of submodels derived from PCIM were 1830 all filtering on IP packets, each was doing it in a slightly different 1831 way. PCIMe proposes a common way to express IP packet filters. The 1832 following figure illustrates how packet-filtering conditions are 1833 expressed in PCIMe. 1835 +---------------------------------+ 1836 | CompoundFilterCondition | 1837 | - IsMirrored boolean | 1838 | - ConditionListType (DNF|CNF) | 1839 +---------------------------------+ 1840 + + + 1841 + + + 1842 + + + 1843 SimplePC SimplePC SimplePC 1844 * @ * @ * @ 1845 * @ * @ * @ 1846 * @ * @ * @ 1847 FlowDirection "In" SrcIP DstIP 1849 Aggregation Legend: 1850 ++++ PolicyConditionInPolicyCondition 1851 **** PolicyVariableInSimplePolicyCondition 1852 @@@@ PolicyValueInSimplePolicyCondition 1854 Figure 9. Packet Filtering in Policy Conditions 1856 In Figure 9. , each SimplePolicyCondition represents a single field to be 1857 filtered on: Source IP address, Destination IP address, Source port, etc. 1858 An additional SimplePolicyCondition indicates the direction that a packet 1859 is traveling on an interface: inbound or outbound. Because of the 1860 FlowDirection condition, care must be taken in aggregating a set of 1861 SimplePolicyConditions into a CompoundFilterCondition. Otherwise, the 1862 resulting CompoundPolicyCondition may match all inbound packets, or all 1863 outbound packets, when this is probably not what was intended. 1865 Individual SimplePolicyConditions may be negated when they are aggregated 1866 by a CompoundFilterCondition. 1868 CompoundFilterCondition is a subclass of CompoundPolicyCondition. It 1869 introduces one additional property, the Boolean property IsMirrored. The 1870 purpose of this property is to allow a single CompoundFilterCondition to 1871 match packets traveling in both directions on a higher-level connection 1872 such as a TCP session. When this property is TRUE, additional packets 1873 match a filter, beyond those that would ordinarily match it. An example 1874 will illustrate how this property works. 1876 Suppose we have a CompoundFilterCondition that aggregates the following 1877 three filters, which are ANDed together: 1879 o FlowDirection = "In" 1880 o Source IP = 9.1.1.1 1881 o Source Port = 80 1883 Regardless of whether IsMirrored is TRUE or FALSE, inbound packets will 1884 match this CompoundFilterCondition if their Source IP address = 9.1.1.1 1885 and their Source port = 80. If IsMirrored is TRUE, however, an outbound 1886 packet will also match the CompoundFilterCondition if its Destination IP 1887 address = 9.1.1.1 and its Destination port = 80. 1889 IsMirrored "flips" the following Source/Destination packet header fields: 1891 o FlowDirection "In" / FlowDirection "Out" 1892 o Source IP address / Destination IP address 1893 o Source port / Destination port 1894 o Source MAC address / Destination MAC address 1895 o Source [layer-2] SAP / Destination [layer-2] SAP. 1897 4.9.2. Device-Level Packet Filters 1899 At the device level, packet header filters are represented by two 1900 subclasses of the abstract class FilterEntryBase: IpHeadersFilter and 1901 8021Filter. Submodels of PCIMe may define other subclasses of 1902 FilterEntryBase in addition to these two; ICPM [6], for example, defines 1903 subclasses for IPsec-specific filters. 1905 Instances of the subclasses of FilterEntryBase are not used directly as 1906 filters. They are always aggregated into a FilterList, by the 1907 aggregation EntriesInFilterList. For PCIMe and its submodels, the 1908 EntrySequence property in this aggregation always takes its default value 1909 '0', indicating that the aggregated filter entries are ANDed together. 1911 The FilterList class includes an enumeration property Direction, 1912 representing the direction of the traffic flow to which the FilterList is 1913 to be applied. The value Mirrored(4) for Direction represents exactly 1914 the same thing as the IsMirrored boolean does in CompoundFilterCondition. 1915 See Section 4.9.1 for details. 1917 4.10. Conformance to PCIM and PCIMe 1919 Because PCIM and PCIMe provide the core classes for modeling policies, 1920 they are not in general sufficient by themselves for representing actual 1921 policy rules. Submodels, such as QPIM and ICPM, provide the means for 1922 expressing policy rules, by defining subclasses of the classes defined in 1923 PCIM and PCIMe, and/or by indicating how the PolicyVariables and 1924 PolicyValues defined in PCIMe can be used to express conditions and 1925 actions applicable to the submodel. 1927 A particular submodel will not, in general, need to use every element 1928 defined in PCIM and PCIMe. For the elements it does not use, a submodel 1929 SHOULD remain silent on whether its implementations must support the 1930 element, must not support the element, should support the element, etc. 1931 For the elements it does use, a submodel SHOULD indicate which elements 1932 its implementations must support, which elements they should support, and 1933 which elements they may support. 1935 PCIM and PCIMe themselves simply define elements that may be of use to 1936 submodels. These documents remain silent on whether implementations are 1937 required to support an element, should support it, etc. 1939 This model (and derived submodels) defines conditions and actions that 1940 are used by policy rules. While the conditions and actions defined 1941 herein are straightforward and may be presumed to be widely supported, as 1942 submodels are developed it is likely that situations will arise in which 1943 specific conditions or actions are not supported by some part of the 1944 policy execution system. Similarly, situations may also occur where 1945 rules contain syntactic or semantic errors. 1947 It should be understood that the behavior and effect of undefined or 1948 incorrectly defined conditions or actions is not prescribed by this 1949 information model. While it would be helpful if it were prescribed, the 1950 variations in implementation restrict the ability for this information 1951 model to control the effect. For example, if an implementation only 1952 detected that a PEP could not enforce a given action on that PEP, it 1953 would be very difficult to declare that such a failure should affect 1954 other PEPs, or the PDP process. On the other hand, if the PDP determines 1955 that it cannot properly evaluate a condition, that failure may well 1956 affect all applications of the containing rules. 1958 5. Class Definitions 1960 The following definitions supplement those in PCIM itself. PCIM 1961 definitions that are not DEPRECATED here are still current parts of the 1962 overall Policy Core Information Model. 1964 5.1. The Abstract Class "PolicySet" 1966 PolicySet is an abstract class that may group policies into a structured 1967 set of policies. 1969 NAME PolicySet 1970 DESCRIPTION An abstract class that represents a set of policies 1971 that form a coherent set. The set of contained 1972 policies has a common decision strategy and a common 1973 set of policy roles. Subclasses include PolicyGroup 1974 and PolicyRule. 1975 DERIVED FROM Policy 1976 ABSTRACT TRUE 1977 PROPERTIES PolicyDecisionStrategy 1978 PolicyRoles 1980 The PolicyDecisionStrategy property specifies the evaluation method for 1981 policy groups and rules contained within the policy set. 1983 NAME PolicyDecisionStrategy 1984 DESCRIPTION The evaluation method used for policies contained in 1985 the PolicySet. FirstMatching enforces the actions of 1986 the first rule that evaluates to TRUE; AllMatching 1987 enforces the actions of all rules that evaluate to 1988 TRUE. 1989 SYNTAX uint16 1990 VALUES 1 [FirstMatching], 2 [AllMatching] 1991 DEFAULT VALUE 1 [FirstMatching] 1993 The definition of PolicyRoles is unchanged from PCIM. It is, however, 1994 moved from the class Policy up to the superclass PolicySet. 1996 5.2. Update PCIM's Class "PolicyGroup" 1998 The PolicyGroup class is moved, so that it is now derived from PolicySet. 2000 NAME PolicyGroup 2001 DESCRIPTION A container for a set of related PolicyRules and 2002 PolicyGroups. 2003 DERIVED FROM PolicySet 2004 ABSTRACT FALSE 2005 PROPERTIES (none) 2007 5.3. Update PCIM's Class "PolicyRule" 2009 The PolicyRule class is moved, so that it is now derived from PolicySet. 2010 The Priority property is also deprecated in PolicyRule, and PolicyRoles 2011 is now inherited from the parent class PolicySet. Finally, a new 2012 property ExecutionStrategy is introduced, paralleling the property of the 2013 same name in the class CompoundPolicyAction. 2015 NAME PolicyRule 2016 DESCRIPTION The central class for representing the "If Condition 2017 then Action" semantics associated with a policy rule. 2018 DERIVED FROM PolicySet 2019 ABSTRACT FALSE 2020 PROPERTIES Enabled 2021 ConditionListType 2022 RuleUsage 2023 Priority DEPRECATED FOR PolicySetComponent.Priority 2024 AND FOR PolicySetInSystem.Priority 2025 Mandatory 2026 SequencedActions 2027 ExecutionStrategy 2028 The property ExecutionStrategy defines the execution strategy to be used 2029 upon the sequenced actions aggregated by this PolicyRule. (An equivalent 2030 ExecutionStrategy property is also defined for the CompoundPolicyAction 2031 class, to provide the same indication for the sequenced actions 2032 aggregated by a CompoundPolicyAction.) This draft defines three 2033 execution strategies: 2035 Do Until Success � execute actions according to predefined order, until 2036 successful execution of a single action. 2037 Do All - execute ALL actions which are part of the modeled 2038 set, according to their predefined order. Continue 2039 doing this, even if one or more of the actions 2040 fails. 2041 Do Until Failure - execute actions according to predefined order, until 2042 the first failure in execution of a single sub- 2043 action. 2045 The property definition is as follows: 2047 NAME ExecutionStrategy 2048 DESCRIPTION An enumeration indicating how to interpret the action 2049 ordering for the actions aggregated by this 2050 PolicyRule. 2051 SYNTAX uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do 2052 Until Failure} ) 2053 DEFAULT VALUE Do All (2) 2055 5.4. The Class "SimplePolicyCondition" 2057 A simple policy condition is composed of an ordered triplet: 2059 MATCH 2061 No formal modeling of the MATCH operator is provided. The 'match' 2062 relationship is implied. Such simple conditions are evaluated by 2063 answering the question: 2065 Does match ? 2067 The 'match' relationship is to be interpreted by analyzing the variable 2068 and value instances associated with the simple condition. 2070 Simple conditions are building blocks for more complex Boolean 2071 Conditions, modeled by the CompoundPolicyCondition class. 2073 The SimplePolicyCondition class is derived from the PolicyCondition class 2074 defined in PCIM. 2076 A variable and a value must be associated with a simple condition to make 2077 it a meaningful condition, using, respectively, the aggregations 2078 PolicyVariableInSimplePolicyCondition and 2079 PolicyValueInSimplePolicyCondition. 2081 The class definition is as follows: 2083 NAME SimplePolicyCondition 2084 DERIVED FROM PolicyCondition 2085 ABSTRACT False 2086 PROPERTIES (none) 2088 5.5. The Class "CompoundPolicyCondition" 2090 This class represents a compound policy condition, formed by aggregation 2091 of simpler policy conditions. 2093 NAME CompoundPolicyCondition 2094 DESCRIPTION A subclass of PolicyCondition that introduces the 2095 ConditionListType property, used for assigning DNF / 2096 CNF semantics to subordinate policy conditions. 2097 DERIVED FROM PolicyCondition 2098 ABSTRACT FALSE 2099 PROPERTIES ConditionListType 2101 The ConditionListType property is used to specify whether the list of 2102 policy conditions associated with this compound policy condition is in 2103 disjunctive normal form (DNF) or conjunctive normal form (CNF). If this 2104 property is not present, the list type defaults to DNF. The property 2105 definition is as follows: 2107 NAME ConditionListType 2108 DESCRIPTION Indicates whether the list of policy conditions 2109 associated with this policy rule is in disjunctive 2110 normal form (DNF) or conjunctive normal form (CNF). 2111 SYNTAX uint16 2112 VALUES DNF(1), CNF(2) 2113 DEFAULT VALUE DNF(1) 2115 5.6. The Class "CompoundFilterCondition" 2117 This subclass of CompoundPolicyCondition introduces one additional 2118 property, the boolean IsMirrored. This property turns on or off the 2119 "flipping" of corresponding source and destination fields in a filter 2120 specification. 2122 NAME CompoundFilterCondition 2123 DESCRIPTION A subclass of CompoundPolicyCondition that introduces 2124 the IsMirrored property. 2125 DERIVED FROM CompoundPolicyCondition 2126 ABSTRACT FALSE 2127 PROPERTIES IsMirrored 2129 The IsMirrored property indicates whether packets that "mirror" a 2130 compound filter condition should be treated as matching the filter. The 2131 property definition is as follows: 2133 NAME IsMirrored 2134 DESCRIPTION Indicates whether packets that mirror the specified 2135 filter are to be treated as matching the filter. 2136 SYNTAX boolean 2137 DEFAULT VALUE FALSE 2139 5.7. The Class "SimplePolicyAction" 2141 The SimplePolicyAction class models the elementary set operation. "SET 2142 TO ". The set operator MUST overwrite an old value of 2143 the variable. 2145 Two aggregations are used in order to create the pair . 2146 The aggregation PolicyVariableInSimplePolicyAction relates a 2147 SimplePolicyAction to a single variable instance. Similarly, the 2148 aggregation PolicyValueInSimplePolicyAction relates a SimplePolicyAction 2149 to a single value instance. Both aggregations are defined in this 2150 document. 2152 NAME SimplePolicyAction 2153 DESCRIPTION A subclass of PolicyAction that introduces the notion 2154 of "SET variable TO value". 2155 DERIVED FROM PolicyAction 2156 ABSTRACT FALSE 2157 PROPERTIES (none) 2159 5.8. The Class "CompoundPolicyAction" 2161 The CompoundPolicyAction class is used to represent an expression 2162 consisting of an ordered sequence of action terms. Each action term is 2163 represented as a subclass of the PolicyAction class, defined in [PCIM]. 2164 Compound actions are constructed by associating dependent action terms 2165 together using the PolicyActionInPolicyAction aggregation. 2167 The class definition is as follows: 2169 NAME CompoundPolicyAction 2170 DESCRIPTION A class for representing sequenced action terms. Each 2171 action term is defined to be a subclass of the 2172 PolicyAction class. 2173 DERIVED FROM PolicyAction 2174 ABSTRACT FALSE 2175 PROPERTIES SequencedActions 2176 ExecutionStrategy 2178 This is a concrete class, and is therefore directly instantiable. 2180 The Property SequencedActions is identical to the SequencedActions 2181 property defined in PCIM for the class PolicyRule. 2183 The property ExecutionStrategy defines the execution strategy to be used 2184 upon the sequenced actions associated with this compound action. (An 2185 equivalent ExecutionStrategy property is also defined for the PolicyRule 2186 class, to provide the same indication for the sequenced actions 2187 associated with a PolicyRule.) This draft defines three execution 2188 strategies: 2190 Do Until Success � execute actions according to predefined order, until 2191 successful execution of a single sub-action. 2192 Do All - execute ALL actions which are part of the modeled 2193 set, according to their predefined order. Continue 2194 doing this, even if one or more of the sub-actions 2195 fails. 2196 Do Until Failure - execute actions according to predefined order, until 2197 the first failure in execution of a single sub- 2198 action. 2200 Since a CompoundPolicyAction may itself be aggregated either by a 2201 PolicyRule or by another CompoundPolicyAction, its success or failure 2202 will be an input to the aggregating entity's execution strategy. 2203 Consequently, the following rules are specified, for determining whether 2204 a CompoundPolicyAction succeeds or fails: 2206 If the CompoundPolicyAction's ExecutionStrategy is Do Until Success, 2207 then 2208 o If one component action succeeds, then the CompoundPolicyAction 2209 succeeds. 2210 o If all component actions fail, then the CompoundPolicyAction 2211 fails. 2213 If the CompoundPolicyAction's ExecutionStrategy is Do All, then 2214 o If all component actions succeed, then the CompoundPolicyAction 2215 succeeds. 2216 o If at least one component action fails, then the 2217 CompoundPolicyAction fails. 2219 If the CompoundPolicyAction's ExecutionStrategy is Do Until Failure, 2220 then 2221 o If all component actions succeed, then the CompoundPolicyAction 2222 succeeds. 2223 o If at least one component action fails, then the 2224 CompoundPolicyAction fails. 2226 The definition of the ExecutionStrategy property is as follows: 2228 NAME ExecutionStrategy 2229 DESCRIPTION An enumeration indicating how to interpret the action 2230 ordering for the actions aggregated by this 2231 CompoundPolicyAction. 2232 SYNTAX uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do 2233 Until Failure} ) 2234 DEFAULT VALUE Do All (2) 2235 5.9. The Abstract Class "PolicyVariable" 2237 Variables are used for building individual conditions. The variable 2238 specifies the property of a flow or an event that should be matched when 2239 evaluating the condition. However, not every combination of a variable 2240 and a value creates a meaningful condition. For example, a source IP 2241 address variable can not be matched against a value that specifies a port 2242 number. A given variable selects the set of matchable value types. 2244 A variable can have constraints that limit the set of values within a 2245 particular value type that can be matched against it in a condition. For 2246 example, a source-port variable limits the set of values to represent 2247 integers to the range of 0-65535. Integers outside this range cannot be 2248 matched to the source-port variable, even though they are of the correct 2249 data type. Constraints for a given variable are indicated through the 2250 ExpectedPolicyValuesForVariable association. 2252 The PolicyVariable is an abstract class. Implicit and explicit context 2253 variable classes are defined as sub classes of the PolicyVariable class. 2254 A set of implicit variables is defined in this document as well. 2256 The class definition is as follows: 2258 NAME PolicyVariable 2259 DERIVED FROM Policy 2260 ABSTRACT TRUE 2261 PROPERTIES (none) 2263 5.10. The Class "PolicyExplicitVariable" 2265 Explicitly defined policy variables are evaluated within the context of 2266 the CIM Schema and its modeling constructs. The PolicyExplicitVariable 2267 class indicates the exact model property to be evaluated or manipulated. 2268 See Section 4.8.6 for a complete discussion of what happens when the 2269 values of the ModelClass and ModelProperty properties in an instance of 2270 this class do not correspond to the characteristics of the model 2271 construct being evaluated or updated. 2273 The class definition is as follows: 2275 NAME PolicyExplicitVariable 2276 DERIVED FROM PolicyVariable 2277 ABSTRACT False 2278 PROPERTIES ModelClass, ModelProperty 2280 5.10.1. The Single-Valued Property "ModelClass" 2282 This property is a string specifying the class name whose property is 2283 evaluated or set as a PolicyVariable. 2285 The property is defined as follows: 2287 NAME ModelClass 2288 SYNTAX String 2290 5.10.2. The Single-Valued Property ModelProperty 2292 This property is a string specifying the property name, within the 2293 ModelClass, which is evaluated or set as a PolicyVariable. The property 2294 is defined as follows: 2296 NAME ModelProperty 2297 SYNTAX String 2299 5.11. The Abstract Class "PolicyImplicitVariable" 2301 Implicitly defined policy variables are evaluated outside of the context 2302 of the CIM Schema and its modeling constructs. Subclasses specify the 2303 data type and semantics of the PolicyVariables. 2305 Interpretation and evaluation of a PolicyImplicitVariable can vary, 2306 depending on the particular context in which it is used. For example, a 2307 "SourceIP" address may denote the source address field of an IP packet 2308 header, or the sender address delivered by an RSVP PATH message. 2310 The class definition is as follows: 2312 NAME PolicyImplicitVariable 2313 DERIVED FROM PolicyVariable 2314 ABSTRACT True 2315 PROPERTIES ValueTypes[ ] 2317 5.11.1. The Multi-Valued Property "ValueTypes" 2319 This property is a set of strings specifying an unordered list of 2320 possible value/data types that can be used in simple conditions and 2321 actions, with this variable. The value types are specified by their 2322 class names (subclasses of PolicyValue such as PolicyStringValue). The 2323 list of class names enables an application to search on a specific name, 2324 as well as to ensure that the data type of the variable is of the correct 2325 type. 2327 The list of default ValueTypes for each subclass of 2328 PolicyImplicitVariable is specified within that variable's definition. 2330 The property is defined as follows: 2332 NAME ValueTypes 2333 SYNTAX String 2334 5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe 2336 The following subclasses of PolicyImplicitVariable are defined in PCIMe. 2338 5.12.1. The Class "PolicySourceIPv4Variable" 2340 NAME PolicySourceIPv4Variable 2341 DESCRIPTION The source IPv4 address. of the outermost IP packet 2342 header. "Outermost" here refers to the IP packet as 2343 it flows on the wire, before any headers have been 2344 stripped from it. 2346 ALLOWED VALUE TYPES: 2347 - PolicyIPv4AddrValue 2349 DERIVED FROM PolicyImplicitVariable 2350 ABSTRACT FALSE 2351 PROPERTIES (none) 2353 5.12.2. The Class "PolicySourceIPv6Variable" 2355 NAME PolicySourceIPv6Variable 2356 DESCRIPTION The source IPv6 address of the outermost IP packet 2357 header. "Outermost" here refers to the IP packet as 2358 it flows on the wire, before any headers have been 2359 stripped from it. 2361 ALLOWED VALUE TYPES: 2362 - PolicyIPv6AddrValue 2364 DERIVED FROM PolicyImplicitVariable 2365 ABSTRACT FALSE 2366 PROPERTIES (none) 2368 5.12.3. The Class "PolicyDestinationIPv4Variable" 2370 NAME PolicyDestinationIPv4Variable 2371 DESCRIPTION The destination IPv4 address of the outermost IP 2372 packet header. "Outermost" here refers to the IP 2373 packet as it flows on the wire, before any headers 2374 have been stripped from it. 2376 ALLOWED VALUE TYPES: 2377 - PolicyIPv4AddrValue 2379 DERIVED FROM PolicyImplicitVariable 2380 ABSTRACT FALSE 2381 PROPERTIES (none) 2383 5.12.4. The Class "PolicyDestinationIPv6Variable" 2385 NAME PolicyDestinationIPv6Variable 2386 DESCRIPTION The destination IPv6 address of the outermost IP 2387 packet header. "Outermost" here refers to the IP 2388 packet as it flows on the wire, before any headers 2389 have been stripped from it. 2391 ALLOWED VALUE TYPES: 2392 - PolicyIPv6AddrValue 2394 DERIVED FROM PolicyImplicitVariable 2395 ABSTRACT FALSE 2396 PROPERTIES (none) 2398 5.12.5. The Class "PolicySourcePortVariable" 2400 NAME PolicySourcePortVariable 2401 DESCRIPTION Ports are defined as the abstraction that transport 2402 protocols use to distinguish among multiple 2403 destinations within a given host computer. For TCP 2404 and UDP flows, the PolicySourcePortVariable is 2405 logically bound to the source port field of the 2406 outermost UDP or TCP packet header. "Outermost" here 2407 refers to the IP packet as it flows on the wire, 2408 before any headers have been stripped from it. 2410 ALLOWED VALUE TYPES: 2411 - PolicyIntegerValue (0..65535) 2413 DERIVED FROM PolicyImplicitVariable 2414 ABSTRACT FALSE 2415 PROPERTIES (none) 2417 5.12.6. The Class "PolicyDestinationPortVariable" 2419 NAME PolicyDestinationPortVariable 2420 DESCRIPTION Ports are defined as the abstraction that transport 2421 protocols use to distinguish among multiple 2422 destinations within a given host computer. For TCP 2423 and UDP flows, the PolicyDestinationPortVariable is 2424 logically bound to the destination port field of the 2425 outermost UDP or TCP packet header. "Outermost" here 2426 refers to the IP packet as it flows on the wire, 2427 before any headers have been stripped from it. 2429 ALLOWED VALUE TYPES: 2430 - PolicyIntegerValue (0..65535) 2432 DERIVED FROM PolicyImplicitVariable 2433 ABSTRACT FALSE 2434 PROPERTIES (none) 2435 5.12.7. The Class "PolicyIPProtocolVariable" 2437 NAME PolicyIPProtocolVariable 2438 DESCRIPTION The IP protocol number. 2440 ALLOWED VALUE TYPES: 2441 - PolicyIntegerValue (0..255) 2443 DERIVED FROM PolicyImplicitVariable 2444 ABSTRACT FALSE 2445 PROPERTIES (none) 2447 5.12.8. The Class "PolicyIPVersionVariable" 2449 NAME PolicyIPVersionVariable 2450 DESCRIPTION The IP version number. The well-known values are 4 2451 and 6. 2453 ALLOWED VALUE TYPES: 2454 - PolicyIntegerValue (0..15) 2456 DERIVED FROM PolicyImplicitVariable 2457 ABSTRACT FALSE 2458 PROPERTIES (none) 2460 5.12.9. The Class "PolicyIPToSVariable" 2462 NAME PolicyIPToSVariable 2463 DESCRIPTION The IP TOS octet. 2465 ALLOWED VALUE TYPES: 2466 - PolicyIntegerValue (0..255) 2467 - PolicyBitStringValue (8 bits) 2469 DERIVED FROM PolicyImplicitVariable 2470 ABSTRACT FALSE 2471 PROPERTIES (none) 2473 5.12.10. The Class "PolicyDSCPVariable" 2475 NAME PolicyDSCPVariable 2476 DESCRIPTION The 6 bit Differentiated Service Code Point. 2478 ALLOWED VALUE TYPES: 2479 - PolicyIntegerValue (0..63) 2480 - PolicyBitStringValue (6 bits) 2482 DERIVED FROM PolicyImplicitVariable 2483 ABSTRACT FALSE 2484 PROPERTIES (none) 2485 5.12.11. The Class "PolicyFlowIdVariable" 2487 NAME PolicyFlowIdVariable 2488 DESCRIPTION The flow identifer of the outermost IPv6 packet 2489 header. "Outermost" here refers to the IP packet as 2490 it flows on the wire, before any headers have been 2491 stripped from it. 2493 ALLOWED VALUE TYPES: 2494 - PolicyIntegerValue (0..1048575 2495 - PolicyBitStringValue (20 bits) 2497 DERIVED FROM PolicyImplicitVariable 2498 ABSTRACT FALSE 2499 PROPERTIES (none) 2501 5.12.12. The Class "PolicySourceMACVariable" 2503 NAME PolicySourceMACVariable 2504 DESCRIPTION The source MAC address. 2506 ALLOWED VALUE TYPES: 2507 - PolicyMACAddrValue 2509 DERIVED FROM PolicyImplicitVariable 2510 ABSTRACT FALSE 2511 PROPERTIES (none) 2513 5.12.13. The Class "PolicyDestinationMACVariable" 2515 NAME PolicyDestinationMACVariable 2516 DESCRIPTION The destination MAC address. 2518 ALLOWED VALUE TYPES: 2519 - PolicyMACAddrValue 2521 DERIVED FROM PolicyImplicitVariable 2522 ABSTRACT FALSE 2523 PROPERTIES (none) 2525 5.12.14. The Class "PolicyVLANVariable" 2527 NAME PolicyVLANVariable 2528 DESCRIPTION The virtual Bridged Local Area Network Identifier, a 2529 12-bit field as defined in the IEEE 802.1q standard. 2531 ALLOWED VALUE TYPES: 2532 - PolicyIntegerValue (0..4095) 2533 - PolicyBitStringValue (12 bits) 2535 DERIVED FROM PolicyImplicitVariable 2536 ABSTRACT FALSE 2537 PROPERTIES (none) 2539 5.12.15. The Class "PolicyCoSVariable" 2541 NAME PolicyCoSVariable 2542 DESCRIPTION Class of Service, a 3-bit field, used in the layer 2 2543 header to select the forwarding treatment. Bound to 2544 the IEEE 802.1q user-priority field. 2546 ALLOWED VALUE TYPES: 2547 - PolicyIntegerValue (0..7) 2548 - PolicyBitStringValue (3 bits) 2550 DERIVED FROM PolicyImplicitVariable 2551 ABSTRACT FALSE 2552 PROPERTIES (none) 2554 5.12.16. The Class "PolicyEthertypeVariable" 2556 NAME PolicyEthertypeVariable 2557 DESCRIPTION The Ethertype protocol number of Ethernet frames. 2559 ALLOWED VALUE TYPES: 2560 - PolicyIntegerValue (0..65535) 2561 - PolicyBitStringValue (16 bits) 2563 DERIVED FROM PolicyImplicitVariable 2564 ABSTRACT FALSE 2565 PROPERTIES (none) 2567 5.12.17. The Class "PolicySourceSAPVariable" 2569 NAME PolicySourceSAPVariable 2570 DESCRIPTION The Source Service Access Point (SAP) number of the 2571 IEEE 802.2 LLC header. 2573 ALLOWED VALUE TYPES: 2574 - PolicyIntegerValue (0..255) 2575 - PolicyBitStringValue (8 bits) 2577 DERIVED FROM PolicyImplicitVariable 2578 ABSTRACT FALSE 2579 PROPERTIES (none) 2581 5.12.18. The Class "PolicyDestinationSAPVariable" 2583 NAME PolicyDestinationSAPVariable 2584 DESCRIPTION The Destination Service Access Point (SAP) number of 2585 the IEEE 802.2 LLC header. 2587 ALLOWED VALUE TYPES: 2588 - PolicyIntegerValue (0..255) 2589 - PolicyBitStringValue (8 bits) 2591 DERIVED FROM PolicyImplicitVariable 2592 ABSTRACT FALSE 2593 PROPERTIES (none) 2595 5.12.19. The Class "PolicySNAPOUIVariable" 2597 NAME PolicySNAPOUIVariable 2598 DESCRIPTION The value of the first three octets of the Sub-Network 2599 Access Protocol (SNAP) Protocol Identifier field for 2600 802.2 SNAP encapsulation, containing an 2601 Organizationally Unique Identifier (OUI). The value 2602 00-00-00 indicates the encapsulation of Ethernet 2603 frames (RFC 1042). OUI value 00-00-F8 indicates the 2604 special encapsulation of Ethernet frames by certain 2605 types of bridges (IEEE 802.1H). Other values are 2606 supported, but are not further defined here. These 2607 OUI. values are to be interpreted according to the 2608 endian-notation conventions of IEEE 802. For either 2609 of the two Ethernet encapsulations, the remainder of 2610 the Protocol Identifier field is represented by the 2611 PolicySNAPTypeVariable. 2613 ALLOWED VALUE TYPES: 2614 - PolicyIntegerValue (0..16777215) 2615 - PolicyBitStringValue (24 bits) 2617 DERIVED FROM PolicyImplicitVariable 2618 ABSTRACT FALSE 2619 PROPERTIES (none) 2621 5.12.20. The Class "PolicySNAPTypeVariable" 2623 NAME PolicySNAPTypeVariable 2624 DESCRIPTION The value of the 4th and 5th octets of the Sub-Network 2625 Access Protocol (SNAP) Protocol Identifier field for 2626 IEEE 802 SNAP encapsulation when the 2627 PolicySNAPOUIVariable indicates one of the two 2628 Encapsulated Ethernet frame formats. This value is 2629 undefined for other values of PolicySNAPOUIVariable. 2631 ALLOWED VALUE TYPES: 2632 - PolicyIntegerValue (0..65535) 2633 - PolicyBitStringValue (16 bits) 2635 DERIVED FROM PolicyImplicitVariable 2636 ABSTRACT FALSE 2637 PROPERTIES (none) 2638 5.12.21. The Class "PolicyFlowDirectionVariable" 2640 NAME PolicyFlowDirectionVariable 2641 DESCRIPTION The direction of a flow relative to a network element. 2642 Direction may be "IN" and/or "OUT". 2644 ALLOWED VALUE TYPES: 2645 - PolicyStringValue ('IN", "OUT") 2647 DERIVED FROM PolicyImplicitVariable 2648 ABSTRACT FALSE 2649 PROPERTIES (none) 2651 To match on both inbound and outbound flows, the associated 2652 PolicyStringValue object has two entries in its StringList property: "IN" 2653 and "OUT". 2655 5.13. The Abstract Class "PolicyValue" 2657 This is an abstract class that serves as the base class for all 2658 subclasses that are used to define value objects in the PCIMe. It is 2659 used for defining values and constants used in policy conditions. The 2660 class definition is as follows: 2662 NAME PolicyValue 2663 DERIVED FROM Policy 2664 ABSTRACT True 2665 PROPERTIES (none) 2667 5.14. Subclasses of "PolicyValue" Specified in PCIMe 2669 The following subsections contain the PolicyValue subclasses defined in 2670 PCIMe. Additional subclasses may be defined in models derived from 2671 PCIMe. 2673 5.14.1. The Class "PolicyIPv4AddrValue" 2675 This class is used to provide a list of IPv4Addresses, hostnames and 2676 address range values to be matched against in a policy condition. The 2677 class definition is as follows: 2679 NAME PolicyIPv4AddrValue 2680 DERIVED FROM PolicyValue 2681 ABSTRACT False 2682 PROPERTIES IPv4AddrList[ ] 2684 The IPv4AddrList property provides an unordered list of strings, each 2685 specifying a single IPv4 address, a hostname, or a range of IPv4 2686 addresses, according to the ABNF definition [8] of an IPv4 address, as 2687 specified below: 2689 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 2690 IPv4prefix = IPv4address "/" 1*2DIGIT 2691 IPv4range = IPv4address"-"IPv4address 2692 IPv4maskedaddress = IPv4address","IPv4address 2693 Hostname (as defined in [9]) 2695 In the above definition, each string entry is either: 2697 1. A single IPv4address in dot notation, as defined above. Example: 2698 121.1.1.2 2700 2. An IPv4prefix address range, as defined above, specified by an 2701 address and a prefix length, separated by "/". Example: 2702 2.3.128.0/15 2704 3. An IPv4range address range defined above, specified by a starting 2705 address in dot notation and an ending address in dot notation, 2706 separated by "-". The range includes all addresses between the 2707 range's starting and ending addresses, including these two 2708 addresses. Example: 1.1.22.1-1.1.22.5 2710 4. An IPv4maskedaddress address range, as defined above, specified by 2711 an address and mask. The address and mask are represented in dot 2712 notation, separated by a comma ",". The masked address appears 2713 before the comma, and the mask appears after the comma. Example: 2714 2.3.128.0,255.255.248.0. 2716 5. A single Hostname. The Hostname format follows the guidelines and 2717 restrictions specified in [9]. Example: www.bigcompany.com. 2719 Conditions matching IPv4AddrValues evaluate to true according to the 2720 generic matching rules. Additionally, a hostname is matched against 2721 another valid IPv4address representation by resolving the hostname into 2722 an IPv4 address first, and then comparing the addresses afterwards. 2723 Matching hostnames against each other is done using a string comparison 2724 of the two names. 2726 The property definition is as follows: 2728 NAME IPv4AddrList 2729 SYNTAX String 2730 FORMAT IPv4address | IPv4prefix | IPv4range | 2731 IPv4maskedaddress | hostname 2733 5.14.2. The Class "PolicyIPv6AddrValue 2735 This class is used to define a list of IPv6 addresses, hostnames, and 2736 address range values. The class definition is as follows: 2738 NAME PolicyIPv6AddrValue 2739 DERIVED FROM PolicyValue 2740 ABSTRACT False 2741 PROPERTIES IPv6AddrList[ ] 2743 The property IPv6AddrList provides an unordered list of strings, each 2744 specifying an IPv6 address, a hostname, or a range of IPv6 addresses. 2745 IPv6 address format definition uses the standard address format defined 2746 in [10]. The ABNF definition [8] as specified in [10] is: 2748 IPv6address = hexpart [ ":" IPv4address ] 2749 IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 2750 IPv6prefix = hexpart "/" 1*2DIGIT 2751 hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] 2752 hexseq = hex4 *( ":" hex4) 2753 hex4 = 1*4HEXDIG 2754 IPv6range = IPv6address"-"IPv6address 2755 IPv6maskedaddress = IPv6address","IPv6address 2756 Hostname (as defines in [NAMES]) 2758 Each string entry is either: 2760 1. A single IPv6address as defined above. 2762 2. A single Hostname. Hostname format follows guidelines and 2763 restrictions specified in [9]. 2765 3. An IPv6range address range, specified by a starting address in dot 2766 notation and an ending address in dot notation, separated by "-". 2767 The range includes all addresses between the range's starting and 2768 ending addresses, including these two addresses. 2770 4. An IPv4maskedaddress address range defined above specified by an 2771 address and mask. The address and mask are represented in dot 2772 notation separated by a comma ",". 2774 5. A single IPv6prefix as defined above. 2776 Conditions matching IPv6AddrValues evaluate to true according to the 2777 generic matching rules. Additionally, a hostname is matched against 2778 another valid IPv6address representation by resolving the hostname into 2779 an IPv6 address first, and then comparing the addresses afterwards. 2780 Matching hostnames against each other is done using a string comparison 2781 of the two names. 2783 5.14.3. The Class "PolicyMACAddrValue" 2785 This class is used to define a list of MAC addresses and MAC address 2786 range values. The class definition is as follows: 2788 NAME PolicyMACAddrValue 2789 DERIVED FROM PolicyValue 2790 ABSTRACT False 2791 PROPERTIES MACAddrList[ ] 2792 The property MACAddrList provides an unordered list of strings, each 2793 specifying a MAC address or a range of MAC addresses. The 802 MAC 2794 address canonical format is used. The ABNF definition [8] is: 2796 MACaddress = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG 2797 MACmaskedaddress = MACaddress","MACaddress 2799 Each string entry is either: 2801 1. A single MAC address. Example: 0000:00A5:0000 2803 2. A MACmaskedaddress address range defined specified by an address 2804 and mask. The mask specifies the relevant bits in the address. 2805 Example: 0000:00A5:0000,FFFF:FFFF:0000 defines a range of MAC 2806 addresses in which the first four octets are equal to 0000:00A5. 2808 The property definition is as follows: 2810 NAME MACAddrList 2811 SYNTAX String 2812 FORMAT MACaddress | MACmaskedaddress 2814 5.14.4. The Class "PolicyStringValue" 2816 This class is used to represent a single string value, or a set of string 2817 values. Each value can have wildcards. The class definition is as 2818 follows: 2820 NAME PolicyStringValue 2821 DERIVED FROM PolicyValue 2822 ABSTRACT False 2823 PROPERTIES StringList[ ] 2825 The property StringList provides an unordered list of strings, each 2826 representing a single string with wildcards. The asterisk character "*" 2827 is used as a wildcard, and represents an arbitrary substring replacement. 2828 For example, the value "abc*def" matches the string "abcxyzdef", and the 2829 value "abc*def*" matches the string "abcxxxdefyyyzzz". The syntax 2830 definition is identical to the substring assertion syntax defined in 2831 [11]. If the asterisk character is required as part of the string value 2832 itself, it MUST be quoted as described in section 4.3 of [11]. 2834 The property definition is as follows: 2836 NAME StringList 2837 SYNTAX String 2839 5.14.5. The Class "PolicyBitStringValue" 2841 This class is used to represent a single bit string value, or a set of 2842 bit string values. The class definition is as follows: 2844 NAME PolicyBitStringValue 2845 DERIVED FROM PolicyValue 2846 ABSTRACT False 2847 PROPERTIES BitStringList[ ] 2849 The property BitStringList provides an unordered list of strings, each 2850 representing a single bit string or a set of bit strings. The number of 2851 bits specified SHOULD equal the number of bits of the expected variable. 2852 For example, for a one-octet variable, 8 bits should be specified. If 2853 the variable does not have a fixed length, the bit string should be 2854 matched against the variable's most significant bit string. The formal 2855 definition of a bit string is: 2857 binary-digit = "0" / "1" 2858 bitString = 1*binary-digit 2859 maskedBitString = bitString","bitString 2861 Each string entry is either: 2863 1. A single bit string. Example: 00111010 2865 2. A range of bit strings specified using a bit string and a bit 2866 mask. The bit string and mask fields have the same number of bits 2867 specified. The mask bit string specifies the significant bits in 2868 the bit string value. For example, 110110, 100110 and 110111 2869 would match the maskedBitString 100110,101110 but 100100 would 2870 not. 2872 The property definition is as follows: 2874 NAME BitStringList 2875 SYNTAX String 2876 FORMAT bitString | maskedBitString 2878 5.14.6. The Class "PolicyIntegerValue" 2880 This class provides a list of integer and integer range values. Integers 2881 of arbitrary sizes can be represented. The class definition is as 2882 follows: 2884 NAME PolicyIntegerValue 2885 DERIVED FROM PolicyValue 2886 ABSTRACT False 2887 PROPERTIES IntegerList[ ] 2889 The property IntegerList provides an unordered list of integers and 2890 integer range values, represented as strings. The format of this 2891 property takes one of the following forms: 2893 1. An integer value. 2895 2. A range of integers. The range is specified by a starting integer 2896 and an ending integer, separated by '..'. The starting integer 2897 MUST be less than or equal to the ending integer. The range 2898 includes all integers between the starting and ending integers, 2899 including these two integers. 2901 To represent a range of integers that is not bounded, the reserved words 2902 -INFINITY and/or INFINITY can be used in place of the starting and ending 2903 integers. In addition to ordinary integer matches, INFINITY matches 2904 INFINITY and -INFINITY matches -INFINITY. 2906 The ABNF definition [8] is: 2908 integer = [-]1*DIGIT | "INFINITY" | "-INFINITY" 2909 integerrange = integer".."integer 2911 Using ranges, the operators greater-than, greater-than-or-equal-to, less- 2912 than, and less-than-or-equal-to can be expressed. For example, "X is- 2913 greater-than 5" (where X is an integer) can be translated to "X matches 2914 6-INFINITY". This enables the match condition semantics of the operator 2915 for the SimplePolicyCondition class to be kept simple (i.e., just the 2916 value "match"). 2918 The property definition is as follows: 2920 NAME IntegerList 2921 SYNTAX String 2922 FORMAT integer | integerrange 2924 5.14.7. The Class "PolicyBooleanValue" 2926 This class is used to represent a Boolean (TRUE/FALSE) value. The class 2927 definition is as follows: 2929 NAME PolicyBooleanValue 2930 DERIVED FROM PolicyValue 2931 ABSTRACT False 2932 PROPERTIES BooleanValue 2934 The property definition is as follows: 2936 NAME BooleanValue 2937 SYNTAX boolean 2939 5.15. The Class "PolicyRoleCollection" 2941 This class represents a collection of managed elements that share a 2942 common role. The PolicyRoleCollection always exists in the context of a 2943 system, specified using the PolicyRoleCollectionInSystem association. 2944 The value of the PolicyRole property in this class specifies the role, 2945 and can be matched with the value(s) in the PolicyRoles array in 2946 PolicyRules and PolicyGroups. ManagedElements that share the role 2947 defined in this collection are aggregated into the collection via the 2948 association ElementInPolicyRoleCollection. 2950 NAME PolicyRoleCollection 2951 DESCRIPTION A subclass of the CIM Collection class used to group 2952 together managed elements that share a role. 2953 DERIVED FROM Collection 2954 ABSTRACT FALSE 2955 PROPERTIES PolicyRole 2957 5.15.1. The Single-Valued Property "PolicyRole" 2959 This property represents the role associated with a PolicyRoleCollection. 2960 The property definition is as follows: 2962 NAME PolicyRole 2963 DESCRIPTION A string representing the role associated with a 2964 PolicyRoleCollection. 2965 SYNTAX string 2967 5.16. The Class "ReusablePolicyContainer" 2969 The new class ReusablePolicyContainer is defined as follows: 2971 NAME ReusablePolicyContainer 2972 DESCRIPTION A class representing an administratively defined 2973 container for reusable policy-related information. 2974 This class does not introduce any additional 2975 properties beyond those in its superclass AdminDomain. 2976 It does, however, participate in a number of unique 2977 associations. 2978 DERIVED FROM AdminDomain 2979 ABSTRACT FALSE 2980 PROPERTIES (none) 2982 5.17. Deprecate PCIM's Class "PolicyRepository" 2984 The class definition of PolicyRepository (from PCIM) is updated as 2985 follows, with an indication that the class has been deprecated. Note 2986 that when an element of the model is deprecated, its replacement element 2987 is identified explicitly. 2989 NAME PolicyRepository 2990 DEPRECATED FOR ReusablePolicyContainer 2991 DESCRIPTION A class representing an administratively defined 2992 container for reusable policy-related information. 2993 This class does not introduce any additional 2994 properties beyond those in its superclass AdminDomain. 2995 It does, however, participate in a number of unique 2996 associations. 2997 DERIVED FROM AdminDomain 2998 ABSTRACT FALSE 2999 PROPERTIES (none) 3001 5.18. The Abstract Class "FilterEntryBase" 3003 FilterEntryBase is the abstract base class from which all filter entry 3004 classes are derived. It serves as the endpoint for the 3005 EntriesInFilterList aggregation, which groups filter entries into filter 3006 lists. Its properties include CIM naming attributes and an IsNegated 3007 boolean property (to easily "NOT" the match information specified in an 3008 instance of one of its subclasses). 3010 The class definition is as follows: 3012 NAME FilterEntryBase 3013 DESCRIPTION An abstract class representing a single 3014 filter that is aggregated into a 3015 FilterList via the aggregation 3016 EntriesInFilterList. 3017 DERIVED FROM LogicalElement 3018 TYPE Abstract 3019 PROPERTIES IsNegated 3021 5.19. The Class "IpHeadersFilter" 3023 This concrete class contains the most commonly required properties for 3024 performing filtering on IP, TCP or UDP headers. Properties not present 3025 in an instance of IPHeadersFilter are treated as 'all values'. A 3026 property HdrIpVersion identifies whether the IP addresses in an instance 3027 are IPv4 or IPv6 addresses. Since the source and destination IP 3028 addresses come from the same packet header, they will always be of the 3029 same type. 3031 The class definition is as follows: 3033 NAME IpHeadersFilter 3034 DESCRIPTION A class representing an entire IP 3035 header filter, or any subset of one. 3036 DERIVED FROM FilterEntryBase 3037 TYPE Concrete 3038 PROPERTIES HdrIpVersion, HdrSrcAddress, 3039 HdrSrcAddressEndOfRange, HdrSrcMask, 3040 HdrDestAddress, HdrDestAddressEndOfRange, 3041 HdrDestMask, HdrProtocolID, 3042 HdrSrcPortStart, HdrSrcPortEnd, 3043 HdrDestPortStart, HdrDestPortEnd, HdrDSCP[ ], 3044 HdrFlowLabel 3046 5.19.1. The Property HdrIpVersion 3048 This property is an 8-bit unsigned integer, identifying the version of 3049 the IP addresses to be filtered on. IP versions are identified as they 3050 are in the Version field of the IP packet header - IPv4 = 4, IPv6 = 6. 3051 These two values are the only ones defined for this property. 3053 The value of this property determines the sizes of the OctetStrings in 3054 the six properties HdrSrcAddress, HdrSrcAddressEndOfRange, HdrSrcMask, 3055 HdrDestAddress, HdrDestAddressEndOfRange, and HdrDestMask, as follows: 3057 o IPv4: OctetString(SIZE (4)) 3058 o IPv6: OctetString(SIZE (16|20)), depending on whether a scope 3059 identifier is present 3061 If a value for this property is not provided, then the filter does not 3062 consider IP version in selecting matching packets, i.e., IP version 3063 matches for all values. In this case, the HdrSrcAddress, 3064 HdrSrcAddressEndOfRange, HdrSrcMask, HdrDestAddress, 3065 HdrDestAddressEndOfRange, and HdrDestMask must also not be present. 3067 5.19.2. The Property HdrSrcAddress 3069 This property is an OctetString, of a size determined by the value of the 3070 HdrIpVersion property, representing a source IP address. When there is 3071 no HdrSrcAddressEndOfRange value, this value is compared to the source 3072 address in the IP header, subject to the mask represented in the 3073 HdrSrcMask property. (Note that the mask is ANDed with the address.) 3074 When there is a HdrSrcAddressEndOfRange value, this value is the start of 3075 the specified range (i.e., the HdrSrcAddress is lower than the 3076 HdrSrcAddressEndOfRange) that is compared to the source address in the IP 3077 header and matches on any value in the range. 3079 If a value for this property is not provided, then the filter does not 3080 consider HdrSrcAddress in selecting matching packets, i.e., HdrSrcAddress 3081 matches for all values. 3083 5.19.3. The Property HdrSrcAddressEndOfRange 3085 This property is an OctetString, of a size determined by the value of the 3086 HdrIpVersion property, representing the end of a range of source IP 3087 addresses (inclusive), where the start of the range is the HdrSrcAddress 3088 property value. 3090 If a value for HdrSrcAddress is not provided, then this property also 3091 MUST NOT be provided. If a value for this property is provided, then 3092 HdrSrcMask MUST NOT be provided. 3094 5.19.4. The Property HdrSrcMask 3096 This property is an OctetString, of a size determined by the value of the 3097 HdrIpVersion property, representing a mask to be used in comparing the 3098 source address in the IP header with the value represented in the 3099 HdrSrcAddress property. 3101 If a value for this property is not provided, then the filter does not 3102 consider HdrSrcMask in selecting matching packets, i.e., the value of 3103 HdrSrcAddress or the source address range must match the source address 3104 in the packet exactly. If a value for this property is provided, then 3105 HdrSrcAddressEndOfRange MUST NOT be provided. 3107 5.19.5. The Property HdrDestAddress 3109 This property is an OctetString, of a size determined by the value of the 3110 HdrIpVersion property, representing a destination IP address. When there 3111 is no HdrDestAddressEndOfRange value, this value is compared to the 3112 destination address in the IP header, subject to the mask represented in 3113 the HdrDestMask property. (Note that the mask is ANDed with the 3114 address.) When there is a HdrDestAddressEndOfRange value, this value is 3115 the start of the specified range (i.e., the HdrDestAddress is lower than 3116 the HdrDestAddressEndOfRange) that is compared to the destination address 3117 in the IP header and matches on any value in the range. 3119 If a value for this property is not provided, then the filter does not 3120 consider HdrDestAddress in selecting matching packets, i.e., 3121 HdrDestAddress matches for all values. 3123 5.19.6. The Property HdrDestAddressEndOfRange 3125 This property is an OctetString, of a size determined by the value of the 3126 HdrIpVersion property, representing the end of a range of destination IP 3127 addresses (inclusive), where the start of the range is the HdrDestAddress 3128 property value. 3130 If a value for HdrDestAddress is not provided, then this property also 3131 MUST NOT be provided. If a value for this property is provided, then 3132 HdrDestMask MUST NOT be provided. 3134 5.19.7. The Property HdrDestMask 3136 This property is an OctetString, of a size determined by the value of the 3137 HdrIpVersion property, representing a mask to be used in comparing the 3138 destination address in the IP header with the value represented in the 3139 HdrDestAddress property. 3141 If a value for this property is not provided, then the filter does not 3142 consider HdrDestMask in selecting matching packets, i.e., the value of 3143 HdrDestAddress or the destination address range must match the 3144 destination address in the packet exactly. If a value for this property 3145 is provided, then HdrDestAddressEndOfRange MUST NOT be provided. 3147 5.19.8. The Property HdrProtocolID 3149 This property is an 8-bit unsigned integer, representing an IP protocol 3150 type. This value is compared to the Protocol field in the IP header. 3152 If a value for this property is not provided, then the filter does not 3153 consider HdrProtocolID in selecting matching packets, i.e., HdrProtocolID 3154 matches for all values. 3156 5.19.9. The Property HdrSrcPortStart 3158 This property is a 16-bit unsigned integer, representing the lower end of 3159 a range of UDP or TCP source ports. The upper end of the range is 3160 represented by the HdrSrcPortEnd property. The value of HdrSrcPortStart 3161 MUST be no greater than the value of HdrSrcPortEnd. A single port is 3162 indicated by equal values for HdrSrcPortStart and HdrSrcPortEnd. 3164 A source port filter is evaluated by testing whether the source port 3165 identified in the IP header falls within the range of values between 3166 HdrSrcPortStart and HdrSrcPortEnd, including these two end points. 3168 If a value for this property is not provided, then the filter does not 3169 consider HdrSrcPortStart in selecting matching packets, i.e., there is no 3170 lower bound in matching source port values. 3172 5.19.10. The Property HdrSrcPortEnd 3174 This property is a 16-bit unsigned integer, representing the upper end of 3175 a range of UDP or TCP source ports. The lower end of the range is 3176 represented by the HdrSrcPortStart property. The value of HdrSrcPortEnd 3177 MUST be no less than the value of HdrSrcPortStart. A single port is 3178 indicated by equal values for HdrSrcPortStart and HdrSrcPortEnd. 3180 A source port filter is evaluated by testing whether the source port 3181 identified in the IP header falls within the range of values between 3182 HdrSrcPortStart and HdrSrcPortEnd, including these two end points. 3184 If a value for this property is not provided, then the filter does not 3185 consider HdrSrcPortEnd in selecting matching packets, i.e., there is no 3186 upper bound in matching source port values. 3188 5.19.11. The Property HdrDestPortStart 3190 This property is a 16-bit unsigned integer, representing the lower end of 3191 a range of UDP or TCP destination ports. The upper end of the range is 3192 represented by the HdrDestPortEnd property. The value of 3193 HdrDestPortStart MUST be no greater than the value of HdrDestPortEnd. A 3194 single port is indicated by equal values for HdrDestPortStart and 3195 HdrDestPortEnd. 3197 A destination port filter is evaluated by testing whether the destination 3198 port identified in the IP header falls within the range of values between 3199 HdrDestPortStart and HdrDestPortEnd, including these two end points. 3201 If a value for this property is not provided, then the filter does not 3202 consider HdrDestPortStart in selecting matching packets, i.e., there is 3203 no lower bound in matching destination port values. 3205 5.19.12. The Property HdrDestPortEnd 3207 This property is a 16-bit unsigned integer, representing the upper end of 3208 a range of UDP or TCP destination ports. The lower end of the range is 3209 represented by the HdrDestPortStart property. The value of 3210 HdrDestPortEnd MUST be no less than the value of HdrDestPortStart. A 3211 single port is indicated by equal values for HdrDestPortStart and 3212 HdrDestPortEnd. 3214 A destination port filter is evaluated by testing whether the destination 3215 port identified in the IP header falls within the range of values between 3216 HdrDestPortStart and HdrDestPortEnd, including these two end points. 3218 If a value for this property is not provided, then the filter does not 3219 consider HdrDestPortEnd in selecting matching packets, i.e., there is no 3220 upper bound in matching destination port values. 3222 5.19.13. The Property HdrDSCP 3224 The property HdrDSCP is defined as an array of uint8's, restricted to the 3225 range 0..63. Since DSCPs are defined as discrete code points, with no 3226 inherent structure, there is no semantically significant relationship 3227 between different DSCPs. Consequently, there is no provision for 3228 specifying a range of DSCPs in this property. However, a list of 3229 individual DSCPs, which are ORed together to form a filter, is supported 3230 by the array syntax. 3232 If a value for this property is not provided, then the filter does not 3233 consider HdrDSCP in selecting matching packets, i.e., HdrDSCP matches for 3234 all values. 3236 5.19.14. The Property HdrFlowLabel 3238 The 20-bit Flow Label field in the IPv6 header may be used by a source to 3239 label sequences of packets for which it requests special handling by IPv6 3240 devices, such as non-default quality of service or 'real-time' service. 3241 This property is an octet string of size 3 (that is, 24 bits), in which 3242 the 20-bit Flow Label appears in the rightmost 20 bits, padded on the 3243 left with b'0000'. 3245 If a value for this property is not provided, then the filter does not 3246 consider HdrFlowLabel in selecting matching packets, i.e., HdrFlowLabel 3247 matches for all values. 3249 5.20. The Class "8021Filter" 3251 This concrete class allows 802.1.source and destination MAC addresses, as 3252 well as the 802.1 protocol ID, priority, and VLAN identifier fields, to 3253 be expressed in a single object 3255 The class definition is as follows: 3257 NAME 8021Filter 3258 DESCRIPTION A class that allows 802.1 source 3259 and destination MAC address and 3260 protocol ID, priority, and VLAN 3261 identifier filters to be 3262 expressed in a single object. 3263 DERIVED FROM FilterEntryBase 3264 TYPE Concrete 3265 PROPERTIES 8021HdrSrcMACAddr, 8021HdrSrcMACMask, 3266 8021HdrDestMACAddr, 8021HdrDestMACMask, 3267 8021HdrProtocolID, 8021HdrPriorityValue, 3268 8021HDRVLANID 3270 5.20.1. The Property 8021HdrSrcMACAddr 3272 This property is an OctetString of size 6, representing a 48-bit source 3273 MAC address in canonical format. This value is compared to the 3274 SourceAddress field in the MAC header, subject to the mask represented in 3275 the 8021HdrSrcMACMask property. 3277 If a value for this property is not provided, then the filter does not 3278 consider 8021HdrSrcMACAddr in selecting matching packets, i.e., 3279 8021HdrSrcMACAddr matches for all values. 3281 5.20.2. The Property 8021HdrSrcMACMask 3283 This property is an OctetString of size 6, representing a 48-bit mask to 3284 be used in comparing the SourceAddress field in the MAC header with the 3285 value represented in the 8021HdrSrcMACAddr property. 3287 If a value for this property is not provided, then the filter does not 3288 consider 8021HdrSrcMACMask in selecting matching packets, i.e., the value 3289 of 8021HdrSrcMACAddr must match the source MAC address in the packet 3290 exactly. 3292 5.20.3. The Property 8021HdrDestMACAddr 3294 This property is an OctetString of size 6, representing a 48-bit 3295 destination MAC address in canonical format. This value is compared to 3296 the DestinationAddress field in the MAC header, subject to the mask 3297 represented in the 8021HdrDestMACMask property. 3299 If a value for this property is not provided, then the filter does not 3300 consider 8021HdrDestMACAddr in selecting matching packets, i.e., 3301 8021HdrDestMACAddr matches for all values. 3303 5.20.4. The Property 8021HdrDestMACMask 3305 This property is an OctetString of size 6, representing a 48-bit mask to 3306 be used in comparing the DestinationAddress field in the MAC header with 3307 the value represented in the 8021HdrDestMACAddr property. 3309 If a value for this property is not provided, then the filter does not 3310 consider 8021HdrDestMACMask in selecting matching packets, i.e., the 3311 value of 8021HdrDestMACAddr must match the destination MAC address in the 3312 packet exactly. 3314 5.20.5. The Property 8021HdrProtocolID 3316 This property is a 16-bit unsigned integer, representing an Ethernet 3317 protocol type. This value is compared to the Ethernet Type field in the 3318 802.3 MAC header. 3320 If a value for this property is not provided, then the filter does not 3321 consider 8021HdrProtocolID in selecting matching packets, i.e., 3322 8021HdrProtocolID matches for all values. 3324 5.20.6. The Property 8021HdrPriorityValue 3326 This property is an 8-bit unsigned integer, representing an 802.1Q 3327 priority. This value is compared to the Priority field in the 802.1Q 3328 header. Since the 802.1Q Priority field consists of 3 bits, the values 3329 for this property are limited to the range 0..7. 3331 If a value for this property is not provided, then the filter does not 3332 consider 8021HdrPriorityValue in selecting matching packets, i.e., 3333 8021HdrPriorityValue matches for all values. 3335 5.20.7. The Property 8021HdrVLANID 3337 This property is a 32-bit unsigned integer, representing an 802.1Q VLAN 3338 Identifier. This value is compared to the VLAN ID field in the 802.1Q 3339 header. Since the 802.1Q VLAN ID field consists of 12 bits, the values 3340 for this property are limited to the range 0..4095. 3342 If a value for this property is not provided, then the filter does not 3343 consider 8021HdrVLANID in selecting matching packets, i.e., 8021HdrVLANID 3344 matches for all values. 3346 5.21. The Class FilterList 3348 This is a concrete class that aggregates instances of (subclasses of) 3349 FilterEntryBase via the aggregation EntriesInFilterList. It is possible 3350 to aggregate different types of filters into a single FilterList - for 3351 example, packet header filters (represented by the IpHeadersFilter class) 3352 and security filters (represented by subclasses of FilterEntryBase 3353 defined by IPsec). 3355 The aggregation property EntriesInFilterList.EntrySequence serves to 3356 order the filter entries in a FilterList. This is necessary when 3357 algorithms such as "Match First" are used to identify traffic based on an 3358 aggregated set of FilterEntries. In modeling QoS classifiers, however, 3359 this property is always set to 0, to indicate that the aggregated filter 3360 entries are ANDed together to form a selector for a class of traffic. 3362 The class definition is as follows: 3364 NAME FilterList 3365 DESCRIPTION A concrete class representing 3366 the aggregation of multiple filters. 3367 DERIVED FROM LogicalElement 3368 TYPE Concrete 3369 PROPERTIES Direction 3371 5.21.1. The Property Direction 3373 This property is a 16-bit unsigned integer enumeration, representing the 3374 direction of the traffic flow to which the FilterList is to be applied. 3375 Defined enumeration values are 3377 o NotApplicable(0) 3378 o Input(1) 3379 o Output(2) 3380 o Both(3) - This value is used to indicate that the direction is 3381 immaterial, e.g., to filter on a source subnet regardless of 3382 whether the flow is inbound or outbound 3383 o Mirrored(4) - This value is also applicable to both inbound and 3384 outbound flow processing, but it indicates that the filter criteria 3385 are applied asymmetrically to traffic in both directions and, thus, 3386 specifies the reversal of source and destination criteria (as 3387 opposed to the equality of these criteria as indicated by "Both"). 3388 The match conditions in the aggregated FilterEntryBase subclass 3389 instances are defined from the perspective of outbound flows and 3390 applied to inbound flows as well by reversing the source and 3391 destination criteria. So, for example, consider a FilterList with 3392 3 filter entries indicating destination port = 80, and source and 3393 destination addresses of a and b, respectively. Then, for the 3394 outbound direction, the filter entries match as specified and the 3395 'mirror' (for the inbound direction) matches on source port = 80 3396 and source and destination addresses of b and a, respectively. 3398 6. Association and Aggregation Definitions 3400 The following definitions supplement those in PCIM itself. PCIM 3401 definitions that are not DEPRECATED here are still current parts of the 3402 overall Policy Core Information Model. 3404 6.1. The Aggregation "PolicySetComponent" 3406 PolicySetComponent is a new aggregation class that collects instances of 3407 PolicySet subclasses (PolicyGroups and PolicyRules) into coherent sets of 3408 policies. 3410 NAME PolicySetComponent 3411 DESCRIPTION A concrete class representing the components of a 3412 policy set that have the same decision strategy, and 3413 are prioritized within the set. 3415 DERIVED FROM PolicyComponent 3416 ABSTRACT FALSE 3417 PROPERTIES GroupComponent[ref PolicySet[0..n]] 3418 PartComponent[ref PolicySet[0..n]] 3419 Priority 3421 The definition of the Priority property is unchanged from its previous 3422 definition in [PCIM]. 3424 NAME Priority 3425 DESCRIPTION A non-negative integer for prioritizing this PolicySet 3426 component relative to other components of the same 3427 PolicySet. A larger value indicates a higher 3428 priority. 3429 SYNTAX uint16 3430 DEFAULT VALUE 0 3432 6.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup" 3434 The new aggregation PolicySetComponent is used directly to represent 3435 aggregation of PolicyGroups by a higher-level PolicyGroup. Thus the 3436 aggregation PolicyGroupInPolicyGroup is no longer needed, and can be 3437 deprecated. 3439 NAME PolicyGroupInPolicyGroup 3440 DEPRECATED FOR PolicySetComponent 3441 DESCRIPTION A class representing the aggregation of PolicyGroups 3442 by a higher-level PolicyGroup. 3443 DERIVED FROM PolicyComponent 3444 ABSTRACT FALSE 3445 PROPERTIES GroupComponent[ref PolicyGroup[0..n]] 3446 PartComponent[ref PolicyGroup[0..n]] 3448 6.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup" 3450 The new aggregation PolicySetComponent is used directly to represent 3451 aggregation of PolicyRules by a PolicyGroup. Thus the aggregation 3452 PolicyRuleInPolicyGroup is no longer needed, and can be deprecated. 3454 NAME PolicyRuleInPolicyGroup 3455 DEPRECATED FOR PolicySetComponent 3456 DESCRIPTION A class representing the aggregation of PolicyRules by 3457 a PolicyGroup. 3458 DERIVED FROM PolicyComponent 3459 ABSTRACT FALSE 3460 PROPERTIES GroupComponent[ref PolicyGroup[0..n]] 3461 PartComponent[ref PolicyRule[0..n]] 3462 6.4. The Abstract Association "PolicySetInSystem" 3464 PolicySetInSystem is a new association that defines a relationship 3465 between a System and a PolicySet used in the administrative scope of that 3466 system (e.g., AdminDomain, ComputerSystem). The Priority property is 3467 used to assign a relative priority to a PolicySet within the 3468 administrative scope in contexts where it is not a component of another 3469 PolicySet. 3471 NAME PolicySetInSystem 3472 DESCRIPTION An abstract class representing the relationship 3473 between a System and a PolicySet that is used in the 3474 administrative scope of the System. 3475 DERIVED FROM PolicyInSystem 3476 ABSTRACT TRUE 3477 PROPERTIES Antecedent[ref System[0..1]] 3478 Dependent [ref PolicySet[0..n]] 3479 Priority 3481 The Priority property is used to specify the relative priority of the 3482 referenced PolicySet when there are more than one PolicySet instances 3483 applied to a managed resource that are not PolicySetComponents and, 3484 therefore, have no other relative priority defined. 3486 NAME Priority 3487 DESCRIPTION A non-negative integer for prioritizing the referenced 3488 PolicySet among other PolicySet instances that are not 3489 components of a common PolicySet. A larger value 3490 indicates a higher priority. 3491 SYNTAX uint16 3492 DEFAULT VALUE 0 3494 6.5. Update PCIM's Weak Association "PolicyGroupInSystem" 3496 Regardless of whether it a component of another PolicySet, a PolicyGroup 3497 is itself defined within the scope of a System. This association links a 3498 PolicyGroup to the System in whose scope the PolicyGroup is defined. It 3499 is a subclass of the abstract PolicySetInSystem association. The class 3500 definition for the association is as follows: 3502 NAME PolicyGroupInSystem 3503 DESCRIPTION A class representing the fact that a PolicyGroup is 3504 defined within the scope of a System. 3505 DERIVED FROM PolicySetInSystem 3506 ABSTRACT FALSE 3507 PROPERTIES Antecedent[ref System[1..1]] 3508 Dependent [ref PolicyGroup[weak]] 3510 The Reference "Antecedent" is inherited from PolicySetInSystem, and 3511 overridden to restrict its cardinality to [1..1]. It serves as an object 3512 reference to a System that provides a scope for one or more PolicyGroups. 3514 Since this is a weak association, the cardinality for this object 3515 reference is always 1, that is, a PolicyGroup is always defined within 3516 the scope of exactly one System. 3518 The Reference "Dependent" is inherited from PolicySetInSystem, and 3519 overridden to become an object reference to a PolicyGroup defined within 3520 the scope of a System. Note that for any single instance of the 3521 association class PolicyGroupInSystem, this property (like all reference 3522 properties) is single-valued. The [0..n] cardinality indicates that a 3523 given System may have 0, 1, or more than one PolicyGroups defined within 3524 its scope. 3526 6.6. Update PCIM's Weak Association "PolicyRuleInSystem" 3528 Regardless of whether it a component of another PolicySet, a PolicyRule 3529 is itself defined within the scope of a System. This association links a 3530 PolicyRule to the System in whose scope the PolicyRule is defined. It is 3531 a subclass of the abstract PolicySetInSystem association. The class 3532 definition for the association is as follows: 3534 NAME PolicyRuleInSystem 3535 DESCRIPTION A class representing the fact that a PolicyRule is 3536 defined within the scope of a System. 3537 DERIVED FROM PolicySetInSystem 3538 ABSTRACT FALSE 3539 PROPERTIES Antecedent[ref System[1..1]] 3540 Dependent[ref PolicyRule[weak]] 3542 The Reference "Antecedent" is inherited from PolicySetInSystem, and 3543 overridden to restrict its cardinality to [1..1]. It serves as an object 3544 reference to a System that provides a scope for one or more PolicyRules. 3545 Since this is a weak association, the cardinality for this object 3546 reference is always 1, that is, a PolicyRule is always defined within the 3547 scope of exactly one System. 3549 The Reference "Dependent" is inherited from PolicySetInSystem, and 3550 overridden to become an object reference to a PolicyRule defined within 3551 the scope of a System. Note that for any single instance of the 3552 association class PolicyRuleInSystem, this property (like all Reference 3553 properties) is single-valued. The [0..n] cardinality indicates that a 3554 given System may have 0, 1, or more than one PolicyRules defined within 3555 its scope. 3557 6.7. The Abstract Aggregation "PolicyConditionStructure" 3559 NAME PolicyConditionStructure 3560 DESCRIPTION A class representing the aggregation of 3561 PolicyConditions by an aggregating instance. 3562 DERIVED FROM PolicyComponent 3563 ABSTRACT TRUE 3564 PROPERTIES PartComponent[ref PolicyCondition[0..n]] 3565 GroupNumber 3566 ConditionNegated 3568 6.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule" 3570 The PCIM aggregation "PolicyConditionInPolicyRule" is updated, to make it 3571 a subclass of the new abstract aggregation PolicyConditionStructure. The 3572 properties GroupNumber and ConditionNegated are now inherited, rather 3573 than specified explicitly as they were in PCIM. 3575 NAME PolicyConditionInPolicyRule 3576 DESCRIPTION A class representing the aggregation of 3577 PolicyConditions by a PolicyRule. 3578 DERIVED FROM PolicyConditionStructure 3579 ABSTRACT FALSE 3580 PROPERTIES GroupComponent[ref PolicyRule[0..n]] 3582 6.9. The Aggregation "PolicyConditionInPolicyCondition" 3584 A second subclass of PolicyConditionStructure is defined, representing 3585 the compounding of policy conditions into a higher-level policy 3586 condition. 3588 NAME PolicyConditionInPolicyCondition 3589 DESCRIPTION A class representing the aggregation of 3590 PolicyConditions by another PolicyCondition. 3591 DERIVED FROM PolicyConditionStructure 3592 ABSTRACT FALSE 3593 PROPERTIES GroupComponent[ref CompoundPolicyCondition[0..n]] 3595 6.10. The Abstract Aggregation "PolicyActionStructure" 3597 NAME PolicyActionStructure 3598 DESCRIPTION A class representing the aggregation of PolicyActions 3599 by an aggregating instance. 3600 DERIVED FROM PolicyComponent 3601 ABSTRACT TRUE 3602 PROPERTIES PartComponent[ref PolicyAction[0..n]] 3603 ActionOrder 3605 The definition of the ActionOrder property appears in Section 7.8.3 of 3606 PCIM [3]. 3608 6.11. Update PCIM's Aggregation "PolicyActionInPolicyRule" 3610 The PCIM aggregation "PolicyActionInPolicyRule" is updated, to make it a 3611 subclass of the new abstract aggregation PolicyActionStructure. The 3612 property ActionOrder is now inherited, rather than specified explicitly 3613 as it was in PCIM. 3615 NAME PolicyActionInPolicyRule 3616 DESCRIPTION A class representing the aggregation of PolicyActions 3617 by a PolicyRule. 3618 DERIVED FROM PolicyActionStructure 3619 ABSTRACT FALSE 3620 PROPERTIES GroupComponent[ref PolicyRule[0..n]] 3622 6.12. The Aggregation "PolicyActionInPolicyAction" 3624 A second subclass of PolicyActionStructure is defined, representing the 3625 compounding of policy actions into a higher-level policy action. 3627 NAME PolicyActionInPolicyAction 3628 DESCRIPTION A class representing the aggregation of PolicyActions 3629 by another PolicyAction. 3630 DERIVED FROM PolicyActionStructure 3631 ABSTRACT FALSE 3632 PROPERTIES GroupComponent[ref CompoundPolicyAction[0..n]] 3634 6.13. The Aggregation "PolicyVariableInSimplePolicyCondition" 3636 A simple policy condition is represented as an ordered triplet {variable, 3637 operator, value}. This aggregation provides the linkage between a 3638 SimplePolicyCondition instance and a single PolicyVariable. The 3639 aggregation PolicyValueInSimplePolicyCondition links the 3640 SimplePolicyCondition to a single PolicyValue. The Operator property of 3641 SimplePolicyCondition represents the third element of the triplet, the 3642 operator. 3644 The class definition for this aggregation is as follows: 3646 NAME PolicyVariableInSimplePolicyCondition 3647 DERIVED FROM PolicyComponent 3648 ABSTRACT False 3649 PROPERTIES GroupComponent[ref SimplePolicyCondition[0..n]] 3650 PartComponent[ref PolicyVariable[1..1] ] 3652 The reference property "GroupComponent" is inherited from 3653 PolicyComponent, and overridden to become an object reference to a 3654 SimplePolicyCondition that contains exactly one PolicyVariable. Note 3655 that for any single instance of the aggregation class 3656 PolicyVariableInSimplePolicyCondition, this property is single-valued. 3657 The [0..n] cardinality indicates that there may be 0, 1, or more 3658 SimplePolicyCondition objects that contain any given policy variable 3659 object. 3661 The reference property "PartComponent" is inherited from PolicyComponent, 3662 and overridden to become an object reference to a PolicyVariable that is 3663 defined within the scope of a SimplePolicyCondition. Note that for any 3664 single instance of the association class 3665 PolicyVariableInSimplePolicyCondition, this property (like all reference 3666 properties) is single-valued. The [1..1] cardinality indicates that a 3667 SimplePolicyCondition must have exactly one policy variable defined 3668 within its scope in order to be meaningful. 3670 6.14. The Aggregation "PolicyValueInSimplePolicyCondition" 3672 A simple policy condition is represented as an ordered triplet {variable, 3673 operator, value}. This aggregation provides the linkage between a 3674 SimplePolicyCondition instance and a single PolicyValue. The aggregation 3675 PolicyVariableInSimplePolicyCondition links the SimplePolicyCondition to 3676 a single PolicyVariable. The Operator property of SimplePolicyCondition 3677 represents the third element of the triplet, the operator. 3679 The class definition for this aggregation is as follows: 3681 NAME PolicyValueInSimplePolicyCondition 3682 DERIVED FROM PolicyComponent 3683 ABSTRACT False 3684 PROPERTIES GroupComponent[ref SimplePolicyCondition[0..n]] 3685 PartComponent[ref PolicyValue[1..1] ] 3687 The reference property "GroupComponent" is inherited from 3688 PolicyComponent, and overridden to become an object reference to a 3689 SimplePolicyCondition that contains exactly one PolicyValue. Note that 3690 for any single instance of the aggregation class 3691 PolicyValueInSimplePolicyCondition, this property is single-valued. The 3692 [0..n] cardinality indicates that there may be 0, 1, or more 3693 SimplePolicyCondition objects that contain any given policy value object. 3695 The reference property "PartComponent" is inherited from PolicyComponent, 3696 and overridden to become an object reference to a PolicyValue that is 3697 defined within the scope of a SimplePolicyCondition. Note that for any 3698 single instance of the association class 3699 PolicyValueInSimplePolicyCondition, this property (like all reference 3700 properties) is single-valued. The [1..1] cardinality indicates that a 3701 SimplePolicyCondition must have exactly one policy value defined within 3702 its scope in order to be meaningful. 3704 6.15. The Aggregation "PolicyVariableInSimplePolicyAction" 3706 A simple policy action is represented as a pair {variable, value}. This 3707 aggregation provides the linkage between a SimplePolicyAction instance 3708 and a single PolicyVariable. The aggregation 3709 PolicyValueInSimplePolicyAction links the SimplePolicyAction to a single 3710 PolicyValue. 3712 The class definition for this aggregation is as follows: 3714 NAME PolicyVariableInSimplePolicyAction 3715 DERIVED FROM PolicyComponent 3716 ABSTRACT False 3717 PROPERTIES GroupComponent[ref SimplePolicyAction[0..n]] 3718 PartComponent[ref PolicyVariable[1..1] ] 3720 The reference property "GroupComponent" is inherited from 3721 PolicyComponent, and overridden to become an object reference to a 3722 SimplePolicyAction that contains exactly one PolicyVariable. Note that 3723 for any single instance of the aggregation class 3724 PolicyVariableInSimplePolicyAction, this property is single-valued. The 3725 [0..n] cardinality indicates that there may be 0, 1, or more 3726 SimplePolicyAction objects that contain any given policy variable object. 3728 The reference property "PartComponent" is inherited from PolicyComponent, 3729 and overridden to become an object reference to a PolicyVariable that is 3730 defined within the scope of a SimplePolicyAction. Note that for any 3731 single instance of the association class 3732 PolicyVariableInSimplePolicyAction, this property (like all reference 3733 properties) is single-valued. The [1..1] cardinality indicates that a 3734 SimplePolicyAction must have exactly one policy variable defined within 3735 its scope in order to be meaningful. 3737 6.16. The Aggregation "PolicyValueInSimplePolicyAction" 3739 A simple policy action is represented as a pair {variable, value}. This 3740 aggregation provides the linkage between a SimplePolicyAction instance 3741 and a single PolicyValue. The aggregation 3742 PolicyVariableInSimplePolicyAction links the SimplePolicyAction to a 3743 single PolicyVariable. 3745 The class definition for this aggregation is as follows: 3747 NAME PolicyValueInSimplePolicyAction 3748 DERIVED FROM PolicyComponent 3749 ABSTRACT False 3750 PROPERTIES GroupComponent[ref SimplePolicyAction[0..n]] 3751 PartComponent[ref PolicyValue[1..1] ] 3753 The reference property "GroupComponent" is inherited from 3754 PolicyComponent, and overridden to become an object reference to a 3755 SimplePolicyAction that contains exactly one PolicyValue. Note that for 3756 any single instance of the aggregation class 3757 PolicyValueInSimplePolicyAction, this property is single-valued. The 3758 [0..n] cardinality indicates that there may be 0, 1, or more 3759 SimplePolicyAction objects that contain any given policy value object. 3761 The reference property "PartComponent" is inherited from PolicyComponent, 3762 and overridden to become an object reference to a PolicyValue that is 3763 defined within the scope of a SimplePolicyAction. Note that for any 3764 single instance of the association class PolicyValueInSimplePolicyAction, 3765 this property (like all reference properties) is single-valued. The 3766 [1..1] cardinality indicates that a SimplePolicyAction must have exactly 3767 one policy value defined within its scope in order to be meaningful. 3769 6.17. The Association "ReusablePolicy" 3771 The association ReusablePolicy makes it possible to include any subclass 3772 of the abstract class "Policy" in a ReusablePolicyContainer. 3774 NAME ReusablePolicy 3775 DESCRIPTION A class representing the inclusion of a reusable 3776 policy element in a ReusablePolicyContainer. Reusable 3777 elements may be PolicyGroups, PolicyRules, 3778 PolicyConditions, PolicyActions, PolicyVariables, 3779 PolicyValues, or instances of any other subclasses of 3780 the abstract class Policy. 3781 DERIVED FROM PolicyInSystem 3782 ABSTRACT FALSE 3783 PROPERTIES Antecedent[ref ReusablePolicyContainer[0..1]] 3785 6.18. Deprecate PCIM's "PolicyConditionInPolicyRepository" 3787 NAME PolicyConditionInPolicyRepository 3788 DEPRECATED FOR ReusablePolicy 3789 DESCRIPTION A class representing the inclusion of a reusable 3790 PolicyCondition in a PolicyRepository. 3791 DERIVED FROM PolicyInSystem 3792 ABSTRACT FALSE 3793 PROPERTIES Antecedent[ref PolicyRepository[0..1]] 3794 Dependent[ref PolicyCondition[0..n]] 3796 6.19. Deprecate PCIM's "PolicyActionInPolicyRepository" 3798 NAME PolicyActionInPolicyRepository 3799 DEPRECATED FOR ReusablePolicy 3800 DESCRIPTION A class representing the inclusion of a reusable 3801 PolicyAction in a PolicyRepository. 3802 DERIVED FROM PolicyInSystem 3803 ABSTRACT FALSE 3804 PROPERTIES Antecedent[ref PolicyRepository[0..1]] 3805 Dependent[ref PolicyAction[0..n]] 3807 6.20. The Association ExpectedPolicyValuesForVariable 3809 This association links a PolicyValue object to a PolicyVariable object, 3810 modeling the set of expected values for that PolicyVariable. Using this 3811 association, a variable (instance) may be constrained to be bound- 3812 to/assigned only a set of allowed values. For example, modeling an 3813 enumerated source port variable, one creates an instance of the 3814 PolicySourcePortVariable class and associates with it the set of values 3815 (integers) representing the allowed enumeration, using appropriate number 3816 of instances of the ExpectedPolicyValuesForVariable association. 3818 Note that a single variable instance may be constrained by any number of 3819 values, and a single value may be used to constrain any number of 3820 variables. These relationships are manifested by the n-to-m cardinality 3821 of the association. 3823 The purpose of this association is to support validation of simple policy 3824 conditions and simple policy actions, prior to their deployment to an 3825 enforcement point. This association, and the PolicyValue object that it 3826 refers to, plays no role when a PDP or a PEP is evaluating a simple 3827 policy condition, or executing a simple policy action. See Section 4.8.3 3828 for more details on this point. 3830 The class definition for the association is as follows: 3832 NAME ExpectedPolicyValuesForVariable 3833 DESCRIPTION A class representing the association of a set of 3834 expected values to a variable object. 3835 DERIVED FROM Dependency 3836 ABSTRACT FALSE 3837 PROPERTIES Antecedent [ref PolicyVariable[0..n]] 3838 Dependent [ref PolicyValue [0..n]] 3840 The reference property Antecedent is inherited from Dependency. Its type 3841 and cardinality are overridden to provide the semantics of a variable 3842 optionally having value constraints. The [0..n] cardinality indicates 3843 that any number of variables may be constrained by a given value. 3845 The reference property "Dependent" is inherited from Dependency, and 3846 overridden to become an object reference to a PolicyValue representing 3847 the values that a particular PolicyVariable can have. The [0..n] 3848 cardinality indicates that a given policy variable may have 0, 1 or more 3849 than one PolicyValues defined to model the set(s) of values that the 3850 policy variable can take. 3852 6.21. The Aggregation "ContainedDomain" 3854 The aggregation ContainedDomain provides a means of nesting of one 3855 ReusablePolicyContainer inside another one. The aggregation is defined 3856 at the level of ReusablePolicyContainer's superclass, AdminDomain, to 3857 give it applicability to areas other than Core Policy. 3859 NAME ContainedDomain 3860 DESCRIPTION A class representing the aggregation of lower level 3861 administrative domains by a higher-level AdminDomain. 3862 DERIVED FROM SystemComponent 3863 ABSTRACT FALSE 3864 PROPERTIES GroupComponent[ref AdminDomain [0..n]] 3865 PartComponent[ref AdminDomain [0..n]] 3867 6.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository" 3869 NAME PolicyRepositoryInPolicyRepository 3870 DEPRECATED FOR ContainedDomain 3871 DESCRIPTION A class representing the aggregation of 3872 PolicyRepositories by a higher-level PolicyRepository. 3873 DERIVED FROM SystemComponent 3874 ABSTRACT FALSE 3875 PROPERTIES GroupComponent[ref PolicyRepository[0..n]] 3876 PartComponent[ref PolicyRepository[0..n]] 3878 6.23. The Aggregation "EntriesInFilterList" 3880 This aggregation is a specialization of the Component aggregation; it is 3881 used to define a set of filter entries (subclasses of FilterEntryBase) 3882 that are aggregated by a FilterList. 3884 The cardinalities of the aggregation itself are 0..1 on the FilterList 3885 end, and 0..n on the FilterEntryBase end. Thus in the general case, a 3886 filter entry can exist without being aggregated into any FilterList. 3887 However, the only way a filter entry can figure in the PCIMe model is by 3888 being aggregated into a FilterList by this aggregation. 3890 The class definition for the aggregation is as follows: 3892 NAME EntriesInFilterList 3893 DESCRIPTION An aggregation used to define a set of 3894 filter entries (subclasses of 3895 FilterEntryBase) that are aggregated by 3896 a particular FilterList. 3897 DERIVED FROM Component 3898 ABSTRACT False 3899 PROPERTIES GroupComponent[ref 3900 FilterList[0..1]], 3901 PartComponent[ref 3902 FilterEntryBase[0..n], 3903 EntrySequence 3905 6.23.1. The Reference GroupComponent 3907 This property is overridden in this aggregation to represent an object 3908 reference to a FilterList object (instead of to the more generic 3909 ManagedSystemElement object defined in its superclass). It also 3910 restricts the cardinality of the aggregate to 0..1 (instead of the more 3911 generic 0-or-more), representing the fact that a filter entry always 3912 exists within the context of at most one FilterList. 3914 6.23.2. The Reference PartComponent 3916 This property is overridden in this aggregation to represent an object 3917 reference to a FilterEntryBase object (instead of to the more generic 3918 ManagedSystemElement object defined in its superclass). This object 3919 represents a single filter entry, which may be aggregated with other 3920 filter entries to form the FilterList. 3922 6.23.3. The Property EntrySequence 3924 An unsigned 16-bit integer indicating the order of the filter entry 3925 relative to all others in the FilterList. The default value '0' 3926 indicates that order is not significant, because the entries in this 3927 FilterList are ANDed together. 3929 6.24. The Aggregation "ElementInPolicyRoleCollection" 3931 The following aggregation is used to associate ManagedElements with a 3932 PolicyRoleCollection object that represents a role played by these 3933 ManagedElements. 3935 NAME ElementInPolicyRoleCollection 3936 DESCRIPTION A class representing the inclusion of a ManagedElement 3937 in a collection, specified as having a given role. 3938 All the managed elements in the collection share the 3939 same role. 3940 DERIVED FROM MemberOfCollection 3941 ABSTRACT FALSE 3942 PROPERTIES Collection[ref PolicyRoleCollection [0..n]] 3943 Member[ref ManagedElement [0..n]] 3945 6.25. The Weak Association "PolicyRoleCollectionInSystem" 3947 A PolicyRoleCollection is defined within the scope of a System. This 3948 association links a PolicyRoleCollection to the System in whose scope it 3949 is defined. 3951 When associating a PolicyRoleCollection with a System, this should be 3952 done consistently with the system that scopes the policy rules/groups 3953 that are applied to the resources in that collection. A 3954 PolicyRoleCollection is associated with the same system as the applicable 3955 PolicyRules and/or PolicyGroups, or to a System higher in the tree formed 3956 by the SystemComponent association. 3958 The class definition for the association is as follows: 3960 NAME PolicyRoleCollectionInSystem 3961 DESCRIPTION A class representing the fact that a 3962 PolicyRoleCollection is defined within the scope of a 3963 System. 3964 DERIVED FROM Dependency 3965 ABSTRACT FALSE 3966 PROPERTIES Antecedent[ref System[1..1]] 3967 Dependent[ref PolicyRoleCollection[weak]] 3969 The reference property Antecedent is inherited from Dependency, and 3970 overridden to become an object reference to a System, and to restrict its 3971 cardinality to [1..1]. It serves as an object reference to a System that 3972 provides a scope for one or more PolicyRoleCollections. Since this is a 3973 weak association, the cardinality for this object reference is always 1, 3974 that is, a PolicyRoleCollection is always defined within the scope of 3975 exactly one System. 3977 The reference property Dependent is inherited from Dependency, and 3978 overridden to become an object reference to a PolicyRoleCollection 3979 defined within the scope of a System. Note that for any single instance 3980 of the association class PolicyRoleCollectionInSystem, this property 3981 (like all Reference properties) is single-valued. The [0..n] cardinality 3982 indicates that a given System may have 0, 1, or more than one 3983 PolicyRoleCollections defined within its scope. 3985 7. Intellectual Property 3987 The IETF takes no position regarding the validity or scope of any 3988 intellectual property or other rights that might be claimed to pertain to 3989 the implementation or use of the technology described in this document or 3990 the extent to which any license under such rights might or might not be 3991 available; neither does it represent that it has made any effort to 3992 identify any such rights. Information on the IETF's procedures with 3993 respect to rights in standards-track and standards-related documentation 3994 can be found in BCP-11. 3996 Copies of claims of rights made available for publication and any 3997 assurances of licenses to be made available, or the result of an attempt 3998 made to obtain a general license or permission for the use of such 3999 proprietary rights by implementers or users of this specification can be 4000 obtained from the IETF Secretariat. 4002 The IETF invites any interested party to bring to its attention any 4003 copyrights, patents or patent applications, or other proprietary rights 4004 which may cover technology that may be required to practice this 4005 standard. Please address the information to the IETF Executive Director. 4007 8. Acknowledgements 4009 The starting point for this document was PCIM itself [3], and the first 4010 three submodels derived from it [5], [6], [7]. The authors of these 4011 documents created the extensions to PCIM, and asked the questions about 4012 PCIM, that are reflected in PCIMe. 4014 9. Security Considerations 4016 The Policy Core Information Model (PCIM) [3] describes the general 4017 security considerations related to the general core policy model. The 4018 extensions defined in this document do not introduce any additional 4019 considerations related to security. 4021 10. References 4023 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4024 Levels", BCP 14, RFC 2119, March 1997. 4026 [2] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF 4027 Standards Process", BCP 11, RFC 2028, October 1996. 4029 [3] Strassner, J., and E. Ellesson, B. Moore, A. Westerinen, "Policy Core 4030 Information Model -- Version 1 Specification", RFC 3060, February 4031 2001. 4033 [4] Distributed Management Task Force, Inc., "DMTF Technologies: CIM 4034 Standards � CIM Schema: Version 2.5", available at 4035 http://www.dmtf.org/standards/cim_schema_v25.php. 4037 [5] Snir, Y., and Y. Ramberg, J. Strassner, R. Cohen, "Policy QoS 4038 Information Model", work in progress, draft-ietf-policy-qos-info- 4039 model-04.txt, November 2001. 4041 [6] Jason, J., and L. Rafalow, E. Vyncke, "IPsec Configuration Policy 4042 Model", work in progress, draft-ietf-ipsp-config-policy-model-04.txt, 4043 November 2001. 4045 [7] Chadha, R., and M. Brunner, M. Yoshida, J. Quittek, G. Mykoniatis, A. 4046 Poylisher, R. Vaidyanathan, A. Kind, F. Reichmeyer, "Policy Framework 4047 MPLS Information Model for QoS and TE", work in progress, draft- 4048 chadha-policy-mpls-te-01.txt, December 2000. 4050 [8] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: 4051 ABNF", RFC 2234, November 1997. 4053 [9] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC 4054 1035, November 1987. 4056 [10] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC 4057 2373, July 1998. 4059 [11] M. Wahl, A. Coulbeck, "Lightweight Directory Access Protocol (v3): 4060 Attribute Syntax Definitions", RFC 2252, December 1997. 4062 [12] A. Westerinen, et al., "Terminology for Policy-Based Management", RFC 4063 3198, November 2001. 4065 [13] S. Waldbusser, and J. Saperia, T. Hongal, "Policy Based Management 4066 MIB", work in progress, , November 4067 2001. 4069 [14] B. Moore, and D. Durham, J. Halpern, J. Strassner, A. Westerinen, W. 4070 Weiss, "Information Model for Describing Network Device QoS Datapath 4071 Mechanisms", work in progress, , March 2002. 4074 11. Authors' Addresses 4076 Bob Moore 4077 IBM Corporation, BRQA/501 4078 4205 S. Miami Blvd. 4079 Research Triangle Park, NC 27709 4080 Phone: +1 919-254-4436 4081 Fax: +1 919-254-6243 4082 E-mail: remoore@us.ibm.com 4084 Lee Rafalow 4085 IBM Corporation, BRQA/501 4086 4205 S. Miami Blvd. 4087 Research Triangle Park, NC 27709 4088 Phone: +1 919-254-4455 4089 Fax: +1 919-254-6243 4090 E-mail: rafalow@us.ibm.com 4092 Yoram Ramberg 4093 Cisco Systems 4094 4 Maskit Street 4095 Herzliya Pituach, Israel 46766 4096 Phone: +972-9-970-0081 4097 Fax: +972-9-970-0219 4098 E-mail: yramberg@cisco.com 4100 Yoram Snir 4101 Cisco Systems 4102 4 Maskit Street 4103 Herzliya Pituach, Israel 46766 4104 Phone: +972-9-970-0085 4105 Fax: +972-9-970-0366 4106 E-mail: ysnir@cisco.com 4108 Andrea Westerinen 4109 Cisco Systems 4110 Building 20 4111 725 Alder Drive 4112 Milpitas, CA 95035 4113 Phone: +1-408-853-8294 4114 Fax: +1-408-527-6351 4115 E-mail: andreaw@cisco.com 4117 Ritu Chadha 4118 Telcordia Technologies 4119 MCC 1J-218R 4120 445 South Street 4121 Morristown NJ 07960. 4122 Phone: +1-973-829-4869 4123 Fax: +1-973-829-5889 4124 E-mail: chadha@research.telcordia.com 4125 Marcus Brunner 4126 NEC Europe Ltd. 4127 C&C Research Laboratories 4128 Adenauerplatz 6 4129 D-69115 Heidelberg, Germany 4130 Phone: +49 (0)6221 9051129 4131 Fax: +49 (0)6221 9051155 4132 E-mail: brunner@ccrle.nec.de 4134 Ron Cohen 4135 Ntear LLC 4136 Phone: 4137 Fax: 4138 E-mail: ronc@ntear.com 4140 John Strassner 4141 INTELLIDEN, Inc. 4142 90 South Cascade Avenue 4143 Colorado Springs, CO 80903 4144 Phone: +1-719-785-0648 4145 E-mail: john.strassner@intelliden.com 4147 12. Full Copyright Statement 4149 Copyright (C) The Internet Society (2002). All Rights Reserved. 4151 This document and translations of it may be copied and furnished to 4152 others, and derivative works that comment on or otherwise explain it or 4153 assist in its implementation may be prepared, copied, published and 4154 distributed, in whole or in part, without restriction of any kind, 4155 provided that the above copyright notice and this paragraph are included 4156 on all such copies and derivative works. However, this document itself 4157 may not be modified in any way, such as by removing the copyright notice 4158 or references to the Internet Society or other Internet organizations, 4159 except as needed for the purpose of developing Internet standards in 4160 which case the procedures for copyrights defined in the Internet 4161 Standards process must be followed, or as required to translate it into 4162 languages other than English. 4164 The limited permissions granted above are perpetual and will not be 4165 revoked by the Internet Society or its successors or assigns. 4167 This document and the information contained herein is provided on an "AS 4168 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 4169 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 4170 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 4171 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 4172 FITNESS FOR A PARTICULAR PURPOSE. 4174 13. Appendix A: Closed Issues 4176 EDITOR'S NOTE: The following list captures the major technical issues 4177 that were resolved during the course of progressing PCIMe from initial 4178 draft to Proposed Standard. This appendix will be removed for submission 4179 to the RFC Editor (unless there is a consensus to preserve it in the 4180 RFC), but it should be archived somewhere. 4182 1. Unrestricted use of DNF/CNF for CompoundPolicyConditions. 4183 Alternative: for the conditions aggregated by a 4184 CompoundPolicyCondition, allow only ANDing, with negation of 4185 individual conditions. Note that this is sufficient to build 4186 multi-field packet filters from single-field 4187 SimplePolicyConditions. 4189 RESOLUTION: The same DNF/CNF capabilities present for aggregating 4190 PolicyConditions into a PolicyRule have been retained for 4191 aggregating PolicyConditions into a CompoundPolicyCondition. 4193 2. For a PolicyVariable in a SimplePolicyCondition, restrict the set 4194 of possible values both via associated PolicyValue objects (tied 4195 in with the ExpectedPolicyValuesForVariable association) and via 4196 the ValueTypes property in the PolicyVariable class. Alternative: 4197 restrict values only via associated PolicyValue objects. 4199 RESOLUTION: PCIMe continues to allow both mechanisms for 4200 restricting the values of a PolicyVariable. 4202 3. Transactional semantics, including rollback, for the 4203 ExecutionStrategy property in PolicyRule and in 4204 CompoundPolicyAction. Alternative: have only 'Do until success' 4205 and 'Do all'. 4207 RESOLUTION: No transactional semantics for action execution. The 4208 value 'Mandatory Do All(1)' has been removed from the two 4209 ExecutionStrategy properties. 4211 4. Stating that CompoundFilterConditions are the preferred way to do 4212 packet filtering in a PolicyCondition. Alternative: make 4213 CompoundFilterConditions and FilterEntries available to submodels, 4214 with no stated (or implied) preference. 4216 RESOLUTION: Recommendations for use of CompoundFilterConditions 4217 and FilterEntries are retained, but they have been recast 4218 slightly. CompoundFilterConditions are now positioned as the 4219 recommended approach for domain-level models. FilterEntries are 4220 the recommended approach for device-level models. 4222 5. Prohibiting equal values for Priority within a PolicySet. 4223 Alternative: allow equal values, with resulting indeterminacy in 4224 PEP behavior. 4226 RESOLUTION: PCIMe will continue to prohibit equal Priority values. 4228 6. Modeling a SimplePolicyAction with just a related PolicyVariable 4229 and PolicyValue -- the "set" or "apply" operation is implicit. 4230 Alternative: include an Operation property in SimplePolicyAction, 4231 similar to the Operation property in SimplePolicyCondition. 4233 RESOLUTION: This issue has been resolved by a change in the 4234 opposite direction. The operations are now implicit for BOTH 4235 SimplePolicyCondition and SimplePolicyAction. See Sections 4.8.3 4236 and 4.8.4, respectively, for discussions of 4237 SimplePolicyCondition's implicit MATCH operator and 4238 SimplePolicyAction's implicit SET operator. 4240 7. Representation of PolicyValues: should values like IPv4 addresses 4241 be represented only as strings (as in LDAP), or natively (e.g., an 4242 IPv4 address would be a four-octet field) with mappings to other 4243 representations such as strings? 4245 RESOLUTION: Mappings have been eliminated. Each value type has a 4246 single representation specified for it. 4248 8. The nesting of rules and groups within rules introduces 4249 significant change and complexity in the model. This nesting 4250 introduces program state (procedural language) into the model 4251 (heretofore a declarative model) as well as implicit hierarchical 4252 contexts on which the rules operate. These require a much more 4253 sophisticated rule-evaluation engine than in the past. 4255 Alternative: Maintain the declarative model, by prohibiting 4256 program state in rule evaluation (i.e., no rules within rules). 4258 RESOLUTION: Nesting of rules and groups within rules has been 4259 retained, but with a significant new limitation: actions 4260 associated with a rule do not have side effects that would impact 4261 condition evaluation for subsequent rules. "Subsequent rules" 4262 here includes both rules nested within the rule whose actions are 4263 under discussion, and rules at the same nesting level as this rule 4264 that are evaluated after it. Note that it has been a feature of 4265 PCIM (RFC 3060) all along that condition evaluation has no side 4266 effects that would influence condition evaluation for subsequent 4267 rules. 4269 There is also one modeling detail associated with nesting that has 4270 been changed. Rather than having separate aggregations 4271 (PolicyGroupInPolicyGroup, etc.) for each of the four nesting 4272 varieties, the single aggregation PolicySetComponent is now used 4273 as a concrete aggregation class. 4275 9. Need to specify a join algorithm for disjoint rule sets. 4277 RESOLUTION: PCIMe now states that for different functional domains 4278 (e.g., QoS and IKE), there is no join algorithm. Each domain, in 4279 effect, has its own rule engine, which operates independently of 4280 the other domains' engine(s). Within a functional domain, 4281 disjoint PolicySets are joined by the Priority property in the 4282 PolicySetInSystem association. In this case the decision strategy 4283 is specified to be FirstMatching. 4285 10. Clarify PolicyImplicitVariables. 4287 RESOLUTION: Each subclass of PolicyImplicitVariable will identify 4288 the exact source of the variable data. For example, there will be 4289 a subclass of PolicyImplicitVariable that specifically identifies 4290 the IPv4 source address in the outermost packet header. IPv4 and 4291 IPv6 addresses will require separate subclasses of 4292 PolicyImplicitVariable. We understand the downside of this 4293 approach: a potential explosion in the number of subclasses of 4294 PolicyImplicitVariable. 4296 11. Clarify PolicyExplicitVariables. 4298 NON-RESOLUTION (in PCIMe-01): This issue is still not resolved at 4299 all. The authors continue to believe that we need the capability 4300 of indicating that a condition should compare against (or an 4301 action should set) a particular property in a particular object 4302 instance. But we do not believe that the current mechanism of 4303 specifying a target object class and property name is sufficient. 4304 For the next version of PCIMe, we need to either find a way to 4305 make this work in general; or find a way to make it work in some 4306 cases, and then describe clearly what these cases are; or remove 4307 PolicyExplicitVariables from PCIMe entirely. 4309 RESOLUTION (in PCIMe-02): From the list of choices above, we took 4310 the path of making explicit variables work in a specific case, and 4311 indicating clearly that they work only in this case. See section 4312 4.8.6