draft-ietf-policy-pcim-ext-08.txt   rfc3460.txt 
Policy Framework Working Group B. Moore, Editor Network Working Group B. Moore, Ed.
INTERNET-DRAFT IBM Request for Comments: 3460 IBM
Updates: RFC 3060 May, 2002 Updates: 3060 January 2003
Category: Standards Track Category: Standards Track
Policy Core Information Model Extensions
<draft-ietf-policy-pcim-ext-08.txt>
Tuesday, May 28, 2002, 8:03 AM
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and Policy Core Information Model (PCIM) Extensions
may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to
cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Status of this Memo
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document specifies a number of changes to the Policy Core This document specifies a number of changes to the Policy Core
Information Model (PCIM, RFC 3060). Two types of changes are included. Information Model (PCIM, RFC 3060). Two types of changes are
First, several completely new elements are introduced, for example, included. First, several completely new elements are introduced, for
classes for header filtering, that extend PCIM into areas that it did not example, classes for header filtering, that extend PCIM into areas
previously cover. Second, there are cases where elements of PCIM (for that it did not previously cover. Second, there are cases where
example, policy rule priorities) are deprecated, and replacement elements elements of PCIM (for example, policy rule priorities) are
are defined (in this case, priorities tied to associations that refer to deprecated, and replacement elements are defined (in this case,
policy rules). Both types of changes are done in such a way that, to the priorities tied to associations that refer to policy rules). Both
extent possible, interoperability with implementations of the original types of changes are done in such a way that, to the extent possible,
PCIM model is preserved. This document updates RFC 3060. interoperability with implementations of the original PCIM model is
preserved. This document updates RFC 3060.
Table of Contents Table of Contents
1. Introduction......................................................5 1. Introduction....................................................5
2. Changes since RFC 3060............................................5 2. Changes since RFC 3060..........................................5
3. Overview of the Changes...........................................6 3. Overview of the Changes.........................................6
3.1. How to Change an Information Model...........................6 3.1. How to Change an Information Model.........................6
3.2. List of Changes to the Model.................................6 3.2. List of Changes to the Model...............................6
3.2.1. Changes to PolicyRepository................................6 3.2.1. Changes to PolicyRepository.........................6
3.2.2. Additional Associations and Additional Reusable Elements...7 3.2.2. Additional Associations and Additional Reusable
3.2.3. Priorities and Decision Strategies.........................7 Elements............................................7
3.2.4. Policy Roles...............................................7 3.2.3. Priorities and Decision Strategies..................7
3.2.5. CompoundPolicyConditions and CompoundPolicyActions.........8 3.2.4. Policy Roles........................................8
3.2.6. Variables and Values.......................................8 3.2.5. CompoundPolicyConditions and
3.2.7. Domain-Level Packet Filtering..............................8 CompoundPolicyActions...............................8
3.2.8. Device-Level Packet Filtering..............................8
4. The Updated Class and Association Class Hierarchies...............9
5. Areas of Extension to PCIM.......................................13
5.1. Policy Scope................................................14
5.1.1. Levels of Abstraction: Domain- and Device-Level Policies..14
5.1.2. Administrative and Functional Scopes......................14
5.2. Reusable Policy Elements....................................15
5.3. Policy Sets.................................................16
5.4. Nested Policy Rules.........................................16
5.4.1. Usage Rules for Nested Rules..............................16
5.4.2. Motivation................................................17
5.5. Priorities and Decision Strategies..........................18
5.5.1. Structuring Decision Strategies...........................19
5.5.2. Side Effects..............................................20
5.5.3. Multiple PolicySet Trees For a Resource...................21
5.5.4. Deterministic Decisions...................................22
5.6. Policy Roles................................................23
5.6.1. Comparison of Roles in PCIM with Roles in snmpconf........23
5.6.2. Addition of PolicyRoleCollection to PCIMe.................23
5.6.3. Roles for PolicyGroups....................................24
5.7. Compound Policy Conditions and Compound Policy Actions......26
5.7.1. Compound Policy Conditions................................26
5.7.2. Compound Policy Actions...................................26
5.8. Variables and Values........................................27
5.8.1. Simple Policy Conditions..................................27
5.8.2. Using Simple Policy Conditions............................28
5.8.3. The Simple Condition Operator.............................29
5.8.4. SimplePolicyActions.......................................32
5.8.5. Policy Variables..........................................33
5.8.6. Explicitly Bound Policy Variables.........................34
5.8.7. Implicitly Bound Policy Variables.........................35
5.8.8. Structure and Usage of Pre-Defined Variables..............36
5.8.9. Rationale for Modeling Implicit Variables as Classes......37
5.8.10. Policy Values............................................38
5.9. Packet Filtering............................................38
5.9.1. Domain-Level Packet Filters...............................39
5.9.2. Device-Level Packet Filters...............................40
5.10. Conformance to PCIM and PCIMe..............................40
6. Class Definitions................................................41
6.1. The Abstract Class "PolicySet"..............................41
6.2. Update PCIM's Class "PolicyGroup"...........................42
6.3. Update PCIM's Class "PolicyRule"............................42
6.4. The Class "SimplePolicyCondition"...........................43
6.5. The Class "CompoundPolicyCondition".........................44
6.6. The Class "CompoundFilterCondition".........................44
6.7. The Class "SimplePolicyAction"..............................45
6.8. The Class "CompoundPolicyAction"............................45
6.9. The Abstract Class "PolicyVariable".........................47
6.10. The Class "PolicyExplicitVariable".........................47
6.10.1. The Single-Valued Property "ModelClass"..................47
6.10.2. The Single-Valued Property ModelProperty.................48
6.11. The Abstract Class "PolicyImplicitVariable"................48
6.11.1. The Multi-Valued Property "ValueTypes"...................48
6.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe..48
6.12.1. The Class "PolicySourceIPv4Variable".....................49
6.12.2. The Class "PolicySourceIPv6Variable".....................49
6.12.3. The Class "PolicyDestinationIPv4Variable"................49
6.12.4. The Class "PolicyDestinationIPv6Variable"................49
6.12.5. The Class "PolicySourcePortVariable".....................50
6.12.6. The Class "PolicyDestinationPortVariable"................50
6.12.7. The Class "PolicyIPProtocolVariable".....................50
6.12.8. The Class "PolicyIPVersionVariable"......................51
6.12.9. The Class "PolicyIPToSVariable"..........................51
6.12.10. The Class "PolicyDSCPVariable"..........................51
6.12.11. The Class "PolicyFlowIdVariable"........................51
6.12.12. The Class "PolicySourceMACVariable".....................52
6.12.13. The Class "PolicyDestinationMACVariable"................52
6.12.14. The Class "PolicyVLANVariable"..........................52
6.12.15. The Class "PolicyCoSVariable"...........................52
6.12.16. The Class "PolicyEthertypeVariable".....................53
6.12.17. The Class "PolicySourceSAPVariable".....................53
6.12.18. The Class "PolicyDestinationSAPVariable"................53
6.12.19. The Class "PolicySNAPOUIVariable".......................54
6.12.20. The Class "PolicySNAPTypeVariable"......................54
6.12.21. The Class "PolicyFlowDirectionVariable".................54
6.13. The Abstract Class "PolicyValue"...........................55
6.14. Subclasses of "PolicyValue" Specified in PCIMe.............55
6.14.1. The Class "PolicyIPv4AddrValue"..........................55
6.14.2. The Class "PolicyIPv6AddrValue...........................56
6.14.3. The Class "PolicyMACAddrValue"...........................57
6.14.4. The Class "PolicyStringValue"............................58
6.14.5. The Class "PolicyBitStringValue".........................58
6.14.6. The Class "PolicyIntegerValue"...........................59
6.14.7. The Class "PolicyBooleanValue"...........................60
6.15. The Class "PolicyRoleCollection"...........................60
6.15.1. The Single-Valued Property "PolicyRole"..................61
6.16. The Class "ReusablePolicyContainer"........................61
6.17. Deprecate PCIM's Class "PolicyRepository"..................61
6.18. The Abstract Class "FilterEntryBase".......................61
6.19. The Class "IpHeadersFilter"................................62
6.19.1. The Property HdrIpVersion................................62
6.19.2. The Property HdrSrcAddress...............................63
6.19.3. The Property HdrSrcAddressEndOfRange.....................63
6.19.4. The Property HdrSrcMask..................................63
6.19.5. The Property HdrDestAddress..............................64
6.19.6. The Property HdrDestAddressEndOfRange....................64
6.19.7. The Property HdrDestMask.................................64
6.19.8. The Property HdrProtocolID...............................64
6.19.9. The Property HdrSrcPortStart.............................65
6.19.10. The Property HdrSrcPortEnd..............................65
6.19.11. The Property HdrDestPortStart...........................65
6.19.12. The Property HdrDestPortEnd.............................66
6.19.13. The Property HdrDSCP....................................66
6.19.14. The Property HdrFlowLabel...............................66
6.20. The Class "8021Filter".....................................66
6.20.1. The Property 8021HdrSrcMACAddr...........................67
6.20.2. The Property 8021HdrSrcMACMask...........................67
6.20.3. The Property 8021HdrDestMACAddr..........................67
6.20.4. The Property 8021HdrDestMACMask..........................67
6.20.5. The Property 8021HdrProtocolID...........................68
6.20.6. The Property 8021HdrPriorityValue........................68
6.20.7. The Property 8021HdrVLANID...............................68
6.21. The Class FilterList.......................................68
6.21.1. The Property Direction...................................69
7. Association and Aggregation Definitions..........................69
7.1. The Aggregation "PolicySetComponent"........................69
7.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup".....70
7.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"......70
7.4. The Abstract Association "PolicySetInSystem"................71
7.5. Update PCIM's Weak Association "PolicyGroupInSystem"........71
7.6. Update PCIM's Weak Association "PolicyRuleInSystem".........72
7.7. The Abstract Aggregation "PolicyConditionStructure".........72
7.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule".....73
7.9. The Aggregation "PolicyConditionInPolicyCondition"..........73
7.10. The Abstract Aggregation "PolicyActionStructure"...........73
7.11. Update PCIM's Aggregation "PolicyActionInPolicyRule".......73
7.12. The Aggregation "PolicyActionInPolicyAction"...............74
7.13. The Aggregation "PolicyVariableInSimplePolicyCondition"....74
7.14. The Aggregation "PolicyValueInSimplePolicyCondition".......75
7.15. The Aggregation "PolicyVariableInSimplePolicyAction".......75
7.16. The Aggregation "PolicyValueInSimplePolicyAction"..........76
7.17. The Association "ReusablePolicy"...........................77
7.18. Deprecate PCIM's "PolicyConditionInPolicyRepository".......77
7.19. Deprecate PCIM's "PolicyActionInPolicyRepository"..........77
7.20. The Association ExpectedPolicyValuesForVariable............77
7.21. The Aggregation "ContainedDomain"..........................78
7.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"......78
7.23. The Aggregation "EntriesInFilterList"......................79
7.23.1. The Reference GroupComponent.............................79
7.23.2. The Reference PartComponent..............................79
7.23.3. The Property EntrySequence...............................80
7.24. The Aggregation "ElementInPolicyRoleCollection"............80
7.25. The Weak Association "PolicyRoleCollectionInSystem"........80
8. Intellectual Property............................................81
9. Acknowledgements.................................................81
10. Contributors....................................................81
11. Security Considerations.........................................83
12. Normative References............................................83
13. Informative References..........................................83
14. Editor's Address................................................84
15. Full Copyright Statement........................................84
16. Appendix A: Closed Issues.......................................85
1. Introduction 3.2.6. Variables and Values................................9
3.2.7. Domain-Level Packet Filtering.......................9
3.2.8. Device-Level Packet Filtering.......................9
4. The Updated Class and Association Class Hierarchies............10
5. Areas of Extension to PCIM.....................................13
5.1. Policy Scope..............................................13
5.1.1. Levels of Abstraction: Domain- and Device-Level
Policies...........................................13
5.1.2. Administrative and Functional Scopes...............14
5.2. Reusable Policy Elements..................................15
5.3. Policy Sets...............................................16
5.4. Nested Policy Rules.......................................16
5.4.1. Usage Rules for Nested Rules.......................17
5.4.2. Motivation.........................................17
5.5. Priorities and Decision Strategies........................18
5.5.1. Structuring Decision Strategies....................19
5.5.2. Side Effects.......................................21
5.5.3. Multiple PolicySet Trees For a Resource............21
5.5.4. Deterministic Decisions............................22
5.6. Policy Roles..............................................23
5.6.1. Comparison of Roles in PCIM with Roles in
snmpconf...........................................23
5.6.2. Addition of PolicyRoleCollection to PCIMe..........24
5.6.3. Roles for PolicyGroups.............................25
5.7. Compound Policy Conditions and Compound Policy Actions....27
5.7.1. Compound Policy Conditions.........................27
5.7.2. Compound Policy Actions............................27
5.8. Variables and Values......................................28
5.8.1. Simple Policy Conditions...........................29
5.8.2. Using Simple Policy Conditions.....................29
5.8.3. The Simple Condition Operator......................31
5.8.4. SimplePolicyActions................................33
5.8.5. Policy Variables...................................35
5.8.6. Explicitly Bound Policy Variables..................36
5.8.7. Implicitly Bound Policy Variables..................37
5.8.8. Structure and Usage of Pre-Defined Variables.......38
5.8.9. Rationale for Modeling Implicit Variables
as Classes.........................................39
5.8.10. Policy Values.....................................40
5.9. Packet Filtering..........................................41
5.9.1. Domain-Level Packet Filters........................41
5.9.2. Device-Level Packet Filters........................42
5.10. Conformance to PCIM and PCIMe............................43
6. Class Definitions..............................................44
6.1. The Abstract Class "PolicySet"............................44
6.2. Update PCIM's Class "PolicyGroup".........................45
6.3. Update PCIM's Class "PolicyRule"..........................45
6.4. The Class "SimplePolicyCondition".........................46
6.5. The Class "CompoundPolicyCondition".......................47
6.6. The Class "CompoundFilterCondition".......................47
6.7. The Class "SimplePolicyAction"............................48
6.8. The Class "CompoundPolicyAction"..........................48
6.9. The Abstract Class "PolicyVariable".......................50
6.10. The Class "PolicyExplicitVariable".......................50
6.10.1. The Single-Valued Property "ModelClass"...........51
6.10.2. The Single-Valued Property ModelProperty..........51
6.11. The Abstract Class "PolicyImplicitVariable"..............51
6.11.1. The Multi-Valued Property "ValueTypes"............52
6.12. Subclasses of "PolicyImplicitVariable" Specified
in PCIMe.................................................52
6.12.1. The Class "PolicySourceIPv4Variable"..............52
6.12.2. The Class "PolicySourceIPv6Variable"..............52
6.12.3. The Class "PolicyDestinationIPv4Variable".........53
6.12.4. The Class "PolicyDestinationIPv6Variable".........53
6.12.5. The Class "PolicySourcePortVariable"..............54
6.12.6. The Class "PolicyDestinationPortVariable".........54
6.12.7. The Class "PolicyIPProtocolVariable"..............54
6.12.8. The Class "PolicyIPVersionVariable"...............55
6.12.9. The Class "PolicyIPToSVariable"...................55
6.12.10. The Class "PolicyDSCPVariable"...................55
6.12.11. The Class "PolicyFlowIdVariable".................56
6.12.12. The Class "PolicySourceMACVariable"..............56
6.12.13. The Class "PolicyDestinationMACVariable".........56
6.12.14. The Class "PolicyVLANVariable"...................56
6.12.15. The Class "PolicyCoSVariable"....................57
6.12.16. The Class "PolicyEthertypeVariable"..............57
6.12.17. The Class "PolicySourceSAPVariable"..............57
6.12.18. The Class "PolicyDestinationSAPVariable".........58
6.12.19. The Class "PolicySNAPOUIVariable"................58
6.12.20. The Class "PolicySNAPTypeVariable"...............59
6.12.21. The Class "PolicyFlowDirectionVariable"..........59
6.13. The Abstract Class "PolicyValue".........................59
6.14. Subclasses of "PolicyValue" Specified in PCIMe...........60
6.14.1. The Class "PolicyIPv4AddrValue"...................60
6.14.2. The Class "PolicyIPv6AddrValue....................61
6.14.3. The Class "PolicyMACAddrValue"....................62
6.14.4. The Class "PolicyStringValue".....................63
6.14.5. The Class "PolicyBitStringValue"..................63
6.14.6. The Class "PolicyIntegerValue"....................64
6.14.7. The Class "PolicyBooleanValue"....................65
6.15. The Class "PolicyRoleCollection".........................65
6.15.1. The Single-Valued Property "PolicyRole"...........66
6.16. The Class "ReusablePolicyContainer".................66
6.17. Deprecate PCIM's Class "PolicyRepository"................66
6.18. The Abstract Class "FilterEntryBase".....................67
6.19. The Class "IpHeadersFilter"..............................67
6.19.1. The Property HdrIpVersion.........................68
6.19.2. The Property HdrSrcAddress........................68
6.19.3. The Property HdrSrcAddressEndOfRange..............68
6.19.4. The Property HdrSrcMask...........................69
6.19.5. The Property HdrDestAddress.......................69
6.19.6. The Property HdrDestAddressEndOfRange.............69
6.19.7. The Property HdrDestMask..........................70
6.19.8. The Property HdrProtocolID........................70
6.19.9. The Property HdrSrcPortStart......................70
6.19.10. The Property HdrSrcPortEnd.......................70
6.19.11. The Property HdrDestPortStart....................71
6.19.12. The Property HdrDestPortEnd......................71
6.19.13. The Property HdrDSCP.............................72
6.19.14. The Property HdrFlowLabel.................... ...72
6.20. The Class "8021Filter"...................................72
6.20.1. The Property 8021HdrSrcMACAddr....................73
6.20.2. The Property 8021HdrSrcMACMask....................73
6.20.3. The Property 8021HdrDestMACAddr...................73
6.20.4. The Property 8021HdrDestMACMask...................73
6.20.5. The Property 8021HdrProtocolID....................74
6.20.6. The Property 8021HdrPriorityValue.................74
6.20.7. The Property 8021HdrVLANID........................74
6.21. The Class FilterList.....................................74
6.21.1. The Property Direction............................75
7. Association and Aggregation Definitions........................75
7.1. The Aggregation "PolicySetComponent"......................75
7.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup"...76
7.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"....76
7.4. The Abstract Association "PolicySetInSystem"..............77
7.5. Update PCIM's Weak Association "PolicyGroupInSystem"......77
7.6. Update PCIM's Weak Association "PolicyRuleInSystem".......78
7.7. The Abstract Aggregation "PolicyConditionStructure".......79
7.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule"...79
7.9. The Aggregation "PolicyConditionInPolicyCondition"........79
7.10. The Abstract Aggregation "PolicyActionStructure".........80
7.11. Update PCIM's Aggregation "PolicyActionInPolicyRule".....80
7.12. The Aggregation "PolicyActionInPolicyAction".............80
7.13. The Aggregation "PolicyVariableInSimplePolicyCondition"..80
7.14. The Aggregation "PolicyValueInSimplePolicyCondition".....81
7.15. The Aggregation "PolicyVariableInSimplePolicyAction".....82
7.16. The Aggregation "PolicyValueInSimplePolicyAction"........83
7.17. The Association "ReusablePolicy".........................83
7.18. Deprecate PCIM's "PolicyConditionInPolicyRepository".....84
7.19. Deprecate PCIM's "PolicyActionInPolicyRepository"........84
7.20. The Association ExpectedPolicyValuesForVariable..........84
7.21. The Aggregation "ContainedDomain"........................85
7.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"....86
7.23. The Aggregation "EntriesInFilterList"....................86
7.23.1. The Reference GroupComponent......................86
7.23.2. The Reference PartComponent.......................87
7.23.3. The Property EntrySequence........................87
7.24. The Aggregation "ElementInPolicyRoleCollection"..........87
7.25. The Weak Association "PolicyRoleCollectionInSystem"......87
8. Intellectual Property..........................................88
9. Acknowledgements..............................................89
10. Contributors..................................................89
11. Security Considerations.......................................91
12. Normative References..........................................91
13. Informative References........................................91
Author's Address..................................................92
Full Copyright Statement..........................................93
1. Introduction
This document specifies a number of changes to the Policy Core This document specifies a number of changes to the Policy Core
Information Model (PCIM, RFC 3060 [1]). Two types of changes are Information Model (PCIM), RFC 3060 [1]. Two types of changes are
included. First, several completely new elements are introduced, for included. First, several completely new elements are introduced, for
example, classes for header filtering, that extend PCIM into areas that example, classes for header filtering, that extend PCIM into areas
it did not previously cover. Second, there are cases where elements of that it did not previously cover. Second, there are cases where
PCIM (for example, policy rule priorities) are deprecated, and elements of PCIM (for example, policy rule priorities) are
replacement elements are defined (in this case, priorities tied to deprecated, and replacement elements are defined (in this case,
associations that refer to policy rules). Both types of changes are done priorities tied to associations that refer to policy rules). Both
in such a way that, to the extent possible, interoperability with types of changes are done in such a way that, to the extent possible,
implementations of the original PCIM model is preserved. interoperability with implementations of the original PCIM model is
preserved.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119, reference [8]. document are to be interpreted as described in BCP 14, RFC 2119 [8].
2. Changes since RFC 3060 2. Changes since RFC 3060
Section 3.2 contains a short discussion of the changes that this document Section 3.2 contains a short discussion of the changes that this
makes to the RFC 3060 information model. Here is a very brief list of document makes to the RFC 3060 information model. Here is a very
the changes: brief list of the changes:
1. Deprecate and replace PolicyRepository and its associations. 1. Deprecate and replace PolicyRepository and its associations.
2. Clarify and expand the ways that PolicyRules and PolicyGroups are 2. Clarify and expand the ways that PolicyRules and PolicyGroups are
aggregated. aggregated.
3. Change how prioritization for PolicyRules is represented, and 3. Change how prioritization for PolicyRules is represented, and
introduce administrator-specified decision strategies for rule introduce administrator-specified decision strategies for rule
evaluation. evaluation.
4. Expand the role of PolicyRoles, and introduce a means of 4. Expand the role of PolicyRoles, and introduce a means of
associating a PolicyRole with a resource. associating a PolicyRole with a resource.
5. Introduce compound policy conditions and compound policy actions 5. Introduce compound policy conditions and compound policy actions
into the model. into the model.
6. Introduce variables and values into the model.
7. Introduce variable and value subclasses for packet-header
filtering.
8. Introduce classes for device-level packet-header filtering.
3. Overview of the Changes 6. Introduce variables and values into the model.
7. Introduce variable and value subclasses for packet-header
filtering.
8. Introduce classes for device-level packet-header filtering.
3.1. How to Change an Information Model 3. Overview of the Changes
The Policy Core Information Model is closely aligned with the DMTF's CIM 3.1. How to Change an Information Model
Core Policy model. Since there is no separately documented set of rules
for specifying IETF information models such as PCIM, it is reasonable to
look to the CIM specifications for guidance on how to modify and extend
the model. Among the CIM rules for changing an information model are the
following. Note that everything said here about "classes" applies to
association classes (including aggregations) as well as to non-
association classes.
o Properties may be added to existing classes. The Policy Core Information Model is closely aligned with the DMTF's
o Classes, and individual properties, may be marked as DEPRECATED. CIM Core Policy model. Since there is no separately documented set
If there is a replacement feature for the deprecated class or of rules for specifying IETF information models such as PCIM, it is
property, it is identified explicitly. Otherwise the notation "No reasonable to look to the CIM specifications for guidance on how to
value" is used. In this document, the notation "DEPRECATED FOR modify and extend the model. Among the CIM rules for changing an
<feature-name>" is used to indicate that a feature has been information model are the following. Note that everything said here
deprecated, and to identify its replacement feature. about "classes" applies to association classes (including
o Classes may be inserted into the inheritance hierarchy above aggregations) as well as to non- association classes.
existing classes, and properties from the existing classes may
then be "pulled up" into the new classes. The net effect is that
the existing classes have exactly the same properties they had
before, but the properties are inherited rather than defined
explicitly in the classes.
o New subclasses may be defined below existing classes.
3.2. List of Changes to the Model o Properties may be added to existing classes.
o Classes, and individual properties, may be marked as DEPRECATED.
If there is a replacement feature for the deprecated class or
property, it is identified explicitly. Otherwise the notation "No
value" is used. In this document, the notation "DEPRECATED FOR
<feature-name>" is used to indicate that a feature has been
deprecated, and to identify its replacement feature.
o Classes may be inserted into the inheritance hierarchy above
existing classes, and properties from the existing classes may
then be "pulled up" into the new classes. The net effect is that
the existing classes have exactly the same properties they had
before, but the properties are inherited rather than defined
explicitly in the classes.
o New subclasses may be defined below existing classes.
The following subsections provide a very brief overview of the changes to 3.2. List of Changes to the Model
PCIM defined in PCIMe. In several cases, the origin of the change is
noted, as QPIM [11], ICPM [12], or QDDIM [15].
3.2.1. Changes to PolicyRepository The following subsections provide a very brief overview of the
changes to PCIM defined in PCIMe. In several cases, the origin of
the change is noted, as QPIM [11], ICPM [12], or QDDIM [15].
Because of the potential for confusion with the Policy Framework 3.2.1. Changes to PolicyRepository
component Policy Repository (from the four-box picture: Policy Management
Tool, Policy Repository, PDP, PEP), "PolicyRepository" is a bad name for
the PCIM class representing a container of reusable policy elements.
Thus the class PolicyRepository is being replaced with the class
ReusablePolicyContainer. To accomplish this change, it is necessary to
deprecate the PCIM class PolicyRepository and its three associations, and
replace them with a new class ReusablePolicyContainer and new
associations.
As a separate change, the associations for ReusablePolicyContainer are Because of the potential for confusion with the Policy Framework
being broadened, to allow a ReusablePolicyContainer to contain any component Policy Repository (from the four-box picture: Policy
reusable policy elements. In PCIM, the only associations defined for a Management Tool, Policy Repository, PDP, PEP), "PolicyRepository" is
PolicyRepository were for it to contain reusable policy conditions and a bad name for the PCIM class representing a container of reusable
policy actions. policy elements. Thus the class PolicyRepository is being replaced
with the class ReusablePolicyContainer. To accomplish this change,
it is necessary to deprecate the PCIM class PolicyRepository and its
three associations, and replace them with a new class
ReusablePolicyContainer and new associations. As a separate change,
the associations for ReusablePolicyContainer are being broadened, to
allow a ReusablePolicyContainer to contain any reusable policy
elements. In PCIM, the only associations defined for a
PolicyRepository were for it to contain reusable policy conditions
and policy actions.
3.2.2. Additional Associations and Additional Reusable Elements 3.2.2. Additional Associations and Additional Reusable Elements
The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule aggregations have, The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule aggregations
in effect, been imported from QPIM. ("In effect" because these two have, in effect, been imported from QPIM. ("In effect" because these
aggregations, as well as PCIM'e two aggregations PolicyGroupInPolicyGroup two aggregations, as well as PCIM's two aggregations
and PolicyRuleInPolicyGroup, are all being combined into a single PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup, are all being
aggregation PolicySetComponent.) These aggregations make it possible to combined into a single aggregation PolicySetComponent.) These
define larger "chunks" of reusable policy to place in a aggregations make it possible to define larger "chunks" of reusable
ReusablePolicyContainer. These aggregations also introduce new semantics policy to place in a ReusablePolicyContainer. These aggregations
representing the contextual implications of having one PolicyRule also introduce new semantics representing the contextual implications
executing within the scope of another PolicyRule. of having one PolicyRule executing within the scope of another
PolicyRule.
3.2.3. Priorities and Decision Strategies 3.2.3. Priorities and Decision Strategies
Drawing from both QPIM and ICPM, the Priority property has been Drawing from both QPIM and ICPM, the Priority property has been
deprecated in PolicyRule, and placed instead on the aggregation deprecated in PolicyRule, and placed instead on the aggregation
PolicySetComponent. The QPIM rules for resolving relative priorities PolicySetComponent. The QPIM rules for resolving relative priorities
across nested PolicyGroups and PolicyRules have been incorporated into across nested PolicyGroups and PolicyRules have been incorporated
PCIMe as well. With the removal of the Priority property from into PCIMe as well. With the removal of the Priority property from
PolicyRule, a new modeling dependency is introduced. In order to PolicyRule, a new modeling dependency is introduced. In order to
prioritize a PolicyRule/PolicyGroup relative to other prioritize a PolicyRule/PolicyGroup relative to other
PolicyRules/PolicyGroups, the elements being prioritized must all reside PolicyRules/PolicyGroups, the elements being prioritized must all
in one of three places: in a common PolicyGroup, in a common PolicyRule, reside in one of three places: in a common PolicyGroup, in a common
or in a common System. PolicyRule, or in a common System.
In the absence of any clear, general criterion for detecting policy In the absence of any clear, general criterion for detecting policy
conflicts, the PCIM restriction stating that priorities are relevant only conflicts, the PCIM restriction stating that priorities are relevant
in the case of conflicts is being removed. In its place, a only in the case of conflicts is being removed. In its place, a
PolicyDecisionStrategy property has been added to the PolicyGroup and PolicyDecisionStrategy property has been added to the PolicyGroup and
PolicyRule classes. This property allows policy administrator to select PolicyRule classes. This property allows policy administrator to
one of two behaviors with respect to rule evaluation: either perform the select one of two behaviors with respect to rule evaluation: either
actions for all PolicyRules whose conditions evaluate to TRUE, or perform perform the actions for all PolicyRules whose conditions evaluate to
the actions only for the highest-priority PolicyRule whose conditions TRUE, or perform the actions only for the highest-priority PolicyRule
evaluate to TRUE. (This is accomplished by placing the whose conditions evaluate to TRUE. (This is accomplished by placing
PolicyDecisionStrategy property in an abstract class PolicySet, from the PolicyDecisionStrategy property in an abstract class PolicySet,
which PolicyGroup and PolicyRule are derived.) The QPIM rules for from which PolicyGroup and PolicyRule are derived.) The QPIM rules
applying decision strategies to a nested set of PolicyGroups and for applying decision strategies to a nested set of PolicyGroups and
PolicyRules have also been imported. PolicyRules have also been imported.
3.2.4. Policy Roles 3.2.4. Policy Roles
The concept of policy roles is added to PolicyGroups (being present The concept of policy roles is added to PolicyGroups (being present
already in the PolicyRule class). This is accomplished via a new already in the PolicyRule class). This is accomplished via a new
superclass for both PolicyRules and PolicyGroups - PolicySet. For nested superclass for both PolicyRules and PolicyGroups - PolicySet. For
PolicyRules and PolicyGroups, any roles associated with the outer rule or nested PolicyRules and PolicyGroups, any roles associated with the
group are automatically "inherited" by the nested one. Additional roles outer rule or group are automatically "inherited" by the nested one.
may be added at the level of a nested rule or group. Additional roles may be added at the level of a nested rule or group.
It was also observed that there is no mechanism in PCIM for assigning It was also observed that there is no mechanism in PCIM for assigning
roles to resources. For example, while it is possible in PCIM to roles to resources. For example, while it is possible in PCIM to
associate a PolicyRule with the role "FrameRelay&&WAN", there is no way associate a PolicyRule with the role "FrameRelay&&WAN", there is no
to indicate which interfaces match this criterion. A new way to indicate which interfaces match this criterion. A new
PolicyRoleCollection class has been defined in PCIMe, representing the PolicyRoleCollection class has been defined in PCIMe, representing
collection of resources associated with a particular role. The linkage the collection of resources associated with a particular role. The
between a PolicyRule or PolicyGroup and a set of resources is then linkage between a PolicyRule or PolicyGroup and a set of resources is
represented by an instance of PolicyRoleCollection. Equivalent values then represented by an instance of PolicyRoleCollection. Equivalent
should be defined in the PolicyRoles property of PolicyRules and values should be defined in the PolicyRoles property of PolicyRules
PolicyGroups, and in the PolicyRole property in PolicyRoleCollection. and PolicyGroups, and in the PolicyRole property in
PolicyRoleCollection.
3.2.5. CompoundPolicyConditions and CompoundPolicyActions 3.2.5. CompoundPolicyConditions and CompoundPolicyActions
The concept of a CompoundPolicyCondition has also been imported into The concept of a CompoundPolicyCondition has also been imported into
PCIMe from QPIM, and broadened to include a parallel PCIMe from QPIM, and broadened to include a parallel
CompoundPolicyAction. In both cases the idea is to create reusable CompoundPolicyAction. In both cases the idea is to create reusable
"chunks" of policy that can exist as named elements in a "chunks" of policy that can exist as named elements in a
ReusablePolicyContainer. The "Compound" classes and their associations ReusablePolicyContainer. The "Compound" classes and their
incorporate the condition and action semantics that PCIM defined at the associations incorporate the condition and action semantics that PCIM
PolicyRule level: DNF/CNF for conditions, and ordering for actions. defined at the PolicyRule level: DNF/CNF for conditions, and ordering
for actions.
Compound conditions and actions are defined to work with any component Compound conditions and actions are defined to work with any
conditions and actions. In other words, while the components may be component conditions and actions. In other words, while the
instances, respectively, of SimplePolicyCondition and SimplePolicyAction components may be instances, respectively, of SimplePolicyCondition
(discussed immediately below), they need not be. and SimplePolicyAction (discussed immediately below), they need not
be.
3.2.6. Variables and Values 3.2.6. Variables and Values
The SimplePolicyCondition / PolicyVariable / PolicyValue structure has The SimplePolicyCondition / PolicyVariable / PolicyValue structure
been imported into PCIMe from QPIM. A list of PCIMe-level variables is has been imported into PCIMe from QPIM. A list of PCIMe-level
defined, as well as a list of PCIMe-level values. Other variables and variables is defined, as well as a list of PCIMe-level values. Other
values may, if necessary, be defined in submodels of PCIMe. For example, variables and values may, if necessary, be defined in submodels of
QPIM defines a set of implicit variables corresponding to fields in RSVP PCIMe. For example, QPIM defines a set of implicit variables
flows. corresponding to fields in RSVP flows.
A corresponding SimplePolicyAction / PolicyVariable / PolicyValue A corresponding SimplePolicyAction / PolicyVariable / PolicyValue
structure is also defined. While the semantics of a structure is also defined. While the semantics of a
SimplePolicyCondition are "variable matches value", a SimplePolicyAction SimplePolicyCondition are "variable matches value", a
has the semantics "set variable to value". SimplePolicyAction has the semantics "set variable to value".
3.2.7. Domain-Level Packet Filtering 3.2.7. Domain-Level Packet Filtering
For packet filtering specified at the domain level, a set of For packet filtering specified at the domain level, a set of
PolicyVariables and PolicyValues are defined, corresponding to the fields PolicyVariables and PolicyValues are defined, corresponding to the
in an IP packet header plus the most common Layer 2 frame header fields. fields in an IP packet header plus the most common Layer 2 frame
It is expected that domain-level policy conditions that filter on these header fields. It is expected that domain-level policy conditions
header fields will be expressed in terms of CompoundPolicyConditions that filter on these header fields will be expressed in terms of
built up from SimplePolicyConditions that use these variables and values. CompoundPolicyConditions built up from SimplePolicyConditions that
An additional PolicyVariable, PacketDirection, is also defined, to use these variables and values. An additional PolicyVariable,
indicate whether a packet being filtered is traveling inbound or outbound PacketDirection, is also defined, to indicate whether a packet being
on an interface. filtered is traveling inbound or outbound on an interface.
3.2.8. Device-Level Packet Filtering 3.2.8. Device-Level Packet Filtering
For packet filtering expressed at the device level, including the packet For packet filtering expressed at the device level, including the
classifier filters modeled in QDDIM, the variables and values discussed packet classifier filters modeled in QDDIM, the variables and values
in Section 3.2.7 need not be used. Filter classes derived from the CIM discussed in Section 3.2.7 need not be used. Filter classes derived
FilterEntryBase class hierarchy are available for use in these contexts. from the CIM FilterEntryBase class hierarchy are available for use in
These latter classes have two important differences from the domain-level these contexts. These latter classes have two important differences
classes: from the domain-level classes:
o They support specification of filters for all of the fields in a o They support specification of filters for all of the fields in a
particular protocol header in a single object instance. With the particular protocol header in a single object instance. With the
domain-level classes, separate instances are needed for each domain-level classes, separate instances are needed for each
header field. header field.
o They provide native representations for the filter values, as
opposed to the string representation used by the domain-level
classes.
Device-level filter classes for the IP-related headers (IP, UDP, and TCP) o They provide native representations for the filter values, as
and the 802 MAC headers are defined, respectively, in Sections 6.19 and opposed to the string representation used by the domain-level
6.20. classes.
4. The Updated Class and Association Class Hierarchies Device-level filter classes for the IP-related headers (IP, UDP, and
TCP) and the 802 MAC headers are defined, respectively, in Sections
6.19 and 6.20.
4. The Updated Class and Association Class Hierarchies
The following figure shows the class inheritance hierarchy for PCIMe. The following figure shows the class inheritance hierarchy for PCIMe.
Changes from the PCIM hierarchy are noted parenthetically. Changes from the PCIM hierarchy are noted parenthetically.
ManagedElement (abstract) ManagedElement (abstract)
| |
+--Policy (abstract) +--Policy (abstract)
| | | |
| +---PolicySet (abstract -- new - 5.3) | +---PolicySet (abstract -- new - 5.3)
| | | | | |
skipping to change at page 10, line 50 skipping to change at page 11, line 6
| | | | | |
| | +---(subtree of more specific classes -- new - 6.12) | | +---(subtree of more specific classes -- new - 6.12)
| | | |
| +---PolicyValue (abstract -- new - 5.8.10) | +---PolicyValue (abstract -- new - 5.8.10)
| | | |
| +---(subtree of more specific classes -- new - 6.14) | +---(subtree of more specific classes -- new - 6.14)
| |
+--Collection (abstract -- newly referenced) +--Collection (abstract -- newly referenced)
| | | |
| +--PolicyRoleCollection (new - 5.6.2) | +--PolicyRoleCollection (new - 5.6.2)
(continued on following page)
(continued from previous page)
ManagedElement(abstract) ManagedElement(abstract)
| |
+--ManagedSystemElement (abstract) +--ManagedSystemElement (abstract)
| |
+--LogicalElement (abstract) +--LogicalElement (abstract)
| |
+--System (abstract) +--System (abstract)
| | | |
| +--AdminDomain (abstract) | +--AdminDomain (abstract)
| | | |
skipping to change at page 12, line 4 skipping to change at page 12, line 4
| |
+--FilterEntryBase (abstract -- new - 6.18) +--FilterEntryBase (abstract -- new - 6.18)
| | | |
| +--IpHeadersFilter (new - 6.19) | +--IpHeadersFilter (new - 6.19)
| | | |
| +--8021Filter (new - 6.20) | +--8021Filter (new - 6.20)
| |
+--FilterList (new - 6.21) +--FilterList (new - 6.21)
Figure 1. Class Inheritance Hierarchy for PCIMe Figure 1. Class Inheritance Hierarchy for PCIMe
The following figure shows the association class hierarchy for PCIMe. As The following figure shows the association class hierarchy for PCIMe.
before, changes from PCIM are noted parenthetically. As before, changes from PCIM are noted parenthetically.
[unrooted] [unrooted]
| |
+---PolicyComponent (abstract) +---PolicyComponent (abstract)
| | | |
| +---PolicySetComponent (new - 5.3) | +---PolicySetComponent (new - 5.3)
| | | |
| +---PolicyGroupInPolicyGroup (deprecated - 5.3) | +---PolicyGroupInPolicyGroup (deprecated - 5.3)
| | | |
| +---PolicyRuleInPolicyGroup (deprecated - 5.3) | +---PolicyRuleInPolicyGroup (deprecated - 5.3)
skipping to change at page 12, line 38 skipping to change at page 12, line 38
| | | | | |
| | +---PolicyActionInPolicyAction (new - 5.7.2) | | +---PolicyActionInPolicyAction (new - 5.7.2)
| | | |
| +---PolicyVariableInSimplePolicyCondition (new - 5.8.2) | +---PolicyVariableInSimplePolicyCondition (new - 5.8.2)
| | | |
| +---PolicyValueInSimplePolicyCondition (new - 5.8.2) | +---PolicyValueInSimplePolicyCondition (new - 5.8.2)
| | | |
| +---PolicyVariableInSimplePolicyAction (new - 5.8.4) | +---PolicyVariableInSimplePolicyAction (new - 5.8.4)
| | | |
| +---PolicyValueInSimplePolicyAction (new - 5.8.4) | +---PolicyValueInSimplePolicyAction (new - 5.8.4)
(continued on following page)
(continued from previous page)
[unrooted] [unrooted]
| |
+---Dependency (abstract) +---Dependency (abstract)
| | | |
| +---PolicyInSystem (abstract) | +---PolicyInSystem (abstract)
| | | | | |
| | +---PolicySetInSystem (abstract, new - 5.3) | | +---PolicySetInSystem (abstract, new - 5.3)
| | | | | | | |
| | | +---PolicyGroupInSystem | | | +---PolicyGroupInSystem
| | | | | | | |
skipping to change at page 13, line 43 skipping to change at page 13, line 28
| | +---PolicyRepositoryInPolicyRepository (deprecated - 5.2) | | +---PolicyRepositoryInPolicyRepository (deprecated - 5.2)
| | | |
| +---EntriesInFilterList (new - 7.23) | +---EntriesInFilterList (new - 7.23)
| |
+---MemberOfCollection (newly referenced) +---MemberOfCollection (newly referenced)
| |
+--- ElementInPolicyRoleCollection (new - 5.6.2) +--- ElementInPolicyRoleCollection (new - 5.6.2)
Figure 2. Association Class Inheritance Hierarchy for PCIMe Figure 2. Association Class Inheritance Hierarchy for PCIMe
In addition to these changes that show up at the class and association In addition to these changes that show up at the class and
class level, there are other changes from PCIM involving individual class association class level, there are other changes from PCIM involving
properties. In some cases new properties are introduced into existing individual class properties. In some cases new properties are
classes, and in other cases existing properties are deprecated (without introduced into existing classes, and in other cases existing
deprecating the classes that contain them). properties are deprecated (without deprecating the classes that
contain them).
5. Areas of Extension to PCIM 5. Areas of Extension to PCIM
The following subsections describe each of the areas for which PCIM The following subsections describe each of the areas for which PCIM
extensions are being defined. extensions are being defined.
5.1. Policy Scope 5.1. Policy Scope
Policy scopes may be thought of in two dimensions: 1) the level of Policy scopes may be thought of in two dimensions: 1) the level of
abstraction of the policy specification and 2) the applicability of abstraction of the policy specification and 2) the applicability of
policies to a set of managed resources. policies to a set of managed resources.
5.1.1. Levels of Abstraction: Domain- and Device-Level Policies 5.1.1. Levels of Abstraction: Domain- and Device-Level Policies
Policies vary in level of abstraction, from the business-level expression Policies vary in level of abstraction, from the business-level
of service level agreements (SLAs) to the specification of a set of rules expression of service level agreements (SLAs) to the specification of
that apply to devices in a network. Those latter policies can, a set of rules that apply to devices in a network. Those latter
themselves, be classified into at least two groups: those policies policies can, themselves, be classified into at least two groups:
consumed by a Policy Decision Point (PDP) that specify the rules for an
administrative and functional domain, and those policies consumed by a
Policy Enforcement Point (PEP) that specify the device-specific rules for
a functional domain. The higher-level rules consumed by a PDP, called
domain-level policies, may have late binding variables unspecified, or
specified by a classification, whereas the device-level rules are likely
to have fewer unresolved bindings.
There is a relationship between these levels of policy specification that those policies consumed by a Policy Decision Point (PDP) that specify
is out of scope for this standards effort, but that is necessary in the the rules for an administrative and functional domain, and those
development and deployment of a usable policy-based configuration system. policies consumed by a Policy Enforcement Point (PEP) that specify
An SLA-level policy transformation to the domain-level policy may be the device-specific rules for a functional domain. The higher-level
thought of as analogous to a visual builder that takes human input and rules consumed by a PDP, called domain-level policies, may have late
develops a programmatic rule specification. The relationship between the binding variables unspecified, or specified by a classification,
domain-level policy and the device-level policy may be thought of as whereas the device-level rules are likely to have fewer unresolved
analogous to that of a compiler and linkage editor that translates the bindings.
rules into specific instructions that can be executed on a specific type
of platform. There is a relationship between these levels of policy specification
that is out of scope for this standards effort, but that is necessary
in the development and deployment of a usable policy-based
configuration system. An SLA-level policy transformation to the
domain-level policy may be thought of as analogous to a visual
builder that takes human input and develops a programmatic rule
specification. The relationship between the domain-level policy and
the device-level policy may be thought of as analogous to that of a
compiler and linkage editor that translates the rules into specific
instructions that can be executed on a specific type of platform.
PCIM and PCIMe may be used to specify rules at any and all of these PCIM and PCIMe may be used to specify rules at any and all of these
levels of abstraction. However, at different levels of abstraction, levels of abstraction. However, at different levels of abstraction,
different mechanisms may be more or less appropriate. different mechanisms may be more or less appropriate.
5.1.2. Administrative and Functional Scopes 5.1.2. Administrative and Functional Scopes
Administrative scopes for policy are represented in PCIM and in these Administrative scopes for policy are represented in PCIM and in these
extensions to PCIM as System subclass instances. Typically, a domain- extensions to PCIM as System subclass instances. Typically, a
level policy would be scoped by an AdminDomain instance (or by a domain-level policy would be scoped by an AdminDomain instance (or by
hierarchy of AdminDomain instances) whereas a device-level policy might a hierarchy of AdminDomain instances) whereas a device-level policy
be scoped by a System instance that represents the PEP (e.g., an instance might be scoped by a System instance that represents the PEP (e.g.,
of ComputerSystem, see CIM [2]). In addition to collecting policies into an instance of ComputerSystem, see CIM [2]). In addition to
an administrative domain, these System classes may also aggregate the collecting policies into an administrative domain, these System
resources to which the policies apply. classes may also aggregate the resources to which the policies apply.
Functional scopes (sometimes referred to as functional domains) are Functional scopes (sometimes referred to as functional domains) are
generally defined by the submodels derived from PCIM and PCIMe, and generally defined by the submodels derived from PCIM and PCIMe, and
correspond to the service or services to which the policies apply. So, correspond to the service or services to which the policies apply.
for example, Quality of Service may be thought of as a functional scope, So, for example, Quality of Service may be thought of as a functional
or Diffserv and Intserv may each be thought of as functional scopes. scope, or Diffserv and Intserv may each be thought of as functional
These scoping decisions are represented by the structure of the submodels scopes. These scoping decisions are represented by the structure of
derived from PCIM and PCIMe, and may be reflected in the number and types the submodels derived from PCIM and PCIMe, and may be reflected in
of PEP policy client(s), services, and the interaction between policies. the number and types of PEP policy client(s), services, and the
Policies in different functional scopes are organized into disjoint sets interaction between policies. Policies in different functional
of policy rules. Different functional domains may share some roles, some scopes are organized into disjoint sets of policy rules. Different
conditions, and even some actions. The rules from different functional functional domains may share some roles, some conditions, and even
domains may even be enforced at the same managed resource, but for the some actions. The rules from different functional domains may even
purposes of policy evaluation they are separate. See section 5.5.3 for be enforced at the same managed resource, but for the purposes of
more information. policy evaluation they are separate. See section 5.5.3 for more
information.
The functional scopes MAY be reflected in administrative scopes. That The functional scopes MAY be reflected in administrative scopes.
is, deployments of policy may have different administrative scopes for That is, deployments of policy may have different administrative
different functional scopes, but there is no requirement to do so. scopes for different functional scopes, but there is no requirement
to do so.
5.2. Reusable Policy Elements 5.2. Reusable Policy Elements
In PCIM, a distinction was drawn between reusable PolicyConditions and In PCIM, a distinction was drawn between reusable PolicyConditions
PolicyActions and rule-specific ones. The PolicyRepository class was and PolicyActions and rule-specific ones. The PolicyRepository class
also defined, to serve as a container for these reusable elements. The was also defined, to serve as a container for these reusable
name "PolicyRepository" has proven to be an unfortunate choice for the elements. The name "PolicyRepository" has proven to be an
class that serves as a container for reusable policy elements. This term unfortunate choice for the class that serves as a container for
is already used in documents like the Policy Framework, to denote the reusable policy elements. This term is already used in documents
location from which the PDP retrieves all policy specifications, and into like the Policy Framework, to denote the location from which the PDP
which the Policy Management Tool places all policy specifications. retrieves all policy specifications, and into which the Policy
Consequently, the PolicyRepository class is being deprecated, in favor of Management Tool places all policy specifications. Consequently, the
a new class ReusablePolicyContainer. PolicyRepository class is being deprecated, in favor of a new class
ReusablePolicyContainer.
When a class is deprecated, any associations that refer to it must also When a class is deprecated, any associations that refer to it must
be deprecated. So replacements are needed for the two associations also be deprecated. So replacements are needed for the two
PolicyConditionInPolicyRepository and PolicyActionInPolicyRepository, as associations PolicyConditionInPolicyRepository and
well as for the aggregation PolicyRepositoryInPolicyRepository. In PolicyActionInPolicyRepository, as well as for the aggregation
addition to renaming the PolicyRepository class to PolicyRepositoryInPolicyRepository. In addition to renaming the
ReusablePolicyContainer, however, PCIMe is also broadening the types of PolicyRepository class to ReusablePolicyContainer, however, PCIMe is
policy elements that can be reusable. Consequently, rather than also broadening the types of policy elements that can be reusable.
providing one-for-one replacements for the two associations, a single Consequently, rather than providing one-for-one replacements for the
higher-level association ReusablePolicy is defined. This new association two associations, a single higher-level association ReusablePolicy is
allows any policy element (that is, an instance of any subclass of the defined. This new association allows any policy element (that is, an
abstract class Policy) to be placed in a ReusablePolicyContainer. instance of any subclass of the abstract class Policy) to be placed
in a ReusablePolicyContainer.
Summarizing, the following changes in Sections 6 and 7 are the result of Summarizing, the following changes in Sections 6 and 7 are the result
this item: of this item:
o The class ReusablePolicyContainer is defined. o The class ReusablePolicyContainer is defined.
o PCIM's PolicyRepository class is deprecated. o PCIM's PolicyRepository class is deprecated.
o The association ReusablePolicy is defined. o The association ReusablePolicy is defined.
o PCIM's PolicyConditionInPolicyRepository association is deprecated. o PCIM's PolicyConditionInPolicyRepository association is
o PCIM's PolicyActionInPolicyRepository association is deprecated. deprecated.
o The aggregation ContainedDomain is defined. o PCIM's PolicyActionInPolicyRepository association is deprecated.
o PCIM's PolicyRepositoryInPolicyRepository aggregation is deprecated. o The aggregation ContainedDomain is defined.
o PCIM's PolicyRepositoryInPolicyRepository aggregation is
deprecated.
5.3. Policy Sets 5.3. Policy Sets
A "policy" can be thought of as a coherent set of rules to administer, A "policy" can be thought of as a coherent set of rules to
manage, and control access to network resources ("Policy Terminology", administer, manage, and control access to network resources ("Policy
reference [10]). The structuring of these coherent sets of rules into Terminology", reference [10]). The structuring of these coherent
subsets is enhanced in this document. In Section 5.4, we discuss the new sets of rules into subsets is enhanced in this document. In Section
options for the nesting of policy rules. 5.4, we discuss the new options for the nesting of policy rules.
A new abstract class, PolicySet, is introduced to provide an abstraction A new abstract class, PolicySet, is introduced to provide an
for a set of rules. It is derived from Policy, and it is inserted into abstraction for a set of rules. It is derived from Policy, and it is
the inheritance hierarchy above both PolicyGroup and PolicyRule. This inserted into the inheritance hierarchy above both PolicyGroup and
reflects the additional structural flexibility and semantic capability of PolicyRule. This reflects the additional structural flexibility and
both subclasses. semantic capability of both subclasses.
Two properties are defined in PolicySet: PolicyDecisionStrategy and Two properties are defined in PolicySet: PolicyDecisionStrategy and
PolicyRoles. The PolicyDecisionStrategy property is included in PolicyRoles. The PolicyDecisionStrategy property is included in
PolicySet to define the evaluation relationship among the rules in the PolicySet to define the evaluation relationship among the rules in
policy set. See Section 5.5 for more information. The PolicyRoles the policy set. See Section 5.5 for more information. The
property is included in PolicySet to characterize the resources to which PolicyRoles property is included in PolicySet to characterize the
the PolicySet applies. See Section 5.6 for more information. resources to which the PolicySet applies. See Section 5.6 for more
information.
Along with the definition of the PolicySet class, a new concrete Along with the definition of the PolicySet class, a new concrete
aggregation class is defined that will also be discussed in the following aggregation class is defined that will also be discussed in the
sections. PolicySetComponent is defined as a subclass of following sections. PolicySetComponent is defined as a subclass of
PolicyComponent; it provides the containment relationship for a PolicySet PolicyComponent; it provides the containment relationship for a
in a PolicySet. PolicySetComponent replaces the two PCIM aggregations PolicySet in a PolicySet. PolicySetComponent replaces the two PCIM
PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup, so these two aggregations PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup, so
aggregations are deprecated. these two aggregations are deprecated.
A PolicySet's relationship to an AdminDomain or other administrative A PolicySet's relationship to an AdminDomain or other administrative
scoping system (for example, a ComputerSystem) is represented by the scoping system (for example, a ComputerSystem) is represented by the
PolicySetInSystem abstract association. This new association is derived PolicySetInSystem abstract association. This new association is
from PolicyInSystem, and the PolicyGroupInSystem and PolicyRuleInSystem derived from PolicyInSystem, and the PolicyGroupInSystem and
associations are now derived from PolicySetInSystem instead of directly PolicyRuleInSystem associations are now derived from
from PolicyInSystem. The PolicySetInSystem.Priority property is PolicySetInSystem instead of directly from PolicyInSystem. The
discussed in Section 5.5.3. PolicySetInSystem.Priority property is discussed in Section 5.5.3.
5.4. Nested Policy Rules 5.4. Nested Policy Rules
As previously discussed, policy is described by a set of policy rules As previously discussed, policy is described by a set of policy rules
that may be grouped into subsets. In this section we introduce the that may be grouped into subsets. In this section we introduce the
notion of nested rules, or the ability to define rules within rules. notion of nested rules, or the ability to define rules within rules.
Nested rules are also called sub-rules, and we use both terms in this Nested rules are also called sub-rules, and we use both terms in this
document interchangeably. The aggregation PolicySetComponent is used to document interchangeably. The aggregation PolicySetComponent is used
represent the nesting of a policy rule in another policy rule. to represent the nesting of a policy rule in another policy rule.
5.4.1. Usage Rules for Nested Rules 5.4.1. Usage Rules for Nested Rules
The relationship between rules and sub-rules is defined as follows: The relationship between rules and sub-rules is defined as follows:
o The parent rule's condition clause is a condition for evaluation o The parent rule's condition clause is a condition for evaluation
of all nested rules; that is, the conditions of the parent are of all nested rules; that is, the conditions of the parent are
logically ANDed to the conditions of the sub-rules. If the parent logically ANDed to the conditions of the sub-rules. If the parent
rule's condition clause evaluates to FALSE, sub-rules MAY be rule's condition clause evaluates to FALSE, sub-rules MAY be
skipped since they also evaluate to FALSE. skipped since they also evaluate to FALSE.
o If the parent rule's condition evaluates to TRUE, the set of sub-
rules SHALL BE evaluated according to the decision strategy and
priorities as discussed in Section 5.5.
o If the parent rule's condition evaluates to TRUE, the parent
rule's set of actions is executed BEFORE execution of the sub-
rules actions. The parent rule's actions are not to be confused
with default actions. A default action is one that is to be
executed only if none of the more specific sub-rules are executed.
If a default action needs to be specified, it needs to be defined
as an action that is part of a catchall sub-rule associated with
the parent rule. The association linking the default action(s) in
this special sub-rule should have the lowest priority relative to
all other sub-rule associations:
if parent-condition then parent rule's action o If the parent rule's condition evaluates to TRUE, the set of sub-
if condA then actA rules SHALL BE evaluated according to the decision strategy and
if condB then ActB priorities as discussed in Section 5.5.
if True then default action
Such a default action functions as a default when FirstMatching o If the parent rule's condition evaluates to TRUE, the parent
decision strategies are in effect (see section 5.5). If rule's set of actions is executed BEFORE execution of the sub-
AllMatching applies, the "default" action is always performed. rules actions. The parent rule's actions are not to be confused
with default actions. A default action is one that is to be
executed only if none of the more specific sub-rules are executed.
If a default action needs to be specified, it needs to be defined
as an action that is part of a catchall sub-rule associated with
the parent rule. The association linking the default action(s) in
this special sub-rule should have the lowest priority relative to
all other sub-rule associations:
o Policy rules have a context in which they are executed. The rule if parent-condition then parent rule's action
engine evaluates and applies the policy rules in the context of if condA then actA
the managed resource(s) that are identified by the policy roles if condB then ActB
(or by an explicit association). Submodels MAY add additional if True then default action
context to policy rules based on rule structure; any such
additional context is defined by the semantics of the action
classes of the submodel.
5.4.2. Motivation Such a default action functions as a default when FirstMatching
decision strategies are in effect (see section 5.5). If
AllMatching applies, the "default" action is always performed.
Rule nesting enhances Policy readability, expressiveness and reusability. o Policy rules have a context in which they are executed. The rule
The ability to nest policy rules and form sub-rules is important for engine evaluates and applies the policy rules in the context of
manageability and scalability, as it enables complex policy rules to be the managed resource(s) that are identified by the policy roles
constructed from multiple simpler policy rules. These enhancements ease (or by an explicit association). Submodels MAY add additional
the policy management tools' task, allowing policy rules to be expressed context to policy rules based on rule structure; any such
in a way closer to how humans think. additional context is defined by the semantics of the action
classes of the submodel.
5.4.2. Motivation
Rule nesting enhances Policy readability, expressiveness and
reusability. The ability to nest policy rules and form sub-rules is
important for manageability and scalability, as it enables complex
policy rules to be constructed from multiple simpler policy rules.
These enhancements ease the policy management tools' task, allowing
policy rules to be expressed in a way closer to how humans think.
Although rule nesting can be used to suggest optimizations in the way Although rule nesting can be used to suggest optimizations in the way
policy rules are evaluated, as discussed in section 5.5.2 "Side Effects," policy rules are evaluated, as discussed in section 5.5.2 "Side
nesting does not specify nor does it require any particular order of Effects," nesting does not specify nor does it require any particular
evaluation of conditions. Optimization of rule evaluation can be done in order of evaluation of conditions. Optimization of rule evaluation
the PDP or in the PEP by dedicated code. This is similar to the relation can be done in the PDP or in the PEP by dedicated code. This is
between a high level programming language like C and machine code. An similar to the relation between a high level programming language
optimizer can create a more efficient machine code than any optimization like C and machine code. An optimizer can create a more efficient
done by the programmer within the source code. Nevertheless, if the PEP machine code than any optimization done by the programmer within the
or PDP does not do optimization, the administrator writing the policy may source code. Nevertheless, if the PEP or PDP does not do
be able to influence the evaluation of the policy rules for execution optimization, the administrator writing the policy may be able to
using rule nesting. influence the evaluation of the policy rules for execution using rule
nesting.
Nested rules are not designed for policy repository retrieval Nested rules are not designed for policy repository retrieval
optimization. It is assumed that all rules and groups that are assigned optimization. It is assumed that all rules and groups that are
to a role are retrieved by the PDP or PEP from the policy repository and assigned to a role are retrieved by the PDP or PEP from the policy
enforced. Optimizing the number of rules retrieved should be done by repository and enforced. Optimizing the number of rules retrieved
clever selection of roles. should be done by clever selection of roles.
5.5. Priorities and Decision Strategies 5.5. Priorities and Decision Strategies
A "decision strategy" is used to specify the evaluation method for the A "decision strategy" is used to specify the evaluation method for
policies in a PolicySet. Two decision strategies are defined: the policies in a PolicySet. Two decision strategies are defined:
"FirstMatching" and "AllMatching." The FirstMatching strategy is used to "FirstMatching" and "AllMatching." The FirstMatching strategy is
cause the evaluation of the rules in a set such that the only actions used to cause the evaluation of the rules in a set such that the only
enforced on a given examination of the PolicySet are those for the first actions enforced on a given examination of the PolicySet are those
rule (that is, the rule with the highest priority) that has its for the first rule (that is, the rule with the highest priority) that
conditions evaluate to TRUE. The AllMatching strategy is used to cause has its conditions evaluate to TRUE. The AllMatching strategy is
the evaluation of all rules in a set; for all of the rules whose used to cause the evaluation of all rules in a set; for all of the
conditions evaluate to TRUE, the actions are enforced. Implementations rules whose conditions evaluate to TRUE, the actions are enforced.
MUST support the FirstMatching decision strategy; implementations MAY Implementations MUST support the FirstMatching decision strategy;
support the AllMatching decision strategy. implementations MAY support the AllMatching decision strategy.
As previously discussed, the PolicySet subclasses are PolicyGroup and As previously discussed, the PolicySet subclasses are PolicyGroup and
PolicyRule: either subclass may contain PolicySets of either subclass. PolicyRule: either subclass may contain PolicySets of either
Loops, including the degenerate case of a PolicySet that contains itself, subclass. Loops, including the degenerate case of a PolicySet that
are not allowed when PolicySets contain other PolicySets. The contains itself, are not allowed when PolicySets contain other
containment relationship is specified using the PolicySetComponent PolicySets. The containment relationship is specified using the
aggregation. PolicySetComponent aggregation.
The relative priority within a PolicySet is established by the Priority The relative priority within a PolicySet is established by the
property of the PolicySetComponent aggregation of the contained Priority property of the PolicySetComponent aggregation of the
PolicyGroup and PolicyRule instances. The use of PCIM's contained PolicyGroup and PolicyRule instances. The use of PCIM's
PolicyRule.Priority property is deprecated in favor of this new property. PolicyRule.Priority property is deprecated in favor of this new
The separation of the priority property from the rule has two advantages. property. The separation of the priority property from the rule has
First, it generalizes the concept of priority, so that it can be used for two advantages. First, it generalizes the concept of priority, so
both groups and rules. Second, it places the priority on the that it can be used for both groups and rules. Second, it places the
relationship between the parent policy set and the subordinate policy priority on the relationship between the parent policy set and the
group or rule. The assignment of a priority value then becomes much subordinate policy group or rule. The assignment of a priority value
easier, in that the value is used only in relationship to other then becomes much easier, in that the value is used only in
priorities in the same set. relationship to other priorities in the same set.
Together, the PolicySet.PolicyDecisionStrategy and Together, the PolicySet.PolicyDecisionStrategy and
PolicySetComponent.Priority determine the processing for the rules PolicySetComponent.Priority determine the processing for the rules
contained in a PolicySet. As before, the larger priority value contained in a PolicySet. As before, the larger priority value
represents the higher priority. Unlike the earlier definition, represents the higher priority. Unlike the earlier definition,
PolicySetComponent.Priority MUST have a unique value when compared with PolicySetComponent.Priority MUST have a unique value when compared
others defined for the same aggregating PolicySet. Thus, the evaluation with others defined for the same aggregating PolicySet. Thus, the
of rules within a set is deterministically specified. evaluation of rules within a set is deterministically specified.
For a FirstMatching decision strategy, the first rule (that is, the one For a FirstMatching decision strategy, the first rule (that is, the
with the highest priority) in the set that evaluates to True, is the only one with the highest priority) in the set that evaluates to True, is
rule whose actions are enforced for a particular evaluation pass through the only rule whose actions are enforced for a particular evaluation
the PolicySet. pass through the PolicySet.
For an AllMatching decision strategy, all of the matching rules are For an AllMatching decision strategy, all of the matching rules are
enforced. The relative priority of the rules is used to determine the enforced. The relative priority of the rules is used to determine
order in which the actions are to be executed by the enforcement point: the order in which the actions are to be executed by the enforcement
the actions of the higher priority rules are executed first. Since the point: the actions of the higher priority rules are executed first.
actions of higher priority rules are executed first, lower priority rules Since the actions of higher priority rules are executed first, lower
that also match may get the "last word," and thus produce a counter- priority rules that also match may get the "last word," and thus
intuitive result. So, for example, if two rules both evaluate to True, produce a counter-intuitive result. So, for example, if two rules
and the higher priority rule sets the DSCP to 3 and the lower priority both evaluate to True, and the higher priority rule sets the DSCP to
rule sets the DSCP to 4, the action of the lower priority rule will be 3 and the lower priority rule sets the DSCP to 4, the action of the
executed later and, therefore, will "win," in this example, setting the lower priority rule will be executed later and, therefore, will
DSCP to 4. Thus, conflicts between rules are resolved by this execution "win," in this example, setting the DSCP to 4. Thus, conflicts
order. between rules are resolved by this execution order.
An implementation of the rule engine need not provide the action An implementation of the rule engine need not provide the action
sequencing but the actions MUST be sequenced by the PEP or PDP on its sequencing but the actions MUST be sequenced by the PEP or PDP on its
behalf. So, for example, the rule engine may provide an ordered list of behalf. So, for example, the rule engine may provide an ordered list
actions to be executed by the PEP and any required serialization is then of actions to be executed by the PEP and any required serialization
provided by the service configured by the rule engine. See Section 5.5.2 is then provided by the service configured by the rule engine. See
for a discussion of side effects. Section 5.5.2 for a discussion of side effects.
5.5.1. Structuring Decision Strategies 5.5.1. Structuring Decision Strategies
As discussed in Sections 5.3 and 5.4, PolicySet instances may be nested As discussed in Sections 5.3 and 5.4, PolicySet instances may be
arbitrarily. For a FirstMatching decision strategy on a PolicySet, any nested arbitrarily. For a FirstMatching decision strategy on a
contained PolicySet that matches satisfies the termination criteria for PolicySet, any contained PolicySet that matches satisfies the
the FirstMatching strategy. A PolicySet is considered to match if it is termination criteria for the FirstMatching strategy. A PolicySet is
a PolicyRule and its conditions evaluate to True, or if the PolicySet is considered to match if it is a PolicyRule and its conditions evaluate
a PolicyGroup and at least one of its contained PolicyGroups or to True, or if the PolicySet is a PolicyGroup and at least one of its
PolicyRules match. The priority associated with contained PolicySets, contained PolicyGroups or PolicyRules match. The priority associated
then, determines when to terminate rule evaluation in the structured set with contained PolicySets, then, determines when to terminate rule
of rules. evaluation in the structured set of rules.
In the example shown in Figure 3, the relative priorities for the nested In the example shown in Figure 3, the relative priorities for the
rules, high to low, are 1A, 1B1, 1X2, 1B3, 1C, 1C1, 1X2 and 1C3. (Note nested rules, high to low, are 1A, 1B1, 1X2, 1B3, 1C, 1C1, 1X2 and
that PolicyRule 1X2 is included in both PolicyGroup 1B and PolicyRule 1C, 1C3. (Note that PolicyRule 1X2 is included in both PolicyGroup 1B
but with different priorities.) Of course, which rules are enforced is and PolicyRule 1C, but with different priorities.) Of course, which
also dependent on which rules, if any, match. rules are enforced is also dependent on which rules, if any, match.
PolicyGroup 1: FirstMatching PolicyGroup 1: FirstMatching
| |
+-- Pri=6 -- PolicyRule 1A +-- Pri=6 -- PolicyRule 1A
| |
+-- Pri=5 -- PolicyGroup 1B: AllMatching +-- Pri=5 -- PolicyGroup 1B: AllMatching
| | | |
| +-- Pri=5 -- PolicyGroup 1B1: AllMatching | +-- Pri=5 -- PolicyGroup 1B1: AllMatching
| | | | | |
| | +---- etc. | | +---- etc.
skipping to change at page 20, line 31 skipping to change at page 20, line 40
+-- Pri=4 -- PolicyRule 1C: FirstMatching +-- Pri=4 -- PolicyRule 1C: FirstMatching
| |
+-- Pri=4 -- PolicyRule 1C1 +-- Pri=4 -- PolicyRule 1C1
| |
+-- Pri=3 -- PolicyRule 1X2 +-- Pri=3 -- PolicyRule 1X2
| |
+-- Pri=2 -- PolicyRule 1C3 +-- Pri=2 -- PolicyRule 1C3
Figure 3. Nested PolicySets with Different Decision Strategies Figure 3. Nested PolicySets with Different Decision Strategies
o Because PolicyGroup 1 has a FirstMatching decision strategy, if o Because PolicyGroup 1 has a FirstMatching decision strategy, if
the conditions of PolicyRule 1A match, its actions are enforced the conditions of PolicyRule 1A match, its actions are enforced
and the evaluation stops. and the evaluation stops.
o If it does not match, PolicyGroup 1B is evaluated using an o If it does not match, PolicyGroup 1B is evaluated using an
AllMatching strategy. Since PolicyGroup 1B1 also has an AllMatching strategy. Since PolicyGroup 1B1 also has an
AllMatching strategy all of the rules and groups of rules AllMatching strategy all of the rules and groups of rules
contained in PolicyGroup 1B1 are evaluated and enforced as contained in PolicyGroup 1B1 are evaluated and enforced as
appropriate. PolicyRule 1X2 and PolicyRule 1B3 are also evaluated appropriate. PolicyRule 1X2 and PolicyRule 1B3 are also evaluated
and enforced as appropriate. If any of the sub-rules in the and enforced as appropriate. If any of the sub-rules in the
subtrees of PolicyGroup 1B evaluate to True, then PolicyRule 1C is subtrees of PolicyGroup 1B evaluate to True, then PolicyRule 1C is
not evaluated because the FirstMatching strategy of PolicyGroup 1 not evaluated because the FirstMatching strategy of PolicyGroup 1
has been satisfied. has been satisfied.
o If neither PolicyRule 1A nor PolicyGroup 1B yield a match, then o If neither PolicyRule 1A nor PolicyGroup 1B yield a match, then
PolicyRule 1C is evaluated. Since it is first matching, rules PolicyRule 1C is evaluated. Since it is first matching, rules
1C1, 1X2, and 1C3 are evaluated until the first match, if any. 1C1, 1X2, and 1C3 are evaluated until the first match, if any.
5.5.2. Side Effects 5.5.2. Side Effects
Although evaluation of conditions is sometimes discussed as an ordered Although evaluation of conditions is sometimes discussed as an
set of operations, the rule engine need not be implemented as a ordered set of operations, the rule engine need not be implemented as
procedural language interpreter. Any side effects of condition evaluation a procedural language interpreter. Any side effects of condition
or the execution of actions MUST NOT affect the result of the evaluation evaluation or the execution of actions MUST NOT affect the result of
of other conditions evaluated by the rule engine in the same evaluation the evaluation of other conditions evaluated by the rule engine in
pass. That is, an implementation of a rule engine MAY evaluate all the same evaluation pass. That is, an implementation of a rule
conditions in any order before applying the priority and determining engine MAY evaluate all conditions in any order before applying the
which actions are to be executed. priority and determining which actions are to be executed.
So, regardless of how a rule engine is implemented, it MUST NOT include So, regardless of how a rule engine is implemented, it MUST NOT
any side effects of condition evaluation in the evaluation of conditions include any side effects of condition evaluation in the evaluation of
for either of the decision strategies. For both the AllMatching decision conditions for either of the decision strategies. For both the
strategy and for the nesting of rules within rules (either directly or AllMatching decision strategy and for the nesting of rules within
indirectly) where the actions of more than one rule may be enforced, any rules (either directly or indirectly) where the actions of more than
side effects of the enforcement of actions MUST NOT be included in one rule may be enforced, any side effects of the enforcement of
condition evaluation on the same evaluation pass. actions MUST NOT be included in condition evaluation on the same
evaluation pass.
5.5.3. Multiple PolicySet Trees For a Resource 5.5.3. Multiple PolicySet Trees For a Resource
As shown in the example in Figure 3. , PolicySet trees are defined by the As shown in the example in Figure 3., PolicySet trees are defined by
PolicySet subclass instances and the PolicySetComponent aggregation the PolicySet subclass instances and the PolicySetComponent
instances between them. Each PolicySet tree has a defined set of aggregation instances between them. Each PolicySet tree has a
decision strategies and evaluation priorities. In section 5.6 we discuss defined set of decision strategies and evaluation priorities. In
some improvements in the use of PolicyRoles that cause the parent section 5.6 we discuss some improvements in the use of PolicyRoles
PolicySet.PolicyRoles to be applied to all contained PolicySet instances. that cause the parent PolicySet.PolicyRoles to be applied to all
However, a given resource may still have multiple, disjoint PolicySet contained PolicySet instances. However, a given resource may still
trees regardless of how they are collected. These top-level PolicySet have multiple, disjoint PolicySet trees regardless of how they are
instances are called "unrooted" relative to the given resource. collected. These top-level PolicySet instances are called "unrooted"
relative to the given resource.
So, a PolicySet instance is defined to be rooted or unrooted in the So, a PolicySet instance is defined to be rooted or unrooted in the
context of a particular managed element; the relationship to the managed context of a particular managed element; the relationship to the
element is usually established by the policy roles of the PolicySet managed element is usually established by the policy roles of the
instance and of the managed element (see 5.6 "Policy Roles"). A PolicySet instance and of the managed element (see 5.6 "Policy
PolicySet instance is unrooted in that context if and only if there is no Roles"). A PolicySet instance is unrooted in that context if and
PolicySetComponent association to a parent PolicySet that is also related only if there is no PolicySetComponent association to a parent
to the same managed element. These PolicySetComponent aggregations are PolicySet that is also related to the same managed element. These
traversed up the tree without regard to how a PolicySet instance came to PolicySetComponent aggregations are traversed up the tree without
be related with the ManagedElement. Figure 4. shows an example where regard to how a PolicySet instance came to be related with the
instance A has role A, instance B has role B and so on. In this example, ManagedElement. Figure 4. shows an example where instance A has role
in the context of interface X, instances B, and C are unrooted and A, instance B has role B and so on. In this example, in the context
instances D, E, and F are all rooted. In the context of interface Y, of interface X, instances B, and C are unrooted and instances D, E,
instance A is unrooted and instances B, C, D, E and F are all rooted. and F are all rooted. In the context of interface Y, instance A is
unrooted and instances B, C, D, E and F are all rooted.
+---+ +-----------+ +-----------+ +---+ +-----------+ +-----------+
| A | | I/F X | | I/F Y | | A | | I/F X | | I/F Y |
+---+ | has roles | | has roles | +---+ | has roles | | has roles |
/ \ | B & C | | A & B | / \ | B & C | | A & B |
/ \ +-----------+ +-----------+ / \ +-----------+ +-----------+
+---+ +---+ +---+ +---+
| B | | C | | B | | C |
+---+ +---+ +---+ +---+
/ \ \ / \ \
/ \ \ / \ \
+---+ +---+ +---+ +---+ +---+ +---+
| D | | E | | F | | D | | E | | F |
+---+ +---+ +---+ +---+ +---+ +---+
Figure 4. Unrooted PolicySet Instances Figure 4. Unrooted PolicySet Instances
For those cases where there are multiple unrooted PolicySet instances For those cases where there are multiple unrooted PolicySet instances
that apply to the same managed resource (i.e., not in a common that apply to the same managed resource (i.e., not in a common
PolicySetComponent tree), the decision strategy among these disjoint PolicySetComponent tree), the decision strategy among these disjoint
PolicySet instances is the FirstMatching strategy. The priority used PolicySet instances is the FirstMatching strategy. The priority used
with this FirstMatching strategy is defined in the PolicySetInSystem with this FirstMatching strategy is defined in the PolicySetInSystem
association. The PolicySetInSystem subclass instances are present for all association. The PolicySetInSystem subclass instances are present
PolicySet instances (it is a required association) but the priority is for all PolicySet instances (it is a required association) but the
only used as a default for unrooted PolicySet instances in a given priority is only used as a default for unrooted PolicySet instances
ManagedElement context. in a given ManagedElement context.
The FirstMatching strategy is used among all unrooted PolicySet instances The FirstMatching strategy is used among all unrooted PolicySet
that apply to a given resource for a given functional domain. So, for instances that apply to a given resource for a given functional
example, the PolicySet instances that are used for QoS policy and the domain. So, for example, the PolicySet instances that are used for
instances that are used for IKE policy, although they are disjoint, are QoS policy and the instances that are used for IKE policy, although
not joined in a FirstMatching decision strategy. Instead, they are they are disjoint, are not joined in a FirstMatching decision
evaluated independently of one another. strategy. Instead, they are evaluated independently of one another.
5.5.4. Deterministic Decisions 5.5.4. Deterministic Decisions
As previously discussed, PolicySetComponent.Priority values MUST be As previously discussed, PolicySetComponent.Priority values MUST be
unique within a containing PolicySet and PolicySetInSystem.Priority unique within a containing PolicySet and PolicySetInSystem.Priority
values MUST be unique for an associated System. Each PolicySet, then, has values MUST be unique for an associated System. Each PolicySet,
a deterministic behavior based upon the decision strategy and uniquely then, has a deterministic behavior based upon the decision strategy
defined priority. and uniquely defined priority.
There are certainly cases where rules need not have a unique priority There are certainly cases where rules need not have a unique priority
value (i.e., where evaluation and execution priority is not important). value (i.e., where evaluation and execution priority is not
However, it is believed that the flexibility gained by this capability is important). However, it is believed that the flexibility gained by
not sufficiently beneficial to justify the possible variations in this capability is not sufficiently beneficial to justify the
implementation behavior and the resulting confusion that might occur. possible variations in implementation behavior and the resulting
confusion that might occur.
5.6. Policy Roles 5.6. Policy Roles
A policy role is defined in [10] as "an administratively specified A policy role is defined in [10] as "an administratively specified
characteristic of a managed element (for example, an interface). It is a characteristic of a managed element (for example, an interface). It
selector for policy rules and PRovisioning Classes (PRCs), to determine is a selector for policy rules and PRovisioning Classes (PRCs), to
the applicability of the rule/PRC to a particular managed element." determine the applicability of the rule/PRC to a particular managed
element."
In PCIMe, PolicyRoles is defined as a property of PolicySet, which is In PCIMe, PolicyRoles is defined as a property of PolicySet, which is
inherited by both PolicyRules and PolicyGroups. In this draft, we also inherited by both PolicyRules and PolicyGroups. In this document, we
add PolicyRole as the identifying name of a collection of resources also add PolicyRole as the identifying name of a collection of
(PolicyRoleCollection), where each element in the collection has the resources (PolicyRoleCollection), where each element in the
specified role characteristic. collection has the specified role characteristic.
5.6.1. Comparison of Roles in PCIM with Roles in snmpconf 5.6.1. Comparison of Roles in PCIM with Roles in snmpconf
In the Configuration Management with SNMP (snmpconf) working group's In the Configuration Management with SNMP (snmpconf) working group's
Policy Based Management MIB [14], policy rules are of the form Policy Based Management MIB [14], policy rules are of the form
if <policyFilter> then <policyAction> if <policyFilter> then <policyAction>
where <policyFilter> is a set of conditions that are used to determine where <policyFilter> is a set of conditions that are used to
whether or not the policy applies to an object instance. The policy determine whether or not the policy applies to an object instance.
filter can perform comparison operations on SNMP variables already The policy filter can perform comparison operations on SNMP variables
defined in MIBS (e.g., "ifType == ethernet"). already defined in MIBS (e.g., "ifType == ethernet").
The policy management MIB defined in [14] defines a Role table that The policy management MIB defined in [14] defines a Role table that
enables one to associate Roles with elements, where roles have the same enables one to associate Roles with elements, where roles have the
semantics as in PCIM. Then, since the policyFilter in a policy allows one same semantics as in PCIM. Then, since the policyFilter in a policy
to define conditions based on the comparison of the values of SNMP allows one to define conditions based on the comparison of the values
variables, one can filter elements based on their roles as defined in the of SNMP variables, one can filter elements based on their roles as
Role group. defined in the Role group.
This approach differs from that adopted in PCIM in the following ways. This approach differs from that adopted in PCIM in the following
First, in PCIM, a set of role(s) is associated with a policy rule as the ways. First, in PCIM, a set of role(s) is associated with a policy
values of the PolicyRoles property of a policy rule. The semantics of rule as the values of the PolicyRoles property of a policy rule. The
role(s) are then expected to be implemented by the PDP (i.e. policies are semantics of role(s) are then expected to be implemented by the PDP
applied to the elements with the appropriate roles). In [14], however, (i.e., policies are applied to the elements with the appropriate
no special processing is required for realizing the semantics of roles; roles). In [14], however, no special processing is required for
roles are treated just as any other SNMP variables and comparisons of realizing the semantics of roles; roles are treated just as any other
role values can be included in the policy filter of a policy rule. SNMP variables and comparisons of role values can be included in the
policy filter of a policy rule.
Secondly, in PCIM, there is no formally defined way of associating a role Secondly, in PCIM, there is no formally defined way of associating a
with an object instance, whereas in [14] this is done via the use of the role with an object instance, whereas in [14] this is done via the
Role tables (pmRoleESTable and pmRoleSETable). The Role tables associate use of the Role tables (pmRoleESTable and pmRoleSETable). The Role
Role values with elements. tables associate Role values with elements.
5.6.2. Addition of PolicyRoleCollection to PCIMe 5.6.2. Addition of PolicyRoleCollection to PCIMe
In order to remedy the latter shortcoming in PCIM (the lack of a way of In order to remedy the latter shortcoming in PCIM (the lack of a way
associating a role with an object instance), PCIMe has a new class of associating a role with an object instance), PCIMe has a new class
PolicyRoleCollection derived from the CIM Collection class. Resources PolicyRoleCollection derived from the CIM Collection class.
that share a common role are aggregated by a PolicyRoleCollection Resources that share a common role are aggregated by a
instance, via the ElementInPolicyRoleCollection aggregation. The role is PolicyRoleCollection instance, via the ElementInPolicyRoleCollection
specified in the PolicyRole property of the aggregating aggregation. The role is specified in the PolicyRole property of the
PolicyRoleCollection instance. aggregating PolicyRoleCollection instance.
A PolicyRoleCollection always exists in the context of a system. As was A PolicyRoleCollection always exists in the context of a system. As
done in PCIM for PolicyRules and PolicyGroups, an association, was done in PCIM for PolicyRules and PolicyGroups, an association,
PolicyRoleCollectionInSystem, captures this relationship. Remember that PolicyRoleCollectionInSystem, captures this relationship. Remember
in CIM, System is a base class for describing network devices and that in CIM, System is a base class for describing network devices
administrative domains. and administrative domains.
The association between a PolicyRoleCollection and a system should be The association between a PolicyRoleCollection and a system should be
consistent with the associations that scope the policy rules/groups that consistent with the associations that scope the policy rules/groups
are applied to the resources in that collection. Specifically, a that are applied to the resources in that collection. Specifically,
PolicyRoleCollection should be associated with the same System as the a PolicyRoleCollection should be associated with the same System as
applicable PolicyRules and/or PolicyGroups, or to a System higher in the the applicable PolicyRules and/or PolicyGroups, or to a System higher
tree formed by the SystemComponent association. When a PEP belongs to in the tree formed by the SystemComponent association. When a PEP
multiple Systems (i.e., AdminDomains), and scoping by a single domain is belongs to multiple Systems (i.e., AdminDomains), and scoping by a
impractical, two alternatives exist. One is to arbitrarily limit domain single domain is impractical, two alternatives exist. One is to
membership to one System/AdminDomain. The other option is to define a arbitrarily limit domain membership to one System/AdminDomain. The
more global AdminDomain that simply includes the others, and/or that other option is to define a more global AdminDomain that simply
spans the business or enterprise. includes the others, and/or that spans the business or enterprise.
As an example, suppose that there are 20 traffic trunks in a network, and As an example, suppose that there are 20 traffic trunks in a network,
that an administrator would like to assign three of them to provide and that an administrator would like to assign three of them to
"gold" service. Also, the administrator has defined several policy rules provide "gold" service. Also, the administrator has defined several
which specify how the "gold" service is delivered. For these rules, the policy rules which specify how the "gold" service is delivered. For
PolicyRoles property (inherited from PolicySet) is set to "Gold Service". these rules, the PolicyRoles property (inherited from PolicySet) is
set to "Gold Service".
In order to associate three traffic trunks with "gold" service, an In order to associate three traffic trunks with "gold" service, an
instance of the PolicyRoleCollection class is created and its PolicyRole instance of the PolicyRoleCollection class is created and its
property is also set to "Gold Service". Following this, the PolicyRole property is also set to "Gold Service". Following this,
administrator associates three traffic trunks with the new instance of the administrator associates three traffic trunks with the new
PolicyRoleCollection via the ElementInPolicyRoleCollection aggregation. instance of PolicyRoleCollection via the
This enables a PDP to determine that the "Gold Service" policy rules ElementInPolicyRoleCollection aggregation. This enables a PDP to
apply to the three aggregated traffic trunks. determine that the "Gold Service" policy rules apply to the three
aggregated traffic trunks.
Note that roles are used to optimize policy retrieval. It is not Note that roles are used to optimize policy retrieval. It is not
mandatory to implement roles or, if they have been implemented, to group mandatory to implement roles or, if they have been implemented, to
elements in a PolicyRoleCollection. However, if roles are used, then group elements in a PolicyRoleCollection. However, if roles are
either the collection approach should be implemented, or elements should used, then either the collection approach should be implemented, or
be capable of reporting their "pre-programmed" roles (as is done in elements should be capable of reporting their "pre-programmed" roles
COPS). (as is done in COPS).
5.6.3. Roles for PolicyGroups 5.6.3. Roles for PolicyGroups
In PCIM, role(s) are only associated with policy rules. However, it may In PCIM, role(s) are only associated with policy rules. However, it
be desirable to associate role(s) with groups of policy rules. For may be desirable to associate role(s) with groups of policy rules.
example, a network administrator may want to define a group of rules that For example, a network administrator may want to define a group of
apply only to Ethernet interfaces. A policy group can be defined with a rules that apply only to Ethernet interfaces. A policy group can be
role-combination="Ethernet", and all the relevant policy rules can be defined with a role-combination="Ethernet", and all the relevant
placed in this policy group. (Note that in PCIMe, role(s) are made policy rules can be placed in this policy group. (Note that in
available to PolicyGroups as well as to PolicyRules by moving PCIM's PCIMe, role(s) are made available to PolicyGroups as well as to
PolicyRoles property up from PolicyRule to the new abstract class PolicyRules by moving PCIM's PolicyRoles property up from PolicyRule
PolicySet. The property is then inherited by both PolicyGroup and to the new abstract class PolicySet. The property is then inherited
PolicyRule.) Then every policy rule in this policy group implicitly by both PolicyGroup and PolicyRule.) Then every policy rule in this
inherits this role-combination from the containing policy group. A policy group implicitly inherits this role-combination from the
similar implicit inheritance applies to nested policy groups. containing policy group. A similar implicit inheritance applies to
nested policy groups.
There is no explicit copying of role(s) from container to contained There is no explicit copying of role(s) from container to contained
entity. Obviously, this implicit inheritance of role(s) leads to the entity. Obviously, this implicit inheritance of role(s) leads to the
possibility of defining inconsistent role(s) (as explained in the example possibility of defining inconsistent role(s) (as explained in the
below); the handling of such inconsistencies is beyond the scope of example below); the handling of such inconsistencies is beyond the
PCIMe. scope of PCIMe.
As an example, suppose that there is a PolicyGroup PG1 that contains As an example, suppose that there is a PolicyGroup PG1 that contains
three PolicyRules, PR1, PR2, and PR3. Assume that PG1 has the roles three PolicyRules, PR1, PR2, and PR3. Assume that PG1 has the roles
"Ethernet" and "Fast". Also, assume that the contained policy rules have "Ethernet" and "Fast". Also, assume that the contained policy rules
the role(s) shown below: have the role(s) shown below:
+------------------------------+ +------------------------------+
| PolicyGroup PG1 | | PolicyGroup PG1 |
| PolicyRoles = Ethernet, Fast | | PolicyRoles = Ethernet, Fast |
+------------------------------+ +------------------------------+
| |
| +------------------------+ | +------------------------+
| | PolicyRule PR1 | | | PolicyRule PR1 |
|--------| PolicyRoles = Ethernet | |--------| PolicyRoles = Ethernet |
| +------------------------+ | +------------------------+
skipping to change at page 25, line 44 skipping to change at page 26, line 33
| +--------------------------+ | +--------------------------+
| |
| +------------------------+ | +------------------------+
| | PolicyRule PR3 | | | PolicyRule PR3 |
|--------| PolicyRoles = Slow | |--------| PolicyRoles = Slow |
+------------------------+ +------------------------+
Figure 5. Inheritance of Roles Figure 5. Inheritance of Roles
In this example, the PolicyRoles property value for PR1 is consistent In this example, the PolicyRoles property value for PR1 is consistent
with the value in PG1, and in fact, did not need to be redefined. The with the value in PG1, and in fact, did not need to be redefined. The
value of PolicyRoles for PR2 is undefined. Its roles are implicitly value of PolicyRoles for PR2 is undefined. Its roles are implicitly
inherited from PG1. Lastly, the value of PolicyRoles for PR3 is "Slow". inherited from PG1. Lastly, the value of PolicyRoles for PR3 is
This appears to be in conflict with the role, "Fast," defined in PG1. "Slow". This appears to be in conflict with the role, "Fast,"
However, whether these roles are actually in conflict is not clear. In defined in PG1. However, whether these roles are actually in
one scenario, the policy administrator may have wanted only "Fast"- conflict is not clear. In one scenario, the policy administrator
"Ethernet" rules in the policy group. In another scenario, the may have wanted only "Fast"- "Ethernet" rules in the policy group.
administrator may be indicating that PR3 applies to all "Ethernet" In another scenario, the administrator may be indicating that PR3
interfaces regardless of whether they are "Fast" or "Slow." Only in the applies to all "Ethernet" interfaces regardless of whether they are
former scenario (only "Fast"-"Ethernet" rules in the policy group) is "Fast" or "Slow." Only in the former scenario (only "Fast"-
there a role conflict. "Ethernet" rules in the policy group) is there a role conflict.
Note that it is possible to override implicitly inherited roles via Note that it is possible to override implicitly inherited roles via
appropriate conditions on a PolicyRule. For example, suppose that PR3 appropriate conditions on a PolicyRule. For example, suppose that
above had defined the following conditions: PR3 above had defined the following conditions:
(interface is not "Fast") and (interface is "Slow") (interface is not "Fast") and (interface is "Slow")
This results in unambiguous semantics for PR3. This results in unambiguous semantics for PR3.
5.7. Compound Policy Conditions and Compound Policy Actions 5.7. Compound Policy Conditions and Compound Policy Actions
Compound policy conditions and compound policy actions are introduced to Compound policy conditions and compound policy actions are introduced
provide additional reusable "chunks" of policy. to provide additional reusable "chunks" of policy.
5.7.1. Compound Policy Conditions 5.7.1. Compound Policy Conditions
A CompoundPolicyCondition is a PolicyCondition representing a Boolean A CompoundPolicyCondition is a PolicyCondition representing a Boolean
combination of simpler conditions. The conditions being combined may be combination of simpler conditions. The conditions being combined may
SimplePolicyConditions (discussed below in Section 6.4), but the utility be SimplePolicyConditions (discussed below in Section 6.4), but the
of reusable combinations of policy conditions is not necessarily limited utility of reusable combinations of policy conditions is not
to the case where the component conditions are simple ones. necessarily limited to the case where the component conditions are
simple ones.
The PCIM extensions to introduce compound policy conditions are The PCIM extensions to introduce compound policy conditions are
relatively straightforward. Since the purpose of the extension is to relatively straightforward. Since the purpose of the extension is to
apply the DNF / CNF logic from PCIM's PolicyConditionInPolicyRule apply the DNF / CNF logic from PCIM's PolicyConditionInPolicyRule
aggregation to a compound condition that aggregates simpler conditions, aggregation to a compound condition that aggregates simpler
the following changes are required: conditions, the following changes are required:
o Create a new aggregation PolicyConditionInPolicyCondition, with the o Create a new aggregation PolicyConditionInPolicyCondition, with
same GroupNumber and ConditionNegated properties as the same GroupNumber and ConditionNegated properties as
PolicyConditionInPolicyRule. The cleanest way to do this is to PolicyConditionInPolicyRule. The cleanest way to do this is to
move the properties up to a new abstract aggregation superclass move the properties up to a new abstract aggregation superclass
PolicyConditionStructure, from which the existing aggregation PolicyConditionStructure, from which the existing aggregation
PolicyConditionInPolicyRule and a new aggregation PolicyConditionInPolicyRule and a new aggregation
PolicyConditionInPolicyCondition are derived. For now there is no PolicyConditionInPolicyCondition are derived. For now there is no
need to re-document the properties themselves, since they are need to re-document the properties themselves, since they are
already documented in PCIM as part of the definition of the already documented in PCIM as part of the definition of the
PolicyConditionInPolicyRule aggregation. PolicyConditionInPolicyRule aggregation.
o It is also necessary to define a concrete subclass
CompoundPolicyCondition of PolicyCondition, to introduce the o It is also necessary to define a concrete subclass
ConditionListType property. This property has the same function, CompoundPolicyCondition of PolicyCondition, to introduce the
and works in exactly the same way, as the corresponding property ConditionListType property. This property has the same function,
currently defined in PCIM for the PolicyRule class. and works in exactly the same way, as the corresponding property
currently defined in PCIM for the PolicyRule class.
The class and property definitions for representing compound policy The class and property definitions for representing compound policy
conditions are below, in Section 6. conditions are below, in Section 6.
5.7.2. Compound Policy Actions 5.7.2. Compound Policy Actions
A compound action is a convenient construct to represent a sequence of A compound action is a convenient construct to represent a sequence
actions to be applied as a single atomic action within a policy rule. In of actions to be applied as a single atomic action within a policy
many cases, actions are related to each other and should be looked upon rule. In many cases, actions are related to each other and should be
as sub-actions of one "logical" action. An example of such a logical looked upon as sub-actions of one "logical" action. An example of
action is "shape & mark" (i.e., shape a certain stream to a set of such a logical action is "shape & mark" (i.e., shape a certain stream
predefined bandwidth characteristics and then mark these packets with a to a set of predefined bandwidth characteristics and then mark these
certain DSCP value). This logical action is actually composed of two packets with a certain DSCP value). This logical action is actually
different QoS actions, which should be performed in a well-defined order composed of two different QoS actions, which should be performed in a
and as a complete set. well-defined order and as a complete set.
The CompoundPolicyAction construct allows one to create a logical The CompoundPolicyAction construct allows one to create a logical
relationship between a number of actions, and to define the activation relationship between a number of actions, and to define the
logic associated with this logical action. activation logic associated with this logical action.
The CompoundPolicyAction construct allows the reusability of these The CompoundPolicyAction construct allows the reusability of these
complex actions, by storing them in a ReusablePolicyContainer and reusing complex actions, by storing them in a ReusablePolicyContainer and
them in different policy rules. Note that a compound action may also be reusing them in different policy rules. Note that a compound action
aggregated by another compound action. may also be aggregated by another compound action.
As was the case with CompoundPolicyCondition, the PCIM extensions to As was the case with CompoundPolicyCondition, the PCIM extensions to
introduce compound policy actions are relatively straightforward. This introduce compound policy actions are relatively straightforward.
time the goal is to apply the property ActionOrder from PCIM's This time the goal is to apply the property ActionOrder from PCIM's
PolicyActionInPolicyRule aggregation to a compound action that aggregates PolicyActionInPolicyRule aggregation to a compound action that
simpler actions. The following changes are required: aggregates simpler actions. The following changes are required:
o Create a new aggregation PolicyActionInPolicyAction, with the same o Create a new aggregation PolicyActionInPolicyAction, with the same
ActionOrder property as PolicyActionInPolicyRule. The cleanest way ActionOrder property as PolicyActionInPolicyRule. The cleanest
to do this is to move the property up to a new abstract aggregation way to do this is to move the property up to a new abstract
superclass PolicyActionStructure, from which the existing aggregation superclass PolicyActionStructure, from which the
aggregation PolicyActionInPolicyRule and a new aggregation existing aggregation PolicyActionInPolicyRule and a new
PolicyActionInPolicyAction are derived. aggregation PolicyActionInPolicyAction are derived.
o It is also necessary to define a concrete subclass
CompoundPolicyAction of PolicyAction, to introduce the o It is also necessary to define a concrete subclass
SequencedActions property. This property has the same function, CompoundPolicyAction of PolicyAction, to introduce the
and works in exactly the same way, as the corresponding property SequencedActions property. This property has the same function,
currently defined in PCIM for the PolicyRule class. and works in exactly the same way, as the corresponding property
o Finally, a new property ExecutionStrategy is needed for both the currently defined in PCIM for the PolicyRule class.
PCIM class PolicyRule and the new class CompoundPolicyAction. This
property allows the policy administrator to specify how the PEP o Finally, a new property ExecutionStrategy is needed for both the
should behave in the case where there are multiple actions PCIM class PolicyRule and the new class CompoundPolicyAction. This
aggregated by a PolicyRule or by a CompoundPolicyAction. property allows the policy administrator to specify how the PEP
should behave in the case where there are multiple actions
aggregated by a PolicyRule or by a CompoundPolicyAction.
The class and property definitions for representing compound policy The class and property definitions for representing compound policy
actions are below, in Section 6. actions are below, in Section 6.
5.8. Variables and Values 5.8. Variables and Values
The following subsections introduce several related concepts, including The following subsections introduce several related concepts,
PolicyVariables and PolicyValues (and their numerous subclasses), including PolicyVariables and PolicyValues (and their numerous
SimplePolicyConditions, and SimplePolicyActions. subclasses), SimplePolicyConditions, and SimplePolicyActions.
5.8.1. Simple Policy Conditions 5.8.1. Simple Policy Conditions
The SimplePolicyCondition class models elementary Boolean expressions of The SimplePolicyCondition class models elementary Boolean expressions
the form: "(<variable> MATCH <value>)". The relationship 'MATCH', which of the form: "(<variable> MATCH <value>)". The relationship 'MATCH',
is implicit in the model, is interpreted based on the variable and the which is implicit in the model, is interpreted based on the variable
value. Section 5.8.3 explains the semantics of the 'MATCH' operator. and the value. Section 5.8.3 explains the semantics of the 'MATCH'
Arbitrarily complex Boolean expressions can be formed by chaining operator. Arbitrarily complex Boolean expressions can be formed by
together any number of simple conditions using relational operators. chaining together any number of simple conditions using relational
Individual simple conditions can be negated as well. Arbitrarily complex operators. Individual simple conditions can be negated as well.
Boolean expressions are modeled by the class CompoundPolicyCondition Arbitrarily complex Boolean expressions are modeled by the class
(described in Section 5.7.1). CompoundPolicyCondition (described in Section 5.7.1).
For example, the expression "SourcePort == 80" can be modeled by a simple For example, the expression "SourcePort == 80" can be modeled by a
condition. In this example, 'SourcePort' is a variable, '==' is the simple condition. In this example, 'SourcePort' is a variable, '=='
relational operator denoting the equality relationship (which is is the relational operator denoting the equality relationship (which
generalized by PCIMe to a "MATCH" relationship), and '80' is an integer is generalized by PCIMe to a "MATCH" relationship), and '80' is an
value. The complete interpretation of a simple condition depends on the integer value. The complete interpretation of a simple condition
binding of the variable. Section 5.8.5 describes variables and their depends on the binding of the variable. Section 5.8.5 describes
binding rules. variables and their binding rules.
The SimplePolicyCondition class refines the basic structure of the The SimplePolicyCondition class refines the basic structure of the
PolicyCondition class defined in PCIM by using the pair (<variable>, PolicyCondition class defined in PCIM by using the pair (<variable>,
<value>) to form the condition. Note that the operator between the <value>) to form the condition. Note that the operator between the
variable and the value is always implied in PCIMe: it is not a part of variable and the value is always implied in PCIMe: it is not a part
the formal notation. of the formal notation.
The variable specifies the attribute of an object that should be matched The variable specifies the attribute of an object that should be
when evaluating the condition. For example, for a QoS model, this object matched when evaluating the condition. For example, for a QoS model,
could represent the flow that is being conditioned. A set of predefined this object could represent the flow that is being conditioned. A
variables that cover network attributes commonly used for filtering is set of predefined variables that cover network attributes commonly
introduced in PCIMe, to encourage interoperability. This list covers used for filtering is introduced in PCIMe, to encourage
layer 3 IP attributes such as IP network addresses, protocols and ports, interoperability. This list covers layer 3 IP attributes such as IP
as well as a set of layer 2 attributes (e.g., MAC addresses). network addresses, protocols and ports, as well as a set of layer 2
attributes (e.g., MAC addresses).
The bound variable is matched against a value to produce the Boolean The bound variable is matched against a value to produce the Boolean
result. For example, in the condition "The source IP address of the flow result. For example, in the condition "The source IP address of the
belongs to the 10.1.x.x subnet", a source IP address variable is matched flow belongs to the 10.1.x.x subnet", a source IP address variable is
against a 10.1.x.x subnet value. matched against a 10.1.x.x subnet value.
5.8.2. Using Simple Policy Conditions 5.8.2. Using Simple Policy Conditions
Simple conditions can be used in policy rules directly, or as building Simple conditions can be used in policy rules directly, or as
blocks for creating compound policy conditions. building blocks for creating compound policy conditions.
Simple condition composition MUST enforce the following data-type Simple condition composition MUST enforce the following data-type
conformance rule: The ValueTypes property of the variable must be conformance rule: The ValueTypes property of the variable must be
compatible with the type of the value class used. The simplest (and compatible with the type of the value class used. The simplest (and
friendliest, from a user point-of-view) way to do this is to equate the friendliest, from a user point-of-view) way to do this is to equate
type of the value class with the name of the class. By ensuring that the the type of the value class with the name of the class. By ensuring
ValueTypes property of the variable matches the name of the value class that the ValueTypes property of the variable matches the name of the
used, we know that the variable and value instance values are compatible value class used, we know that the variable and value instance values
with each other. are compatible with each other.
Composing a simple condition requires that an instance of the class Composing a simple condition requires that an instance of the class
SimplePolicyCondition be created, and that instances of the variable and SimplePolicyCondition be created, and that instances of the variable
value classes that it uses also exist. Note that the variable and/or and value classes that it uses also exist. Note that the variable
value instances may already exist as reusable objects in an appropriate and/or value instances may already exist as reusable objects in an
ReusablePolicyContainer. appropriate ReusablePolicyContainer.
Two aggregations are used in order to create the pair (<variable>, Two aggregations are used in order to create the pair (<variable>,
<value>). The aggregation PolicyVariableInSimplePolicyCondition relates <value>). The aggregation PolicyVariableInSimplePolicyCondition
a SimplePolicyCondition to a single variable instance. Similarly, the relates a SimplePolicyCondition to a single variable instance.
aggregation PolicyValueInSimplePolicyCondition relates a Similarly, the aggregation PolicyValueInSimplePolicyCondition relates
SimplePolicyCondition to a single value instance. Both aggregations are a SimplePolicyCondition to a single value instance. Both
defined in this document. aggregations are defined in this document.
Figure 6. depicts a SimplePolicyCondition with its associated variable Figure 6. depicts a SimplePolicyCondition with its associated
and value. Also shown are two PolicyValue instances that identify the variable and value. Also shown are two PolicyValue instances that
values that the variable can assume. identify the values that the variable can assume.
+-----------------------+ +-----------------------+
| SimplePolicyCondition | | SimplePolicyCondition |
+-----------------------+ +-----------------------+
* @ * @
* @ * @
+------------------+ * @ +---------------+ +------------------+ * @ +---------------+
| (PolicyVariable) |*** @@@| (PolicyValue) | | (PolicyVariable) |*** @@@| (PolicyValue) |
+------------------+ +---------------+ +------------------+ +---------------+
# # # #
skipping to change at page 29, line 44 skipping to change at page 31, line 5
**** PolicyVariableInSimplePolicyCondition **** PolicyVariableInSimplePolicyCondition
@@@@ PolicyValueInSimplePolicyCondition @@@@ PolicyValueInSimplePolicyCondition
#### ExpectedPolicyValuesForVariable #### ExpectedPolicyValuesForVariable
Figure 6. SimplePolicyCondition Figure 6. SimplePolicyCondition
Note: The class names in parenthesis denote subclasses. The classes Note: The class names in parenthesis denote subclasses. The classes
named in the figure are abstract, and thus cannot themselves be named in the figure are abstract, and thus cannot themselves be
instantiated. instantiated.
5.8.3. The Simple Condition Operator 5.8.3. The Simple Condition Operator
A simple condition models an elementary Boolean expression of the form A simple condition models an elementary Boolean expression of the
"variable MATCHes value". However, the formal notation of the form "variable MATCHes value". However, the formal notation of the
SimplePolicyCondition, together with its associations, models only a SimplePolicyCondition, together with its associations, models only a
pair, (<variable>, <value>). The 'MATCH' operator is not directly pair, (<variable>, <value>). The 'MATCH' operator is not directly
modeled -- it is implied. Furthermore, this implied 'MATCH' operator modeled -- it is implied. Furthermore, this implied 'MATCH' operator
carries overloaded semantics. carries overloaded semantics.
For example, in the simple condition "DestinationPort MATCH '80'", the For example, in the simple condition "DestinationPort MATCH '80'",
interpretation of the 'MATCH' operator is equality (the 'equal' the interpretation of the 'MATCH' operator is equality (the 'equal'
operator). Clearly, a different interpretation is needed in the operator). Clearly, a different interpretation is needed in the
following cases: following cases:
o "DestinationPort MATCH {'80', '8080'}" -- operator is 'IS SET o "DestinationPort MATCH {'80', '8080'}" -- operator is 'IS SET
MEMBER' MEMBER'
o "DestinationPort MATCH {'1 to 255'}" -- operator is 'IN INTEGER o "DestinationPort MATCH {'1 to 255'}" -- operator is 'IN INTEGER
RANGE' RANGE'
o "SourceIPAddress MATCH 'MyCompany.com'" -- operator is 'IP ADDRESS o "SourceIPAddress MATCH 'MyCompany.com'" -- operator is 'IP ADDRESS
AS RESOLVED BY DNS' AS RESOLVED BY DNS'
The examples above illustrate the implicit, context-dependant nature of The examples above illustrate the implicit, context-dependent nature
the 'MATCH' operator. The interpretation depends on the actual variable of the 'MATCH' operator. The interpretation depends on the actual
and value instances in the simple condition. The interpretation is variable and value instances in the simple condition. The
always derived from the bound variable and the value instance associated interpretation is always derived from the bound variable and the
with the simple condition. Text accompanying the value class and value instance associated with the simple condition. Text
implicit variable definition is used for interpreting the semantics of accompanying the value class and implicit variable definition is used
the 'MATCH' relationship. In the following list, we define generic for interpreting the semantics of the 'MATCH' relationship. In the
(type-independent) matching. following list, we define generic (type-independent) matching.
PolicyValues may be multi-fielded, where each field may contain a range PolicyValues may be multi-fielded, where each field may contain a
of values. The same equally holds for PolicyVariables. Basically, we range of values. The same equally holds for PolicyVariables.
have to deal with single values (singleton), ranges ([lower bound .. Basically, we have to deal with single values (singleton), ranges
upper bound]), and sets (a,b,c). So independent of the variable and ([lower bound .. upper bound]), and sets (a,b,c). So independent of
value type, the following set of generic matching rules for the 'MATCH' the variable and value type, the following set of generic matching
operator are defined. rules for the 'MATCH' operator are defined.
o singleton matches singleton -> the matching rule is defined in the o singleton matches singleton -> the matching rule is defined in the
type type
o singleton matches range [lower bound .. upper bound] -> the o singleton matches range [lower bound .. upper bound] -> the
matching evaluates to true, if the singleton matches the lower matching evaluates to true, if the singleton matches the lower
bound or the upper bound or a value in between bound or the upper bound or a value in between
o singleton matches set -> the matching evaluates to true, if the o singleton matches set -> the matching evaluates to true, if the
value of the singleton matches one of the components in the set, value of the singleton matches one of the components in the set,
where a component may be a singleton or range again where a component may be a singleton or range again
o ranges [A..B] matches singleton -> is true if A matches B matches o ranges [A..B] matches singleton -> is true if A matches B matches
singleton singleton
o range [A..B] matches range [X..Y] -> the matching evaluates to o range [A..B] matches range [X..Y] -> the matching evaluates to
true, if all values of the range [A..B] are also in the range true, if all values of the range [A..B] are also in the range
[X..Y]. For instance, [3..5] match [1..6] evaluates to true, [X..Y]. For instance, [3..5] match [1..6] evaluates to true,
whereas [3..5] match [4..6] evaluates to false. whereas [3..5] match [4..6] evaluates to false.
o range [A..B] matches set (a,b,c, ...) -> the matching evaluates to o range [A..B] matches set (a,b,c, ...) -> the matching evaluates to
true, if all values in the range [A..B] are part of the set. For true, if all values in the range [A..B] are part of the set. For
instance, range [2..3] match set ([1..2],3) evaluates to true, as instance, range [2..3] match set ([1..2],3) evaluates to true, as
well as range [2..3] match set (2,3), and range [2..3] match set well as range [2..3] match set (2,3), and range [2..3] match set
([1..2],[3..5]). ([1..2],[3..5]).
o set (a,b,c, ...) match singleton -> is true if a match b match c o set (a,b,c, ...) match singleton -> is true if a match b match c
match ... match singleton match ... match singleton
o set match range -> the matching evaluates to true, if all values o set match range -> the matching evaluates to true, if all values
in the set are part of the range. For example, set (2,3) match in the set are part of the range. For example, set (2,3) match
range [1..4] evaluates to true. range [1..4] evaluates to true.
o set (a,b,c,...) match set (x,y,z,...) -> the matching evaluates to o set (a,b,c,...) match set (x,y,z,...) -> the matching evaluates to
true, if all values in the set (a,b,c,...) are part of the set true, if all values in the set (a,b,c,...) are part of the set
(x,y,z,...). For example, set (1,2,3) match set (1,2,3,4) (x,y,z,...). For example, set (1,2,3) match set (1,2,3,4)
evaluates to true. Set (1,2,3) match set (1,2) evaluates to evaluates to true. Set (1,2,3) match set (1,2) evaluates to
false. false.
Variables may contain various types (Section 6.11.1). When not stated Variables may contain various types (Section 6.11.1). When not
otherwise, the type of the value bound to the variable at condition stated otherwise, the type of the value bound to the variable at
evaluation time and the value type of the PolicyValue instance need to be condition evaluation time and the value type of the PolicyValue
of the same type. If they differ, then the condition evaluates to FALSE. instance need to be of the same type. If they differ, then the
condition evaluates to FALSE.
The ExpectedPolicyValuesForVariable association specifies an expected set The ExpectedPolicyValuesForVariable association specifies an expected
of values that can be matched with a variable within a simple condition. set of values that can be matched with a variable within a simple
Using this association, a source or destination port can be limited to condition. Using this association, a source or destination port can
the range 0-200, a source or destination IP address can be limited to a be limited to the range 0-200, a source or destination IP address can
specified list of IPv4 address values, etc. be limited to a specified list of IPv4 address values, etc.
+-----------------------+ +-----------------------+
| SimplePolicyCondition | | SimplePolicyCondition |
+-----------------------+ +-----------------------+
* @ * @
* @ * @
* @ * @
+-----------------------------------+ +--------------------------+ +-----------------------------------+ +--------------------------+
| Name=SmallSourcePorts | | Name=Port300 | | Name=SmallSourcePorts | | Name=Port300 |
| Class=PolicySourcePortVariable | | Class=PolicyIntegerValue | | Class=PolicySourcePortVariable | | Class=PolicyIntegerValue |
| ValueTypes=[PolicyIntegerValue] | | IntegerList = [300] | | ValueTypes=[PolicyIntegerValue] | | IntegerList = [300] |
+-----------------------------------+ +--------------------------+ +-----------------------------------+ +--------------------------+
# #
# #
# #
+-------------------------+ +-------------------------+
|Name=SmallPortsValues | |Name=SmallPortsValues |
|Class=PolicyIntegerValue | |Class=PolicyIntegerValue |
|IntegerList=[1..200] | |IntegerList=[1..200] |
+-------------------------+ +-------------------------+
Aggregation Legend: Aggregation Legend:
**** PolicyVariableInSimplePolicyCondition **** PolicyVariableInSimplePolicyCondition
@@@@ PolicyValueInSimplePolicyCondition @@@@ PolicyValueInSimplePolicyCondition
#### ExpectedPolicyValuesForVariable #### ExpectedPolicyValuesForVariable
Figure 7. An Invalid SimplePolicyCondition Figure 7. An Invalid SimplePolicyCondition
The ability to express these limitations appears in the model to support
validation of a SimplePolicyCondition prior to its deployment to an
enforcement point. A Policy Management Tool, for example SHOULD NOT
accept the SimplePolicyCondition shown in Figure 7. If, however, a
policy rule containing this condition does appear at an enforcement
point, the expected values play no role in the determination of whether
the condition evaluates to True or False. Thus in this example, the
SimplePolicyCondition evaluates to True if the source port for the packet
under consideration is 300, and it evaluates to False otherwise.
5.8.4. SimplePolicyActions The ability to express these limitations appears in the model to
support validation of a SimplePolicyCondition prior to its deployment
to an enforcement point. A Policy Management Tool, for example
SHOULD NOT accept the SimplePolicyCondition shown in Figure 7. If,
however, a policy rule containing this condition does appear at an
enforcement point, the expected values play no role in the
determination of whether the condition evaluates to True or False.
Thus in this example, the SimplePolicyCondition evaluates to True if
the source port for the packet under consideration is 300, and it
evaluates to False otherwise.
The SimplePolicyAction class models the elementary set operation. "SET 5.8.4. SimplePolicyActions
<variable> TO <value>". The set operator MUST overwrite an old value of
the variable. In the case where the variable to be updated is multi- The SimplePolicyAction class models the elementary set operation.
valued, the only update operation defined is a complete replacement of "SET <variable> TO <value>". The set operator MUST overwrite an old
all previous values with a new set. In other words, there are no Add or value of the variable. In the case where the variable to be updated
Remove [to/from the set of values] operations defined for is multi- valued, the only update operation defined is a complete
SimplePolicyActions. replacement of all previous values with a new set. In other words,
there are no Add or Remove [to/from the set of values] operations
defined for SimplePolicyActions.
For example, the action "set DSCP to EF" can be modeled by a simple For example, the action "set DSCP to EF" can be modeled by a simple
action. In this example, 'DSCP' is an implicit variable referring to the action. In this example, 'DSCP' is an implicit variable referring to
IP packet header DSCP field. 'EF' is an integer or bit string value (6 the IP packet header DSCP field. 'EF' is an integer or bit string
bits). The complete interpretation of a simple action depends on the value (6 bits). The complete interpretation of a simple action
binding of the variable. depends on the binding of the variable.
The SimplePolicyAction class refines the basic structure of the The SimplePolicyAction class refines the basic structure of the
PolicyAction class defined in PCIM, by specifying the contents of the PolicyAction class defined in PCIM, by specifying the contents of the
action using the (<variable>, <value>) pair to form the action. The action using the (<variable>, <value>) pair to form the action. The
variable specifies the attribute of an object. The value of this variable specifies the attribute of an object. The value of this
attribute is set to the value specified in <value>. Selection of the attribute is set to the value specified in <value>. Selection of the
object is a function of the type of variable involved. See Sections object is a function of the type of variable involved. See Sections
5.8.6 and 5.8.7, respectively, for details on object selection for 5.8.6 and 5.8.7, respectively, for details on object selection for
explicitly bound and implicitly bound policy variables. explicitly bound and implicitly bound policy variables.
SimplePolicyActions can be used in policy rules directly, or as building SimplePolicyActions can be used in policy rules directly, or as
blocks for creating CompoundPolicyActions. building blocks for creating CompoundPolicyActions.
The set operation is only valid if the list of types of the variable The set operation is only valid if the list of types of the variable
(ValueTypes property of PolicyImplicitVariable) includes the specified (ValueTypes property of PolicyImplicitVariable) includes the
type of the value. Conversion of values from one representation into specified type of the value. Conversion of values from one
another is not defined. For example, a variable of IPv4Address type may representation into another is not defined. For example, a variable
not be set to a string containing a DNS name. Conversions are part of an of IPv4Address type may not be set to a string containing a DNS name.
implementation-specific mapping of the model. Conversions are part of an implementation-specific mapping of the
model.
As was the case with SimplePolicyConditions, the role of expected values As was the case with SimplePolicyConditions, the role of expected
for the variables that appear in SimplePolicyActions is for validation, values for the variables that appear in SimplePolicyActions is for
prior to the time when an action is executed. Expected values play no validation, prior to the time when an action is executed. Expected
role in action execution. values play no role in action execution.
Composing a simple action requires that an instance of the class Composing a simple action requires that an instance of the class
SimplePolicyAction be created, and that instances of the variable and SimplePolicyAction be created, and that instances of the variable and
value classes that it uses also exist. Note that the variable and/or value classes that it uses also exist. Note that the variable and/or
value instances may already exist as reusable objects in an appropriate value instances may already exist as reusable objects in an
ReusablePolicyContainer. appropriate ReusablePolicyContainer.
Two aggregations are used in order to create the pair (<variable>, Two aggregations are used in order to create the pair (<variable>,
<value>). The aggregation PolicyVariableInSimplePolicyAction relates a <value>). The aggregation PolicyVariableInSimplePolicyAction relates
SimplePolicyAction to a single variable instance. Similarly, the a SimplePolicyAction to a single variable instance. Similarly, the
aggregation PolicyValueInSimplePolicyAction relates a SimplePolicyAction aggregation PolicyValueInSimplePolicyAction relates a
to a single value instance. Both aggregations are defined in this SimplePolicyAction to a single value instance. Both aggregations are
document. defined in this document.
Figure 8. depicts a SimplePolicyAction with its associated variable and Figure 8. depicts a SimplePolicyAction with its associated variable
value. and value.
+-----------------------+ +-----------------------+
| SimplePolicyAction | | SimplePolicyAction |
| | | |
+-----------------------+ +-----------------------+
* @ * @
* @ * @
+------------------+ * @ +---------------+ +------------------+ * @ +---------------+
| (PolicyVariable) |*** @@@| (PolicyValue) | | (PolicyVariable) |*** @@@| (PolicyValue) |
+------------------+ +---------------+ +------------------+ +---------------+
# # # #
# ooo # # ooo #
# # # #
+---------------+ +---------------+ +---------------+ +---------------+
| (PolicyValue) | ooo | (PolicyValue) | | (PolicyValue) | ooo | (PolicyValue) |
+---------------+ +---------------+ +---------------+ +---------------+
Aggregation Legend: Aggregation Legend:
**** PolicyVariableInSimplePolicyAction **** PolicyVariableInSimplePolicyAction
@@@@ PolicyValueInSimplePolicyAction @@@@ PolicyValueInSimplePolicyAction
#### ExpectedPolicyValuesForVariable #### ExpectedPolicyValuesForVariable
Figure 8. SimplePolicyAction Figure 8. SimplePolicyAction
5.8.5. Policy Variables 5.8.5. Policy Variables
A variable generically represents information that changes (or "varies"), A variable generically represents information that changes (or
and that is set or evaluated by software. In policy, conditions and "varies"), and that is set or evaluated by software. In policy,
actions can abstract information as "policy variables" to be evaluated in conditions and actions can abstract information as "policy variables"
logical expressions, or set by actions. to be evaluated in logical expressions, or set by actions.
PCIMe defines two types of PolicyVariables, PolicyImplicitVariables and PCIMe defines two types of PolicyVariables, PolicyImplicitVariables
PolicyExplicitVariables. The semantic difference between these classes and PolicyExplicitVariables. The semantic difference between these
is based on modeling context. Explicit variables are bound to exact classes is based on modeling context. Explicit variables are bound
model constructs, while implicit variables are defined and evaluated to exact model constructs, while implicit variables are defined and
outside of a model. For example, one can imagine a PolicyCondition evaluated outside of a model. For example, one can imagine a
testing whether a CIM ManagedSystemElement's Status property has the PolicyCondition testing whether a CIM ManagedSystemElement's Status
value "Error." The Status property is an explicitly defined property has the value "Error." The Status property is an explicitly
PolicyVariable (i.e., it is defined in the context of the CIM Schema, and defined PolicyVariable (i.e., it is defined in the context of the CIM
evaluated in the context of a specific instance). On the other hand, Schema, and evaluated in the context of a specific instance). On the
network packets are not explicitly modeled or instantiated, since there other hand, network packets are not explicitly modeled or
is no perceived value (at this time) in managing at the packet level. instantiated, since there is no perceived value (at this time) in
Therefore, a PolicyCondition can make no explicit reference to a model managing at the packet level. Therefore, a PolicyCondition can make
construct that represents a network packet's source address. In this no explicit reference to a model construct that represents a network
case, an implicit PolicyVariable is defined, to allow evaluation or packet's source address. In this case, an implicit PolicyVariable is
modification of a packet's source address. defined, to allow evaluation or modification of a packet's source
address.
5.8.6. Explicitly Bound Policy Variables 5.8.6. Explicitly Bound Policy Variables
Explicitly bound policy variables indicate the class and property names Explicitly bound policy variables indicate the class and property
of the model construct to be evaluated or set. The CIM Schema defines names of the model construct to be evaluated or set. The CIM Schema
and constrains "appropriate" values for the variable (i.e., model defines and constrains "appropriate" values for the variable (i.e.,
property) using data types and other information such as class/property model property) using data types and other information such as
qualifiers. class/property qualifiers.
A PolicyExplicitVariable is "explicit" because its model semantics are A PolicyExplicitVariable is "explicit" because its model semantics
exactly defined. It is NOT explicit due to an exact binding to a are exactly defined. It is NOT explicit due to an exact binding to a
particular object instance. If PolicyExplicitVariables were tied to particular object instance. If PolicyExplicitVariables were tied to
instances (either via associations or by an object identification instances (either via associations or by an object identification
property in the class itself), then we would be forcing element-specific property in the class itself), then we would be forcing element-
rules. On the other hand, if we only specify the object's model context specific rules. On the other hand, if we only specify the object's
(class and property name), but leave the binding to the policy framework model context (class and property name), but leave the binding to the
(for example, using policy roles), then greater flexibility results for policy framework (for example, using policy roles), then greater
either general or element-specific rules. flexibility results for either general or element-specific rules.
For example, an element-specific rule is obtained by a condition For example, an element-specific rule is obtained by a condition
((<variable>, <value>) pair) that defines CIM LogicalDevice ((<variable>, <value>) pair) that defines CIM LogicalDevice
DeviceID="12345". Alternately, if a PolicyRule's PolicyRoles is "edge DeviceID="12345". Alternately, if a PolicyRule's PolicyRoles is
device" and the condition ((<variable>, <value>) pair) is Status="Error", "edge device" and the condition ((<variable>, <value>) pair) is
then a general rule results for all edge devices in error. Status="Error", then a general rule results for all edge devices in
error.
Currently, the only binding for a PolicyExplicitVariable defined in PCIMe Currently, the only binding for a PolicyExplicitVariable defined in
is to the instances selected by policy roles. For each such instance, a PCIMe is to the instances selected by policy roles. For each such
SimplePolicyCondition that aggregates the PolicyExplicitVariable instance, a SimplePolicyCondition that aggregates the
evaluates to True if and only if ALL of the following are true: PolicyExplicitVariable evaluates to True if and only if ALL of the
following are true:
o The instance selected is of the class identified by the variable's o The instance selected is of the class identified by the variable's
ModelClass property, or of a subclass of this class. ModelClass property, or of a subclass of this class.
o The instance selected has the property identified by the o The instance selected has the property identified by the
variable's ModelProperty property. variable's ModelProperty property.
o The value of this property in the instance matches the value o The value of this property in the instance matches the value
specified in the PolicyValue aggregated by the condition. specified in the PolicyValue aggregated by the condition.
In all other cases, the SimplePolicyCondition evaluates to False. In all other cases, the SimplePolicyCondition evaluates to False.
For the case where a SimplePolicyAction aggregates a For the case where a SimplePolicyAction aggregates a
PolicyExplicitVariable, the indicated property in the selected instance PolicyExplicitVariable, the indicated property in the selected
is set to the value represented by the PolicyValue that the instance is set to the value represented by the PolicyValue that the
SimplePolicyAction also aggregates. However, if the selected instance is SimplePolicyAction also aggregates. However, if the selected
not of the class identified by the variable's ModelClass property, or of instance is not of the class identified by the variable's ModelClass
a subclass of this class, then the action is not performed. In this case property, or of a subclass of this class, then the action is not
the SimplePolicyAction is not treated either as a successfully executed performed. In this case the SimplePolicyAction is not treated either
action (for the execution strategy Do Until Success) or as a failed as a successfully executed action (for the execution strategy Do
action (for the execution strategy Do Until Failure). Instead, the Until Success) or as a failed action (for the execution strategy Do
remaining actions for the policy rule, if any, are executed as if this Until Failure). Instead, the remaining actions for the policy rule,
SimplePolicyAction were not present at all in the list of actions if any, are executed as if this SimplePolicyAction were not present
aggregated by the rule. at all in the list of actions aggregated by the rule.
Explicit variables would be more powerful if they could reach beyond the Explicit variables would be more powerful if they could reach beyond
instances selected by policy roles, to related instances. However, to the instances selected by policy roles, to related instances.
represent a policy rule involving such variables in any kind of general However, to represent a policy rule involving such variables in any
way requires something that starts to resemble very much a complete kind of general way requires something that starts to resemble very
policy language. Clearly such a language is outside the scope of PCIMe, much a complete policy language. Clearly such a language is outside
although it might be the subject of a future draft. the scope of PCIMe, although it might be the subject of a future
document.
By restricting much of the generality, it would be possible for explicit By restricting much of the generality, it would be possible for
variables in PCIMe to reach slightly beyond a selected instance. For explicit variables in PCIMe to reach slightly beyond a selected
example, if a selected instance were related to exactly one instance of instance. For example, if a selected instance were related to
another class via a particular association class, and if the goal of the exactly one instance of another class via a particular association
policy rule were both to test a property of this related instance and to class, and if the goal of the policy rule were both to test a
set a property of that same instance, then it would be possible to property of this related instance and to set a property of that same
represent the condition and action of the rule using instance, then it would be possible to represent the condition and
PolicyExplicitVariables. Rather than handling this one specific case action of the rule using PolicyExplicitVariables. Rather than
with explicit variables, though, it was decided to lump them with the handling this one specific case with explicit variables, though, it
more general case, and deal with them if and when a policy language is was decided to lump them with the more general case, and deal with
defined. them if and when a policy language is defined.
Refer to Section 6.10 for the formal definition of the class Refer to Section 6.10 for the formal definition of the class
PolicyExplicitVariable. PolicyExplicitVariable.
5.8.7. Implicitly Bound Policy Variables 5.8.7. Implicitly Bound Policy Variables
Implicitly bound policy variables define the data type and semantics of a Implicitly bound policy variables define the data type and semantics
variable. This determines how the variable is bound to a value in a of a variable. This determines how the variable is bound to a value
condition or an action. Further instructions are provided for specifying in a condition or an action. Further instructions are provided for
data type and/or value constraints for implicitly bound variables. specifying data type and/or value constraints for implicitly bound
variables.
PCIMe introduces an abstract class, PolicyImplicitVariable, to model PCIMe introduces an abstract class, PolicyImplicitVariable, to model
implicitly bound variables. This class is derived from the abstract implicitly bound variables. This class is derived from the abstract
class PolicyVariable also defined in PCIMe. Each of the implicitly bound class PolicyVariable also defined in PCIMe. Each of the implicitly
variables introduced by PCIMe (and those that are introduced by domain- bound variables introduced by PCIMe (and those that are introduced by
specific sub-models) MUST be derived from the PolicyImplicitVariable domain- specific sub-models) MUST be derived from the
class. The rationale for using this mechanism for modeling is explained PolicyImplicitVariable class. The rationale for using this mechanism
below in Section 5.8.9. for modeling is explained below in Section 5.8.9.
A domain-specific policy information model that extends PCIMe may define A domain-specific policy information model that extends PCIMe may
additional implicitly bound variables either by deriving them directly define additional implicitly bound variables either by deriving them
from the class PolicyImplicitVariable, or by further refining an existing directly from the class PolicyImplicitVariable, or by further
variable class such as SourcePort. When refining a class such as refining an existing variable class such as SourcePort. When
SourcePort, existing binding rules, type or value constraints may be refining a class such as SourcePort, existing binding rules, type or
narrowed. value constraints may be narrowed.
5.8.8. Structure and Usage of Pre-Defined Variables 5.8.8. Structure and Usage of Pre-Defined Variables
A class derived from PolicyImplicitVariable to model a particular A class derived from PolicyImplicitVariable to model a particular
implicitly bound variable SHOULD be constructed so that its name depicts implicitly bound variable SHOULD be constructed so that its name
the meaning of the variable. For example, a class defined to model the depicts the meaning of the variable. For example, a class defined to
source port of a TCP/UDP flow SHOULD have 'SourcePort' in its name. model the source port of a TCP/UDP flow SHOULD have 'SourcePort' in
its name.
PCIMe defines one association and one general-purpose mechanism that PCIMe defines one association and one general-purpose mechanism that
together characterize each of the implicitly bound variables that it together characterize each of the implicitly bound variables that it
introduces: introduces:
1. The ExpectedPolicyValuesForVariable association defines the set of 1. The ExpectedPolicyValuesForVariable association defines the set of
value classes that could be matched to this variable. value classes that could be matched to this variable.
2. The list of constraints on the values that the PolicyVariable can 2. The list of constraints on the values that the PolicyVariable can
hold (i.e., values that the variable must match) are defined by hold (i.e., values that the variable must match) are defined by
the appropriate properties of an associated PolicyValue class. the appropriate properties of an associated PolicyValue class.
In the example presented above, a PolicyImplicitVariable represents the In the example presented above, a PolicyImplicitVariable represents
SourcePort of incoming traffic. The ValueTypes property of an instance the SourcePort of incoming traffic. The ValueTypes property of an
of this class will hold the class name PolicyIntegerValue. This by instance of this class will hold the class name PolicyIntegerValue.
itself constrains the data type of the SourcePort instance to be an This by itself constrains the data type of the SourcePort instance to
integer. However, we can further constrain the particular values that be an integer. However, we can further constrain the particular
the SourcePort variable can hold by entering valid ranges in the values that the SourcePort variable can hold by entering valid ranges
IntegerList property of the PolicyIntegerValue instance (0 - 65535 in in the IntegerList property of the PolicyIntegerValue instance (0 -
this document). 65535 in this document).
The combination of the VariableName and the The combination of the VariableName and the
ExpectedPolicyValuesForVariable association provide a consistent and ExpectedPolicyValuesForVariable association provide a consistent and
extensible set of metadata that define the semantics of variables that extensible set of metadata that define the semantics of variables
are used to form policy conditions. Since the that are used to form policy conditions. Since the
ExpectedPolicyValuesForVariable association points to a PolicyValue ExpectedPolicyValuesForVariable association points to a PolicyValue
instance, any of the values expressible in the PolicyValue class can be instance, any of the values expressible in the PolicyValue class can
used to constrain values that the PolicyImplicitVariable can hold. For be used to constrain values that the PolicyImplicitVariable can hold.
example: For example:
o The ValueTypes property can be used to ensure that only proper o The ValueTypes property can be used to ensure that only proper
classes are used in the expression. For example, the SourcePort classes are used in the expression. For example, the SourcePort
variable will not be allowed to ever be of type variable will not be allowed to ever be of type
PolicyIPv4AddrValue, since source ports have different semantics PolicyIPv4AddrValue, since source ports have different semantics
than IP addresses and may not be matched. However, integer value than IP addresses and may not be matched. However, integer value
types are allowed as the property ValueTypes holds the string types are allowed as the property ValueTypes holds the string
"PolicyIntegerValue", which is the class name for integer values. "PolicyIntegerValue", which is the class name for integer values.
o The ExpectedPolicyValuesForVariable association also ensures that o The ExpectedPolicyValuesForVariable association also ensures that
variable-specific semantics are enforced (e.g., the SourcePort variable-specific semantics are enforced (e.g., the SourcePort
variable may include a constraint association to a value object variable may include a constraint association to a value object
defining a specific integer range that should be matched). defining a specific integer range that should be matched).
5.8.9. Rationale for Modeling Implicit Variables as Classes 5.8.9. Rationale for Modeling Implicit Variables as Classes
An implicitly bound variable can be modeled in one of several ways, An implicitly bound variable can be modeled in one of several ways,
including a single class with an enumerator for each individual including a single class with an enumerator for each individual
implicitly bound variable and an abstract class extended for each implicitly bound variable and an abstract class extended for each
individual variable. The reasons for using a class inheritance mechanism individual variable. The reasons for using a class inheritance
for specifying individual implicitly bound variables are these: mechanism for specifying individual implicitly bound variables are
these:
1. It is easy to extend. A domain-specific information model can 1. It is easy to extend. A domain-specific information model can
easily extend the PolicyImplicitVariable class or its subclasses easily extend the PolicyImplicitVariable class or its subclasses
to define domain-specific and context-specific variables. For to define domain-specific and context-specific variables. For
example, a domain-specific QoS policy information model may example, a domain-specific QoS policy information model may
introduce an implicitly bound variable class to model applications introduce an implicitly bound variable class to model applications
by deriving a qosApplicationVariable class from the by deriving a qosApplicationVariable class from the
PolicyImplicitVariable abstract class. PolicyImplicitVariable abstract class.
2. Introduction of a single structural class for implicitly bound 2. Introduction of a single structural class for implicitly bound
variables would have to include an enumerator property that variables would have to include an enumerator property that
contains all possible individual implicitly bound variables. This contains all possible individual implicitly bound variables. This
means that a domain-specific information model wishing to means that a domain-specific information model wishing to
introduce an implicitly bound variable must extend the enumerator introduce an implicitly bound variable must extend the enumerator
itself. This results in multiple definitions of the same class, itself. This results in multiple definitions of the same class,
differing in the values available in the enumerator class. One differing in the values available in the enumerator class. One
definition, in this document, would include the common implicitly definition, in this document, would include the common implicitly
bound variables' names, while a second definition, in the domain- bound variables' names, while a second definition, in the domain-
specific information model document, may include additional values specific information model document, may include additional values
('qosApplicationVariable' in the example above). It wouldnt even ('qosApplicationVariable' in the example above). It wouldn't even
be obvious to the application developer that multiple class be obvious to the application developer that multiple class
definitions existed. It would be harder still for the application definitions existed. It would be harder still for the application
developer to actually find the correct class to use. developer to actually find the correct class to use.
3. In addition, an enumerator-based definition would require each 3. In addition, an enumerator-based definition would require each
additional value to be registered with IANA to ascertain adherence additional value to be registered with IANA to ascertain adherence
to standards. This would make the process cumbersome. to standards. This would make the process cumbersome.
4. A possible argument against the inheritance mechanism would cite 4. A possible argument against the inheritance mechanism would cite
the fact that this approach results in an explosion of class the fact that this approach results in an explosion of class
definitions compared to an enumerator class, which only introduces definitions compared to an enumerator class, which only introduces
a single class. While, by itself, this is not a strike against a single class. While, by itself, this is not a strike against
the approach, it may be argued that data models derived from this the approach, it may be argued that data models derived from this
information model may be more difficult to optimize for information model may be more difficult to optimize for
applications. This argument is rejected on the grounds that applications. This argument is rejected on the grounds that
application optimization is of lesser value for an information application optimization is of lesser value for an information
model than clarity and ease of extension. In addition, it is hard model than clarity and ease of extension. In addition, it is hard
to claim that the inheritance model places an absolute burden on to claim that the inheritance model places an absolute burden on
the optimization. For example, a data model may still use the optimization. For example, a data model may still use
enumeration to denote instances of pre-defined variables and claim enumeration to denote instances of pre-defined variables and claim
PCIMe compliance, as long as the data model can be mapped PCIMe compliance, as long as the data model can be mapped
correctly to the definitions specified in this document. correctly to the definitions specified in this document.
5.8.10. Policy Values 5.8.10. Policy Values
The abstract class PolicyValue is used for modeling values and constants The abstract class PolicyValue is used for modeling values and
used in policy conditions. Different value types are derived from this constants used in policy conditions. Different value types are
class, to represent the various attributes required. Extensions of the derived from this class, to represent the various attributes
abstract class PolicyValue, defined in this document, provide a list of required. Extensions of the abstract class PolicyValue, defined in
values for basic network attributes. Values can be used to represent this document, provide a list of values for basic network attributes.
constants as named values. Named values can be kept in a reusable policy Values can be used to represent constants as named values. Named
container to be reused by multiple conditions. Examples of constants values can be kept in a reusable policy container to be reused by
include well-known ports, well-known protocols, server addresses, and multiple conditions. Examples of constants include well-known ports,
other similar concepts. well-known protocols, server addresses, and other similar concepts.
The PolicyValue subclasses define three basic types of values: scalars, The PolicyValue subclasses define three basic types of values:
ranges and sets. For example, a well-known port number could be defined scalars, ranges and sets. For example, a well-known port number
using the PolicyIntegerValue class, defining a single value (80 for could be defined using the PolicyIntegerValue class, defining a
HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively. single value (80 for HTTP), a range (80-88), or a set (80, 82, 8080)
For details, please see the class definition for each value type in of ports, respectively. For details, please see the class definition
Section 6.14 of this document. for each value type in Section 6.14 of this document.
PCIMe defines the following subclasses of the abstract class PolicyValue: PCIMe defines the following subclasses of the abstract class
PolicyValue:
Classes for general use: Classes for general use:
- PolicyStringValue, - PolicyStringValue,
- PolicyIntegerValue, - PolicyIntegerValue,
- PolicyBitStringValue - PolicyBitStringValue
- PolicyBooleanValue. - PolicyBooleanValue.
Classes for layer 3 Network values: Classes for layer 3 Network values:
- PolicyIPv4AddrValue, - PolicyIPv4AddrValue,
- PolicyIPv6AddrValue. - PolicyIPv6AddrValue.
Classes for layer 2 Network values: Classes for layer 2 Network values:
- PolicyMACAddrValue. - PolicyMACAddrValue.
For details, please see the class definition section of each class in For details, please see the class definition section of each class in
Section 6.14 of this document. Section 6.14 of this document.
5.9. Packet Filtering 5.9. Packet Filtering
PCIMe contains two mechanisms for representing packet filters. The more PCIMe contains two mechanisms for representing packet filters. The
general of these, termed here the domain-level model, expresses packet more general of these, termed here the domain-level model, expresses
filters in terms of policy variables and policy values. The other packet filters in terms of policy variables and policy values. The
mechanism, termed here the device-level model, expresses packet filters other mechanism, termed here the device-level model, expresses packet
in a way that maps more directly to the packet fields to which the filters in a way that maps more directly to the packet fields to
filters are being applied. While it is possible to map between these two which the filters are being applied. While it is possible to map
representations of packet filters, no mapping is provided in PCIMe between these two representations of packet filters, no mapping is
itself. provided in PCIMe itself.
5.9.1. Domain-Level Packet Filters 5.9.1. Domain-Level Packet Filters
In addition to filling in the holes in the overall Policy infrastructure, In addition to filling in the holes in the overall Policy
PCIMe proposes a single mechanism for expressing domain-level packet infrastructure, PCIMe proposes a single mechanism for expressing
filters in policy conditions. This is being done in response to concerns domain-level packet filters in policy conditions. This is being done
that even though the initial "wave" of submodels derived from PCIM were in response to concerns that even though the initial "wave" of
all filtering on IP packets, each was doing it in a slightly different submodels derived from PCIM were all filtering on IP packets, each
way. PCIMe proposes a common way to express IP packet filters. The was doing it in a slightly different way. PCIMe proposes a common
following figure illustrates how packet-filtering conditions are way to express IP packet filters. The following figure illustrates
expressed in PCIMe. how packet-filtering conditions are expressed in PCIMe.
+---------------------------------+ +---------------------------------+
| CompoundFilterCondition | | CompoundFilterCondition |
| - IsMirrored boolean | | - IsMirrored boolean |
| - ConditionListType (DNF|CNF) | | - ConditionListType (DNF|CNF) |
+---------------------------------+ +---------------------------------+
+ + + + + +
+ + + + + +
+ + + + + +
SimplePC SimplePC SimplePC SimplePC SimplePC SimplePC
* @ * @ * @ * @ * @ * @
* @ * @ * @ * @ * @ * @
* @ * @ * @ * @ * @ * @
FlowDirection "In" SrcIP <addr1> DstIP <addr2> FlowDirection "In" SrcIP <addr1> DstIP <addr2>
Aggregation Legend: Aggregation Legend:
++++ PolicyConditionInPolicyCondition ++++ PolicyConditionInPolicyCondition
**** PolicyVariableInSimplePolicyCondition **** PolicyVariableInSimplePolicyCondition
@@@@ PolicyValueInSimplePolicyCondition @@@@ PolicyValueInSimplePolicyCondition
Figure 9. Packet Filtering in Policy Conditions Figure 9. Packet Filtering in Policy Conditions
In Figure 9. , each SimplePolicyCondition represents a single field to be In Figure 9., each SimplePolicyCondition represents a single field to
filtered on: Source IP address, Destination IP address, Source port, etc. be filtered on: Source IP address, Destination IP address, Source
An additional SimplePolicyCondition indicates the direction that a packet port, etc. An additional SimplePolicyCondition indicates the
is traveling on an interface: inbound or outbound. Because of the direction that a packet is traveling on an interface: inbound or
FlowDirection condition, care must be taken in aggregating a set of outbound. Because of the FlowDirection condition, care must be taken
SimplePolicyConditions into a CompoundFilterCondition. Otherwise, the in aggregating a set of SimplePolicyConditions into a
resulting CompoundPolicyCondition may match all inbound packets, or all CompoundFilterCondition. Otherwise, the resulting
CompoundPolicyCondition may match all inbound packets, or all
outbound packets, when this is probably not what was intended. outbound packets, when this is probably not what was intended.
Individual SimplePolicyConditions may be negated when they are aggregated Individual SimplePolicyConditions may be negated when they are
by a CompoundFilterCondition. aggregated by a CompoundFilterCondition.
CompoundFilterCondition is a subclass of CompoundPolicyCondition. It CompoundFilterCondition is a subclass of CompoundPolicyCondition. It
introduces one additional property, the Boolean property IsMirrored. The introduces one additional property, the Boolean property IsMirrored.
purpose of this property is to allow a single CompoundFilterCondition to The purpose of this property is to allow a single
match packets traveling in both directions on a higher-level connection CompoundFilterCondition to match packets traveling in both directions
such as a TCP session. When this property is TRUE, additional packets on a higher-level connection such as a TCP session. When this
match a filter, beyond those that would ordinarily match it. An example property is TRUE, additional packets match a filter, beyond those
will illustrate how this property works. that would ordinarily match it. An example will illustrate how this
property works.
Suppose we have a CompoundFilterCondition that aggregates the following Suppose we have a CompoundFilterCondition that aggregates the
three filters, which are ANDed together: following three filters, which are ANDed together:
o FlowDirection = "In" o FlowDirection = "In"
o Source IP = 9.1.1.1 o Source IP = 9.1.1.1
o Source Port = 80 o Source Port = 80
Regardless of whether IsMirrored is TRUE or FALSE, inbound packets will Regardless of whether IsMirrored is TRUE or FALSE, inbound packets
match this CompoundFilterCondition if their Source IP address = 9.1.1.1 will match this CompoundFilterCondition if their Source IP address =
and their Source port = 80. If IsMirrored is TRUE, however, an outbound 9.1.1.1 and their Source port = 80. If IsMirrored is TRUE, however,
packet will also match the CompoundFilterCondition if its Destination IP an outbound packet will also match the CompoundFilterCondition if its
address = 9.1.1.1 and its Destination port = 80. Destination IP address = 9.1.1.1 and its Destination port = 80.
IsMirrored "flips" the following Source/Destination packet header fields: IsMirrored "flips" the following Source/Destination packet header
fields:
o FlowDirection "In" / FlowDirection "Out" o FlowDirection "In" / FlowDirection "Out"
o Source IP address / Destination IP address o Source IP address / Destination IP address
o Source port / Destination port o Source port / Destination port
o Source MAC address / Destination MAC address o Source MAC address / Destination MAC address
o Source [layer-2] SAP / Destination [layer-2] SAP. o Source [layer-2] SAP / Destination [layer-2] SAP.
5.9.2. Device-Level Packet Filters 5.9.2. Device-Level Packet Filters
At the device level, packet header filters are represented by two At the device level, packet header filters are represented by two
subclasses of the abstract class FilterEntryBase: IpHeadersFilter and subclasses of the abstract class FilterEntryBase: IpHeadersFilter and
8021Filter. Submodels of PCIMe may define other subclasses of 8021Filter. Submodels of PCIMe may define other subclasses of
FilterEntryBase in addition to these two; ICPM [12], for example, defines FilterEntryBase in addition to these two; ICPM [12], for example,
subclasses for IPsec-specific filters. defines subclasses for IPsec-specific filters.
Instances of the subclasses of FilterEntryBase are not used directly as Instances of the subclasses of FilterEntryBase are not used directly
filters. They are always aggregated into a FilterList, by the as filters. They are always aggregated into a FilterList, by the
aggregation EntriesInFilterList. For PCIMe and its submodels, the aggregation EntriesInFilterList. For PCIMe and its submodels, the
EntrySequence property in this aggregation always takes its default value EntrySequence property in this aggregation always takes its default
'0', indicating that the aggregated filter entries are ANDed together. value '0', indicating that the aggregated filter entries are ANDed
together.
The FilterList class includes an enumeration property Direction, The FilterList class includes an enumeration property Direction,
representing the direction of the traffic flow to which the FilterList is representing the direction of the traffic flow to which the
to be applied. The value Mirrored(4) for Direction represents exactly FilterList is to be applied. The value Mirrored(4) for Direction
the same thing as the IsMirrored boolean does in CompoundFilterCondition. represents exactly the same thing as the IsMirrored boolean does in
See Section 5.9.1 for details. CompoundFilterCondition. See Section 5.9.1 for details.
5.10. Conformance to PCIM and PCIMe 5.10. Conformance to PCIM and PCIMe
Because PCIM and PCIMe provide the core classes for modeling policies, Because PCIM and PCIMe provide the core classes for modeling
they are not in general sufficient by themselves for representing actual policies, they are not in general sufficient by themselves for
policy rules. Submodels, such as QPIM and ICPM, provide the means for representing actual policy rules. Submodels, such as QPIM and ICPM,
expressing policy rules, by defining subclasses of the classes defined in provide the means for expressing policy rules, by defining subclasses
PCIM and PCIMe, and/or by indicating how the PolicyVariables and of the classes defined in PCIM and PCIMe, and/or by indicating how
PolicyValues defined in PCIMe can be used to express conditions and the PolicyVariables and PolicyValues defined in PCIMe can be used to
actions applicable to the submodel. express conditions and actions applicable to the submodel.
A particular submodel will not, in general, need to use every element A particular submodel will not, in general, need to use every element
defined in PCIM and PCIMe. For the elements it does not use, a submodel defined in PCIM and PCIMe. For the elements it does not use, a
SHOULD remain silent on whether its implementations must support the submodel SHOULD remain silent on whether its implementations must
element, must not support the element, should support the element, etc. support the element, must not support the element, should support the
For the elements it does use, a submodel SHOULD indicate which elements element, etc. For the elements it does use, a submodel SHOULD
its implementations must support, which elements they should support, and indicate which elements its implementations must support, which
which elements they may support. elements they should support, and which elements they may support.
PCIM and PCIMe themselves simply define elements that may be of use to PCIM and PCIMe themselves simply define elements that may be of use
submodels. These documents remain silent on whether implementations are to submodels. These documents remain silent on whether
required to support an element, should support it, etc. implementations are required to support an element, should support
it, etc.
This model (and derived submodels) defines conditions and actions that This model (and derived submodels) defines conditions and actions
are used by policy rules. While the conditions and actions defined that are used by policy rules. While the conditions and actions
herein are straightforward and may be presumed to be widely supported, as defined herein are straightforward and may be presumed to be widely
submodels are developed it is likely that situations will arise in which supported, as submodels are developed it is likely that situations
specific conditions or actions are not supported by some part of the will arise in which specific conditions or actions are not supported
policy execution system. Similarly, situations may also occur where by some part of the policy execution system. Similarly, situations
rules contain syntactic or semantic errors. may also occur where rules contain syntactic or semantic errors.
It should be understood that the behavior and effect of undefined or It should be understood that the behavior and effect of undefined or
incorrectly defined conditions or actions is not prescribed by this incorrectly defined conditions or actions is not prescribed by this
information model. While it would be helpful if it were prescribed, the information model. While it would be helpful if it were prescribed,
variations in implementation restrict the ability for this information the variations in implementation restrict the ability for this
model to control the effect. For example, if an implementation only information model to control the effect. For example, if an
detected that a PEP could not enforce a given action on that PEP, it implementation only detected that a PEP could not enforce a given
would be very difficult to declare that such a failure should affect action on that PEP, it would be very difficult to declare that such a
other PEPs, or the PDP process. On the other hand, if the PDP determines failure should affect other PEPs, or the PDP process. On the other
that it cannot properly evaluate a condition, that failure may well hand, if the PDP determines that it cannot properly evaluate a
affect all applications of the containing rules. condition, that failure may well affect all applications of the
containing rules.
6. Class Definitions 6. Class Definitions
The following definitions supplement those in PCIM itself. PCIM The following definitions supplement those in PCIM itself. PCIM
definitions that are not DEPRECATED here are still current parts of the definitions that are not DEPRECATED here are still current parts of
overall Policy Core Information Model. the overall Policy Core Information Model.
6.1. The Abstract Class "PolicySet" 6.1. The Abstract Class "PolicySet"
PolicySet is an abstract class that may group policies into a structured PolicySet is an abstract class that may group policies into a
set of policies. structured set of policies.
NAME PolicySet NAME PolicySet
DESCRIPTION An abstract class that represents a set of policies DESCRIPTION An abstract class that represents a set of policies
that form a coherent set. The set of contained that form a coherent set. The set of contained
policies has a common decision strategy and a common policies has a common decision strategy and a
set of policy roles. Subclasses include PolicyGroup common set of policy roles. Subclasses include
and PolicyRule. PolicyGroup and PolicyRule.
DERIVED FROM Policy DERIVED FROM Policy
ABSTRACT TRUE ABSTRACT TRUE
PROPERTIES PolicyDecisionStrategy PROPERTIES PolicyDecisionStrategy
PolicyRoles PolicyRoles
The PolicyDecisionStrategy property specifies the evaluation method for The PolicyDecisionStrategy property specifies the evaluation method
policy groups and rules contained within the policy set. for policy groups and rules contained within the policy set.
NAME PolicyDecisionStrategy NAME PolicyDecisionStrategy
DESCRIPTION The evaluation method used for policies contained in DESCRIPTION The evaluation method used for policies contained in
the PolicySet. FirstMatching enforces the actions of the PolicySet. FirstMatching enforces the actions
the first rule that evaluates to TRUE; AllMatching of the first rule that evaluates to TRUE;
enforces the actions of all rules that evaluate to All Matching enforces the actions of all rules
TRUE. that evaluate to TRUE.
SYNTAX uint16 SYNTAX uint16
VALUES 1 [FirstMatching], 2 [AllMatching] VALUES 1 [FirstMatching], 2 [AllMatching]
DEFAULT VALUE 1 [FirstMatching] DEFAULT VALUE 1 [FirstMatching]
The definition of PolicyRoles is unchanged from PCIM. It is, however, The definition of PolicyRoles is unchanged from PCIM. It is,
moved from the class Policy up to the superclass PolicySet. however, moved from the class Policy up to the superclass PolicySet.
6.2. Update PCIM's Class "PolicyGroup" 6.2. Update PCIM's Class "PolicyGroup"
The PolicyGroup class is moved, so that it is now derived from PolicySet. The PolicyGroup class is moved, so that it is now derived from
PolicySet.
NAME PolicyGroup NAME PolicyGroup
DESCRIPTION A container for a set of related PolicyRules and DESCRIPTION A container for a set of related PolicyRules and
PolicyGroups. PolicyGroups.
DERIVED FROM PolicySet DERIVED FROM PolicySet
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.3. Update PCIM's Class "PolicyRule" 6.3. Update PCIM's Class "PolicyRule"
The PolicyRule class is moved, so that it is now derived from PolicySet. The PolicyRule class is moved, so that it is now derived from
The Priority property is also deprecated in PolicyRule, and PolicyRoles PolicySet. The Priority property is also deprecated in PolicyRule,
is now inherited from the parent class PolicySet. Finally, a new and PolicyRoles is now inherited from the parent class PolicySet.
property ExecutionStrategy is introduced, paralleling the property of the Finally, a new property ExecutionStrategy is introduced, paralleling
same name in the class CompoundPolicyAction. the property of the same name in the class CompoundPolicyAction.
NAME PolicyRule NAME PolicyRule
DESCRIPTION The central class for representing the "If Condition DESCRIPTION The central class for representing the "If Condition
then Action" semantics associated with a policy rule. then Action" semantics associated with a policy
DERIVED FROM PolicySet rule.
ABSTRACT FALSE DERIVED FROM PolicySet
PROPERTIES Enabled ABSTRACT FALSE
ConditionListType PROPERTIES Enabled
RuleUsage ConditionListType
Priority DEPRECATED FOR PolicySetComponent.Priority RuleUsage
AND FOR PolicySetInSystem.Priority Priority DEPRECATED FOR PolicySetComponent.Priority
Mandatory AND FOR PolicySetInSystem.Priority
SequencedActions Mandatory
ExecutionStrategy SequencedActions
The property ExecutionStrategy defines the execution strategy to be used ExecutionStrategy
upon the sequenced actions aggregated by this PolicyRule. (An equivalent
ExecutionStrategy property is also defined for the CompoundPolicyAction
class, to provide the same indication for the sequenced actions
aggregated by a CompoundPolicyAction.) This draft defines three
execution strategies:
Do Until Success execute actions according to predefined order, until The property ExecutionStrategy defines the execution strategy to be
successful execution of a single action. used upon the sequenced actions aggregated by this PolicyRule. (An
Do All - execute ALL actions which are part of the modeled equivalent ExecutionStrategy property is also defined for the
set, according to their predefined order. Continue CompoundPolicyAction class, to provide the same indication for the
doing this, even if one or more of the actions sequenced actions aggregated by a CompoundPolicyAction.) This
fails. document defines three execution strategies:
Do Until Failure - execute actions according to predefined order, until
the first failure in execution of a single sub- Do Until Success - execute actions according to predefined order,
action. until successful execution of a single action.
Do All - execute ALL actions which are part of the modeled
set, according to their predefined order.
Continue doing this, even if one or more of the
actions fails.
Do Until Failure - execute actions according to predefined order,
until the first failure in execution of a single
sub-action.
The property definition is as follows: The property definition is as follows:
NAME ExecutionStrategy NAME ExecutionStrategy
DESCRIPTION An enumeration indicating how to interpret the action DESCRIPTION An enumeration indicating how to interpret the
ordering for the actions aggregated by this action ordering for the actions aggregated by this
PolicyRule. PolicyRule.
SYNTAX uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do SYNTAX uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do
Until Failure} ) Until Failure} )
DEFAULT VALUE Do All (2) DEFAULT VALUE Do All (2)
6.4. The Class "SimplePolicyCondition" 6.4. The Class "SimplePolicyCondition"
A simple policy condition is composed of an ordered triplet: A simple policy condition is composed of an ordered triplet:
<Variable> MATCH <Value> <Variable> MATCH <Value>
No formal modeling of the MATCH operator is provided. The 'match' No formal modeling of the MATCH operator is provided. The 'match'
relationship is implied. Such simple conditions are evaluated by relationship is implied. Such simple conditions are evaluated by
answering the question: answering the question:
Does <variable> match <value>? Does <variable> match <value>?
The 'match' relationship is to be interpreted by analyzing the variable The 'match' relationship is to be interpreted by analyzing the
and value instances associated with the simple condition. variable and value instances associated with the simple condition.
Simple conditions are building blocks for more complex Boolean Simple conditions are building blocks for more complex Boolean
Conditions, modeled by the CompoundPolicyCondition class. Conditions, modeled by the CompoundPolicyCondition class.
The SimplePolicyCondition class is derived from the PolicyCondition class The SimplePolicyCondition class is derived from the PolicyCondition
defined in PCIM. class defined in PCIM.
A variable and a value must be associated with a simple condition to make A variable and a value must be associated with a simple condition to
it a meaningful condition, using, respectively, the aggregations make it a meaningful condition, using, respectively, the aggregations
PolicyVariableInSimplePolicyCondition and PolicyVariableInSimplePolicyCondition and
PolicyValueInSimplePolicyCondition. PolicyValueInSimplePolicyCondition.
The class definition is as follows: The class definition is as follows:
NAME SimplePolicyCondition NAME SimplePolicyCondition
DERIVED FROM PolicyCondition DERIVED FROM PolicyCondition
ABSTRACT False ABSTRACT False
PROPERTIES (none) PROPERTIES (none)
6.5. The Class "CompoundPolicyCondition" 6.5. The Class "CompoundPolicyCondition"
This class represents a compound policy condition, formed by aggregation This class represents a compound policy condition, formed by
of simpler policy conditions. aggregation of simpler policy conditions.
NAME CompoundPolicyCondition NAME CompoundPolicyCondition
DESCRIPTION A subclass of PolicyCondition that introduces the DESCRIPTION A subclass of PolicyCondition that introduces the
ConditionListType property, used for assigning DNF / ConditionListType property, used for assigning DNF /
CNF semantics to subordinate policy conditions. CNF semantics to subordinate policy conditions.
DERIVED FROM PolicyCondition DERIVED FROM PolicyCondition
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES ConditionListType PROPERTIES ConditionListType
The ConditionListType property is used to specify whether the list of The ConditionListType property is used to specify whether the list of
policy conditions associated with this compound policy condition is in policy conditions associated with this compound policy condition is
disjunctive normal form (DNF) or conjunctive normal form (CNF). If this in disjunctive normal form (DNF) or conjunctive normal form (CNF).
property is not present, the list type defaults to DNF. The property If this property is not present, the list type defaults to DNF. The
definition is as follows: property definition is as follows:
NAME ConditionListType NAME ConditionListType
DESCRIPTION Indicates whether the list of policy conditions DESCRIPTION Indicates whether the list of policy conditions
associated with this policy rule is in disjunctive associated with this policy rule is in disjunctive
normal form (DNF) or conjunctive normal form (CNF). normal form (DNF) or conjunctive normal form (CNF).
SYNTAX uint16 SYNTAX uint16
VALUES DNF(1), CNF(2) VALUES DNF(1), CNF(2)
DEFAULT VALUE DNF(1) DEFAULT VALUE DNF(1)
6.6. The Class "CompoundFilterCondition" 6.6. The Class "CompoundFilterCondition"
This subclass of CompoundPolicyCondition introduces one additional This subclass of CompoundPolicyCondition introduces one additional
property, the boolean IsMirrored. This property turns on or off the property, the boolean IsMirrored. This property turns on or off the
"flipping" of corresponding source and destination fields in a filter "flipping" of corresponding source and destination fields in a filter
specification. specification.
NAME CompoundFilterCondition NAME CompoundFilterCondition
DESCRIPTION A subclass of CompoundPolicyCondition that introduces DESCRIPTION A subclass of CompoundPolicyCondition that
the IsMirrored property. introduces the IsMirrored property.
DERIVED FROM CompoundPolicyCondition DERIVED FROM CompoundPolicyCondition
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES IsMirrored PROPERTIES IsMirrored
The IsMirrored property indicates whether packets that "mirror" a The IsMirrored property indicates whether packets that "mirror" a
compound filter condition should be treated as matching the filter. The compound filter condition should be treated as matching the filter.
property definition is as follows: The property definition is as follows:
NAME IsMirrored NAME IsMirrored
DESCRIPTION Indicates whether packets that mirror the specified DESCRIPTION Indicates whether packets that mirror the specified
filter are to be treated as matching the filter. filter are to be treated as matching the filter.
SYNTAX boolean SYNTAX boolean
DEFAULT VALUE FALSE DEFAULT VALUE FALSE
6.7. The Class "SimplePolicyAction" 6.7. The Class "SimplePolicyAction"
The SimplePolicyAction class models the elementary set operation. "SET The SimplePolicyAction class models the elementary set operation.
<variable> TO <value>". The set operator MUST overwrite an old value of "SET <variable> TO <value>". The set operator MUST overwrite an old
the variable. value of the variable.
Two aggregations are used in order to create the pair <variable> <value>. Two aggregations are used in order to create the pair <variable>
The aggregation PolicyVariableInSimplePolicyAction relates a <value>. The aggregation PolicyVariableInSimplePolicyAction relates
SimplePolicyAction to a single variable instance. Similarly, the a SimplePolicyAction to a single variable instance. Similarly, the
aggregation PolicyValueInSimplePolicyAction relates a SimplePolicyAction aggregation PolicyValueInSimplePolicyAction relates a
to a single value instance. Both aggregations are defined in this SimplePolicyAction to a single value instance. Both aggregations are
document. defined in this document.
NAME SimplePolicyAction NAME SimplePolicyAction
DESCRIPTION A subclass of PolicyAction that introduces the notion DESCRIPTION A subclass of PolicyAction that introduces the
of "SET variable TO value". notion of "SET variable TO value".
DERIVED FROM PolicyAction DERIVED FROM PolicyAction
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.8. The Class "CompoundPolicyAction" 6.8. The Class "CompoundPolicyAction"
The CompoundPolicyAction class is used to represent an expression The CompoundPolicyAction class is used to represent an expression
consisting of an ordered sequence of action terms. Each action term is consisting of an ordered sequence of action terms. Each action term
represented as a subclass of the PolicyAction class, defined in [PCIM]. is represented as a subclass of the PolicyAction class, defined in
Compound actions are constructed by associating dependent action terms [PCIM]. Compound actions are constructed by associating dependent
together using the PolicyActionInPolicyAction aggregation. action terms together using the PolicyActionInPolicyAction
aggregation.
The class definition is as follows: The class definition is as follows:
NAME CompoundPolicyAction NAME CompoundPolicyAction
DESCRIPTION A class for representing sequenced action terms. Each DESCRIPTION A class for representing sequenced action terms.
action term is defined to be a subclass of the Each action term is defined to be a subclass of the
PolicyAction class. PolicyAction class.
DERIVED FROM PolicyAction DERIVED FROM PolicyAction
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES SequencedActions PROPERTIES SequencedActions
ExecutionStrategy ExecutionStrategy
This is a concrete class, and is therefore directly instantiable. This is a concrete class, and is therefore directly instantiable.
The Property SequencedActions is identical to the SequencedActions The Property SequencedActions is identical to the SequencedActions
property defined in PCIM for the class PolicyRule. property defined in PCIM for the class PolicyRule.
The property ExecutionStrategy defines the execution strategy to be used The property ExecutionStrategy defines the execution strategy to be
upon the sequenced actions associated with this compound action. (An used upon the sequenced actions associated with this compound action.
equivalent ExecutionStrategy property is also defined for the PolicyRule (An equivalent ExecutionStrategy property is also defined for the
class, to provide the same indication for the sequenced actions PolicyRule class, to provide the same indication for the sequenced
associated with a PolicyRule.) This draft defines three execution actions associated with a PolicyRule.) This document defines three
strategies: execution strategies:
Do Until Success execute actions according to predefined order, until Do Until Success - execute actions according to predefined order,
successful execution of a single sub-action. until successful execution of a single sub-action.
Do All - execute ALL actions which are part of the modeled Do All - execute ALL actions which are part of the modeled
set, according to their predefined order. Continue set, according to their predefined order.
doing this, even if one or more of the sub-actions Continue doing this, even if one or more of the
fails. sub-actions fails.
Do Until Failure - execute actions according to predefined order, until Do Until Failure - execute actions according to predefined order,
the first failure in execution of a single sub- until the first failure in execution of a single
action. sub-action.
Since a CompoundPolicyAction may itself be aggregated either by a Since a CompoundPolicyAction may itself be aggregated either by a
PolicyRule or by another CompoundPolicyAction, its success or failure PolicyRule or by another CompoundPolicyAction, its success or failure
will be an input to the aggregating entity's execution strategy. will be an input to the aggregating entity's execution strategy.
Consequently, the following rules are specified, for determining whether Consequently, the following rules are specified, for determining
a CompoundPolicyAction succeeds or fails: whether a CompoundPolicyAction succeeds or fails:
If the CompoundPolicyAction's ExecutionStrategy is Do Until Success, If the CompoundPolicyAction's ExecutionStrategy is Do Until Success,
then then:
o If one component action succeeds, then the CompoundPolicyAction
succeeds.
o If all component actions fail, then the CompoundPolicyAction
fails.
If the CompoundPolicyAction's ExecutionStrategy is Do All, then o If one component action succeeds, then the CompoundPolicyAction
o If all component actions succeed, then the CompoundPolicyAction succeeds.
succeeds. o If all component actions fail, then the CompoundPolicyAction
o If at least one component action fails, then the fails.
CompoundPolicyAction fails.
If the CompoundPolicyAction's ExecutionStrategy is Do Until Failure, If the CompoundPolicyAction's ExecutionStrategy is Do All, then:
then
o If all component actions succeed, then the CompoundPolicyAction o If all component actions succeed, then the CompoundPolicyAction
succeeds. succeeds.
o If at least one component action fails, then the o If at least one component action fails, then the
CompoundPolicyAction fails. CompoundPolicyAction fails.
If the CompoundPolicyAction's ExecutionStrategy is Do Until Failure,
then:
o If all component actions succeed, then the CompoundPolicyAction
succeeds.
o If at least one component action fails, then the
CompoundPolicyAction fails.
The definition of the ExecutionStrategy property is as follows: The definition of the ExecutionStrategy property is as follows:
NAME ExecutionStrategy NAME ExecutionStrategy
DESCRIPTION An enumeration indicating how to interpret the action DESCRIPTION An enumeration indicating how to interpret the
ordering for the actions aggregated by this action ordering for the actions aggregated by this
CompoundPolicyAction. CompoundPolicyAction.
SYNTAX uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do SYNTAX uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do
Until Failure} ) Until Failure} )
DEFAULT VALUE Do All (2) DEFAULT VALUE Do All (2)
6.9. The Abstract Class "PolicyVariable"
6.9. The Abstract Class "PolicyVariable"
Variables are used for building individual conditions. The variable Variables are used for building individual conditions. The variable
specifies the property of a flow or an event that should be matched when specifies the property of a flow or an event that should be matched
evaluating the condition. However, not every combination of a variable when evaluating the condition. However, not every combination of a
and a value creates a meaningful condition. For example, a source IP variable and a value creates a meaningful condition. For example, a
address variable can not be matched against a value that specifies a port source IP address variable can not be matched against a value that
number. A given variable selects the set of matchable value types. specifies a port number. A given variable selects the set of
matchable value types.
A variable can have constraints that limit the set of values within a A variable can have constraints that limit the set of values within a
particular value type that can be matched against it in a condition. For particular value type that can be matched against it in a condition.
example, a source-port variable limits the set of values to represent For example, a source-port variable limits the set of values to
integers to the range of 0-65535. Integers outside this range cannot be represent integers to the range of 0-65535. Integers outside this
matched to the source-port variable, even though they are of the correct range cannot be matched to the source-port variable, even though they
data type. Constraints for a given variable are indicated through the are of the correct data type. Constraints for a given variable are
ExpectedPolicyValuesForVariable association. indicated through the ExpectedPolicyValuesForVariable association.
The PolicyVariable is an abstract class. Implicit and explicit context The PolicyVariable is an abstract class. Implicit and explicit
variable classes are defined as sub classes of the PolicyVariable class. context variable classes are defined as sub classes of the
A set of implicit variables is defined in this document as well. PolicyVariable class. A set of implicit variables is defined in this
document as well.
The class definition is as follows: The class definition is as follows:
NAME PolicyVariable NAME PolicyVariable
DERIVED FROM Policy DERIVED FROM Policy
ABSTRACT TRUE ABSTRACT TRUE
PROPERTIES (none) PROPERTIES (none)
6.10. The Class "PolicyExplicitVariable" 6.10. The Class "PolicyExplicitVariable"
Explicitly defined policy variables are evaluated within the context of Explicitly defined policy variables are evaluated within the context
the CIM Schema and its modeling constructs. The PolicyExplicitVariable of the CIM Schema and its modeling constructs. The
class indicates the exact model property to be evaluated or manipulated. PolicyExplicitVariable class indicates the exact model property to be
See Section 5.8.6 for a complete discussion of what happens when the evaluated or manipulated. See Section 5.8.6 for a complete
values of the ModelClass and ModelProperty properties in an instance of discussion of what happens when the values of the ModelClass and
this class do not correspond to the characteristics of the model ModelProperty properties in an instance of this class do not
construct being evaluated or updated. correspond to the characteristics of the model construct being
evaluated or updated.
The class definition is as follows: The class definition is as follows:
NAME PolicyExplicitVariable NAME PolicyExplicitVariable
DERIVED FROM PolicyVariable DERIVED FROM PolicyVariable
ABSTRACT False ABSTRACT False
PROPERTIES ModelClass, ModelProperty PROPERTIES ModelClass, ModelProperty
6.10.1. The Single-Valued Property "ModelClass" 6.10.1. The Single-Valued Property "ModelClass"
This property is a string specifying the class name whose property is This property is a string specifying the class name whose property is
evaluated or set as a PolicyVariable. evaluated or set as a PolicyVariable.
The property is defined as follows: The property is defined as follows:
NAME ModelClass NAME ModelClass
SYNTAX String SYNTAX String
6.10.2. The Single-Valued Property ModelProperty 6.10.2. The Single-Valued Property ModelProperty
This property is a string specifying the property name, within the This property is a string specifying the property name, within the
ModelClass, which is evaluated or set as a PolicyVariable. The property ModelClass, which is evaluated or set as a PolicyVariable. The
is defined as follows: property is defined as follows:
NAME ModelProperty NAME ModelProperty
SYNTAX String SYNTAX String
6.11. The Abstract Class "PolicyImplicitVariable" 6.11. The Abstract Class "PolicyImplicitVariable"
Implicitly defined policy variables are evaluated outside of the context Implicitly defined policy variables are evaluated outside of the
of the CIM Schema and its modeling constructs. Subclasses specify the context of the CIM Schema and its modeling constructs. Subclasses
data type and semantics of the PolicyVariables. specify the data type and semantics of the PolicyVariables.
Interpretation and evaluation of a PolicyImplicitVariable can vary, Interpretation and evaluation of a PolicyImplicitVariable can vary,
depending on the particular context in which it is used. For example, a depending on the particular context in which it is used. For
"SourceIP" address may denote the source address field of an IP packet example, a "SourceIP" address may denote the source address field of
header, or the sender address delivered by an RSVP PATH message. an IP packet header, or the sender address delivered by an RSVP PATH
message.
The class definition is as follows: The class definition is as follows:
NAME PolicyImplicitVariable NAME PolicyImplicitVariable
DERIVED FROM PolicyVariable DERIVED FROM PolicyVariable
ABSTRACT True ABSTRACT True
PROPERTIES ValueTypes[ ] PROPERTIES ValueTypes[ ]
6.11.1. The Multi-Valued Property "ValueTypes" 6.11.1. The Multi-Valued Property "ValueTypes"
This property is a set of strings specifying an unordered list of This property is a set of strings specifying an unordered list of
possible value/data types that can be used in simple conditions and possible value/data types that can be used in simple conditions and
actions, with this variable. The value types are specified by their actions, with this variable. The value types are specified by their
class names (subclasses of PolicyValue such as PolicyStringValue). The class names (subclasses of PolicyValue such as PolicyStringValue).
list of class names enables an application to search on a specific name, The list of class names enables an application to search on a
as well as to ensure that the data type of the variable is of the correct specific name, as well as to ensure that the data type of the
type. variable is of the correct type.
The list of default ValueTypes for each subclass of The list of default ValueTypes for each subclass of
PolicyImplicitVariable is specified within that variable's definition. PolicyImplicitVariable is specified within that variable's
definition.
The property is defined as follows: The property is defined as follows:
NAME ValueTypes NAME ValueTypes
SYNTAX String SYNTAX String
6.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe
The following subclasses of PolicyImplicitVariable are defined in PCIMe.
6.12.1. The Class "PolicySourceIPv4Variable" 6.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe
NAME PolicySourceIPv4Variable The following subclasses of PolicyImplicitVariable are defined in
DESCRIPTION The source IPv4 address. of the outermost IP packet PCIMe.
header. "Outermost" here refers to the IP packet as
it flows on the wire, before any headers have been
stripped from it.
ALLOWED VALUE TYPES: 6.12.1. The Class "PolicySourceIPv4Variable"
- PolicyIPv4AddrValue
DERIVED FROM PolicyImplicitVariable NAME PolicySourceIPv4Variable
ABSTRACT FALSE DESCRIPTION The source IPv4 address. of the outermost IP packet
PROPERTIES (none) header. "Outermost" here refers to the IP packet as
it flows on the wire, before any headers have been
stripped from it.
6.12.2. The Class "PolicySourceIPv6Variable" ALLOWED VALUE TYPES:
- PolicyIPv4AddrValue
NAME PolicySourceIPv6Variable DERIVED FROM PolicyImplicitVariable
DESCRIPTION The source IPv6 address of the outermost IP packet ABSTRACT FALSE
header. "Outermost" here refers to the IP packet as PROPERTIES (none)
it flows on the wire, before any headers have been
stripped from it.
ALLOWED VALUE TYPES: 6.12.2. The Class "PolicySourceIPv6Variable"
- PolicyIPv6AddrValue
DERIVED FROM PolicyImplicitVariable NAME PolicySourceIPv6Variable
ABSTRACT FALSE DESCRIPTION The source IPv6 address of the outermost IP packet
PROPERTIES (none) header. "Outermost" here refers to the IP packet as
it flows on the wire, before any headers have been
stripped from it.
6.12.3. The Class "PolicyDestinationIPv4Variable" ALLOWED VALUE TYPES:
- PolicyIPv6AddrValue
NAME PolicyDestinationIPv4Variable DERIVED FROM PolicyImplicitVariable
DESCRIPTION The destination IPv4 address of the outermost IP ABSTRACT FALSE
packet header. "Outermost" here refers to the IP PROPERTIES (none)
packet as it flows on the wire, before any headers
have been stripped from it.
ALLOWED VALUE TYPES: 6.12.3. The Class "PolicyDestinationIPv4Variable"
- PolicyIPv4AddrValue
DERIVED FROM PolicyImplicitVariable NAME PolicyDestinationIPv4Variable
ABSTRACT FALSE DESCRIPTION The destination IPv4 address of the outermost IP
PROPERTIES (none) packet header. "Outermost" here refers to the IP
packet as it flows on the wire, before any headers
have been stripped from it.
6.12.4. The Class "PolicyDestinationIPv6Variable" ALLOWED VALUE TYPES:
- PolicyIPv4AddrValue
NAME PolicyDestinationIPv6Variable DERIVED FROM PolicyImplicitVariable
DESCRIPTION The destination IPv6 address of the outermost IP ABSTRACT FALSE
packet header. "Outermost" here refers to the IP PROPERTIES (none)
packet as it flows on the wire, before any headers
have been stripped from it.
ALLOWED VALUE TYPES: 6.12.4. The Class "PolicyDestinationIPv6Variable"
- PolicyIPv6AddrValue
DERIVED FROM PolicyImplicitVariable NAME PolicyDestinationIPv6Variable
ABSTRACT FALSE DESCRIPTION The destination IPv6 address of the outermost IP
PROPERTIES (none) packet header. "Outermost" here refers to the IP
packet as it flows on the wire, before any headers
have been stripped from it.
6.12.5. The Class "PolicySourcePortVariable" ALLOWED VALUE TYPES:
- PolicyIPv6AddrValue
NAME PolicySourcePortVariable DERIVED FROM PolicyImplicitVariable
DESCRIPTION Ports are defined as the abstraction that transport ABSTRACT FALSE
protocols use to distinguish among multiple PROPERTIES (none)
destinations within a given host computer. For TCP
and UDP flows, the PolicySourcePortVariable is
logically bound to the source port field of the
outermost UDP or TCP packet header. "Outermost" here
refers to the IP packet as it flows on the wire,
before any headers have been stripped from it.
ALLOWED VALUE TYPES: 6.12.5. The Class "PolicySourcePortVariable"
- PolicyIntegerValue (0..65535)
DERIVED FROM PolicyImplicitVariable NAME PolicySourcePortVariable
ABSTRACT FALSE DESCRIPTION Ports are defined as the abstraction that transport
PROPERTIES (none) protocols use to distinguish among multiple
destinations within a given host computer. For TCP
and UDP flows, the PolicySourcePortVariable is
logically bound to the source port field of the
outermost UDP or TCP packet header. "Outermost"
here refers to the IP packet as it flows on the
wire, before any headers have been stripped from
it.
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..65535)
6.12.6. The Class "PolicyDestinationPortVariable" DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
NAME PolicyDestinationPortVariable 6.12.6. The Class "PolicyDestinationPortVariable"
DESCRIPTION Ports are defined as the abstraction that transport
protocols use to distinguish among multiple
destinations within a given host computer. For TCP
and UDP flows, the PolicyDestinationPortVariable is
logically bound to the destination port field of the
outermost UDP or TCP packet header. "Outermost" here
refers to the IP packet as it flows on the wire,
before any headers have been stripped from it.
ALLOWED VALUE TYPES: NAME PolicyDestinationPortVariable
- PolicyIntegerValue (0..65535) DESCRIPTION Ports are defined as the abstraction that transport
protocols use to distinguish among multiple
destinations within a given host computer. For TCP
and UDP flows, the PolicyDestinationPortVariable is
logically bound to the destination port field of the
outermost UDP or TCP packet header. "Outermost"
here refers to the IP packet as it flows on the
wire, before any headers have been stripped from it.
DERIVED FROM PolicyImplicitVariable ALLOWED VALUE TYPES:
ABSTRACT FALSE - PolicyIntegerValue (0..65535)
PROPERTIES (none)
6.12.7. The Class "PolicyIPProtocolVariable" DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
NAME PolicyIPProtocolVariable 6.12.7. The Class "PolicyIPProtocolVariable"
DESCRIPTION The IP protocol number.
ALLOWED VALUE TYPES: NAME PolicyIPProtocolVariable
DESCRIPTION The IP protocol number.
- PolicyIntegerValue (0..255) ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..255)
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.12.8. The Class "PolicyIPVersionVariable" 6.12.8. The Class "PolicyIPVersionVariable"
NAME PolicyIPVersionVariable NAME PolicyIPVersionVariable
DESCRIPTION The IP version number. The well-known values are 4 DESCRIPTION The IP version number. The well-known values are 4
and 6. and 6.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..15) - PolicyIntegerValue (0..15)
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.12.9. The Class "PolicyIPToSVariable" 6.12.9. The Class "PolicyIPToSVariable"
NAME PolicyIPToSVariable NAME PolicyIPToSVariable
DESCRIPTION The IP TOS octet. DESCRIPTION The IP TOS octet.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..255) - PolicyIntegerValue (0..255)
- PolicyBitStringValue (8 bits) - PolicyBitStringValue (8 bits)
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.12.10. The Class "PolicyDSCPVariable" 6.12.10. The Class "PolicyDSCPVariable"
NAME PolicyDSCPVariable NAME PolicyDSCPVariable
DESCRIPTION The 6 bit Differentiated Service Code Point. DESCRIPTION The 6 bit Differentiated Service Code Point.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..63) - PolicyIntegerValue (0..63)
- PolicyBitStringValue (6 bits) - PolicyBitStringValue (6 bits)
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.12.11. The Class "PolicyFlowIdVariable" 6.12.11. The Class "PolicyFlowIdVariable"
NAME PolicyFlowIdVariable NAME PolicyFlowIdVariable
DESCRIPTION The flow identifer of the outermost IPv6 packet DESCRIPTION The flow identifier of the outermost IPv6 packet
header. "Outermost" here refers to the IP packet as header. "Outermost" here refers to the IP packet as
it flows on the wire, before any headers have been it flows on the wire, before any headers have been
stripped from it. stripped from it.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..1048575 - PolicyIntegerValue (0..1048575
- PolicyBitStringValue (20 bits) - PolicyBitStringValue (20 bits)
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.12.12. The Class "PolicySourceMACVariable" 6.12.12. The Class "PolicySourceMACVariable"
NAME PolicySourceMACVariable NAME PolicySourceMACVariable
DESCRIPTION The source MAC address. DESCRIPTION The source MAC address.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyMACAddrValue - PolicyMACAddrValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.12.13. The Class "PolicyDestinationMACVariable" 6.12.13. The Class "PolicyDestinationMACVariable"
NAME PolicyDestinationMACVariable NAME PolicyDestinationMACVariable
DESCRIPTION The destination MAC address. DESCRIPTION The destination MAC address.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyMACAddrValue - PolicyMACAddrValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.12.14. The Class "PolicyVLANVariable" 6.12.14. The Class "PolicyVLANVariable"
NAME PolicyVLANVariable NAME PolicyVLANVariable
DESCRIPTION The virtual Bridged Local Area Network Identifier, a DESCRIPTION The virtual Bridged Local Area Network Identifier, a
12-bit field as defined in the IEEE 802.1q standard. 12-bit field as defined in the IEEE 802.1q standard.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..4095) - PolicyIntegerValue (0..4095)
- PolicyBitStringValue (12 bits) - PolicyBitStringValue (12 bits)
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.12.15. The Class "PolicyCoSVariable" 6.12.15. The Class "PolicyCoSVariable"
NAME PolicyCoSVariable NAME PolicyCoSVariable
DESCRIPTION Class of Service, a 3-bit field, used in the layer 2 DESCRIPTION Class of Service, a 3-bit field, used in the layer 2
header to select the forwarding treatment. Bound to header to select the forwarding treatment. Bound to
the IEEE 802.1q user-priority field. the IEEE 802.1q user-priority field.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..7) - PolicyIntegerValue (0..7)
- PolicyBitStringValue (3 bits) - PolicyBitStringValue (3 bits)
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.12.16. The Class "PolicyEthertypeVariable" 6.12.16. The Class "PolicyEthertypeVariable"
NAME PolicyEthertypeVariable NAME PolicyEthertypeVariable
DESCRIPTION The Ethertype protocol number of Ethernet frames. DESCRIPTION The Ethertype protocol number of Ethernet frames.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..65535) - PolicyIntegerValue (0..65535)
- PolicyBitStringValue (16 bits) - PolicyBitStringValue (16 bits)
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.12.17. The Class "PolicySourceSAPVariable" 6.12.17. The Class "PolicySourceSAPVariable"
NAME PolicySourceSAPVariable NAME PolicySourceSAPVariable
DESCRIPTION The Source Service Access Point (SAP) number of the DESCRIPTION The Source Service Access Point (SAP) number of the
IEEE 802.2 LLC header. IEEE 802.2 LLC header.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..255) - PolicyIntegerValue (0..255)
- PolicyBitStringValue (8 bits) - PolicyBitStringValue (8 bits)
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.12.18. The Class "PolicyDestinationSAPVariable" 6.12.18. The Class "PolicyDestinationSAPVariable"
NAME PolicyDestinationSAPVariable NAME PolicyDestinationSAPVariable
DESCRIPTION The Destination Service Access Point (SAP) number of DESCRIPTION The Destination Service Access Point (SAP) number of
the IEEE 802.2 LLC header. the IEEE 802.2 LLC header.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..255) - PolicyIntegerValue (0..255)
- PolicyBitStringValue (8 bits) - PolicyBitStringValue (8 bits)
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.12.19. The Class "PolicySNAPOUIVariable"
NAME PolicySNAPOUIVariable 6.12.19. The Class "PolicySNAPOUIVariable"
DESCRIPTION The value of the first three octets of the Sub-Network
Access Protocol (SNAP) Protocol Identifier field for
802.2 SNAP encapsulation, containing an
Organizationally Unique Identifier (OUI). The value
00-00-00 indicates the encapsulation of Ethernet
frames (RFC 1042). OUI value 00-00-F8 indicates the
special encapsulation of Ethernet frames by certain
types of bridges (IEEE 802.1H). Other values are
supported, but are not further defined here. These
OUI. values are to be interpreted according to the
endian-notation conventions of IEEE 802. For either
of the two Ethernet encapsulations, the remainder of
the Protocol Identifier field is represented by the
PolicySNAPTypeVariable.
ALLOWED VALUE TYPES: NAME PolicySNAPOUIVariable
- PolicyIntegerValue (0..16777215) DESCRIPTION The value of the first three octets of the Sub-
- PolicyBitStringValue (24 bits) Network Access Protocol (SNAP) Protocol Identifier
field for 802.2 SNAP encapsulation, containing an
Organizationally Unique Identifier (OUI). The value
00-00-00 indicates the encapsulation of Ethernet
frames (RFC 1042). OUI value 00-00-F8 indicates the
special encapsulation of Ethernet frames by certain
types of bridges (IEEE 802.1H). Other values are
supported, but are not further defined here. These
OUI values are to be interpreted according to the
endian-notation conventions of IEEE 802. For either
of the two Ethernet encapsulations, the remainder of
the Protocol Identifier field is represented by the
PolicySNAPTypeVariable.
DERIVED FROM PolicyImplicitVariable ALLOWED VALUE TYPES:
ABSTRACT FALSE - PolicyIntegerValue (0..16777215)
PROPERTIES (none) - PolicyBitStringValue (24 bits)
6.12.20. The Class "PolicySNAPTypeVariable" DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
NAME PolicySNAPTypeVariable 6.12.20. The Class "PolicySNAPTypeVariable"
DESCRIPTION The value of the 4th and 5th octets of the Sub-Network
Access Protocol (SNAP) Protocol Identifier field for
IEEE 802 SNAP encapsulation when the
PolicySNAPOUIVariable indicates one of the two
Encapsulated Ethernet frame formats. This value is
undefined for other values of PolicySNAPOUIVariable.
ALLOWED VALUE TYPES: NAME PolicySNAPTypeVariable
- PolicyIntegerValue (0..65535) DESCRIPTION The value of the 4th and 5th octets of the Sub-
- PolicyBitStringValue (16 bits) Network Access Protocol (SNAP) Protocol Identifier
field for IEEE 802 SNAP encapsulation when the
PolicySNAPOUIVariable indicates one of the two
Encapsulated Ethernet frame formats. This value is
undefined for other values of PolicySNAPOUIVariable.
DERIVED FROM PolicyImplicitVariable ALLOWED VALUE TYPES:
ABSTRACT FALSE - PolicyIntegerValue (0..65535)
PROPERTIES (none) - PolicyBitStringValue (16 bits)
6.12.21. The Class "PolicyFlowDirectionVariable" DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
NAME PolicyFlowDirectionVariable 6.12.21. The Class "PolicyFlowDirectionVariable"
DESCRIPTION The direction of a flow relative to a network element.
Direction may be "IN" and/or "OUT".
ALLOWED VALUE TYPES: NAME PolicyFlowDirectionVariable
DESCRIPTION The direction of a flow relative to a network
element. Direction may be "IN" and/or "OUT".
- PolicyStringValue ('IN", "OUT") ALLOWED VALUE TYPES:
- PolicyStringValue ('IN", "OUT")
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
To match on both inbound and outbound flows, the associated To match on both inbound and outbound flows, the associated
PolicyStringValue object has two entries in its StringList property: "IN" PolicyStringValue object has two entries in its StringList property:
and "OUT". "IN" and "OUT".
6.13. The Abstract Class "PolicyValue" 6.13. The Abstract Class "PolicyValue"
This is an abstract class that serves as the base class for all This is an abstract class that serves as the base class for all
subclasses that are used to define value objects in the PCIMe. It is subclasses that are used to define value objects in the PCIMe. It is
used for defining values and constants used in policy conditions. The used for defining values and constants used in policy conditions.
class definition is as follows: The class definition is as follows:
NAME PolicyValue NAME PolicyValue
DERIVED FROM Policy DERIVED FROM Policy
ABSTRACT True ABSTRACT True
PROPERTIES (none) PROPERTIES (none)
6.14. Subclasses of "PolicyValue" Specified in PCIMe 6.14. Subclasses of "PolicyValue" Specified in PCIMe
The following subsections contain the PolicyValue subclasses defined in The following subsections contain the PolicyValue subclasses defined
PCIMe. Additional subclasses may be defined in models derived from in PCIMe. Additional subclasses may be defined in models derived
PCIMe. from PCIMe.
6.14.1. The Class "PolicyIPv4AddrValue" 6.14.1. The Class "PolicyIPv4AddrValue"
This class is used to provide a list of IPv4Addresses, hostnames and This class is used to provide a list of IPv4Addresses, hostnames and
address range values to be matched against in a policy condition. The address range values to be matched against in a policy condition.
class definition is as follows: The class definition is as follows:
NAME PolicyIPv4AddrValue NAME PolicyIPv4AddrValue
DERIVED FROM PolicyValue DERIVED FROM PolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES IPv4AddrList[ ] PROPERTIES IPv4AddrList[ ]
The IPv4AddrList property provides an unordered list of strings, each The IPv4AddrList property provides an unordered list of strings, each
specifying a single IPv4 address, a hostname, or a range of IPv4 specifying a single IPv4 address, a hostname, or a range of IPv4
addresses, according to the ABNF definition [6] of an IPv4 address, as addresses, according to the ABNF definition [6] of an IPv4 address,
specified below: as specified below:
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv4prefix = IPv4address "/" 1*2DIGIT IPv4prefix = IPv4address "/" 1*2DIGIT
IPv4range = IPv4address"-"IPv4address IPv4range = IPv4address"-"IPv4address
IPv4maskedaddress = IPv4address","IPv4address IPv4maskedaddress = IPv4address","IPv4address
Hostname (as defined in [4]) Hostname (as defined in [4])
In the above definition, each string entry is either: In the above definition, each string entry is either:
1. A single IPv4address in dot notation, as defined above. Example: 1. A single IPv4address in dot notation, as defined above. Example:
121.1.1.2 121.1.1.2
2. An IPv4prefix address range, as defined above, specified by an 2. An IPv4prefix address range, as defined above, specified by an
address and a prefix length, separated by "/". Example: address and a prefix length, separated by "/". Example:
2.3.128.0/15 2.3.128.0/15
3. An IPv4range address range defined above, specified by a starting 3. An IPv4range address range defined above, specified by a starting
address in dot notation and an ending address in dot notation, address in dot notation and an ending address in dot notation,
separated by "-". The range includes all addresses between the separated by "-". The range includes all addresses between the
range's starting and ending addresses, including these two range's starting and ending addresses, including these two
addresses. Example: 1.1.22.1-1.1.22.5 addresses. Example: 1.1.22.1-1.1.22.5
4. An IPv4maskedaddress address range, as defined above, specified by 4. An IPv4maskedaddress address range, as defined above, specified by
an address and mask. The address and mask are represented in dot an address and mask. The address and mask are represented in dot
notation, separated by a comma ",". The masked address appears notation, separated by a comma ",". The masked address appears
before the comma, and the mask appears after the comma. Example: before the comma, and the mask appears after the comma. Example:
2.3.128.0,255.255.248.0. 2.3.128.0,255.255.248.0.
5. A single Hostname. The Hostname format follows the guidelines and 5. A single Hostname. The Hostname format follows the guidelines and
restrictions specified in [4]. Example: www.bigcompany.com. restrictions specified in [4]. Example: www.bigcompany.com.
Conditions matching IPv4AddrValues evaluate to true according to the Conditions matching IPv4AddrValues evaluate to true according to the
generic matching rules. Additionally, a hostname is matched against generic matching rules. Additionally, a hostname is matched against
another valid IPv4address representation by resolving the hostname into another valid IPv4address representation by resolving the hostname
an IPv4 address first, and then comparing the addresses afterwards. into an IPv4 address first, and then comparing the addresses
Matching hostnames against each other is done using a string comparison afterwards. Matching hostnames against each other is done using a
of the two names. string comparison of the two names.
The property definition is as follows: The property definition is as follows:
NAME IPv4AddrList NAME IPv4AddrList
SYNTAX String SYNTAX String
FORMAT IPv4address | IPv4prefix | IPv4range | FORMAT IPv4address | IPv4prefix | IPv4range |
IPv4maskedaddress | hostname IPv4maskedaddress | hostname
6.14.2. The Class "PolicyIPv6AddrValue 6.14.2. The Class "PolicyIPv6AddrValue
This class is used to define a list of IPv6 addresses, hostnames, and This class is used to define a list of IPv6 addresses, hostnames, and
address range values. The class definition is as follows: address range values. The class definition is as follows:
NAME PolicyIPv6AddrValue NAME PolicyIPv6AddrValue
DERIVED FROM PolicyValue DERIVED FROM PolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES IPv6AddrList[ ] PROPERTIES IPv6AddrList[ ]
The property IPv6AddrList provides an unordered list of strings, each The property IPv6AddrList provides an unordered list of strings, each
specifying an IPv6 address, a hostname, or a range of IPv6 addresses. specifying an IPv6 address, a hostname, or a range of IPv6 addresses.
IPv6 address format definition uses the standard address format defined IPv6 address format definition uses the standard address format
in [7]. The ABNF definition [6] as specified in [7] is: defined in [7]. The ABNF definition [6] as specified in [7] is:
IPv6address = hexpart [ ":" IPv4address ] IPv6address = hexpart [ ":" IPv4address ]
IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
IPv6prefix = hexpart "/" 1*2DIGIT IPv6prefix = hexpart "/" 1*2DIGIT
hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
hexseq = hex4 *( ":" hex4) hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG hex4 = 1*4HEXDIG
IPv6range = IPv6address"-"IPv6address IPv6range = IPv6address"-"IPv6address
IPv6maskedaddress = IPv6address","IPv6address IPv6maskedaddress = IPv6address","IPv6address
Hostname (as defines in [NAMES]) Hostname (as defines in [NAMES])
Each string entry is either: Each string entry is either:
1. A single IPv6address as defined above. 1. A single IPv6address as defined above.
2. A single Hostname. Hostname format follows guidelines and 2. A single Hostname. Hostname format follows guidelines and
restrictions specified in [4]. restrictions specified in [4].
3. An IPv6range address range, specified by a starting address in dot 3. An IPv6range address range, specified by a starting address in dot
notation and an ending address in dot notation, separated by "-". notation and an ending address in dot notation, separated by "-".
The range includes all addresses between the range's starting and The range includes all addresses between the range's starting and
ending addresses, including these two addresses. ending addresses, including these two addresses.
4. An IPv4maskedaddress address range defined above specified by an 4. An IPv4maskedaddress address range defined above specified by an
address and mask. The address and mask are represented in dot address and mask. The address and mask are represented in dot
notation separated by a comma ",". notation separated by a comma ",".
5. A single IPv6prefix as defined above. 5. A single IPv6prefix as defined above.
Conditions matching IPv6AddrValues evaluate to true according to the Conditions matching IPv6AddrValues evaluate to true according to the
generic matching rules. Additionally, a hostname is matched against generic matching rules. Additionally, a hostname is matched against
another valid IPv6address representation by resolving the hostname into another valid IPv6address representation by resolving the hostname
an IPv6 address first, and then comparing the addresses afterwards. into an IPv6 address first, and then comparing the addresses
Matching hostnames against each other is done using a string comparison afterwards. Matching hostnames against each other is done using a
of the two names. string comparison of the two names.
6.14.3. The Class "PolicyMACAddrValue" 6.14.3. The Class "PolicyMACAddrValue"
This class is used to define a list of MAC addresses and MAC address This class is used to define a list of MAC addresses and MAC address
range values. The class definition is as follows: range values. The class definition is as follows:
NAME PolicyMACAddrValue NAME PolicyMACAddrValue
DERIVED FROM PolicyValue DERIVED FROM PolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES MACAddrList[ ] PROPERTIES MACAddrList[ ]
The property MACAddrList provides an unordered list of strings, each The property MACAddrList provides an unordered list of strings, each
specifying a MAC address or a range of MAC addresses. The 802 MAC specifying a MAC address or a range of MAC addresses. The 802 MAC
address canonical format is used. The ABNF definition [6] is: address canonical format is used. The ABNF definition [6] is:
MACaddress = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG
MACmaskedaddress = MACaddress","MACaddress
MACaddress = 1*4HEXDIG ":" 1*4HEXDIG ":" 1*4HEXDIG
MACmaskedaddress = MACaddress","MACaddress
Each string entry is either: Each string entry is either:
1. A single MAC address. Example: 0000:00A5:0000 1. A single MAC address. Example: 0000:00A5:0000
2. A MACmaskedaddress address range defined specified by an address 2. A MACmaskedaddress address range defined specified by an address
and mask. The mask specifies the relevant bits in the address. and mask. The mask specifies the relevant bits in the address.
Example: 0000:00A5:0000,FFFF:FFFF:0000 defines a range of MAC Example: 0000:00A5:0000,FFFF:FFFF:0000 defines a range of MAC
addresses in which the first four octets are equal to 0000:00A5. addresses in which the first four octets are equal to 0000:00A5.
The property definition is as follows: The property definition is as follows:
NAME MACAddrList NAME MACAddrList
SYNTAX String SYNTAX String
FORMAT MACaddress | MACmaskedaddress FORMAT MACaddress | MACmaskedaddress
6.14.4. The Class "PolicyStringValue" 6.14.4. The Class "PolicyStringValue"
This class is used to represent a single string value, or a set of string This class is used to represent a single string value, or a set of
values. Each value can have wildcards. The class definition is as string values. Each value can have wildcards. The class definition
follows: is as follows:
NAME PolicyStringValue NAME PolicyStringValue
DERIVED FROM PolicyValue DERIVED FROM PolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES StringList[ ] PROPERTIES StringList[ ]
The property StringList provides an unordered list of strings, each The property StringList provides an unordered list of strings, each
representing a single string with wildcards. The asterisk character "*" representing a single string with wildcards. The asterisk character
is used as a wildcard, and represents an arbitrary substring replacement. "*" is used as a wildcard, and represents an arbitrary substring
For example, the value "abc*def" matches the string "abcxyzdef", and the replacement. For example, the value "abc*def" matches the string
value "abc*def*" matches the string "abcxxxdefyyyzzz". The syntax "abcxyzdef", and the value "abc*def*" matches the string
definition is identical to the substring assertion syntax defined in [5]. "abcxxxdefyyyzzz". The syntax definition is identical to the
If the asterisk character is required as part of the string value itself, substring assertion syntax defined in [5]. If the asterisk character
it MUST be quoted as described in Section 4.3 of [5]. is required as part of the string value itself, it MUST be quoted as
described in Section 4.3 of [5].
The property definition is as follows: The property definition is as follows:
NAME StringList NAME StringList
SYNTAX String SYNTAX String
6.14.5. The Class "PolicyBitStringValue" 6.14.5. The Class "PolicyBitStringValue"
This class is used to represent a single bit string value, or a set of This class is used to represent a single bit string value, or a set
bit string values. The class definition is as follows: of bit string values. The class definition is as follows:
NAME PolicyBitStringValue NAME PolicyBitStringValue
DERIVED FROM PolicyValue DERIVED FROM PolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES BitStringList[ ] PROPERTIES BitStringList[ ]
The property BitStringList provides an unordered list of strings, each The property BitStringList provides an unordered list of strings,
representing a single bit string or a set of bit strings. The number of each representing a single bit string or a set of bit strings. The
bits specified SHOULD equal the number of bits of the expected variable. number of bits specified SHOULD equal the number of bits of the
For example, for a one-octet variable, 8 bits should be specified. If expected variable. For example, for a one-octet variable, 8 bits
the variable does not have a fixed length, the bit string should be should be specified. If the variable does not have a fixed length,
matched against the variable's most significant bit string. The formal the bit string should be matched against the variable's most
definition of a bit string is: significant bit string. The formal definition of a bit string is:
binary-digit = "0" / "1" binary-digit = "0" / "1"
bitString = 1*binary-digit bitString = 1*binary-digit
maskedBitString = bitString","bitString maskedBitString = bitString","bitString
Each string entry is either: Each string entry is either:
1. A single bit string. Example: 00111010 1. A single bit string. Example: 00111010
2. A range of bit strings specified using a bit string and a bit 2. A range of bit strings specified using a bit string and a bit
mask. The bit string and mask fields have the same number of bits mask. The bit string and mask fields have the same number of bits
specified. The mask bit string specifies the significant bits in specified. The mask bit string specifies the significant bits in
the bit string value. For example, 110110, 100110 and 110111 the bit string value. For example, 110110, 100110 and 110111
would match the maskedBitString 100110,101110 but 100100 would would match the maskedBitString 100110,101110 but 100100 would
not. not.
The property definition is as follows: The property definition is as follows:
NAME BitStringList NAME BitStringList
SYNTAX String SYNTAX String
FORMAT bitString | maskedBitString FORMAT bitString | maskedBitString
6.14.6. The Class "PolicyIntegerValue" 6.14.6. The Class "PolicyIntegerValue"
This class provides a list of integer and integer range values. Integers This class provides a list of integer and integer range values.
of arbitrary sizes can be represented. The class definition is as Integers of arbitrary sizes can be represented. The class definition
follows: is as follows:
NAME PolicyIntegerValue NAME PolicyIntegerValue
DERIVED FROM PolicyValue DERIVED FROM PolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES IntegerList[ ] PROPERTIES IntegerList[ ]
The property IntegerList provides an unordered list of integers and The property IntegerList provides an unordered list of integers and
integer range values, represented as strings. The format of this integer range values, represented as strings. The format of this
property takes one of the following forms: property takes one of the following forms:
1. An integer value. 1. An integer value.
2. A range of integers. The range is specified by a starting integer 2. A range of integers. The range is specified by a starting integer
and an ending integer, separated by '..'. The starting integer and an ending integer, separated by '..'. The starting integer
MUST be less than or equal to the ending integer. The range MUST be less than or equal to the ending integer. The range
includes all integers between the starting and ending integers, includes all integers between the starting and ending integers,
including these two integers. including these two integers.
To represent a range of integers that is not bounded, the reserved words To represent a range of integers that is not bounded, the reserved
-INFINITY and/or INFINITY can be used in place of the starting and ending words -INFINITY and/or INFINITY can be used in place of the starting
integers. In addition to ordinary integer matches, INFINITY matches and ending integers. In addition to ordinary integer matches,
INFINITY and -INFINITY matches -INFINITY. INFINITY matches INFINITY and -INFINITY matches -INFINITY.
The ABNF definition [6] is: The ABNF definition [6] is:
integer = [-]1*DIGIT | "INFINITY" | "-INFINITY" integer = [-]1*DIGIT | "INFINITY" | "-INFINITY"
integerrange = integer".."integer integerrange = integer".."integer
Using ranges, the operators greater-than, greater-than-or-equal-to, less- Using ranges, the operators greater-than, greater-than-or-equal-to,
than, and less-than-or-equal-to can be expressed. For example, "X is- less- than, and less-than-or-equal-to can be expressed. For example,
greater-than 5" (where X is an integer) can be translated to "X matches "X is- greater-than 5" (where X is an integer) can be translated to
6-INFINITY". This enables the match condition semantics of the operator "X matches 6-INFINITY". This enables the match condition semantics
for the SimplePolicyCondition class to be kept simple (i.e., just the of the operator for the SimplePolicyCondition class to be kept simple
value "match"). (i.e., just the value "match").
The property definition is as follows: The property definition is as follows:
NAME IntegerList NAME IntegerList
SYNTAX String SYNTAX String
FORMAT integer | integerrange FORMAT integer | integerrange
6.14.7. The Class "PolicyBooleanValue" 6.14.7. The Class "PolicyBooleanValue"
This class is used to represent a Boolean (TRUE/FALSE) value. The class This class is used to represent a Boolean (TRUE/FALSE) value. The
definition is as follows: class definition is as follows:
NAME PolicyBooleanValue NAME PolicyBooleanValue
DERIVED FROM PolicyValue DERIVED FROM PolicyValue
ABSTRACT False ABSTRACT False
PROPERTIES BooleanValue PROPERTIES BooleanValue
The property definition is as follows: The property definition is as follows:
NAME BooleanValue NAME BooleanValue
SYNTAX boolean SYNTAX boolean
6.15. The Class "PolicyRoleCollection" 6.15. The Class "PolicyRoleCollection"
This class represents a collection of managed elements that share a This class represents a collection of managed elements that share a
common role. The PolicyRoleCollection always exists in the context of a common role. The PolicyRoleCollection always exists in the context
system, specified using the PolicyRoleCollectionInSystem association. of a system, specified using the PolicyRoleCollectionInSystem
The value of the PolicyRole property in this class specifies the role, association. The value of the PolicyRole property in this class
and can be matched with the value(s) in the PolicyRoles array in specifies the role, and can be matched with the value(s) in the
PolicyRules and PolicyGroups. ManagedElements that share the role PolicyRoles array in PolicyRules and PolicyGroups. ManagedElements
defined in this collection are aggregated into the collection via the that share the role defined in this collection are aggregated into
association ElementInPolicyRoleCollection. the collection via the association ElementInPolicyRoleCollection.
NAME PolicyRoleCollection NAME PolicyRoleCollection
DESCRIPTION A subclass of the CIM Collection class used to group DESCRIPTION A subclass of the CIM Collection class used to group
together managed elements that share a role. together managed elements that share a role.
DERIVED FROM Collection DERIVED FROM Collection
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES PolicyRole
6.15.1. The Single-Valued Property "PolicyRole" PROPERTIES PolicyRole
This property represents the role associated with a PolicyRoleCollection. 6.15.1. The Single-Valued Property "PolicyRole"
The property definition is as follows:
NAME PolicyRole This property represents the role associated with a
DESCRIPTION A string representing the role associated with a PolicyRoleCollection. The property definition is as follows:
PolicyRoleCollection.
SYNTAX string
6.16. The Class "ReusablePolicyContainer" NAME PolicyRole
DESCRIPTION A string representing the role associated with a
PolicyRoleCollection.
SYNTAX string
6.16. The Class "ReusablePolicyContainer"
The new class ReusablePolicyContainer is defined as follows: The new class ReusablePolicyContainer is defined as follows:
NAME ReusablePolicyContainer NAME ReusablePolicyContainer
DESCRIPTION A class representing an administratively defined DESCRIPTION A class representing an administratively defined
container for reusable policy-related information. container for reusable policy-related information.
This class does not introduce any additional This class does not introduce any additional
properties beyond those in its superclass AdminDomain. properties beyond those in its superclass
It does, however, participate in a number of unique AdminDomain. It does, however, participate in
associations. a number of unique associations.
DERIVED FROM AdminDomain DERIVED FROM AdminDomain
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
6.17. Deprecate PCIM's Class "PolicyRepository" 6.17. Deprecate PCIM's Class "PolicyRepository"
The class definition of PolicyRepository (from PCIM) is updated as The class definition of PolicyRepository (from PCIM) is updated as
follows, with an indication that the class has been deprecated. Note follows, with an indication that the class has been deprecated. Note
that when an element of the model is deprecated, its replacement element that when an element of the model is deprecated, its replacement
is identified explicitly. element is identified explicitly.
NAME PolicyRepository NAME PolicyRepository
DEPRECATED FOR ReusablePolicyContainer DEPRECATED FOR ReusablePolicyContainer
DESCRIPTION A class representing an administratively defined DESCRIPTION A class representing an administratively defined
container for reusable policy-related information. container for reusable policy-related information.
This class does not introduce any additional This class does not introduce any additional
properties beyond those in its superclass AdminDomain. properties beyond those in its superclass
It does, however, participate in a number of unique AdminDomain. It does, however, participate in a
associations. number of unique associations.
DERIVED FROM AdminDomain
ABSTRACT FALSE
PROPERTIES (none)
6.18. The Abstract Class "FilterEntryBase" DERIVED FROM AdminDomain
ABSTRACT FALSE
PROPERTIES (none)
FilterEntryBase is the abstract base class from which all filter entry 6.18. The Abstract Class "FilterEntryBase"
classes are derived. It serves as the endpoint for the
EntriesInFilterList aggregation, which groups filter entries into filter FilterEntryBase is the abstract base class from which all filter
lists. Its properties include CIM naming attributes and an IsNegated entry classes are derived. It serves as the endpoint for the
boolean property (to easily "NOT" the match information specified in an EntriesInFilterList aggregation, which groups filter entries into
instance of one of its subclasses). filter lists. Its properties include CIM naming attributes and an
IsNegated boolean property (to easily "NOT" the match information
specified in an instance of one of its subclasses).
The class definition is as follows: The class definition is as follows:
NAME FilterEntryBase NAME FilterEntryBase
DESCRIPTION An abstract class representing a single DESCRIPTION An abstract class representing a single
filter that is aggregated into a filter that is aggregated into a
FilterList via the aggregation FilterList via the aggregation
EntriesInFilterList. EntriesInFilterList.
DERIVED FROM LogicalElement DERIVED FROM LogicalElement
TYPE Abstract TYPE Abstract
PROPERTIES IsNegated PROPERTIES IsNegated
6.19. The Class "IpHeadersFilter" 6.19. The Class "IpHeadersFilter"
This concrete class contains the most commonly required properties for This concrete class contains the most commonly required properties
performing filtering on IP, TCP or UDP headers. Properties not present for performing filtering on IP, TCP or UDP headers. Properties not
in an instance of IPHeadersFilter are treated as 'all values'. A present in an instance of IPHeadersFilter are treated as 'all
property HdrIpVersion identifies whether the IP addresses in an instance values'. A property HdrIpVersion identifies whether the IP addresses
are IPv4 or IPv6 addresses. Since the source and destination IP in an instance are IPv4 or IPv6 addresses. Since the source and
addresses come from the same packet header, they will always be of the destination IP addresses come from the same packet header, they will
same type. always be of the same type.
The class definition is as follows: The class definition is as follows:
NAME IpHeadersFilter NAME IpHeadersFilter
DESCRIPTION A class representing an entire IP DESCRIPTION A class representing an entire IP
header filter, or any subset of one. header filter, or any subset of one.
DERIVED FROM FilterEntryBase DERIVED FROM FilterEntryBase
TYPE Concrete TYPE Concrete
PROPERTIES HdrIpVersion, HdrSrcAddress, PROPERTIES HdrIpVersion, HdrSrcAddress,
HdrSrcAddressEndOfRange, HdrSrcMask, HdrSrcAddressEndOfRange, HdrSrcMask,
HdrDestAddress, HdrDestAddressEndOfRange, HdrDestAddress, HdrDestAddressEndOfRange,
HdrDestMask, HdrProtocolID, HdrDestMask, HdrProtocolID,
HdrSrcPortStart, HdrSrcPortEnd, HdrSrcPortStart, HdrSrcPortEnd,
HdrDestPortStart, HdrDestPortEnd, HdrDSCP[ ], HdrDestPortStart, HdrDestPortEnd, HdrDSCP[ ],
HdrFlowLabel HdrFlowLabel
6.19.1. The Property HdrIpVersion 6.19.1. The Property HdrIpVersion
This property is an 8-bit unsigned integer, identifying the version of This property is an 8-bit unsigned integer, identifying the version
the IP addresses to be filtered on. IP versions are identified as they of the IP addresses to be filtered on. IP versions are identified as
are in the Version field of the IP packet header - IPv4 = 4, IPv6 = 6. they are in the Version field of the IP packet header - IPv4 = 4,
These two values are the only ones defined for this property. IPv6 = 6. These two values are the only ones defined for this
property.
The value of this property determines the sizes of the OctetStrings in The value of this property determines the sizes of the OctetStrings
the six properties HdrSrcAddress, HdrSrcAddressEndOfRange, HdrSrcMask, in the six properties HdrSrcAddress, HdrSrcAddressEndOfRange,
HdrDestAddress, HdrDestAddressEndOfRange, and HdrDestMask, as follows: HdrSrcMask, HdrDestAddress, HdrDestAddressEndOfRange, and
HdrDestMask, as follows:
o IPv4: OctetString(SIZE (4)) o IPv4: OctetString(SIZE (4))
o IPv6: OctetString(SIZE (16|20)), depending on whether a scope
identifier is present
If a value for this property is not provided, then the filter does not o IPv6: OctetString(SIZE (16|20)), depending on whether a scope
consider IP version in selecting matching packets, i.e., IP version identifier is present
matches for all values. In this case, the HdrSrcAddress,
If a value for this property is not provided, then the filter does
not consider IP version in selecting matching packets, i.e., IP
version matches for all values. In this case, the HdrSrcAddress,
HdrSrcAddressEndOfRange, HdrSrcMask, HdrDestAddress, HdrSrcAddressEndOfRange, HdrSrcMask, HdrDestAddress,
HdrDestAddressEndOfRange, and HdrDestMask must also not be present. HdrDestAddressEndOfRange, and HdrDestMask must also not be present.
6.19.2. The Property HdrSrcAddress 6.19.2. The Property HdrSrcAddress
This property is an OctetString, of a size determined by the value of the This property is an OctetString, of a size determined by the value of
HdrIpVersion property, representing a source IP address. When there is the HdrIpVersion property, representing a source IP address. When
no HdrSrcAddressEndOfRange value, this value is compared to the source there is no HdrSrcAddressEndOfRange value, this value is compared to
address in the IP header, subject to the mask represented in the the source address in the IP header, subject to the mask represented
HdrSrcMask property. (Note that the mask is ANDed with the address.) in the HdrSrcMask property. (Note that the mask is ANDed with the
When there is a HdrSrcAddressEndOfRange value, this value is the start of address.) When there is a HdrSrcAddressEndOfRange value, this value
the specified range (i.e., the HdrSrcAddress is lower than the is the start of the specified range (i.e., the HdrSrcAddress is lower
HdrSrcAddressEndOfRange) that is compared to the source address in the IP than the HdrSrcAddressEndOfRange) that is compared to the source
header and matches on any value in the range. address in the IP header and matches on any value in the range.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider HdrSrcAddress in selecting matching packets, i.e., HdrSrcAddress not consider HdrSrcAddress in selecting matching packets, i.e.,
matches for all values. HdrSrcAddress matches for all values.
6.19.3. The Property HdrSrcAddressEndOfRange 6.19.3. The Property HdrSrcAddressEndOfRange
This property is an OctetString, of a size determined by the value of the This property is an OctetString, of a size determined by the value of
HdrIpVersion property, representing the end of a range of source IP the HdrIpVersion property, representing the end of a range of source
addresses (inclusive), where the start of the range is the HdrSrcAddress IP addresses (inclusive), where the start of the range is the
property value. HdrSrcAddress property value.
If a value for HdrSrcAddress is not provided, then this property also If a value for HdrSrcAddress is not provided, then this property also
MUST NOT be provided. If a value for this property is provided, then MUST NOT be provided. If a value for this property is provided, then
HdrSrcMask MUST NOT be provided. HdrSrcMask MUST NOT be provided.
6.19.4. The Property HdrSrcMask 6.19.4. The Property HdrSrcMask
This property is an OctetString, of a size determined by the value of the This property is an OctetString, of a size determined by the value of
HdrIpVersion property, representing a mask to be used in comparing the the HdrIpVersion property, representing a mask to be used in
source address in the IP header with the value represented in the comparing the source address in the IP header with the value
HdrSrcAddress property. represented in the HdrSrcAddress property.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider HdrSrcMask in selecting matching packets, i.e., the value of not consider HdrSrcMask in selecting matching packets, i.e., the
HdrSrcAddress or the source address range must match the source address value of HdrSrcAddress or the source address range must match the
in the packet exactly. If a value for this property is provided, then source address in the packet exactly. If a value for this property
HdrSrcAddressEndOfRange MUST NOT be provided. is provided, then HdrSrcAddressEndOfRange MUST NOT be provided.
6.19.5. The Property HdrDestAddress 6.19.5. The Property HdrDestAddress
This property is an OctetString, of a size determined by the value of the This property is an OctetString, of a size determined by the value of
HdrIpVersion property, representing a destination IP address. When there the HdrIpVersion property, representing a destination IP address.
is no HdrDestAddressEndOfRange value, this value is compared to the When there is no HdrDestAddressEndOfRange value, this value is
destination address in the IP header, subject to the mask represented in compared to the destination address in the IP header, subject to the
the HdrDestMask property. (Note that the mask is ANDed with the mask represented in the HdrDestMask property. (Note that the mask is
address.) When there is a HdrDestAddressEndOfRange value, this value is ANDed with the address.) When there is a HdrDestAddressEndOfRange
the start of the specified range (i.e., the HdrDestAddress is lower than value, this value is the start of the specified range (i.e., the
the HdrDestAddressEndOfRange) that is compared to the destination address HdrDestAddress is lower than the HdrDestAddressEndOfRange) that is
in the IP header and matches on any value in the range. compared to the destination address in the IP header and matches on
any value in the range.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider HdrDestAddress in selecting matching packets, i.e., not consider HdrDestAddress in selecting matching packets, i.e.,
HdrDestAddress matches for all values. HdrDestAddress matches for all values.
6.19.6. The Property HdrDestAddressEndOfRange 6.19.6. The Property HdrDestAddressEndOfRange
This property is an OctetString, of a size determined by the value of the This property is an OctetString, of a size determined by the value of
HdrIpVersion property, representing the end of a range of destination IP the HdrIpVersion property, representing the end of a range of
addresses (inclusive), where the start of the range is the HdrDestAddress destination IP addresses (inclusive), where the start of the range is
property value. the HdrDestAddress property value.
If a value for HdrDestAddress is not provided, then this property also If a value for HdrDestAddress is not provided, then this property
MUST NOT be provided. If a value for this property is provided, then also MUST NOT be provided. If a value for this property is provided,
HdrDestMask MUST NOT be provided. then HdrDestMask MUST NOT be provided.
6.19.7. The Property HdrDestMask 6.19.7. The Property HdrDestMask
This property is an OctetString, of a size determined by the value of the This property is an OctetString, of a size determined by the value of
HdrIpVersion property, representing a mask to be used in comparing the the HdrIpVersion property, representing a mask to be used in
destination address in the IP header with the value represented in the comparing the destination address in the IP header with the value
HdrDestAddress property. represented in the HdrDestAddress property.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider HdrDestMask in selecting matching packets, i.e., the value of not consider HdrDestMask in selecting matching packets, i.e., the
HdrDestAddress or the destination address range must match the value of HdrDestAddress or the destination address range must match
destination address in the packet exactly. If a value for this property the destination address in the packet exactly. If a value for this
is provided, then HdrDestAddressEndOfRange MUST NOT be provided. property is provided, then HdrDestAddressEndOfRange MUST NOT be
provided.
6.19.8. The Property HdrProtocolID 6.19.8. The Property HdrProtocolID
This property is an 8-bit unsigned integer, representing an IP protocol This property is an 8-bit unsigned integer, representing an IP
type. This value is compared to the Protocol field in the IP header. protocol type. This value is compared to the Protocol field in the
IP header.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider HdrProtocolID in selecting matching packets, i.e., HdrProtocolID not consider HdrProtocolID in selecting matching packets, i.e.,
matches for all values. HdrProtocolID matches for all values.
6.19.9. The Property HdrSrcPortStart 6.19.9. The Property HdrSrcPortStart
This property is a 16-bit unsigned integer, representing the lower end of This property is a 16-bit unsigned integer, representing the lower
a range of UDP or TCP source ports. The upper end of the range is end of a range of UDP or TCP source ports. The upper end of the
represented by the HdrSrcPortEnd property. The value of HdrSrcPortStart range is represented by the HdrSrcPortEnd property. The value of
MUST be no greater than the value of HdrSrcPortEnd. A single port is HdrSrcPortStart MUST be no greater than the value of HdrSrcPortEnd.
indicated by equal values for HdrSrcPortStart and HdrSrcPortEnd. A single port is indicated by equal values for HdrSrcPortStart and
HdrSrcPortEnd.
A source port filter is evaluated by testing whether the source port A source port filter is evaluated by testing whether the source port
identified in the IP header falls within the range of values between identified in the IP header falls within the range of values between
HdrSrcPortStart and HdrSrcPortEnd, including these two end points. HdrSrcPortStart and HdrSrcPortEnd, including these two end points.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider HdrSrcPortStart in selecting matching packets, i.e., there is no not consider HdrSrcPortStart in selecting matching packets, i.e.,
lower bound in matching source port values. there is no lower bound in matching source port values.
6.19.10. The Property HdrSrcPortEnd 6.19.10. The Property HdrSrcPortEnd
This property is a 16-bit unsigned integer, representing the upper end of This property is a 16-bit unsigned integer, representing the upper
a range of UDP or TCP source ports. The lower end of the range is end of a range of UDP or TCP source ports. The lower end of the
represented by the HdrSrcPortStart property. The value of HdrSrcPortEnd range is represented by the HdrSrcPortStart property. The value of
MUST be no less than the value of HdrSrcPortStart. A single port is HdrSrcPortEnd MUST be no less than the value of HdrSrcPortStart. A
indicated by equal values for HdrSrcPortStart and HdrSrcPortEnd. single port is indicated by equal values for HdrSrcPortStart and
HdrSrcPortEnd.
A source port filter is evaluated by testing whether the source port A source port filter is evaluated by testing whether the source port
identified in the IP header falls within the range of values between identified in the IP header falls within the range of values between
HdrSrcPortStart and HdrSrcPortEnd, including these two end points. HdrSrcPortStart and HdrSrcPortEnd, including these two end points.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider HdrSrcPortEnd in selecting matching packets, i.e., there is no not consider HdrSrcPortEnd in selecting matching packets, i.e., there
upper bound in matching source port values. is no upper bound in matching source port values.
6.19.11. The Property HdrDestPortStart 6.19.11. The Property HdrDestPortStart
This property is a 16-bit unsigned integer, representing the lower end of This property is a 16-bit unsigned integer, representing the lower
a range of UDP or TCP destination ports. The upper end of the range is end of a range of UDP or TCP destination ports. The upper end of the
represented by the HdrDestPortEnd property. The value of range is represented by the HdrDestPortEnd property. The value of
HdrDestPortStart MUST be no greater than the value of HdrDestPortEnd. A HdrDestPortStart MUST be no greater than the value of HdrDestPortEnd.
single port is indicated by equal values for HdrDestPortStart and A single port is indicated by equal values for HdrDestPortStart and
HdrDestPortEnd. HdrDestPortEnd.
A destination port filter is evaluated by testing whether the destination A destination port filter is evaluated by testing whether the
port identified in the IP header falls within the range of values between destination port identified in the IP header falls within the range
HdrDestPortStart and HdrDestPortEnd, including these two end points. of values between HdrDestPortStart and HdrDestPortEnd, including
these two end points.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider HdrDestPortStart in selecting matching packets, i.e., there is not consider HdrDestPortStart in selecting matching packets, i.e.,
no lower bound in matching destination port values. there is no lower bound in matching destination port values.
6.19.12. The Property HdrDestPortEnd 6.19.12. The Property HdrDestPortEnd
This property is a 16-bit unsigned integer, representing the upper end of This property is a 16-bit unsigned integer, representing the upper
a range of UDP or TCP destination ports. The lower end of the range is end of a range of UDP or TCP destination ports. The lower end of the
represented by the HdrDestPortStart property. The value of range is represented by the HdrDestPortStart property. The value of
HdrDestPortEnd MUST be no less than the value of HdrDestPortStart. A HdrDestPortEnd MUST be no less than the value of HdrDestPortStart. A
single port is indicated by equal values for HdrDestPortStart and single port is indicated by equal values for HdrDestPortStart and
HdrDestPortEnd. HdrDestPortEnd.
A destination port filter is evaluated by testing whether the destination A destination port filter is evaluated by testing whether the
port identified in the IP header falls within the range of values between destination port identified in the IP header falls within the range
HdrDestPortStart and HdrDestPortEnd, including these two end points. of values between HdrDestPortStart and HdrDestPortEnd, including
these two end points.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider HdrDestPortEnd in selecting matching packets, i.e., there is no not consider HdrDestPortEnd in selecting matching packets, i.e.,
upper bound in matching destination port values. there is no upper bound in matching destination port values.
6.19.13. The Property HdrDSCP 6.19.13. The Property HdrDSCP
The property HdrDSCP is defined as an array of uint8's, restricted to the The property HdrDSCP is defined as an array of uint8's, restricted to
range 0..63. Since DSCPs are defined as discrete code points, with no the range 0..63. Since DSCPs are defined as discrete code points,
inherent structure, there is no semantically significant relationship with no inherent structure, there is no semantically significant
between different DSCPs. Consequently, there is no provision for relationship between different DSCPs. Consequently, there is no
specifying a range of DSCPs in this property. However, a list of provision for specifying a range of DSCPs in this property. However,
individual DSCPs, which are ORed together to form a filter, is supported a list of individual DSCPs, which are ORed together to form a filter,
by the array syntax. is supported by the array syntax.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider HdrDSCP in selecting matching packets, i.e., HdrDSCP matches for not consider HdrDSCP in selecting matching packets, i.e., HdrDSCP
all values. matches for all values.
6.19.14. The Property HdrFlowLabel 6.19.14. The Property HdrFlowLabel
The 20-bit Flow Label field in the IPv6 header may be used by a source to The 20-bit Flow Label field in the IPv6 header may be used by a
label sequences of packets for which it requests special handling by IPv6 source to label sequences of packets for which it requests special
devices, such as non-default quality of service or 'real-time' service. handling by IPv6 devices, such as non-default quality of service or
This property is an octet string of size 3 (that is, 24 bits), in which 'real-time' service. This property is an octet string of size 3
the 20-bit Flow Label appears in the rightmost 20 bits, padded on the (that is, 24 bits), in which the 20-bit Flow Label appears in the
left with b'0000'. rightmost 20 bits, padded on the left with b'0000'.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider HdrFlowLabel in selecting matching packets, i.e., HdrFlowLabel not consider HdrFlowLabel in selecting matching packets, i.e.,
matches for all values. HdrFlowLabel matches for all values.
6.20. The Class "8021Filter" 6.20. The Class "8021Filter"
This concrete class allows 802.1.source and destination MAC addresses, as This concrete class allows 802.1.source and destination MAC
well as the 802.1 protocol ID, priority, and VLAN identifier fields, to addresses, as well as the 802.1 protocol ID, priority, and VLAN
be expressed in a single object identifier fields, to be expressed in a single object
The class definition is as follows: The class definition is as follows:
NAME 8021Filter NAME 8021Filter
DESCRIPTION A class that allows 802.1 source DESCRIPTION A class that allows 802.1 source
and destination MAC address and and destination MAC address and
protocol ID, priority, and VLAN protocol ID, priority, and VLAN
identifier filters to be identifier filters to be
expressed in a single object. expressed in a single object.
DERIVED FROM FilterEntryBase DERIVED FROM FilterEntryBase
TYPE Concrete TYPE Concrete
PROPERTIES 8021HdrSrcMACAddr, 8021HdrSrcMACMask, PROPERTIES 8021HdrSrcMACAddr, 8021HdrSrcMACMask,
8021HdrDestMACAddr, 8021HdrDestMACMask, 8021HdrDestMACAddr, 8021HdrDestMACMask,
8021HdrProtocolID, 8021HdrPriorityValue, 8021HdrProtocolID, 8021HdrPriorityValue,
8021HDRVLANID 8021HDRVLANID
6.20.1. The Property 8021HdrSrcMACAddr 6.20.1. The Property 8021HdrSrcMACAddr
This property is an OctetString of size 6, representing a 48-bit source This property is an OctetString of size 6, representing a 48-bit
MAC address in canonical format. This value is compared to the source MAC address in canonical format. This value is compared to
SourceAddress field in the MAC header, subject to the mask represented in the SourceAddress field in the MAC header, subject to the mask
the 8021HdrSrcMACMask property. represented in the 8021HdrSrcMACMask property.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider 8021HdrSrcMACAddr in selecting matching packets, i.e., not consider 8021HdrSrcMACAddr in selecting matching packets, i.e.,
8021HdrSrcMACAddr matches for all values. 8021HdrSrcMACAddr matches for all values.
6.20.2. The Property 8021HdrSrcMACMask 6.20.2. The Property 8021HdrSrcMACMask
This property is an OctetString of size 6, representing a 48-bit mask to This property is an OctetString of size 6, representing a 48-bit mask
be used in comparing the SourceAddress field in the MAC header with the to be used in comparing the SourceAddress field in the MAC header
value represented in the 8021HdrSrcMACAddr property. with the value represented in the 8021HdrSrcMACAddr property.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider 8021HdrSrcMACMask in selecting matching packets, i.e., the value not consider 8021HdrSrcMACMask in selecting matching packets, i.e.,
of 8021HdrSrcMACAddr must match the source MAC address in the packet the value of 8021HdrSrcMACAddr must match the source MAC address in
exactly. the packet exactly.
6.20.3. The Property 8021HdrDestMACAddr 6.20.3. The Property 8021HdrDestMACAddr
This property is an OctetString of size 6, representing a 48-bit This property is an OctetString of size 6, representing a 48-bit
destination MAC address in canonical format. This value is compared to destination MAC address in canonical format. This value is compared
the DestinationAddress field in the MAC header, subject to the mask to the DestinationAddress field in the MAC header, subject to the
represented in the 8021HdrDestMACMask property. mask represented in the 8021HdrDestMACMask property.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider 8021HdrDestMACAddr in selecting matching packets, i.e., not consider 8021HdrDestMACAddr in selecting matching packets, i.e.,
8021HdrDestMACAddr matches for all values. 8021HdrDestMACAddr matches for all values.
6.20.4. The Property 8021HdrDestMACMask 6.20.4. The Property 8021HdrDestMACMask
This property is an OctetString of size 6, representing a 48-bit mask to This property is an OctetString of size 6, representing a 48-bit mask
be used in comparing the DestinationAddress field in the MAC header with to be used in comparing the DestinationAddress field in the MAC
the value represented in the 8021HdrDestMACAddr property. header with the value represented in the 8021HdrDestMACAddr property.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider 8021HdrDestMACMask in selecting matching packets, i.e., the not consider 8021HdrDestMACMask in selecting matching packets, i.e.,
value of 8021HdrDestMACAddr must match the destination MAC address in the the value of 8021HdrDestMACAddr must match the destination MAC
packet exactly. address in the packet exactly.
6.20.5. The Property 8021HdrProtocolID 6.20.5. The Property 8021HdrProtocolID
This property is a 16-bit unsigned integer, representing an Ethernet This property is a 16-bit unsigned integer, representing an Ethernet
protocol type. This value is compared to the Ethernet Type field in the protocol type. This value is compared to the Ethernet Type field in
802.3 MAC header. the 802.3 MAC header.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider 8021HdrProtocolID in selecting matching packets, i.e., not consider 8021HdrProtocolID in selecting matching packets, i.e.,
8021HdrProtocolID matches for all values. 8021HdrProtocolID matches for all values.
6.20.6. The Property 8021HdrPriorityValue 6.20.6. The Property 8021HdrPriorityValue
This property is an 8-bit unsigned integer, representing an 802.1Q This property is an 8-bit unsigned integer, representing an 802.1Q
priority. This value is compared to the Priority field in the 802.1Q priority. This value is compared to the Priority field in the 802.1Q
header. Since the 802.1Q Priority field consists of 3 bits, the values header. Since the 802.1Q Priority field consists of 3 bits, the
for this property are limited to the range 0..7. values for this property are limited to the range 0..7.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider 8021HdrPriorityValue in selecting matching packets, i.e., not consider 8021HdrPriorityValue in selecting matching packets,
8021HdrPriorityValue matches for all values. i.e., 8021HdrPriorityValue matches for all values.
6.20.7. The Property 8021HdrVLANID 6.20.7. The Property 8021HdrVLANID
This property is a 32-bit unsigned integer, representing an 802.1Q VLAN This property is a 32-bit unsigned integer, representing an 802.1Q
Identifier. This value is compared to the VLAN ID field in the 802.1Q VLAN Identifier. This value is compared to the VLAN ID field in the
header. Since the 802.1Q VLAN ID field consists of 12 bits, the values 802.1Q header. Since the 802.1Q VLAN ID field consists of 12 bits,
for this property are limited to the range 0..4095. the values for this property are limited to the range 0..4095.
If a value for this property is not provided, then the filter does not If a value for this property is not provided, then the filter does
consider 8021HdrVLANID in selecting matching packets, i.e., 8021HdrVLANID not consider 8021HdrVLANID in selecting matching packets, i.e.,
matches for all values. 8021HdrVLANID matches for all values.
6.21. The Class FilterList 6.21. The Class FilterList
This is a concrete class that aggregates instances of (subclasses of) This is a concrete class that aggregates instances of (subclasses of)
FilterEntryBase via the aggregation EntriesInFilterList. It is possible FilterEntryBase via the aggregation EntriesInFilterList. It is
to aggregate different types of filters into a single FilterList - for possible to aggregate different types of filters into a single
example, packet header filters (represented by the IpHeadersFilter class) FilterList - for example, packet header filters (represented by the
and security filters (represented by subclasses of FilterEntryBase IpHeadersFilter class) and security filters (represented by
defined by IPsec). subclasses of FilterEntryBase defined by IPsec).
The aggregation property EntriesInFilterList.EntrySequence is always set The aggregation property EntriesInFilterList.EntrySequence is always
to 0, to indicate that the aggregated filter entries are ANDed together set to 0, to indicate that the aggregated filter entries are ANDed
to form a selector for a class of traffic. together to form a selector for a class of traffic.
The class definition is as follows: The class definition is as follows:
NAME FilterList NAME FilterList
DESCRIPTION A concrete class representing DESCRIPTION A concrete class representing
the aggregation of multiple filters. the aggregation of multiple filters.
DERIVED FROM LogicalElement DERIVED FROM LogicalElement
TYPE Concrete TYPE Concrete
PROPERTIES Direction PROPERTIES Direction
6.21.1. The Property Direction 6.21.1. The Property Direction
This property is a 16-bit unsigned integer enumeration, representing the This property is a 16-bit unsigned integer enumeration, representing
direction of the traffic flow to which the FilterList is to be applied. the direction of the traffic flow to which the FilterList is to be
Defined enumeration values are applied. Defined enumeration values are
o NotApplicable(0) o NotApplicable(0)
o Input(1) o Input(1)
o Output(2) o Output(2)
o Both(3) - This value is used to indicate that the direction is o Both(3) - This value is used to indicate that the direction is
immaterial, e.g., to filter on a source subnet regardless of immaterial, e.g., to filter on a source subnet regardless of
whether the flow is inbound or outbound whether the flow is inbound or outbound
o Mirrored(4) - This value is also applicable to both inbound and o Mirrored(4) - This value is also applicable to both inbound and
outbound flow processing, but it indicates that the filter criteria outbound flow processing, but it indicates that the filter
are applied asymmetrically to traffic in both directions and, thus, criteria are applied asymmetrically to traffic in both directions
specifies the reversal of source and destination criteria (as and, thus, specifies the reversal of source and destination
opposed to the equality of these criteria as indicated by "Both"). criteria (as opposed to the equality of these criteria as
The match conditions in the aggregated FilterEntryBase subclass indicated by "Both"). The match conditions in the aggregated
instances are defined from the perspective of outbound flows and FilterEntryBase subclass instances are defined from the
applied to inbound flows as well by reversing the source and perspective of outbound flows and applied to inbound flows as well
destination criteria. So, for example, consider a FilterList with by reversing the source and destination criteria. So, for
3 filter entries indicating destination port = 80, and source and example, consider a FilterList with 3 filter entries indicating
destination addresses of a and b, respectively. Then, for the destination port = 80, and source and destination addresses of a
outbound direction, the filter entries match as specified and the and b, respectively. Then, for the outbound direction, the filter
'mirror' (for the inbound direction) matches on source port = 80 entries match as specified and the 'mirror' (for the inbound
and source and destination addresses of b and a, respectively. direction) matches on source port = 80 and source and destination
addresses of b and a, respectively.
7. Association and Aggregation Definitions 7. Association and Aggregation Definitions
The following definitions supplement those in PCIM itself. PCIM The following definitions supplement those in PCIM itself. PCIM
definitions that are not DEPRECATED here are still current parts of the definitions that are not DEPRECATED here are still current parts of
overall Policy Core Information Model. the overall Policy Core Information Model.
7.1. The Aggregation "PolicySetComponent" 7.1. The Aggregation "PolicySetComponent"
PolicySetComponent is a new aggregation class that collects instances of PolicySetComponent is a new aggregation class that collects instances
PolicySet subclasses (PolicyGroups and PolicyRules) into coherent sets of of PolicySet subclasses (PolicyGroups and PolicyRules) into coherent
policies. sets of policies.
NAME PolicySetComponent NAME PolicySetComponent
DESCRIPTION A concrete class representing the components of a DESCRIPTION A concrete class representing the components of a
policy set that have the same decision strategy, and policy set that have the same decision strategy, and
are prioritized within the set. are prioritized within the set.
DERIVED FROM PolicyComponent DERIVED FROM PolicyComponent
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicySet[0..n]] PROPERTIES GroupComponent[ref PolicySet[0..n]]
PartComponent[ref PolicySet[0..n]] PartComponent[ref PolicySet[0..n]]
Priority Priority
The definition of the Priority property is unchanged from its previous The definition of the Priority property is unchanged from its
definition in [PCIM]. previous definition in [PCIM].
NAME Priority NAME Priority
DESCRIPTION A non-negative integer for prioritizing this PolicySet DESCRIPTION A non-negative integer for prioritizing this
component relative to other components of the same PolicySet component relative to other components of
PolicySet. A larger value indicates a higher the same PolicySet. A larger value indicates a
priority. higher priority.
SYNTAX uint16 SYNTAX uint16
DEFAULT VALUE 0 DEFAULT VALUE 0
7.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup" 7.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup"
The new aggregation PolicySetComponent is used directly to represent The new aggregation PolicySetComponent is used directly to represent
aggregation of PolicyGroups by a higher-level PolicyGroup. Thus the aggregation of PolicyGroups by a higher-level PolicyGroup. Thus the
aggregation PolicyGroupInPolicyGroup is no longer needed, and can be aggregation PolicyGroupInPolicyGroup is no longer needed, and can be
deprecated. deprecated.
NAME PolicyGroupInPolicyGroup NAME PolicyGroupInPolicyGroup
DEPRECATED FOR PolicySetComponent DEPRECATED FOR PolicySetComponent
DESCRIPTION A class representing the aggregation of PolicyGroups DESCRIPTION A class representing the aggregation of PolicyGroups
by a higher-level PolicyGroup. by a higher-level PolicyGroup.
DERIVED FROM PolicyComponent DERIVED FROM PolicyComponent
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyGroup[0..n]] PROPERTIES GroupComponent[ref PolicyGroup[0..n]]
PartComponent[ref PolicyGroup[0..n]] PartComponent[ref PolicyGroup[0..n]]
7.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup" 7.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"
The new aggregation PolicySetComponent is used directly to represent The new aggregation PolicySetComponent is used directly to represent
aggregation of PolicyRules by a PolicyGroup. Thus the aggregation aggregation of PolicyRules by a PolicyGroup. Thus the aggregation
PolicyRuleInPolicyGroup is no longer needed, and can be deprecated. PolicyRuleInPolicyGroup is no longer needed, and can be deprecated.
NAME PolicyRuleInPolicyGroup NAME PolicyRuleInPolicyGroup
DEPRECATED FOR PolicySetComponent DEPRECATED FOR PolicySetComponent
DESCRIPTION A class representing the aggregation of PolicyRules by DESCRIPTION A class representing the aggregation of PolicyRules
a PolicyGroup. by a PolicyGroup.
DERIVED FROM PolicyComponent DERIVED FROM PolicyComponent
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyGroup[0..n]] PROPERTIES GroupComponent[ref PolicyGroup[0..n]]
PartComponent[ref PolicyRule[0..n]] PartComponent[ref PolicyRule[0..n]]
7.4. The Abstract Association "PolicySetInSystem"
7.4. The Abstract Association "PolicySetInSystem"
PolicySetInSystem is a new association that defines a relationship PolicySetInSystem is a new association that defines a relationship
between a System and a PolicySet used in the administrative scope of that between a System and a PolicySet used in the administrative scope of
system (e.g., AdminDomain, ComputerSystem). The Priority property is that system (e.g., AdminDomain, ComputerSystem). The Priority
used to assign a relative priority to a PolicySet within the property is used to assign a relative priority to a PolicySet within
administrative scope in contexts where it is not a component of another the administrative scope in contexts where it is not a component of
PolicySet. another PolicySet.
NAME PolicySetInSystem NAME PolicySetInSystem
DESCRIPTION An abstract class representing the relationship DESCRIPTION An abstract class representing the relationship
between a System and a PolicySet that is used in the between a System and a PolicySet that is used in the
administrative scope of the System. administrative scope of the System.
DERIVED FROM PolicyInSystem DERIVED FROM PolicyInSystem
ABSTRACT TRUE ABSTRACT TRUE
PROPERTIES Antecedent[ref System[0..1]] PROPERTIES Antecedent[ref System[0..1]]
Dependent [ref PolicySet[0..n]] Dependent [ref PolicySet[0..n]]
Priority Priority
The Priority property is used to specify the relative priority of the The Priority property is used to specify the relative priority of the
referenced PolicySet when there are more than one PolicySet instances referenced PolicySet when there are more than one PolicySet instances
applied to a managed resource that are not PolicySetComponents and, applied to a managed resource that are not PolicySetComponents and,
therefore, have no other relative priority defined. therefore, have no other relative priority defined.
NAME Priority NAME Priority
DESCRIPTION A non-negative integer for prioritizing the referenced DESCRIPTION A non-negative integer for prioritizing the
PolicySet among other PolicySet instances that are not referenced PolicySet among other PolicySet
components of a common PolicySet. A larger value instances that are not components of a common
indicates a higher priority. PolicySet. A larger value indicates a higher
SYNTAX uint16 priority.
DEFAULT VALUE 0 SYNTAX uint16
DEFAULT VALUE 0
7.5. Update PCIM's Weak Association "PolicyGroupInSystem" 7.5. Update PCIM's Weak Association "PolicyGroupInSystem"
Regardless of whether it a component of another PolicySet, a PolicyGroup Regardless of whether it a component of another PolicySet, a
is itself defined within the scope of a System. This association links a PolicyGroup is itself defined within the scope of a System. This
PolicyGroup to the System in whose scope the PolicyGroup is defined. It association links a PolicyGroup to the System in whose scope the
is a subclass of the abstract PolicySetInSystem association. The class PolicyGroup is defined. It is a subclass of the abstract
definition for the association is as follows: PolicySetInSystem association. The class definition for the
association is as follows:
NAME PolicyGroupInSystem NAME PolicyGroupInSystem
DESCRIPTION A class representing the fact that a PolicyGroup is DESCRIPTION A class representing the fact that a PolicyGroup is
defined within the scope of a System. defined within the scope of a System.
DERIVED FROM PolicySetInSystem DERIVED FROM PolicySetInSystem
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Antecedent[ref System[1..1]] PROPERTIES Antecedent[ref System[1..1]]
Dependent [ref PolicyGroup[weak]] Dependent [ref PolicyGroup[weak]]
The Reference "Antecedent" is inherited from PolicySetInSystem, and The Reference "Antecedent" is inherited from PolicySetInSystem, and
overridden to restrict its cardinality to [1..1]. It serves as an object overridden to restrict its cardinality to [1..1]. It serves as an
reference to a System that provides a scope for one or more PolicyGroups. object reference to a System that provides a scope for one or more
PolicyGroups. Since this is a weak association, the cardinality for
Since this is a weak association, the cardinality for this object this object reference is always 1, that is, a PolicyGroup is always
reference is always 1, that is, a PolicyGroup is always defined within defined within the scope of exactly one System.
the scope of exactly one System.
The Reference "Dependent" is inherited from PolicySetInSystem, and The Reference "Dependent" is inherited from PolicySetInSystem, and
overridden to become an object reference to a PolicyGroup defined within overridden to become an object reference to a PolicyGroup defined
the scope of a System. Note that for any single instance of the within the scope of a System. Note that for any single instance of
association class PolicyGroupInSystem, this property (like all reference the association class PolicyGroupInSystem, this property (like all
properties) is single-valued. The [0..n] cardinality indicates that a reference properties) is single-valued. The [0..n] cardinality
given System may have 0, 1, or more than one PolicyGroups defined within indicates that a given System may have 0, 1, or more than one
its scope. PolicyGroups defined within its scope.
7.6. Update PCIM's Weak Association "PolicyRuleInSystem" 7.6. Update PCIM's Weak Association "PolicyRuleInSystem"
Regardless of whether it a component of another PolicySet, a PolicyRule Regardless of whether it a component of another PolicySet, a
is itself defined within the scope of a System. This association links a PolicyRule is itself defined within the scope of a System. This
PolicyRule to the System in whose scope the PolicyRule is defined. It is association links a PolicyRule to the System in whose scope the
a subclass of the abstract PolicySetInSystem association. The class PolicyRule is defined. It is a subclass of the abstract
definition for the association is as follows: PolicySetInSystem association. The class definition for the
association is as follows:
NAME PolicyRuleInSystem NAME PolicyRuleInSystem
DESCRIPTION A class representing the fact that a PolicyRule is DESCRIPTION A class representing the fact that a PolicyRule is
defined within the scope of a System. defined within the scope of a System.
DERIVED FROM PolicySetInSystem DERIVED FROM PolicySetInSystem
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Antecedent[ref System[1..1]] PROPERTIES Antecedent[ref System[1..1]]
Dependent[ref PolicyRule[weak]] Dependent[ref PolicyRule[weak]]
The Reference "Antecedent" is inherited from PolicySetInSystem, and The Reference "Antecedent" is inherited from PolicySetInSystem, and
overridden to restrict its cardinality to [1..1]. It serves as an object overridden to restrict its cardinality to [1..1]. It serves as an
reference to a System that provides a scope for one or more PolicyRules. object reference to a System that provides a scope for one or more
Since this is a weak association, the cardinality for this object PolicyRules. Since this is a weak association, the cardinality for
reference is always 1, that is, a PolicyRule is always defined within the this object reference is always 1, that is, a PolicyRule is always
scope of exactly one System. defined within the scope of exactly one System.
The Reference "Dependent" is inherited from PolicySetInSystem, and The Reference "Dependent" is inherited from PolicySetInSystem, and
overridden to become an object reference to a PolicyRule defined within overridden to become an object reference to a PolicyRule defined
the scope of a System. Note that for any single instance of the within the scope of a System. Note that for any single instance of
association class PolicyRuleInSystem, this property (like all Reference the association class PolicyRuleInSystem, this property (like all
properties) is single-valued. The [0..n] cardinality indicates that a Reference properties) is single-valued. The [0..n] cardinality
given System may have 0, 1, or more than one PolicyRules defined within indicates that a given System may have 0, 1, or more than one
its scope. PolicyRules defined within its scope.
7.7. The Abstract Aggregation "PolicyConditionStructure"
NAME PolicyConditionStructure 7.7. The Abstract Aggregation "PolicyConditionStructure"
DESCRIPTION A class representing the aggregation of
PolicyConditions by an aggregating instance.
DERIVED FROM PolicyComponent
ABSTRACT TRUE
PROPERTIES PartComponent[ref PolicyCondition[0..n]]
GroupNumber
ConditionNegated
7.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule" NAME PolicyConditionStructure
DESCRIPTION A class representing the aggregation of
PolicyConditions by an aggregating instance.
DERIVED FROM PolicyComponent
ABSTRACT TRUE
PROPERTIES PartComponent[ref PolicyCondition[0..n]]
GroupNumber
ConditionNegated
7.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule"
The PCIM aggregation "PolicyConditionInPolicyRule" is updated, to make it The PCIM aggregation "PolicyConditionInPolicyRule" is updated, to
a subclass of the new abstract aggregation PolicyConditionStructure. The make it a subclass of the new abstract aggregation
properties GroupNumber and ConditionNegated are now inherited, rather PolicyConditionStructure. The properties GroupNumber and
than specified explicitly as they were in PCIM. ConditionNegated are now inherited, rather than specified explicitly
as they were in PCIM.
NAME PolicyConditionInPolicyRule NAME PolicyConditionInPolicyRule
DESCRIPTION A class representing the aggregation of DESCRIPTION A class representing the aggregation of
PolicyConditions by a PolicyRule. PolicyConditions by a PolicyRule.
DERIVED FROM PolicyConditionStructure DERIVED FROM PolicyConditionStructure
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyRule[0..n]] PROPERTIES GroupComponent[ref PolicyRule[0..n]]
7.9. The Aggregation "PolicyConditionInPolicyCondition" 7.9. The Aggregation "PolicyConditionInPolicyCondition"
A second subclass of PolicyConditionStructure is defined, representing A second subclass of PolicyConditionStructure is defined,
the compounding of policy conditions into a higher-level policy representing the compounding of policy conditions into a higher-level
condition. policy condition.
NAME PolicyConditionInPolicyCondition NAME PolicyConditionInPolicyCondition
DESCRIPTION A class representing the aggregation of DESCRIPTION A class representing the aggregation of
PolicyConditions by another PolicyCondition. PolicyConditions by another PolicyCondition.
DERIVED FROM PolicyConditionStructure DERIVED FROM PolicyConditionStructure
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref CompoundPolicyCondition[0..n]] PROPERTIES GroupComponent[ref CompoundPolicyCondition[0..n]]
7.10. The Abstract Aggregation "PolicyActionStructure" 7.10. The Abstract Aggregation "PolicyActionStructure"
NAME PolicyActionStructure NAME PolicyActionStructure
DESCRIPTION A class representing the aggregation of PolicyActions DESCRIPTION A class representing the aggregation of
by an aggregating instance. PolicyActions by an aggregating instance.
DERIVED FROM PolicyComponent DERIVED FROM PolicyComponent
ABSTRACT TRUE ABSTRACT TRUE
PROPERTIES PartComponent[ref PolicyAction[0..n]] PROPERTIES PartComponent[ref PolicyAction[0..n]]
ActionOrder ActionOrder
The definition of the ActionOrder property appears in Section 7.8.3 of The definition of the ActionOrder property appears in Section 7.8.3
PCIM [1]. of PCIM [1].
7.11. Update PCIM's Aggregation "PolicyActionInPolicyRule" 7.11. Update PCIM's Aggregation "PolicyActionInPolicyRule"
The PCIM aggregation "PolicyActionInPolicyRule" is updated, to make it a The PCIM aggregation "PolicyActionInPolicyRule" is updated, to make
subclass of the new abstract aggregation PolicyActionStructure. The it a subclass of the new abstract aggregation PolicyActionStructure.
property ActionOrder is now inherited, rather than specified explicitly The property ActionOrder is now inherited, rather than specified
as it was in PCIM. explicitly as it was in PCIM.
NAME PolicyActionInPolicyRule NAME PolicyActionInPolicyRule
DESCRIPTION A class representing the aggregation of PolicyActions DESCRIPTION A class representing the aggregation of
by a PolicyRule. PolicyActions by a PolicyRule.
DERIVED FROM PolicyActionStructure DERIVED FROM PolicyActionStructure
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyRule[0..n]] PROPERTIES GroupComponent[ref PolicyRule[0..n]]
7.12. The Aggregation "PolicyActionInPolicyAction" 7.12. The Aggregation "PolicyActionInPolicyAction"
A second subclass of PolicyActionStructure is defined, representing the A second subclass of PolicyActionStructure is defined, representing
compounding of policy actions into a higher-level policy action. the compounding of policy actions into a higher-level policy action.
NAME PolicyActionInPolicyAction NAME PolicyActionInPolicyAction
DESCRIPTION A class representing the aggregation of PolicyActions DESCRIPTION A class representing the aggregation of
by another PolicyAction. PolicyActions by another PolicyAction.
DERIVED FROM PolicyActionStructure DERIVED FROM PolicyActionStructure
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref CompoundPolicyAction[0..n]] PROPERTIES GroupComponent[ref CompoundPolicyAction[0..n]]
7.13. The Aggregation "PolicyVariableInSimplePolicyCondition" 7.13. The Aggregation "PolicyVariableInSimplePolicyCondition"
A simple policy condition is represented as an ordered triplet {variable, A simple policy condition is represented as an ordered triplet
operator, value}. This aggregation provides the linkage between a {variable, operator, value}. This aggregation provides the linkage
SimplePolicyCondition instance and a single PolicyVariable. The between a SimplePolicyCondition instance and a single PolicyVariable.
aggregation PolicyValueInSimplePolicyCondition links the The aggregation PolicyValueInSimplePolicyCondition links the
SimplePolicyCondition to a single PolicyValue. The Operator property of SimplePolicyCondition to a single PolicyValue. The Operator property
SimplePolicyCondition represents the third element of the triplet, the of SimplePolicyCondition represents the third element of the triplet,
operator. the operator.
The class definition for this aggregation is as follows: The class definition for this aggregation is as follows:
NAME PolicyVariableInSimplePolicyCondition NAME PolicyVariableInSimplePolicyCondition
DERIVED FROM PolicyComponent DERIVED FROM PolicyComponent
ABSTRACT False ABSTRACT False
PROPERTIES GroupComponent[ref SimplePolicyCondition[0..n]] PROPERTIES GroupComponent[ref SimplePolicyCondition[0..n]]
PartComponent[ref PolicyVariable[1..1] ] PartComponent[ref PolicyVariable[1..1] ]
The reference property "GroupComponent" is inherited from The reference property "GroupComponent" is inherited from
PolicyComponent, and overridden to become an object reference to a PolicyComponent, and overridden to become an object reference to a
SimplePolicyCondition that contains exactly one PolicyVariable. Note SimplePolicyCondition that contains exactly one PolicyVariable. Note
that for any single instance of the aggregation class that for any single instance of the aggregation class
PolicyVariableInSimplePolicyCondition, this property is single-valued. PolicyVariableInSimplePolicyCondition, this property is single-
The [0..n] cardinality indicates that there may be 0, 1, or more valued. The [0..n] cardinality indicates that there may be 0, 1, or
SimplePolicyCondition objects that contain any given policy variable more SimplePolicyCondition objects that contain any given policy
object. variable object.
The reference property "PartComponent" is inherited from PolicyComponent, The reference property "PartComponent" is inherited from
and overridden to become an object reference to a PolicyVariable that is PolicyComponent, and overridden to become an object reference to a
defined within the scope of a SimplePolicyCondition. Note that for any PolicyVariable that is defined within the scope of a
single instance of the association class SimplePolicyCondition. Note that for any single instance of the
PolicyVariableInSimplePolicyCondition, this property (like all reference association class PolicyVariableInSimplePolicyCondition, this
properties) is single-valued. The [1..1] cardinality indicates that a property (like all reference properties) is single-valued. The
SimplePolicyCondition must have exactly one policy variable defined [1..1] cardinality indicates that a SimplePolicyCondition must have
within its scope in order to be meaningful. exactly one policy variable defined within its scope in order to be
meaningful.
7.14. The Aggregation "PolicyValueInSimplePolicyCondition" 7.14. The Aggregation "PolicyValueInSimplePolicyCondition"
A simple policy condition is represented as an ordered triplet {variable, A simple policy condition is represented as an ordered triplet
operator, value}. This aggregation provides the linkage between a {variable, operator, value}. This aggregation provides the linkage
SimplePolicyCondition instance and a single PolicyValue. The aggregation between a SimplePolicyCondition instance and a single PolicyValue.
PolicyVariableInSimplePolicyCondition links the SimplePolicyCondition to The aggregation PolicyVariableInSimplePolicyCondition links the
a single PolicyVariable. The Operator property of SimplePolicyCondition SimplePolicyCondition to a single PolicyVariable. The Operator
represents the third element of the triplet, the operator. property of SimplePolicyCondition represents the third element of the
triplet, the operator.
The class definition for this aggregation is as follows: The class definition for this aggregation is as follows:
NAME PolicyValueInSimplePolicyCondition NAME PolicyValueInSimplePolicyCondition
DERIVED FROM PolicyComponent DERIVED FROM PolicyComponent
ABSTRACT False ABSTRACT False
PROPERTIES GroupComponent[ref SimplePolicyCondition[0..n]] PROPERTIES GroupComponent[ref SimplePolicyCondition[0..n]]
PartComponent[ref PolicyValue[1..1] ] PartComponent[ref PolicyValue[1..1] ]
The reference property "GroupComponent" is inherited from The reference property "GroupComponent" is inherited from
PolicyComponent, and overridden to become an object reference to a PolicyComponent, and overridden to become an object reference to a
SimplePolicyCondition that contains exactly one PolicyValue. Note that SimplePolicyCondition that contains exactly one PolicyValue. Note
for any single instance of the aggregation class that for any single instance of the aggregation class
PolicyValueInSimplePolicyCondition, this property is single-valued. The PolicyValueInSimplePolicyCondition, this property is single-valued.
[0..n] cardinality indicates that there may be 0, 1, or more The [0..n] cardinality indicates that there may be 0, 1, or more
SimplePolicyCondition objects that contain any given policy value object. SimplePolicyCondition objects that contain any given policy value
object.
The reference property "PartComponent" is inherited from PolicyComponent, The reference property "PartComponent" is inherited from
and overridden to become an object reference to a PolicyValue that is PolicyComponent, and overridden to become an object reference to a
defined within the scope of a SimplePolicyCondition. Note that for any PolicyValue that is defined within the scope of a
single instance of the association class SimplePolicyCondition. Note that for any single instance of the
PolicyValueInSimplePolicyCondition, this property (like all reference association class PolicyValueInSimplePolicyCondition, this property
properties) is single-valued. The [1..1] cardinality indicates that a (like all reference properties) is single-valued. The [1..1]
SimplePolicyCondition must have exactly one policy value defined within cardinality indicates that a SimplePolicyCondition must have exactly
its scope in order to be meaningful. one policy value defined within its scope in order to be meaningful.
7.15. The Aggregation "PolicyVariableInSimplePolicyAction" 7.15. The Aggregation "PolicyVariableInSimplePolicyAction"
A simple policy action is represented as a pair {variable, value}. This A simple policy action is represented as a pair {variable, value}.
aggregation provides the linkage between a SimplePolicyAction instance This aggregation provides the linkage between a SimplePolicyAction
and a single PolicyVariable. The aggregation instance and a single PolicyVariable. The aggregation
PolicyValueInSimplePolicyAction links the SimplePolicyAction to a single PolicyValueInSimplePolicyAction links the SimplePolicyAction to a
PolicyValue. single PolicyValue.
The class definition for this aggregation is as follows: The class definition for this aggregation is as follows:
NAME PolicyVariableInSimplePolicyAction NAME PolicyVariableInSimplePolicyAction
DERIVED FROM PolicyComponent DERIVED FROM PolicyComponent
ABSTRACT False ABSTRACT False
PROPERTIES GroupComponent[ref SimplePolicyAction[0..n]] PROPERTIES GroupComponent[ref SimplePolicyAction[0..n]]
PartComponent[ref PolicyVariable[1..1] ] PartComponent[ref PolicyVariable[1..1] ]
The reference property "GroupComponent" is inherited from The reference property "GroupComponent" is inherited from
PolicyComponent, and overridden to become an object reference to a PolicyComponent, and overridden to become an object reference to a
SimplePolicyAction that contains exactly one PolicyVariable. Note that SimplePolicyAction that contains exactly one PolicyVariable. Note
for any single instance of the aggregation class that for any single instance of the aggregation class
PolicyVariableInSimplePolicyAction, this property is single-valued. The PolicyVariableInSimplePolicyAction, this property is single-valued.
[0..n] cardinality indicates that there may be 0, 1, or more The [0..n] cardinality indicates that there may be 0, 1, or more
SimplePolicyAction objects that contain any given policy variable object. SimplePolicyAction objects that contain any given policy variable
object.
The reference property "PartComponent" is inherited from PolicyComponent, The reference property "PartComponent" is inherited from
and overridden to become an object reference to a PolicyVariable that is PolicyComponent, and overridden to become an object reference to a
defined within the scope of a SimplePolicyAction. Note that for any PolicyVariable that is defined within the scope of a
single instance of the association class SimplePolicyAction. Note that for any single instance of the
PolicyVariableInSimplePolicyAction, this property (like all reference association class PolicyVariableInSimplePolicyAction, this property
properties) is single-valued. The [1..1] cardinality indicates that a (like all reference properties) is single-valued. The [1..1]
SimplePolicyAction must have exactly one policy variable defined within cardinality indicates that a SimplePolicyAction must have exactly one
its scope in order to be meaningful. policy variable defined within its scope in order to be meaningful.
7.16. The Aggregation "PolicyValueInSimplePolicyAction" 7.16. The Aggregation "PolicyValueInSimplePolicyAction"
A simple policy action is represented as a pair {variable, value}. This A simple policy action is represented as a pair {variable, value}.
aggregation provides the linkage between a SimplePolicyAction instance This aggregation provides the linkage between a SimplePolicyAction
and a single PolicyValue. The aggregation instance and a single PolicyValue. The aggregation
PolicyVariableInSimplePolicyAction links the SimplePolicyAction to a PolicyVariableInSimplePolicyAction links the SimplePolicyAction to a
single PolicyVariable. single PolicyVariable.
The class definition for this aggregation is as follows: The class definition for this aggregation is as follows:
NAME PolicyValueInSimplePolicyAction NAME PolicyValueInSimplePolicyAction
DERIVED FROM PolicyComponent DERIVED FROM PolicyComponent
ABSTRACT False ABSTRACT False
PROPERTIES GroupComponent[ref SimplePolicyAction[0..n]] PROPERTIES GroupComponent[ref SimplePolicyAction[0..n]]
PartComponent[ref PolicyValue[1..1] ] PartComponent[ref PolicyValue[1..1] ]
The reference property "GroupComponent" is inherited from The reference property "GroupComponent" is inherited from
PolicyComponent, and overridden to become an object reference to a PolicyComponent, and overridden to become an object reference to a
SimplePolicyAction that contains exactly one PolicyValue. Note that for SimplePolicyAction that contains exactly one PolicyValue. Note that
any single instance of the aggregation class for any single instance of the aggregation class
PolicyValueInSimplePolicyAction, this property is single-valued. The PolicyValueInSimplePolicyAction, this property is single-valued. The
[0..n] cardinality indicates that there may be 0, 1, or more [0..n] cardinality indicates that there may be 0, 1, or more
SimplePolicyAction objects that contain any given policy value object. SimplePolicyAction objects that contain any given policy value
object.
The reference property "PartComponent" is inherited from PolicyComponent, The reference property "PartComponent" is inherited from
and overridden to become an object reference to a PolicyValue that is PolicyComponent, and overridden to become an object reference to a
defined within the scope of a SimplePolicyAction. Note that for any PolicyValue that is defined within the scope of a SimplePolicyAction.
single instance of the association class PolicyValueInSimplePolicyAction, Note that for any single instance of the association class
this property (like all reference properties) is single-valued. The PolicyValueInSimplePolicyAction, this property (like all reference
[1..1] cardinality indicates that a SimplePolicyAction must have exactly properties) is single-valued. The [1..1] cardinality indicates that
one policy value defined within its scope in order to be meaningful. a SimplePolicyAction must have exactly one policy value defined
within its scope in order to be meaningful.
7.17. The Association "ReusablePolicy" 7.17. The Association "ReusablePolicy"
The association ReusablePolicy makes it possible to include any subclass The association ReusablePolicy makes it possible to include any
of the abstract class "Policy" in a ReusablePolicyContainer. subclass of the abstract class "Policy" in a ReusablePolicyContainer.
NAME ReusablePolicy NAME ReusablePolicy
DESCRIPTION A class representing the inclusion of a reusable DESCRIPTION A class representing the inclusion of a reusable
policy element in a ReusablePolicyContainer. Reusable policy element in a ReusablePolicyContainer.
elements may be PolicyGroups, PolicyRules, Reusable elements may be PolicyGroups, PolicyRules,
PolicyConditions, PolicyActions, PolicyVariables, PolicyConditions, PolicyActions, PolicyVariables,
PolicyValues, or instances of any other subclasses of PolicyValues, or instances of any other subclasses
the abstract class Policy. of the abstract class Policy.
DERIVED FROM PolicyInSystem
ABSTRACT FALSE
PROPERTIES Antecedent[ref ReusablePolicyContainer[0..1]]
7.18. Deprecate PCIM's "PolicyConditionInPolicyRepository" DERIVED FROM PolicyInSystem
ABSTRACT FALSE
PROPERTIES Antecedent[ref ReusablePolicyContainer[0..1]]
NAME PolicyConditionInPolicyRepository 7.18. Deprecate PCIM's "PolicyConditionInPolicyRepository"
DEPRECATED FOR ReusablePolicy
DESCRIPTION A class representing the inclusion of a reusable
PolicyCondition in a PolicyRepository.
DERIVED FROM PolicyInSystem
ABSTRACT FALSE
PROPERTIES Antecedent[ref PolicyRepository[0..1]]
Dependent[ref PolicyCondition[0..n]]
7.19. Deprecate PCIM's "PolicyActionInPolicyRepository" NAME PolicyConditionInPolicyRepository
DEPRECATED FOR ReusablePolicy
DESCRIPTION A class representing the inclusion of a reusable
PolicyCondition in a PolicyRepository.
DERIVED FROM PolicyInSystem
ABSTRACT FALSE
PROPERTIES Antecedent[ref PolicyRepository[0..1]]
Dependent[ref PolicyCondition[0..n]]
NAME PolicyActionInPolicyRepository 7.19. Deprecate PCIM's "PolicyActionInPolicyRepository"
DEPRECATED FOR ReusablePolicy
DESCRIPTION A class representing the inclusion of a reusable
PolicyAction in a PolicyRepository.
DERIVED FROM PolicyInSystem
ABSTRACT FALSE
PROPERTIES Antecedent[ref PolicyRepository[0..1]]
Dependent[ref PolicyAction[0..n]]
7.20. The Association ExpectedPolicyValuesForVariable NAME PolicyActionInPolicyRepository
DEPRECATED FOR ReusablePolicy
DESCRIPTION A class representing the inclusion of a reusable
PolicyAction in a PolicyRepository.
DERIVED FROM PolicyInSystem
ABSTRACT FALSE
PROPERTIES Antecedent[ref PolicyRepository[0..1]]
Dependent[ref PolicyAction[0..n]]
This association links a PolicyValue object to a PolicyVariable object, 7.20. The Association ExpectedPolicyValuesForVariable
modeling the set of expected values for that PolicyVariable. Using this
association, a variable (instance) may be constrained to be bound-
to/assigned only a set of allowed values. For example, modeling an
enumerated source port variable, one creates an instance of the
PolicySourcePortVariable class and associates with it the set of values
(integers) representing the allowed enumeration, using appropriate number
of instances of the ExpectedPolicyValuesForVariable association.
Note that a single variable instance may be constrained by any number of This association links a PolicyValue object to a PolicyVariable
values, and a single value may be used to constrain any number of object, modeling the set of expected values for that PolicyVariable.
variables. These relationships are manifested by the n-to-m cardinality Using this association, a variable (instance) may be constrained to
of the association. be bound- to/assigned only a set of allowed values. For example,
modeling an enumerated source port variable, one creates an instance
of the PolicySourcePortVariable class and associates with it the set
of values (integers) representing the allowed enumeration, using
appropriate number of instances of the
ExpectedPolicyValuesForVariable association.
The purpose of this association is to support validation of simple policy Note that a single variable instance may be constrained by any number
conditions and simple policy actions, prior to their deployment to an of values, and a single value may be used to constrain any number of
enforcement point. This association, and the PolicyValue object that it variables. These relationships are manifested by the n-to-m
refers to, plays no role when a PDP or a PEP is evaluating a simple cardinality of the association.
policy condition, or executing a simple policy action. See Section 5.8.3
for more details on this point. The purpose of this association is to support validation of simple
policy conditions and simple policy actions, prior to their
deployment to an enforcement point. This association, and the
PolicyValue object that it refers to, plays no role when a PDP or a
PEP is evaluating a simple policy condition, or executing a simple
policy action. See Section 5.8.3 for more details on this point.
The class definition for the association is as follows: The class definition for the association is as follows:
NAME ExpectedPolicyValuesForVariable NAME ExpectedPolicyValuesForVariable
DESCRIPTION A class representing the association of a set of DESCRIPTION A class representing the association of a set of
expected values to a variable object. expected values to a variable object.
DERIVED FROM Dependency DERIVED FROM Dependency
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Antecedent [ref PolicyVariable[0..n]] PROPERTIES Antecedent [ref PolicyVariable[0..n]]
Dependent [ref PolicyValue [0..n]] Dependent [ref PolicyValue [0..n]]
The reference property Antecedent is inherited from Dependency. Its type The reference property Antecedent is inherited from Dependency. Its
and cardinality are overridden to provide the semantics of a variable type and cardinality are overridden to provide the semantics of a
optionally having value constraints. The [0..n] cardinality indicates variable optionally having value constraints. The [0..n] cardinality
that any number of variables may be constrained by a given value. indicates that any number of variables may be constraine