draft-ietf-policy-pcim-ext-01.txt   draft-ietf-policy-pcim-ext-02.txt 
Policy Framework Working Group B. Moore Policy Framework Working Group B. Moore
INTERNET-DRAFT L. Rafalow INTERNET-DRAFT L. Rafalow
Updates: 3060 IBM Updates: 3060 IBM
Category: Standards Track Y. Ramberg Category: Standards Track Y. Ramberg
Y. Snir Y. Snir
J. Strassner
A. Westerinen A. Westerinen
Cisco Systems Cisco Systems
R. Chadha R. Chadha
Telcordia Technologies Telcordia Technologies
M. Brunner M. Brunner
NEC NEC
R. Cohen R. Cohen
Ntear LLC Ntear LLC
J. Strassner
INTELLLIDEN, Inc.
Policy Core Information Model Extensions Policy Core Information Model Extensions
<draft-ietf-policy-pcim-ext-01.txt> <draft-ietf-policy-pcim-ext-02.txt>
Monday, April 09, 2001, 11:13 AM Friday, July 20, 2001, 10:53 AM
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
This document proposes a number of changes to the Policy Core Information This document proposes a number of changes to the Policy Core Information
Model (PCIM, RFC 3060). These changes include both extensions of PCIM Model (PCIM, RFC 3060). These changes include both extensions of PCIM
into areas that it did not previously cover, and changes to the existing into areas that it did not previously cover, and changes to the existing
PCIM classes and associations. Both sets of changes are done in a way PCIM classes and associations. Both sets of changes are done in a way
that, to the extent possible, preserves interoperability with that, to the extent possible, preserves interoperability with
implementations of the original PCIM model. implementations of the original PCIM model.
Table of Contents Table of Contents
1. Introduction......................................................4 1. Introduction......................................................5
2. Overview of the Changes...........................................4 2. Overview of the Changes...........................................5
2.1. How to Change an Information Model...........................4 2.1. How to Change an Information Model...........................5
2.2. List of Changes to the Model.................................5 2.2. List of Changes to the Model.................................6
2.2.1. Changes to PolicyRepository................................5 2.2.1. Changes to PolicyRepository................................6
2.2.2. Additional Associations and Additional Reusable Elements...5 2.2.2. Additional Associations and Additional Reusable Elements...6
2.2.3. Priorities and Decision Strategies.........................6 2.2.3. Priorities and Decision Strategies.........................6
2.2.4. Policy Roles...............................................6 2.2.4. Policy Roles...............................................7
2.2.5. CompoundPolicyConditions and CompoundPolicyActions.........7 2.2.5. CompoundPolicyConditions and CompoundPolicyActions.........7
2.2.6. Variables and Values.......................................7 2.2.6. Variables and Values.......................................7
2.2.7. Packet Filtering...........................................7 2.2.7. Domain-Level Packet Filtering..............................8
3. The Updated Class and Association Class Hierarchies...............7 2.2.8. Device-Level Packet Filtering..............................8
4. Areas of Extension to PCIM.......................................11 3. The Updated Class and Association Class Hierarchies...............8
4.1. Policy Scope................................................12 4. Areas of Extension to PCIM.......................................12
4.1.1. Levels of Abstraction: Domain- and Device-Level Policies..12 4.1. Policy Scope................................................13
4.1.2. Administrative and Functional Scopes......................12 4.1.1. Levels of Abstraction: Domain- and Device-Level Policies..13
4.2. Reusable Policy Elements....................................13 4.1.2. Administrative and Functional Scopes......................13
4.3. Policy Sets.................................................14 4.2. Reusable Policy Elements....................................14
4.4. Nested Policy Rules.........................................14 4.3. Policy Sets.................................................15
4.4.1. Usage Rules for Nested Rules..............................14 4.4. Nested Policy Rules.........................................15
4.4.2. Motivation................................................15 4.4.1. Usage Rules for Nested Rules..............................15
4.4.3. Usage Example.............................................16 4.4.2. Motivation................................................16
4.5. Priorities and Decision Strategies..........................18 4.5. Priorities and Decision Strategies..........................17
4.5.1. Structuring Decision Strategies...........................19 4.5.1. Structuring Decision Strategies...........................18
4.5.2. Side Effects..............................................20 4.5.2. Side Effects..............................................19
4.5.3. Multiple PolicySet Trees For a Resource...................20 4.5.3. Multiple PolicySet Trees For a Resource...................20
4.5.4. Deterministic Decisions...................................21 4.5.4. Deterministic Decisions...................................21
4.6. Policy Roles................................................21 4.6. Policy Roles................................................21
4.6.1. Comparison of Roles in PCIM with Roles in snmpconf........21 4.6.1. Comparison of Roles in PCIM with Roles in snmpconf........22
4.6.2. Addition of PolicyRoleCollection to PCIMe.................22 4.6.2. Addition of PolicyRoleCollection to PCIMe.................22
4.6.3. Roles for PolicyGroups....................................23 4.6.3. Roles for PolicyGroups....................................23
4.7. Compound Policy Conditions and Compound Policy Actions......24 4.7. Compound Policy Conditions and Compound Policy Actions......25
4.7.1. Compound Policy Conditions................................25 4.7.1. Compound Policy Conditions................................25
4.7.2. Compound Policy Actions...................................25 4.7.2. Compound Policy Actions...................................25
4.8. Variables and Values........................................27 4.8. Variables and Values........................................26
4.8.1. Simple Policy Conditions..................................27 4.8.1. Simple Policy Conditions..................................26
4.8.2. Using Simple Policy Conditions............................28 4.8.2. Using Simple Policy Conditions............................27
4.8.3. The Simple Condition Operator.............................29 4.8.3. The Simple Condition Operator.............................28
4.8.4. SimplePolicyActions.......................................31 4.8.4. SimplePolicyActions.......................................31
4.8.5. Policy Variables..........................................32 4.8.5. Policy Variables..........................................32
4.8.6. Explicitly Bound Policy Variables.........................33 4.8.6. Explicitly Bound Policy Variables.........................33
4.8.7. Implicitly Bound Policy Variables.........................33 4.8.7. Implicitly Bound Policy Variables.........................34
4.8.8. Structure and Usage of Pre-Defined Variables..............34 4.8.8. Structure and Usage of Pre-Defined Variables..............34
4.8.9. Rationale for Modeling Implicit Variables as Classes......35 4.8.9. Rationale for Modeling Implicit Variables as Classes......35
4.8.10. Policy Values............................................36 4.8.10. Policy Values............................................36
4.9. Packet Filtering............................................37 4.9. Packet Filtering............................................37
5. Class Definitions................................................38 4.9.1. Domain-Level Packet Filters...............................37
5.1. The Abstract Class "PolicySet"..............................38 4.9.2. Device-Level Packet Filters...............................39
5.2. Update PCIM's Class "PolicyGroup"...........................39 5. Class Definitions................................................39
5.3. Update PCIM's Class "PolicyRule"............................39 5.1. The Abstract Class "PolicySet"..............................39
5.4. The Class "SimplePolicyCondition"...........................40 5.2. Update PCIM's Class "PolicyGroup"...........................40
5.5. The Class "CompoundPolicyCondition".........................41 5.3. Update PCIM's Class "PolicyRule"............................40
5.6. The Class "CompoundFilterCondition".........................41 5.4. The Class "SimplePolicyCondition"...........................41
5.7. The Class "SimplePolicyAction"..............................42 5.5. The Class "CompoundPolicyCondition".........................42
5.8. The Class "CompoundPolicyAction"............................42 5.6. The Class "CompoundFilterCondition".........................42
5.9. The Abstract Class "PolicyVariable".........................43 5.7. The Class "SimplePolicyAction"..............................43
5.10. The Class "PolicyExplicitVariable".........................44 5.8. The Class "CompoundPolicyAction"............................43
5.10.1. The Single-Valued Property "ModelClass"..................44 5.9. The Abstract Class "PolicyVariable".........................45
5.10.2. The Single-Valued Property ModelProperty.................44 5.10. The Class "PolicyExplicitVariable".........................45
5.11. The Abstract Class "PolicyImplicitVariable"................44 5.10.1. The Single-Valued Property "ModelClass"..................45
5.11.1. The Multi-Valued Property "ValueTypes"...................45 5.10.2. The Single-Valued Property ModelProperty.................46
5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe..45 5.11. The Abstract Class "PolicyImplicitVariable"................46
5.12.1. The Class "PolicySourceIPv4Variable".....................45 5.11.1. The Multi-Valued Property "ValueTypes"...................46
5.12.2. The Class "PolicySourceIPv6Variable".....................45 5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe..47
5.12.3. The Class "PolicyDestinationIPv4Variable"................45 5.12.1. The Class "PolicySourceIPv4Variable".....................47
5.12.4. The Class "PolicyDestinationIPv6Variable"................46 5.12.2. The Class "PolicySourceIPv6Variable".....................47
5.12.5. The Class "PolicySourcePortVariable".....................46 5.12.3. The Class "PolicyDestinationIPv4Variable"................47
5.12.6. The Class "PolicyDestinationPortVariable"................46 5.12.4. The Class "PolicyDestinationIPv6Variable"................47
5.12.7. The Class "PolicyIPProtocolVariable".....................47 5.12.5. The Class "PolicySourcePortVariable".....................48
5.12.8. The Class "PolicyIPVersionVariable"......................47 5.12.6. The Class "PolicyDestinationPortVariable"................48
5.12.9. The Class "PolicyIPToSVariable"..........................47 5.12.7. The Class "PolicyIPProtocolVariable".....................49
5.12.10. The Class "PolicyDSCPVariable"..........................47 5.12.8. The Class "PolicyIPVersionVariable"......................49
5.12.11. The Class "PolicyFlowIdVariable"........................48 5.12.9. The Class "PolicyIPToSVariable"..........................49
5.12.12. The Class "PolicySourceMACVariable".....................48 5.12.10. The Class "PolicyDSCPVariable"..........................49
5.12.13. The Class "PolicyDestinationMACVariable"................48 5.12.11. The Class "PolicyFlowIdVariable"........................50
5.12.14. The Class "PolicyVLANVariable"..........................48 5.12.12. The Class "PolicySourceMACVariable".....................50
5.12.15. The Class "PolicyCoSVariable"...........................49 5.12.13. The Class "PolicyDestinationMACVariable"................50
5.12.16. The Class "PolicyEthertypeVariable".....................49 5.12.14. The Class "PolicyVLANVariable"..........................50
5.12.17. The Class "PolicySourceSAPVariable".....................49 5.12.15. The Class "PolicyCoSVariable"...........................51
5.12.18. The Class "PolicyDestinationSAPVariable"................49 5.12.16. The Class "PolicyEthertypeVariable".....................51
5.12.19. The Class "PolicySNAPVariable"..........................50 5.12.17. The Class "PolicySourceSAPVariable".....................51
5.12.20. The Class "PolicyFlowDirectionVariable".................50 5.12.18. The Class "PolicyDestinationSAPVariable"................51
5.13. The Abstract Class "PolicyValue"...........................50 5.12.19. The Class "PolicySNAPVariable"..........................52
5.14. Subclasses of "PolicyValue" Specified in PCIMe.............51 5.12.20. The Class "PolicyFlowDirectionVariable".................52
5.14.1. The Class "PolicyIPv4AddrValue"..........................51 5.13. The Abstract Class "PolicyValue"...........................52
5.14.2. The Class "PolicyIPv6AddrValue...........................52 5.14. Subclasses of "PolicyValue" Specified in PCIMe.............53
5.14.3. The Class "PolicyMACAddrValue"...........................53 5.14.1. The Class "PolicyIPv4AddrValue"..........................53
5.14.4. The Class "PolicyStringValue"............................53 5.14.2. The Class "PolicyIPv6AddrValue...........................54
5.14.5. The Class "PolicyBitStringValue".........................54 5.14.3. The Class "PolicyMACAddrValue"...........................55
5.14.6. The Class "PolicyIntegerValue"...........................55 5.14.4. The Class "PolicyStringValue"............................55
5.14.7. The Class "PolicyBooleanValue"...........................56 5.14.5. The Class "PolicyBitStringValue".........................56
5.15. The Class "PolicyRoleCollection"...........................56 5.14.6. The Class "PolicyIntegerValue"...........................57
5.15.1. The Single-Valued Property "PolicyRole"..................56 5.14.7. The Class "PolicyBooleanValue"...........................58
5.16. The Class "ReusablePolicyContainer"........................56 5.15. The Class "PolicyRoleCollection"...........................58
5.17. Deprecate PCIM's Class "PolicyRepository"..................57 5.15.1. The Single-Valued Property "PolicyRole"..................58
6. Association and Aggregation Definitions..........................57 5.16. The Class "ReusablePolicyContainer"........................58
6.1. The Aggregation "PolicySetComponent"........................57 5.17. Deprecate PCIM's Class "PolicyRepository"..................59
6.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup".....58 5.18. The Abstract Class "FilterEntryBase".......................59
6.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"......58 5.19. The Class "IPHeaderFilter".................................59
6.4. The Abstract Association "PolicySetInSystem"................58 5.19.1. The Property IpVersion...................................60
6.5. Update PCIM's Weak Association "PolicyGroupInSystem"........59 5.19.2. The Property SrcAddress..................................60
6.6. Update PCIM's Weak Association "PolicyRuleInSystem".........60 5.19.3. The Property SrcMask.....................................60
6.7. The Abstract Aggregation "CompoundedPolicyCondition"........60 5.19.4. The Property DestAddress.................................60
6.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule".....60 5.19.5. The Property DestMask....................................61
6.9. The Aggregation "PolicyConditionInPolicyCondition"..........61 5.19.6. The Property ProtocolID..................................61
6.10. The Abstract Aggregation "CompoundedPolicyAction"..........61 5.19.7. The Property SrcPortStart................................61
6.11. Update PCIM's Aggregation "PolicyActionInPolicyRule".......61 5.19.8. The Property SrcPortEnd..................................61
6.12. The Aggregation "PolicyActionInPolicyAction"...............61 5.19.9. The Property DestPortStart...............................61
6.13. The Aggregation "PolicyVariableInSimplePolicyCondition"....62 5.19.10. The Property DestPortEnd................................61
6.14. The Aggregation "PolicyValueInSimplePolicyCondition".......62 5.19.11. The Property DSCP.......................................62
6.15. The Aggregation "PolicyVariableInSimplePolicyAction".......63 5.19.12. The Property FlowLabel..................................62
6.16. The Aggregation "PolicyValueInSimplePolicyAction"..........64 5.20. The Class "8021Filter".....................................62
6.17. The Association "ReusablePolicy"...........................64 5.20.1. The Property SrcMACAddr..................................62
6.18. Deprecate PCIM's "PolicyConditionInPolicyRepository".......65 5.20.2. The Property SrcMACMask..................................63
6.19. Deprecate PCIM's "PolicyActionInPolicyRepository"..........65 5.20.3. The Property DestMACAddr.................................63
6.20. The Association PolicyValueConstraintInVariable............65 5.20.4. The Property DestMACMask.................................63
6.21. The Aggregation "PolicyContainerInPolicyContainer".........66 5.20.5. The Property ProtocolID..................................63
6.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"......66 5.20.6. The Property PriorityValue...............................63
6.23. The Aggregation "ElementInPolicyRoleCollection"............66 5.20.7. The Property VLANID......................................63
6.24. The Weak Association "PolicyRoleCollectionInSystem"........67 5.21. The Class FilterList.......................................63
7. Intellectual Property............................................67 5.21.1. The Property Direction...................................64
8. Acknowledgements.................................................68 6. Association and Aggregation Definitions..........................64
9. Security Considerations..........................................68 6.1. The Aggregation "PolicySetComponent"........................64
10. References......................................................68 6.2. Deprecate PCIM's Aggregation "PolicyGroupInPolicyGroup".....65
11. Authors' Addresses..............................................69 6.3. Deprecate PCIM's Aggregation "PolicyRuleInPolicyGroup"......65
12. Full Copyright Statement........................................70 6.4. The Abstract Association "PolicySetInSystem"................66
13. Appendix A: Open Issues.........................................71 6.5. Update PCIM's Weak Association "PolicyGroupInSystem"........66
6.6. Update PCIM's Weak Association "PolicyRuleInSystem".........67
6.7. The Abstract Aggregation "PolicyConditionStructure".........67
6.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule".....68
6.9. The Aggregation "PolicyConditionInPolicyCondition"..........68
6.10. The Abstract Aggregation "PolicyActionStructure"...........68
6.11. Update PCIM's Aggregation "PolicyActionInPolicyRule".......68
6.12. The Aggregation "PolicyActionInPolicyAction"...............69
6.13. The Aggregation "PolicyVariableInSimplePolicyCondition"....69
6.14. The Aggregation "PolicyValueInSimplePolicyCondition".......70
6.15. The Aggregation "PolicyVariableInSimplePolicyAction".......70
6.16. The Aggregation "PolicyValueInSimplePolicyAction"..........71
6.17. The Association "ReusablePolicy"...........................72
6.18. Deprecate PCIM's "PolicyConditionInPolicyRepository".......72
6.19. Deprecate PCIM's "PolicyActionInPolicyRepository"..........72
6.20. The Association ExpectedPolicyValuesForVariable............72
6.21. The Aggregation "PolicyContainerInPolicyContainer".........73
6.22. Deprecate PCIM's "PolicyRepositoryInPolicyRepository"......74
6.23. The Aggregation "EntriesInFilterList"......................74
6.23.1. The Reference GroupComponent.............................74
6.23.2. The Reference PartComponent..............................74
6.23.3. The Property EntrySequence...............................75
6.24. The Aggregation "ElementInPolicyRoleCollection"............75
6.25. The Weak Association "PolicyRoleCollectionInSystem"........75
7. Intellectual Property............................................76
8. Acknowledgements.................................................76
9. Security Considerations..........................................76
10. References......................................................77
11. Authors' Addresses..............................................78
12. Full Copyright Statement........................................79
13. Appendix A: Closed Issues.......................................80
1. Introduction 1. Introduction
This document (PCIM Extensions, abbreviated here to PCIMe) proposes a This document (PCIM Extensions, abbreviated here to PCIMe) proposes a
number of changes to the Policy Core Information Model (PCIM, RFC 3060 number of changes to the Policy Core Information Model (PCIM, RFC 3060
[3]). These changes include both extensions of PCIM into areas that it [3]). These changes include both extensions of PCIM into areas that it
did not previously cover, and changes to the existing PCIM classes and did not previously cover, and changes to the existing PCIM classes and
associations. Both sets of changes are done in a way that, to the extent associations. Both sets of changes are done in a way that, to the extent
possible, preserves interoperability with implementations of the original possible, preserves interoperability with implementations of the original
PCIM model. PCIM model.
EDITOR'S NOTE: In its -01 release, this document is still at a
preliminary stage of development. Elements may be added and/or elements
may be removed prior to the document's advancement to Proposed Standard.
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 [1]. document are to be interpreted as described in RFC 2119, reference [1].
2. Overview of the Changes 2. Overview of the Changes
2.1. How to Change an Information Model 2.1. How to Change an Information Model
The Policy Core Information Model is closely aligned with the DMTF's CIM The Policy Core Information Model is closely aligned with the DMTF's CIM
Core Policy model. Since there is no separately documented set of rules Core Policy model. Since there is no separately documented set of rules
skipping to change at page 5, line 29 skipping to change at page 6, line 8
existing classes, and properties from the existing classes may existing classes, and properties from the existing classes may
then be "pulled up" into the new classes. The net effect is that then be "pulled up" into the new classes. The net effect is that
the existing classes have exactly the same properties they had the existing classes have exactly the same properties they had
before, but the properties are inherited rather than defined before, but the properties are inherited rather than defined
explicitly in the classes. explicitly in the classes.
o New subclasses may be defined below existing classes. o New subclasses may be defined below existing classes.
2.2. List of Changes to the Model 2.2. List of Changes to the Model
The following subsections provide a very brief overview of the changes to The following subsections provide a very brief overview of the changes to
PCIM being proposed in PCIMe. PCIM defined in PCIMe. In several cases, the origin of the change is
noted, as QPIM [5], ICIM [6], or QDDIM [14].
2.2.1. Changes to PolicyRepository 2.2.1. Changes to PolicyRepository
Because of the potential for confusion with the Policy Framework Because of the potential for confusion with the Policy Framework
component Policy Repository (from the four-box picture: Policy Management component Policy Repository (from the four-box picture: Policy Management
Tool, Policy Repository, PDP, PEP), "PolicyRepository" is a bad name for Tool, Policy Repository, PDP, PEP), "PolicyRepository" is a bad name for
the PCIM class representing a container of reusable policy elements. the PCIM class representing a container of reusable policy elements.
Thus the class PolicyRepository is being replaced with the class Thus the class PolicyRepository is being replaced with the class
ReusablePolicyContainer. To accomplish this change, it is necessary to ReusablePolicyContainer. To accomplish this change, it is necessary to
deprecate the PCIM class PolicyRepository and its three associations, and deprecate the PCIM class PolicyRepository and its three associations, and
skipping to change at page 5, line 51 skipping to change at page 6, line 31
associations. associations.
As a separate change, the associations for ReusablePolicyContainer are As a separate change, the associations for ReusablePolicyContainer are
being broadened, to allow a ReusablePolicyContainer to contain any being broadened, to allow a ReusablePolicyContainer to contain any
reusable policy elements. In PCIM, the only associations defined for a reusable policy elements. In PCIM, the only associations defined for a
PolicyRepository were for it to contain reusable policy conditions and PolicyRepository were for it to contain reusable policy conditions and
policy actions. policy actions.
2.2.2. Additional Associations and Additional Reusable Elements 2.2.2. Additional Associations and Additional Reusable Elements
The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule aggregations are, The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule aggregations have,
in effect, being imported from QPIM. ("In effect" because these two in effect, been imported from QPIM. ("In effect" because these two
aggregations, as well as PCIM'e two aggregations PolicyGroupInPolicyGroup aggregations, as well as PCIM'e two aggregations PolicyGroupInPolicyGroup
and PolicyRuleInPolicyGroup, are all being combined into a single and PolicyRuleInPolicyGroup, are all being combined into a single
aggregation PolicySetComponent.) These aggregations make it possible to aggregation PolicySetComponent.) These aggregations make it possible to
define larger "chunks" of reusable policy to place in a define larger "chunks" of reusable policy to place in a
ReusablePolicyContainer. These aggregations also introduce new semantics ReusablePolicyContainer. These aggregations also introduce new semantics
representing the contextual implications of having one PolicyRule representing the contextual implications of having one PolicyRule
executing within the scope of another PolicyRule. executing within the scope of another PolicyRule.
2.2.3. Priorities and Decision Strategies 2.2.3. Priorities and Decision Strategies
Drawing from both QPIM and ICIM, the Priority property is being Drawing from both QPIM and ICIM, 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 are being incorporated into across nested PolicyGroups and PolicyRules have been incorporated into
PCIMe as well. With the removal of the Priority property from 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 relative to other PolicyRules, the rules must be prioritize a PolicyRule/PolicyGroup relative to other
placed in either a common PolicyGroup or a common PolicyRule. PolicyRules/PolicyGroups, the elements being prioritized must all reside
in one of three places: in a common PolicyGroup, in a common 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 only
in the case of conflicts is being removed. In its place, a in the case of conflicts is being removed. In its place, a
PolicyDecisionStrategy property is being added to the PolicyGroup and PolicyDecisionStrategy property has been added to the PolicyGroup and
PolicyRule classes, to allow the policy administrator to select one of PolicyRule classes. This property allows policy administrator to select
two behaviors with respect to rule evaluation: either perform the actions one of two behaviors with respect to rule evaluation: either perform the
for all PolicyRules whose conditions evaluate to TRUE, or perform the actions for all PolicyRules whose conditions evaluate to TRUE, or perform
actions only for the highest-priority PolicyRule whose conditions the actions only for the highest-priority PolicyRule whose conditions
evaluate to TRUE. (This is accomplished by placing the evaluate to TRUE. (This is accomplished by placing the
PolicyDecisionStrategy property in an abstract class PolicySet, from PolicyDecisionStrategy property in an abstract class PolicySet, from
which PolicyGroup and PolicyRule are derived.) The QPIM rules for which PolicyGroup and PolicyRule are derived.) The QPIM rules for
applying decision strategies to a nested set of PolicyGroups and applying decision strategies to a nested set of PolicyGroups and
PolicyRules are also being imported. PolicyRules have also been imported.
2.2.4. Policy Roles 2.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 - PolicySets. For superclass for both PolicyRules and PolicyGroups - PolicySet. For nested
nested PolicyRules and PolicyGroups, any roles associated with the outer PolicyRules and PolicyGroups, any roles associated with the outer rule or
rule or group are automatically "inherited" by the nested one. group are automatically "inherited" by the nested one. Additional roles
Additional roles may be added at the level of the nested rule or group. may be added at the level of a nested rule or group.
It was also observed that there was 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 was possible to associate a roles to resources. For example, while it is possible in PCIM to
PolicyRule with the role "FrameRelay&&WAN", there was no way to indicate associate a PolicyRule with the role "FrameRelay&&WAN", there is no way
which interfaces matched this criterion. A new PolicyRoleCollection to indicate which interfaces match this criterion. A new
class is defined in PCIMe, representing the collection of resources PolicyRoleCollection class has been defined in PCIMe, representing the
associated with a particular role. The linkage between a PolicyRule or collection of resources associated with a particular role. The linkage
PolicyGroup and a set of resources is then represented by an instance of between a PolicyRule or PolicyGroup and a set of resources is then
PolicyRoleCollection. Equivalent values should be defined in entries in represented by an instance of PolicyRoleCollection. Equivalent values
the PolicyRoles property, inherited by PolicyRules and PolicyGroups from should be defined in the PolicyRoles property of PolicyRules and
PolicySet, and in the PolicyRole property in PolicyRoleCollection. PolicyGroups, and in the PolicyRole property in PolicyRoleCollection.
2.2.5. CompoundPolicyConditions and CompoundPolicyActions 2.2.5. CompoundPolicyConditions and CompoundPolicyActions
The concept of a CompoundPolicyCondition is also being 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 associations
incorporate the condition and action semantics that PCIM defined at the incorporate the condition and action semantics that PCIM defined at the
PolicyRule level: DNF/CNF for conditions, and ordering for actions. 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 component
conditions and actions. In other words, while the components may be conditions and actions. In other words, while the components may be
instances, respectively, of SimplePolicyCondition and SimplePolicyAction instances, respectively, of SimplePolicyCondition and SimplePolicyAction
(discussed immediately below), they need not be. (discussed immediately below), they need not be.
2.2.6. Variables and Values 2.2.6. Variables and Values
The SimplePolicyCondition / PolicyVariable / PolicyValue structure is The SimplePolicyCondition / PolicyVariable / PolicyValue structure has
being imported into PCIMe from QPIM. A list of PCIMe-level variables is been imported into PCIMe from QPIM. A list of PCIMe-level variables is
defined, as well as a list of PCIMe-level values. Other variables and defined, as well as a list of PCIMe-level values. Other variables and
values may, if necessary, be defined in submodels of PCIMe. values may, if necessary, be defined in submodels of PCIMe. For example,
QPIM defines a set of implicit variables 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 SimplePolicyAction
has the semantics "set variable to value". has the semantics "set variable to value".
2.2.7. Packet Filtering 2.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 fields
in an IP packet header plus the most common Layer 2 frame header fields. in an IP packet header plus the most common Layer 2 frame header fields.
It is expected that domain-level policy conditions that filter on these It is expected that domain-level policy conditions that filter on these
header fields will be expressed in terms of CompoundPolicyConditions header fields will be expressed in terms of CompoundPolicyConditions
built up from SimplePolicyConditions that use these variables and values. built up from SimplePolicyConditions that use these variables and values.
An additional PolicyVariable, PacketDirection, is also defined, to An additional PolicyVariable, PacketDirection, is also defined, to
indicate whether a packet being filtered is traveling inbound or outbound indicate whether a packet being filtered is traveling inbound or outbound
on an interface. on an interface.
2.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 packet
classifier filters modeled in QDDIM, these variables and values need not classifier filters modeled in QDDIM, the variables and values discussed
be used. Filter classes derived from the CIM FilterEntryBase class in Section 2.2.7 need not be used. Filter classes derived from the CIM
hierarchy may still be used in these contexts. FilterEntryBase class hierarchy are available for use in these contexts.
These latter classes have two important differences from the domain-level
classes:
o They support specification of filters for all of the fields in a
particular protocol header in a single object instance. With the
domain-level classes, separate instances are needed for each
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 and 802 MAC headers are defined,
respectively, in sections 5.19 and 5.20.
3. The Updated Class and Association Class Hierarchies 3. 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)
| | | |
skipping to change at page 9, line 12 skipping to change at page 10, line 12
| +--PolicyRoleCollection (new - 4.6.2) | +--PolicyRoleCollection (new - 4.6.2)
(continued on following page) (continued on following page)
(continued from previous page) (continued from previous page)
ManagedElement(abstract) ManagedElement(abstract)
| |
+--ManagedSystemElement (abstract) +--ManagedSystemElement (abstract)
| |
+--LogicalElement (abstract) +--LogicalElement (abstract)
| |
+--System (abstract) +--System (abstract)
| |
| +--AdminDomain (abstract)
| |
| +---ReusablePolicyContainer (new - 4.2)
| |
| +---PolicyRepository (deprecated - 4.2)
| |
+--AdminDomain (abstract) +--FilterEntryBase (abstract -- new - 5.18)
| | |
+---ReusablePolicyContainer (new - 4.2) | +--IPHeaderFilter (new - 5.19)
| |
| +--8021Filter (new - 5.20)
| |
+---PolicyRepository (deprecated - 4.2) +--FilterList (new - 5.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. As
before, changes from PCIM are noted parenthetically. before, changes from PCIM are noted parenthetically.
[unrooted] [unrooted]
| |
+---PolicyComponent (abstract) +---PolicyComponent (abstract)
| | | |
| +---PolicySetComponent (new - 4.3) | +---PolicySetComponent (new - 4.3)
| | | |
| +---PolicyGroupInPolicyGroup (deprecated - 4.3) | +---PolicyGroupInPolicyGroup (deprecated - 4.3)
| | | |
| +---PolicyRuleInPolicyGroup (deprecated - 4.3) | +---PolicyRuleInPolicyGroup (deprecated - 4.3)
| | | |
| +---CompoundedPolicyCondition (abstract -- new - 4.7.1) | +---PolicyConditionStructure (abstract -- new - 4.7.1)
| | | | | |
| | +---PolicyConditionInPolicyRule (moved - 4.7.1) | | +---PolicyConditionInPolicyRule (moved - 4.7.1)
| | | | | |
| | +---PolicyConditionInPolicyCondition (new - 4.7.1) | | +---PolicyConditionInPolicyCondition (new - 4.7.1)
| | | |
| +---PolicyRuleValidityPeriod | +---PolicyRuleValidityPeriod
| | | |
| +---CompoundedPolicyAction (abstract -- new - 4.7.2) | +---PolicyActionStructure (abstract -- new - 4.7.2)
| | | | | |
| | +---PolicyActionInPolicyRule (moved - 4.7.2) | | +---PolicyActionInPolicyRule (moved - 4.7.2)
| | | | | |
| | +---PolicyActionInPolicyAction (new - 4.7.2) | | +---PolicyActionInPolicyAction (new - 4.7.2)
| | | |
| +---PolicyVariableInSimplePolicyCondition (new - 4.8.2) | +---PolicyVariableInSimplePolicyCondition (new - 4.8.2)
| | | |
| +---PolicyValueInSimplePolicyCondition (new - 4.8.2) | +---PolicyValueInSimplePolicyCondition (new - 4.8.2)
| | | |
| +---PolicyVariableInSimplePolicyAction (new - 4.8.4) | +---PolicyVariableInSimplePolicyAction (new - 4.8.4)
skipping to change at page 11, line 23 skipping to change at page 12, line 23
| | | +---PolicyGroupInSystem | | | +---PolicyGroupInSystem
| | | | | | | |
| | | +---PolicyRuleInSystem | | | +---PolicyRuleInSystem
| | | | | |
| | +---ReusablePolicy (new - 4.2) | | +---ReusablePolicy (new - 4.2)
| | | | | |
| | +---PolicyConditionInPolicyRepository (deprecated - 4.2) | | +---PolicyConditionInPolicyRepository (deprecated - 4.2)
| | | | | |
| | +---PolicyActionInPolicyRepository (deprecated - 4.2) | | +---PolicyActionInPolicyRepository (deprecated - 4.2)
| | | |
| +---PolicyValueConstraintInVariable (new - 4.8) | +---ExpectedPolicyValuesForVariable (new - 4.8)
| | | |
| +---PolicyRoleCollectionInSystem (new - 4.6.2) | +---PolicyRoleCollectionInSystem (new - 4.6.2)
| |
+---Component (abstract) +---Component (abstract)
| | | |
| +---SystemComponent | +---SystemComponent
| | |
| | +---PolicyContainerInPolicyContainer (new - 4.2)
| | |
| | +---PolicyRepositoryInPolicyRepository (deprecated - 4.2)
| | | |
| +---PolicyContainerInPolicyContainer (new - 4.2) | +---EntriesInFilterList (new - 6.23)
| |
| +---PolicyRepositoryInPolicyRepository (deprecated - 4.2)
| |
+---MemberOfCollection (newly referenced) +---MemberOfCollection (newly referenced)
| |
+--- ElementInPolicyRoleCollection (new - 4.6.2) +--- ElementInPolicyRoleCollection (new - 4.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 association
class level, there are other changes from PCIM involving individual class class level, there are other changes from PCIM involving individual class
properties. In some cases new properties are introduced into existing properties. In some cases new properties are introduced into existing
skipping to change at page 12, line 36 skipping to change at page 13, line 36
is out of scope for this standards effort, but that is necessary in the is out of scope for this standards effort, but that is necessary in the
development and deployment of a usable policy-based configuration system. development and deployment of a usable policy-based configuration system.
An SLA-level policy transformation to the domain-level policy may be 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 thought of as analogous to a visual builder that takes human input and
develops a programmatic rule specification. The relationship between the develops a programmatic rule specification. The relationship between the
domain-level policy and the device-level policy may be thought of as 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 analogous to that of a compiler and linkage editor that translates the
rules into specific instructions that can be executed on a specific type rules into specific instructions that can be executed on a specific type
of platform. of platform.
The policy core information model may be used to specify rules at any and PCIM and PCIMe may be used to specify rules at any and all of these
all of these levels of abstraction. However, at different levels of levels of abstraction. However, at different levels of abstraction,
abstraction, different mechanisms may be more or less appropriate. different mechanisms may be more or less appropriate.
4.1.2. Administrative and Functional Scopes 4.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 domain-
level policy would be scoped by an AdminDomain instance (or by a level policy would be scoped by an AdminDomain instance (or by a
hierarchy of AdminDomain instances) whereas a device-level policy might hierarchy of AdminDomain instances) whereas a device-level policy might
be scoped by a System instance that represents the PEP (e.g., be scoped by a System instance that represents the PEP (e.g., an instance
ComputerSystem, see CIM [4]). In addition to collecting policies into an of ComputerSystem, see CIM [4]). In addition to collecting policies into
administrative domain, these System classes may also aggregate the an administrative domain, these System classes may also aggregate the
resources to which the policies apply. 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 derivation from the policy framework 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. So,
for example, Quality of Service may be thought of as a functional scope for example, Quality of Service may be thought of as a functional scope,
or Diffserv and Intserv may each be thought of as functional scopes, or Diffserv and Intserv may each be thought of as functional scopes.
these scoping decisions are made by the derivation of the framework and These scoping decisions are represented by the structure of the submodels
may be reflected in the number and types of PEP policy client(s), derived from PCIM and PCIMe, and may be reflected in the number and types
services and the interaction between policies. Policies in different of PEP policy client(s), services, and the interaction between policies.
functional scopes are organized in disjoint sets of policy rules. Policies in different functional scopes are organized into disjoint sets
Different functional domains may share the use of some roles, some of policy rules. Different functional domains may share some roles, some
conditions, and even some actions. The rules from different functional conditions, and even some actions. The rules from different functional
domains may even be enforced at the same managed resource but for the domains may even be enforced at the same managed resource, but for the
purposes of policy evaluation they are separate. See section 4.5 for purposes of policy evaluation they are separate. See section 4.5.3 for
more information. more information.
The functional scopes MAY be reflected in administrative scopes. That The functional scopes MAY be reflected in administrative scopes. That
is, deployments of policy may have different administrative scopes for is, deployments of policy may have different administrative scopes for
different functional scopes, but there is no requirement to do so. different functional scopes, but there is no requirement to do so.
4.2. Reusable Policy Elements 4.2. Reusable Policy Elements
In PCIM, a distinction was drawn between reusable PolicyConditions and In PCIM, a distinction was drawn between reusable PolicyConditions and
PolicyActions and rule-specific ones. The PolicyRepository class was PolicyActions and rule-specific ones. The PolicyRepository class was
skipping to change at page 14, line 8 skipping to change at page 15, line 8
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 deprecated.
o PCIM's PolicyActionInPolicyRepository association is deprecated. o PCIM's PolicyActionInPolicyRepository association is deprecated.
o The aggregation PolicyContainerInPolicyContainer is defined. o The aggregation PolicyContainerInPolicyContainer is defined.
o PCIM's PolicyRepositoryInPolicyRepository aggregation is deprecated. o PCIM's PolicyRepositoryInPolicyRepository aggregation is deprecated.
4.3. Policy Sets 4.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 administer,
manage, and control access to network resources (PolTerm, reference manage, and control access to network resources ("Policy Terminology",
[12]). The structuring of these coherent sets of rules into subsets is reference [12]). The structuring of these coherent sets of rules into
enhanced in this document. In section 4.4, we discuss the new options subsets is enhanced in this document. In Section 4.4, we discuss the new
for the nesting of policy rules. 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 abstraction
for a set of rules. It is derived from Policy, and it is inserted into for a set of rules. It is derived from Policy, and it is inserted into
the inheritance hierarchy above both PolicyGroup and PolicyRule. This the inheritance hierarchy above both PolicyGroup and PolicyRule. This
reflects the additional structure flexibility and semantic capability of reflects the additional structural flexibility and semantic capability of
both subclasses. both subclasses.
Two properties are defined in PolicySet: PolicyDecisionStrategy and Two properties are defined in PolicySet: PolicyDecisionStrategy and
PolicyRoles. PolicyDecisionStrategy is added to PolicySet to define the PolicyRoles. The PolicyDecisionStrategy property is included in
evaluation relationship between the rules in the policy set. See section PolicySet to define the evaluation relationship among the rules in the
4.5 for more information. PolicyRoles is added to PolicySet to name the policy set. See Section 4.5 for more information. The PolicyRoles
retrieval sets. See section 4.6 for more information. property is included in PolicySet to characterize the resources to which
the PolicySet applies. See Section 4.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 following
sections. PolicySetComponent is defined as a subclass of 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 PolicySet
in a PolicySet. PolicySetComponent replaces the two PCIM aggregations in a PolicySet. PolicySetComponent replaces the two PCIM aggregations
PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup, so these two PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup, so these two
aggregations are deprecated. aggregations are deprecated.
The PolicySet relationship to an AdminDomain or other administrative A PolicySet's relationship to an AdminDomain or other administrative
scoping system (e.g., a ComputerSystem) is defined in 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 derived
from PolicyInSystem, and the PolicyGroupInSystem and PolicyRuleInSystem from PolicyInSystem, and the PolicyGroupInSystem and PolicyRuleInSystem
associations are now derived from PolicySetInSystem instead of directly associations are now derived from PolicySetInSystem instead of directly
from PolicyInSystem. The PolicySetInSystem.Priority property is from PolicyInSystem. The PolicySetInSystem.Priority property is
discussed in section 4.5. discussed in Section 4.5.3.
4.4. Nested Policy Rules 4.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 to
represent the nesting of a policy rule in another policy rule. represent the nesting of a policy rule in another policy rule.
4.4.1. Usage Rules for Nested Rules 4.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 pre-condition for o The parent rule's condition clause is a condition for evaluation
evaluation of all nested rules. If the parent rule's condition of all nested rules; that is, the conditions of the parent are
clause evaluates to FALSE, all sub-rules SHALL be skipped and logically ANDed to the conditions of the sub-rules. If the parent
their condition clauses SHALL NOT be evaluated. rule's condition clause evaluates to FALSE, sub-rules MAY be
skipped since they also evaluate to FALSE.
o If the parent rule's condition evaluates to TRUE, the set of sub- o If the parent rule's condition evaluates to TRUE, the set of sub-
rules SHALL BE executed according to the decision strategy and rules SHALL BE evaluated according to the decision strategy and
priorities as discussed in Section 4.5. priorities as discussed in Section 4.5.
o If the parent rule's condition evaluates to TRUE, the parent o If the parent rule's condition evaluates to TRUE, the parent
rule's set of actions is executed BEFORE execution of the sub- rule's set of actions is executed BEFORE execution of the sub-
rulesĘ actions. The parent rule's actions are not to be confused rulesĘ actions. The parent rule's actions are not to be confused
with default actions. A default action is one that is to be with default actions. A default action is one that is to be
executed only if none of the more specific sub-rules are executed. 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 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 as an action that is part of a catchall sub-rule associated with
the parent rule. The association linking the default action(s) in the parent rule. The association linking the default action(s) in
this special sub-rule should have the lowest priority relative to this special sub-rule should have the lowest priority relative to
all other sub-rule associations: all other sub-rule associations:
if precondition then parent rule's action if parent-condition then parent rule's action
if condA then actA if condA then actA
if condB then ActB if condB then ActB
if True then default action if True then default action
Default actions have meaning when FirstMatching decision Such a default action functions as a default when FirstMatching
strategies are in effect (see section 4.5). decision strategies are in effect (see section 4.5). If
AllMatching applies, the "default" action is always performed.
o Policy rules have an implicit context in which they are executed. o Policy rules have a context in which they are executed. The rule
For example, the context of a policy rule could be all packets engine evaluates and applies the policy rules in the context of
running on an interface or set of interfaces on which the rule is the managed resource(s) that are identified by the policy roles
applied. Similarly, a parent rule provides a context to all of (or by an explicit association). Submodels MAY add additional
its sub-rules. The context of the sub-rules is the restriction of context to policy rules based on rule structure; any such
the context of the parent rule to the set of cases that match the additional context is defined by the semantics of the action
parent rule's condition clause. classes of the submodel.
4.4.2. Motivation 4.4.2. Motivation
The motivation for introducing nested rules includes enhancing the
definition of Policy, defining and reusing context hierarchies,
optimizing how a rule is evaluated, and providing finer-grained control
over condition evaluation.
Rule nesting enhances Policy readability, expressiveness and reusability. Rule nesting enhances Policy readability, expressiveness and reusability.
The ability to nest policy rules and form sub-rules is important for The ability to nest policy rules and form sub-rules is important for
manageability and scalability, as it enables complex policy rules to be manageability and scalability, as it enables complex policy rules to be
constructed from multiple simpler policy rules. These enhancements ease constructed from multiple simpler policy rules. These enhancements ease
the policy management tools' task, allowing policy rules to be expressed the policy management tools' task, allowing policy rules to be expressed
in a way closer to how humans think. in a way closer to how humans think.
Sub-rules enable the policy designer to define a hierarchy of rules. Although rule nesting can be used to suggest optimizations in the way
This hierarchy has the property that sub-rules can be scoped by their policy rules are evaluated, as discussed in section 4.5.2 "Side Effects,"
parent rules. This scoping, or context of evaluation and execution, is a nesting does not specify nor does it require any particular order of
powerful tool in enabling the policy designer to obtain the fine-grained evaluation of conditions. Optimization of rule evaluation can be done in
control needed to appropriately manage resources for certain the PDP or in the PEP by dedicated code. This is similar to the relation
applications. The example in the following section demonstrates that
expressing relative bandwidth allocation rules can be done naturally
using a hierarchical rule structure.
Rule nesting can be used to optimize the way policy rules are evaluated
and executed. Once the parent rule's condition clause is evaluated to
FALSE, all sub-rules are skipped, optimizing the number of lookups
required. Note that this is not the prime reason for rule nesting, but
rather a side benefit. Optimization of rule execution can be done in the
PDP or in the PEP by dedicated code. This is similar to the relation
between a high level programming language like C and machine code. An between a high level programming language like C and machine code. An
optimizer can create a more efficient machine code than any optimization optimizer can create a more efficient machine code than any optimization
done by the programmer within the source code. Nevertheless, if the PEP done by the programmer within the source code. Nevertheless, if the PEP
or PDP does not do optimization, the administrator writing the policy can or PDP does not do optimization, the administrator writing the policy may
optimize the policy rules for execution using rule nesting. be able to influence the evaluation of the policy rules for execution
using rule nesting.
Evaluation of some conditions does not require simple examination of a
field within a packet. For example, condition evaluation may require a
PDP (or a PEP) to access an external database (e.g., a directory), query
an external PDP (e.g., Kerberos) or possibly investigate a state within
the network (e.g., issue an SNMP query). These non-local condition
evaluations should be minimized, as they cause delay in rule evaluation,
load the network and other resources, and may have undesirable side
effects.
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 assigned
to a role are retrieved by the PDP or PEP from the policy repository and to a role are retrieved by the PDP or PEP from the policy repository and
enforced. Optimizing the number of rules retrieved should be done by enforced. Optimizing the number of rules retrieved should be done by
clever selection of roles. clever selection of roles.
4.4.3. Usage Example
This section provides a usage example that aims to clarify the motivation
for the definition of rule nesting and the use of the relative context.
Consider the following example, where a set of rules is used to specify
the minimal bandwidth allocations on an interface. The policy reads:
On any interface on which these rules apply, guarantee at least
30% of the interface bandwidth to UDP flows, and at least 40% of
the interface bandwidth to TCP flows.
When formatted in the condition and action rule structure, the policy
reads:
If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1)
If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)
Now, let's add some sub-rules to further differentiate how bandwidth
should be allocated to specific UDP and TCP applications (indentation
indicates rule nesting):
If (IP protocol is UDP) THEN (guarantee 30% of available BW) (1)
If (protocol is TFTP) (guarantee 10% of available BW) (1a)
If (protocol is NFS) THEN (guarantee 40% of available BW) (1b)
If (IP protocol is TCP) THEN (guarantee 40% of available BW) (2)
If (protocol is HTTP) THEN guarantee 20% of available BW) (2a)
If (protocol is FTP) THEN (guarantee 30% of available BW) (2b)
The UDP sub-rules specify that TFTP should be allocated 10% of the
bandwidth allocated to UDP while NFS should be allocated 40% of the UDP
portion. For TCP flows, HTTP should be allocated 20% of the TCP
bandwidth while FTP should be allocated 30%.
The context of each of the two high-level rules (those marked (1) and (2)
above) is all flows running on an interface. The two sub-rules of the
UDP rule, marked (1a) and (1b) above specify a more granular context:
within UDP flows, TFTP should be allocated 10% of the bandwidth while NFS
should be allocated 40%. The context of these sub-rules is therefore UDP
flows only. Similar functionality applies for the hierarchy of rules
treating TCP flows.
A context hierarchy enhances reusability. The rules that divide
bandwidth between TFTP and NFS can be re-used and associated to rules
that allocate different percentages of the bandwidth for different
interfaces (or even for the same interface, but under different
conditions) for UDP.
This set of rules can be implemented using a hierarchical scheduler.
Classifiers map TFTP packets to one queue, NFS packets to a second queue
and the rest of UDP packets to the third queue. The first (UDP)
scheduler assigns weights to each queue according to the guaranteed
bandwidth percentages defined in sub-rules (1a) and (1b).
The second scheduler similarly assigns weights to 3 other queues
according to the guaranteed bandwidth percentages defined in sub-rules
(2a) and (2b). The UDP scheduler places packets into a UDP output queue.
The TCP scheduler places packets on a TCP output queue. The rest of the
traffic is placed on a third queue. A scheduler extracts packets from
each of these three queues for transmission. The UDP queue is assigned a
30% weight according to rule (1), while the TCP queue is assigned a 40%
weight according to rule (2).
This example shows how rule nesting helps in specifying policy without
the need to describe the mechanisms (queues and schedulers) used to
implement it. The rule specification allows the policy administrator to
express the policies he or she wants to enforce on the domain, and allows
the PDP or the PEP to map these policies to its mechanisms. This is an
example of a mapping between a rule based policy information model and a
data path model [QDDIM].
4.5. Priorities and Decision Strategies 4.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 the
policies in a PolicySet. Two decision strategies are defined: 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 used to
cause the evaluation of the rules in a set such that the only actions cause the evaluation of the rules in a set such that the only actions
enforced on a given examination of the PolicySet are those for the first enforced on a given examination of the PolicySet are those for the first
rule (that is, the rule with the highest priority) that has its rule (that is, the rule with the highest priority) that has its
conditions evaluate to TRUE. The AllMatching strategy is used to cause conditions evaluate to TRUE. The AllMatching strategy is used to cause
the evaluation of all rules in a set; for all of the rules whose the evaluation of all rules in a set; for all of the rules whose
skipping to change at page 18, line 27 skipping to change at page 17, line 35
support the AllMatching decision strategy. 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 subclass.
Loops, including the degenerate case of a PolicySet that contains itself, Loops, including the degenerate case of a PolicySet that contains itself,
are not allowed when PolicySets contain other PolicySets. The are not allowed when PolicySets contain other PolicySets. The
containment relationship is specified using the PolicySetComponent containment relationship is specified using the PolicySetComponent
aggregation. aggregation.
The relative priority within a PolicySet is established by the Priority The relative priority within a PolicySet is established by the Priority
property of the PolicySetComponent aggregation of contained PolicyGroup property of the PolicySetComponent aggregation of the contained
and PolicyRule instances. The use of PCIM's PolicyRule.Priority property PolicyGroup and PolicyRule instances. The use of PCIM's
is deprecated in favor of this new property. The separation of the PolicyRule.Priority property is deprecated in favor of this new property.
priority property from the rule has two advantages. First, it The separation of the priority property from the rule has two advantages.
generalizes the concept of priority, so it can be used for both groups First, it generalizes the concept of priority, so that it can be used for
and rules; and, second, it places the priority on the relationship both groups and rules. Second, it places the priority on the
between the parent policy set and the subordinate policy group or rule. relationship between the parent policy set and the subordinate policy
The assignment of a priority value, then, becomes much easier in that the group or rule. The assignment of a priority value then becomes much
value is used only in relationship to other priorities in the same set. easier, in that the value is used only in 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 with
others defined for the aggregating PolicySet. Thus, the evaluation of others defined for the same aggregating PolicySet. Thus, the evaluation
rules within a set is deterministically specified. of rules within a set is deterministically specified.
For a FirstMatching decision strategy, the first rule (i.e., the one with For a FirstMatching decision strategy, the first rule (that is, the one
the highest priority) in the set that evaluates to True, is the only rule with the highest priority) in the set that evaluates to True, is the only
whose actions are enforced for a particular evaluation pass through the rule whose actions are enforced for a particular evaluation pass through
PolicySet. 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 the
order in which the actions are to be executed by the enforcement point: order in which the actions are to be executed by the enforcement point:
the actions of the higher priority rules are executed first. Since the the actions of the higher priority rules are executed first. Since the
actions of higher priority rules are executed first, lower priority rules actions of higher priority rules are executed first, lower priority rules
that also match may get the "last word," and thus produce a counter- that also match may get the "last word," and thus produce a counter-
intuitive result. So, for example, if two rules both evaluate to True, intuitive result. So, for example, if two rules both evaluate to True,
and the higher priority rule sets the DSCP to 3 and the lower priority and the higher priority rule sets the DSCP to 3 and the lower priority
rule sets the DSCP to 4, the action of the lower priority rule will be rule sets the DSCP to 4, the action of the lower priority rule will be
skipping to change at page 19, line 19 skipping to change at page 18, line 29
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 of
actions to be executed by the PEP and any required serialization is then actions to be executed by the PEP and any required serialization is then
provided by the service configured by the rule engine. See section 4.5.2 provided by the service configured by the rule engine. See section 4.5.2
for a discussion of side effects. for a discussion of side effects.
4.5.1. Structuring Decision Strategies 4.5.1. Structuring Decision Strategies
When policy sets are nested, as shown in Figure 3, the decision When policy sets are nested, as shown in Figure 3. , the decision
strategies may be nested arbitrarily. In this example, the relative strategies may be nested arbitrarily. In this example, the relative
priorities for the nested rules, high to low, are 1A, 1B1, 1X2, 1B3, 1C, priorities for the nested rules, high to low, are 1A, 1B1, 1X2, 1B3, 1C,
1C1, 1X2 and 1C3. (Note that PolicyRule 1X2 is included in both 1C1, 1X2 and 1C3. (Note that PolicyRule 1X2 is included in both
PolicyGroup 1B and PolicyRule 1C, but with different priorities.) Of PolicyGroup 1B and PolicyRule 1C, but with different priorities.) Of
course, which rules are enforced is also dependent on which rules, if course, which rules are enforced is also dependent on which rules, if
any, match. any, match.
PolicyGroup 1: FirstMatching PolicyGroup 1: FirstMatching
| |
+-- Pri=6 -- PolicyRule 1A +-- Pri=6 -- PolicyRule 1A
skipping to change at page 20, line 43 skipping to change at page 20, line 19
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 include
any side effects of condition evaluation in the evaluation of conditions any side effects of condition evaluation in the evaluation of conditions
for either of the decision strategies. For both the AllMatching decision for either of the decision strategies. For both the AllMatching decision
strategy and for the nesting of rules within rules (either directly or strategy and for the nesting of rules within rules (either directly or
indirectly) where the actions of more than one rule may be enforced, any indirectly) where the actions of more than one rule may be enforced, any
side effects of the enforcement of actions MUST NOT be included in side effects of the enforcement of actions MUST NOT be included in
condition evaluation on the same evaluation pass. condition evaluation on the same evaluation pass.
4.5.3. Multiple PolicySet Trees For a Resource 4.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 the
PolicySet subclass instances and the PolicySetComponent aggregation PolicySet subclass instances and the PolicySetComponent aggregation
instances between them. Each PolicySet tree has a defined set of instances between them. Each PolicySet tree has a defined set of
decision strategies and evaluation priorities. In section 4.6 we discuss decision strategies and evaluation priorities. In section 4.6 we discuss
some improvements in the use of PolicyRoles that cause the parent some improvements in the use of PolicyRoles that cause the parent
PolicySet.PolicyRoles to be applied to all contained PolicySet instances. PolicySet.PolicyRoles to be applied to all contained PolicySet instances.
However, a given resource may still have multiple, disjoint PolicySet However, a given resource may still have multiple, disjoint PolicySet
trees that are collected from different roles and role combinations. trees that are collected from different roles and role combinations.
Note that these top-level PolicySet instances (called "unrooted") may These top-level PolicySet instances are called "unrooted".
only be unrooted in a given context.
A PolicySet instance is defined to be unrooted in the context of a
particular managed element; the relationship to the managed element is
usually established by the policy roles of the PolicySet instance and of
the managed element (see 4.6 "Policy Roles"). A PolicySet instance is
unrooted in that context if and only if there is no PolicySetComponent
association to a parent PolicySet that is also related to the same
managed element. Figure 4. shows an example where instance A has role A,
instance B has role B and so on. In this example, in the context of
interface X, B, and C are unrooted and, because roles are inherited,
instances D, E, and F are all rooted.
+---+ +-----------+
| A | | I/F X |
+---+ | has roles |
/ \ | B & C |
/ \ +-----------+
+---+ +---+
| B | | C |
+---+ +---+
/ \ \
/ \ \
+---+ +---+ +---+
| D | | E | | F |
+---+ +---+ +---+
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. association.
The FirstMatching strategy is used among all PolicySet instances that The FirstMatching strategy is used among all PolicySet instances that
apply to a given resource for a given functional domain. So, for apply to a given resource for a given functional domain. So, for
skipping to change at page 22, line 16 skipping to change at page 22, line 33
enables one to associate Roles with elements, where roles have the same enables one to associate Roles with elements, where roles have the same
semantics as in PCIM. Then, since the policyFilter in a policy allows one semantics as in PCIM. Then, since the policyFilter in a policy allows one
to define conditions based on the comparison of the values of SNMP to define conditions based on the comparison of the values of SNMP
variables, one can filter elements based on their roles as defined in the variables, one can filter elements based on their roles as defined in the
Role group. 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 ways.
First, in PCIM, a set of role(s) is associated with a policy rule as the First, in PCIM, a set of role(s) is associated with a policy rule as the
values of the PolicyRoles property of a policy rule. The semantics of values of the PolicyRoles property of a policy rule. The semantics of
role(s) are then expected to be implemented by the PDP (i.e. policies are role(s) are then expected to be implemented by the PDP (i.e. policies are
applied to the elements with the appropriate roles). In [draft-ietf- applied to the elements with the appropriate roles). In [13], however,
snmpconf-pm-04], however, no special processing is required for realizing no special processing is required for realizing the semantics of roles;
the semantics of roles; roles are treated just as any other SNMP roles are treated just as any other SNMP variables and comparisons of
variables and comparisons of role values can be included in the policy role values can be included in the policy filter of a policy rule.
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 role
with an object instance, whereas in [13] this is done via the use of the with an object instance, whereas in [13] this is done via the use of the
Role tables (pmRoleESTable and pmRoleSETable). The Role tables associate Role tables (pmRoleESTable and pmRoleSETable). The Role tables associate
Role values with elements. Role values with elements.
4.6.2. Addition of PolicyRoleCollection to PCIMe 4.6.2. Addition of PolicyRoleCollection to PCIMe
In order to remedy the latter shortcoming in PCIM (i.e. the lack of a way In order to remedy the latter shortcoming in PCIM (the lack of a way of
of associating a role with an object instance), we define a new class associating a role with an object instance), PCIMe has a new class
PolicyRoleCollection that subclasses from the CIM Collection class. PolicyRoleCollection derived from the CIM Collection class. Resources
Resources that share a common role belong to a PolicyRoleCollection that share a common role are aggregated by a PolicyRoleCollection
instance. Membership in this collection is indicated using the instance, via the ElementInPolicyRoleCollection aggregation. The role is
aggregation ElementInPolicyRoleCollection. The resource's role is specified in the PolicyRole property of the aggregating
specified in the PolicyRole property of the PolicyRoleCollection class. 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 was
done in PCIM for PolicyRules and PolicyGroups, this is captured by an done in PCIM for PolicyRules and PolicyGroups, an association,
association, PolicyRoleCollectionInSystem. Remember that in PCIM, a PolicyRoleCollectionInSystem, captures this relationship. Remember that
System is a base class for describing network devices and administrative in CIM, System is a base class for describing network devices and
domains. administrative domains.
When associating a PolicyRoleCollection with a System, this should be The association between a PolicyRoleCollection and a system should be
done consistently with the system that scopes the policy rules/groups consistent with the associations that scope the policy rules/groups that
that are applied to the resources in that collection. A are applied to the resources in that collection. Specifically, a
PolicyRoleCollection is associated with the same system as the applicable PolicyRoleCollection should be associated with the same System as the
PolicyRules and/or PolicyGroups, or to a System higher in the tree formed applicable PolicyRules and/or PolicyGroups, or to a System higher in the
by the SystemComponent association. When a PEP belongs to multiple tree formed by the SystemComponent association. When a PEP belongs to
Systems (i.e., AdminDomains), and scoping by a single domain is multiple Systems (i.e., AdminDomains), and scoping by a single domain is
impractical, two alternatives exist. One is to arbitrarily limit domain impractical, two alternatives exist. One is to arbitrarily limit domain
membership to one System/AdminDomain. The other option is to define a membership to one System/AdminDomain. The other option is to define a
more global AdminDomain that simply includes the others, and/or that more global AdminDomain that simply includes the others, and/or that
spans the business or enterprise. 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, and
that an administrator would like to assign three of them to provide that an administrator would like to assign three of them to provide
"gold" service. Also, the administrator has defined several policy rules "gold" service. Also, the administrator has defined several policy rules
which specify how the "gold" service is delivered. For these rules, the which specify how the "gold" service is delivered. For these rules, the
PolicyRoles property (inherited from PolicySet) is set to "Gold Service". PolicyRoles property (inherited from PolicySet) is set to "Gold Service".
skipping to change at page 23, line 38 skipping to change at page 24, line 5
apply only to Ethernet interfaces. A policy group can be defined with a apply only to Ethernet interfaces. A policy group can be defined with a
role-combination="Ethernet", and all the relevant policy rules can be role-combination="Ethernet", and all the relevant policy rules can be
placed in this policy group. (Note that in PCIMe, role(s) are made placed in this policy group. (Note that in PCIMe, role(s) are made
available to PolicyGroups as well as to PolicyRules by moving PCIM's available to PolicyGroups as well as to PolicyRules by moving PCIM's
PolicyRoles property up from PolicyRule to the new abstract class PolicyRoles property up from PolicyRule to the new abstract class
PolicySet. The property is then inherited by both PolicyGroup and PolicySet. The property is then inherited by both PolicyGroup and
PolicyRule.) Then every policy rule in this policy group implicitly PolicyRule.) Then every policy rule in this policy group implicitly
inherits this role-combination from the containing policy group. A inherits this role-combination from the containing policy group. A
similar implicit inheritance applies to nested policy groups. similar implicit inheritance applies to nested policy groups.
Note that there is no explicit copying of role(s) from container to There is no explicit copying of role(s) from container to contained
contained entity. Obviously, this implicit inheritance of role(s) leads entity. Obviously, this implicit inheritance of role(s) leads to the
to the possibility of defining inconsistent role(s) (as explained in the possibility of defining inconsistent role(s) (as explained in the example
example below); the handling of such inconsistencies is beyond the scope below); the handling of such inconsistencies is beyond the scope of
of PCIMe. 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 have
the role(s) shown below: the role(s) shown below:
+------------------------------+ +------------------------------+
| PolicyGroup PG1 | | PolicyGroup PG1 |
| PolicyRoles = Ethernet, Fast | | PolicyRoles = Ethernet, Fast |
+------------------------------+ +------------------------------+
skipping to change at page 24, line 25 skipping to change at page 24, line 36
| +--------------------------+ | +--------------------------+
| | PolicyRule PR2 | | | PolicyRule PR2 |
|--------| PolicyRoles = <undefined>| |--------| PolicyRoles = <undefined>|
| +--------------------------+ | +--------------------------+
| |
| +------------------------+ | +------------------------+
| | PolicyRule PR3 | | | PolicyRule PR3 |
|--------| PolicyRoles = Slow | |--------| PolicyRoles = Slow |
+------------------------+ +------------------------+
Figure 4. 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 "Slow".
This appears to be in conflict with the role, "Fast," defined in PG1. This appears to be in conflict with the role, "Fast," defined in PG1.
However, whether these roles are actually in conflict is not clear. In However, whether these roles are actually in conflict is not clear. In
one scenario, the policy administrator may have wanted only "Fast"- one scenario, the policy administrator may have wanted only "Fast"-
"Ethernet" rules in the policy group. In another scenario, the "Ethernet" rules in the policy group. In another scenario, the
administrator may be indicating that PR3 applies to all "Ethernet" administrator may be indicating that PR3 applies to all "Ethernet"
skipping to change at page 25, line 23 skipping to change at page 25, line 29
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 conditions,
the following changes are required: the following changes are required:
o Create a new aggregation PolicyConditionInPolicyCondition, with the o Create a new aggregation PolicyConditionInPolicyCondition, with the
same GroupNumber and ConditionNegated properties as 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
CompoundedPolicyCondition, 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 o It is also necessary to define a concrete subclass
CompoundPolicyCondition of PolicyCondition, to introduce the CompoundPolicyCondition of PolicyCondition, to introduce the
ConditionListType property. This property has the same function, ConditionListType property. This property has the same function,
and works in exactly the same way, as the corresponding property and works in exactly the same way, as the corresponding property
currently defined in PCIM for the PolicyRule class. currently defined in PCIM for the PolicyRule class.
skipping to change at page 26, line 16 skipping to change at page 26, line 25
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. This
time the goal is to apply the property ActionOrder from PCIM's 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 aggregates
simpler actions. The following changes are required: 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 way
to do this is to move the property up to a new abstract aggregation to do this is to move the property up to a new abstract aggregation
superclass CompoundedPolicyAction, from which the existing superclass PolicyActionStructure, from which the existing
aggregation PolicyActionInPolicyRule and a new aggregation aggregation PolicyActionInPolicyRule and a new aggregation
PolicyActionInPolicyAction are derived. For now there is no need PolicyActionInPolicyAction are derived.
to re-document the ActionOrder property itself, since it is already
documented in PCIM as part of the definition of the
PolicyActionInPolicyRule aggregation.
o It is also necessary to define a concrete subclass o It is also necessary to define a concrete subclass
CompoundPolicyAction of PolicyAction, to introduce the CompoundPolicyAction of PolicyAction, to introduce the
SequencedActions property. This property has the same function, SequencedActions property. This property has the same function,
and works in exactly the same way, as the corresponding property and works in exactly the same way, as the corresponding property
currently defined in PCIM for the PolicyRule class. currently defined in PCIM for the PolicyRule class.
o Finally, a new property ExecutionStrategy is needed for both the o Finally, a new property ExecutionStrategy is needed for both the
PCIM class PolicyRule and the new class CompoundPolicyAction. This PCIM class PolicyRule and the new class CompoundPolicyAction. This
property allows the policy administrator to specify how the PEP property allows the policy administrator to specify how the PEP
should behave in the case where there are multiple actions should behave in the case where there are multiple actions
aggregated by a PolicyRule or by a CompoundPolicyAction. 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 5. actions are below, in Section 5.
Compound actions allow the definition of logically complex policy rules
and action behavior. The following example illustrates two advantages of
using compound actions.
A QoS policy domain may include a rule that defines the following
behavior:
If (CONDITION) Then Do:
"Shape traffic to <X> and Set DSCP to EF (high priority traffic);
if canĘt shape than Set DSCP to BE (best effort)."
This rule can be realized by defining two CompoundPolicyAction instances,
A and B. Two sub-actions are grouped into CompoundPolicyAction A:
Shape traffic to <X>
Mark to EF (DSCP).
The ExecutionStrategy property of CompoundPolicyAction A would be defined
as "Mandatory Do all". This means that if shaping or marking cannot both
be done, then nothing should be done.
A second action, CompoundPolicyAction B, would hold the Mark to BE sub-
action.
CompoundPolicyAction A and CompoundPolicyAction B would be aggregated
into the policy rule using the PolicyActionInPolicyRule aggregation. The
CompoundPolicyAction A will be ordered for execution before the
CompoundPolicyAction B. The PolicyRule's ExecutionStrategy property
would be set to "Do until success". In this way, CompoundPolicyAction A
will be enforced on all PEPs that support shaping, while
CompoundPolicyAction B will be enforced otherwise.
4.8. Variables and Values 4.8. Variables and Values
The following subsections introduce several related concepts, including The following subsections introduce several related concepts, including
PolicyVariables and PolicyValues (and their numerous subclasses), PolicyVariables and PolicyValues (and their numerous subclasses),
SimplePolicyConditions, and SimplePolicyActions. SimplePolicyConditions, and SimplePolicyActions.
4.8.1. Simple Policy Conditions 4.8.1. Simple Policy Conditions
The SimplePolicyCondition class models elementary Boolean conditional The SimplePolicyCondition class models elementary Boolean expressions of
expressions of the form: "If (<variable> MATCH <value>)". The "If" the form: "(<variable> MATCH <value>)". The relationship 'MATCH', which
clause and the "MATCH" are implied in the formal notation. The is implicit in the model, is interpreted based on the variable and the
relationship is always 'MATCH' and is interpreted based on the variable value. Section 4.8.3 explains the semantics of the 'MATCH' operator.
and the value. Section 4.8.3 explains the semantics of the operator and Arbitrarily complex Boolean expressions can be formed by chaining
how to extend them. Arbitrarily complex Boolean expressions can be together any number of simple conditions using relational operators.
formed by chaining together any number of simple conditions using
relational operators. Individual simple conditions can be negated as
well. Arbitrarily complex Boolean expressions are modeled by the class
CompoundPolicyCondition (described in section 4.7.1).
For example, the expression "If SourcePort == 80" can be modeled by a Individual simple conditions can be negated as well. Arbitrarily complex
simple condition. In this example, 'SourcePort' is a variable, '==' is Boolean expressions are modeled by the class CompoundPolicyCondition
the relational operator denoting the equality relationship (which is (described in Section 4.7.1).
generalized by PCIMe to a "match" relationship), and '80' is an integer
For example, the expression "SourcePort == 80" can be modeled by a simple
condition. In this example, 'SourcePort' is a variable, '==' is the
relational operator denoting the equality relationship (which is
generalized by PCIMe to a "MATCH" relationship), and '80' is an integer
value. The complete interpretation of a simple condition depends on the value. The complete interpretation of a simple condition depends on the
binding of the variable. Section 4.8.5 describes variables and their binding of the variable. Section 4.8.5 describes variables and their
binding rules. 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> and 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 of
the formal notation. 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 matched
when evaluating the condition. For example, for a QoS derivation, this when evaluating the condition. For example, for a QoS model, this object
object could represent the flow that is being conditioned. A set of could represent the flow that is being conditioned. A set of predefined
predefined variables that cover network attributes that are commonly used variables that cover network attributes commonly used for filtering is
for filtering is introduced here in PCIMe to encourage interoperability. introduced in PCIMe, to encourage interoperability. This list covers
This list covers layer 3 IP attributes such as IP network addresses, layer 3 IP attributes such as IP network addresses, protocols and ports,
protocols and ports, as well as a set of layer 2 attributes (e.g., MAC as well as a set of layer 2 attributes (e.g., MAC addresses).
addresses).
The PCIMe defines a single operator, "match", as explained in section
4.8.3.
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 "If the source IP address of the result. For example, in the condition "The source IP address of the flow
flow belongs to the 10.1.x.x subnet", a source IP address variable is belongs to the 10.1.x.x subnet", a source IP address variable is matched
matched against a 10.1.x.x subnet value. The operator specifies the type against a 10.1.x.x subnet value.
of relation between the variable and the value evaluated in the
condition.
4.8.2. Using Simple Policy Conditions 4.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 building
blocks for creating compound policy conditions. 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) is to equate the type of the friendliest, from a user point-of-view) way to do this is to equate the
value class with the name of the class. By ensuring that the ValueTypes type of the value class with the name of the class. By ensuring that the
property of the variable matches the name of the value class used, we ValueTypes property of the variable matches the name of the value class
know that the variable and value instance values are compatible with each used, we know that the variable and value instance values are compatible
other. 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 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 appropriate
ReusablePolicyContainer. 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 a <value>). The aggregation PolicyVariableInSimplePolicyCondition relates
SimplePolicyCondition to a single variable instance. Similarly, the a SimplePolicyCondition to a single variable instance. Similarly, the
aggregation PolicyValueInSimplePolicyCondition relates a aggregation PolicyValueInSimplePolicyCondition relates a
SimplePolicyCondition to a single value instance. Both aggregations are SimplePolicyCondition to a single value instance. Both aggregations are
defined in this document. defined in this document.
Figure 5 depicts a SimplePolicyCondition with its associated variable and Figure 6. depicts a SimplePolicyCondition with its associated variable
value. and value. Also shown are two PolicyValue instances that identify the
values that the variable can assume.
+-----------------------+ +-----------------------+
| SimplePolicyCondition | | SimplePolicyCondition |
+-----------------------+ +-----------------------+
* @ * @
* @ * @
+------------------+ * @ +---------------+ +------------------+ * @ +---------------+
| (PolicyVariable) |*** @@@| (PolicyValue) | | (PolicyVariable) |*** @@@| (PolicyValue) |
+------------------+ +---------------+ +------------------+ +---------------+
# # # #
# ooo # # ooo #
# # # #
+---------------+ +---------------+ +---------------+ +---------------+
| (PolicyValue) | ooo | (PolicyValue) | | (PolicyValue) | ooo | (PolicyValue) |
+---------------+ +---------------+ +---------------+ +---------------+
Aggregation Legend: Aggregation Legend:
**** PolicyVariableInSimplePolicyCondition **** PolicyVariableInSimplePolicyCondition
@@@@ PolicyValueInSimplePolicyCondition @@@@ PolicyValueInSimplePolicyCondition
#### PolicyValueConstraintInVariable #### ExpectedPolicyValuesForVariable
Figure 5. SimplePolicyCondition Figure 6. SimplePolicyCondition
Note: The class names in parenthesis denote subclasses. The named Note: The class names in parenthesis denote subclasses. The classes
classes in the figure are abstract and cannot, therefore, be named in the figure are abstract, and thus cannot themselves be
instantiated. instantiated.
4.8.3. The Simple Condition Operator 4.8.3. The Simple Condition Operator
A simple condition models an elementary Boolean expression conditional A simple condition models an elementary Boolean expression of the form
clause of the form "If variable MATCHes value". However, the formal "variable MATCHes value". However, the formal notation of the
notation of the SimplePolicyCondition, together with its associations, SimplePolicyCondition, together with its associations, models only a
models only a pair, {variable, value}. The "If" term and the "MATCH" pair, (<variable>, <value>). The 'MATCH' operator is not directly
operator are not directly modeled -- they are implied. The implied MATCH modeled -- it is implied. Furthermore, this implied 'MATCH' operator
operator carries an overloaded semantics. carries overloaded semantics.
For example, in the simple condition "If DestinationPort MATCH '80'" the For example, in the simple condition "DestinationPort MATCH '80'", the
interpretation of the MATCH operator is equality (the 'equal' operator). interpretation of the 'MATCH' operator is equality (the 'equal'
Clearly, a different interpretation is needed in the following cases: operator). Clearly, a different interpretation is needed in the
following cases:
o "If DestinationPort MATCH {'80', '8080'}" -- operator is 'IS SET o "DestinationPort MATCH {'80', '8080'}" -- operator is 'IS SET
MEMBER' MEMBER'
o "If DestinationPort MATCH {'1 to 255'}" -- operator is 'IN INTEGER o "DestinationPort MATCH {'1 to 255'}" -- operator is 'IN INTEGER
RANGE' RANGE'
o "If SourceIPAddress MATCH 'MyCompany.com'" -- operator is 'IP o "SourceIPAddress MATCH 'MyCompany.com'" -- operator is 'IP ADDRESS
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-dependant nature of
the interpretation of the MATCH operator. The interpretation depends on the 'MATCH' operator. The interpretation depends on the actual variable
the actual variable and value instances in the simple condition. The and value instances in the simple condition. The interpretation is
interpretation is always derived from the bound variable and the value always derived from the bound variable and the value instance associated
instance associated with the simple condition. Text accompanying the with the simple condition. Text accompanying the value class and
value class and implicit variable definition is used for interpreting the implicit variable definition is used for interpreting the semantics of
semantics of the MATCH relationship. In the following we define generic the 'MATCH' relationship. In the following list, we define generic
(type-independent) matching. (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 range
of values. The same equally holds for PolicyVariables. Basically, we of values. The same equally holds for PolicyVariables. Basically, we
have to deal with single values (singleton), ranges ([lower bound .. have to deal with single values (singleton), ranges ([lower bound ..
upper bound]), and sets (a,b,c). So independent of the variable and upper bound]), and sets (a,b,c). So independent of the variable and
value type, the following set of generic matching rules for the MATCH value type, the following set of generic matching rules for the 'MATCH'
operator are defined. 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
skipping to change at page 30, line 54 skipping to change at page 30, line 14
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 XXX). When not stated Variables may contain various types (section 5.11.1). When not stated
otherwise, the type of the value bound to the variable at condition otherwise, the type of the value bound to the variable at condition
evaluation time and the value type of the PolicyValue instance need to be evaluation time and the value type of the PolicyValue instance need to be
of the same type. If they differ the condition evaluates to FALSE. of the same type. If they differ, then the condition evaluates to FALSE.
Matching rules for value type specific matching see below. The ExpectedPolicyValuesForVariable association specifies an expected set
of values that can be matched with a variable within a simple condition.
Using this association, a source or destination port can be limited to
the range 0-200, a source or destination IP address can be limited to a
specified list of IPv4 address values, etc.
The PolicyValueConstraintInVariable association specifies additional +-----------------------+
constraints on the possible values and value types that can be matched | SimplePolicyCondition |
with a variable within a simple condition. Using this association, a +-----------------------+
source or destination port can be constrained to be matched against * @
integer values in the range 0-65535. A source or destination IP address * @
can be constrained to be matched against a specified list of IPv4 address * @
values, etc. In order to check whether a value X can be used with a +-----------------------------------+ +--------------------------+
variable A constrained by value Y, the following conformance test should | Name=SmallSourcePorts | | Name=Port300 |
be made. If all events for which the SimplePolicyCondition (A match X) | Class=PolicySourcePortVariable | | Class=PolicyIntegerValue |
evaluates to TRUE also evaluate to TRUE for the SimplePolicyCondition (A | ValueTypes=[PolicyIntegerVariable]| | IntegerList = [300] |
match Y), than X conforms to the constraint Y. If multiple values Y1, +-----------------------------------+ +--------------------------+
Y2, ..., Yn constrain a variable, then the conformance test involves #
checking against the condition (A match Y1) OR (A match Y2) OR ... OR (A #
match Yn). #
+-------------------------+
|Name=SmallPortsValues |
|Class=PolicyIntegerValue |
|IntegerList=[1..200] |
+-------------------------+
Aggregation Legend:
**** PolicyVariableInSimplePolicyCondition
@@@@ PolicyValueInSimplePolicyCondition
#### ExpectedPolicyValuesForVariable
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.
4.8.4. SimplePolicyActions 4.8.4. SimplePolicyActions
The SimplePolicyAction class models the elementary set operation. "SET The SimplePolicyAction class models the elementary set operation. "SET
<variable> TO <value>". The set operator MUST overwrite an old value of <variable> TO <value>". The set operator MUST overwrite an old value of
the variable. the variable. In the case where the variable to be updated is multi-
valued, the only update operation defined is a complete 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 the
IP packet header DSCP field. 'EF' is an integer or bit string value (6 IP packet header DSCP field. 'EF' is an integer or bit string value (6
bits). The complete interpretation of a simple action depends on the bits). The complete interpretation of a simple action depends on the
binding of the variable. Section [4.8.4] describes variables and their binding of the variable.
binding rules for conditions.
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 that has passed the variable specifies the attribute of an object. The value of this
condition by evaluating to true. This means the binding of the variable attribute is set to the value specified in <value>. Selection of the
is delayed until the condition evaluates to true for one or more objects. object is a function of the type of variable involved. See Sections
The value of the object's attribute is set to <value>. 4.8.6 and 4.8.7, respectively, for details on object selection for
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 building
blocks for creating CompoundPolicyActions. 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 specified
type of the value. Conversion of values from one representation into type of the value. Conversion of values from one representation into
another is not defined. E.g., a variable of IPv4Address type may not be another is not defined. For example, a variable of IPv4Address type may
set to a string containing a DNS name. Conversions are part of an not be set to a string containing a DNS name. Conversions are part of an
implementation-specific mapping of the model. implementation-specific mapping of the model.
As was the case with SimplePolicyConditions, the role of expected values
for the variables that appear in SimplePolicyActions is for validation,
prior to the time when an action is executed. Expected 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 appropriate
ReusablePolicyContainer. ReusablePolicyContainer.
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 a
SimplePolicyAction to a single variable instance. Similarly, the SimplePolicyAction to a single variable instance. Similarly, the
aggregation PolicyValueInSimplePolicyAction relates a SimplePolicyAction aggregation PolicyValueInSimplePolicyAction relates a SimplePolicyAction
to a single value instance. Both aggregations are defined in this to a single value instance. Both aggregations are defined in this
document. document.
Figure 6 depicts a SimplePolicyAction with its associated variable and Figure 8. depicts a SimplePolicyAction with its associated variable and
value. value.
+-----------------------+ +-----------------------+
| SimplePolicyAction | | SimplePolicyAction |
| | | |
+-----------------------+ +-----------------------+
* @ * @
* @ * @
+------------------+ * @ +---------------+ +------------------+ * @ +---------------+
| (PolicyVariable) |*** @@@| (PolicyValue) | | (PolicyVariable) |*** @@@| (PolicyValue) |
skipping to change at page 32, line 41 skipping to change at page 32, line 34
# # # #
# ooo # # ooo #
# # # #
+---------------+ +---------------+ +---------------+ +---------------+
| (PolicyValue) | ooo | (PolicyValue) | | (PolicyValue) | ooo | (PolicyValue) |
+---------------+ +---------------+ +---------------+ +---------------+
Aggregation Legend: Aggregation Legend:
**** PolicyVariableInSimplePolicyAction **** PolicyVariableInSimplePolicyAction
@@@@ PolicyValueInSimplePolicyAction @@@@ PolicyValueInSimplePolicyAction
#### PolicyValueConstraintInVariable #### ExpectedPolicyValuesForVariable
Figure 6. SimplePolicyAction Figure 8. SimplePolicyAction
4.8.5. Policy Variables 4.8.5. Policy Variables
A variable generically represents information that changes (or "varies"), A variable generically represents information that changes (or "varies"),
and that is set or evaluated by software. In policy, conditions and and that is set or evaluated by software. In policy, conditions and
actions can abstract information as "policy variables" to be evaluated in actions can abstract information as "policy variables" to be evaluated in
logical expressions, or set by actions. logical expressions, or set by actions.
PCIMe defines two types of PolicyVariables, a PolicyImplicitVariable and PCIMe defines two types of PolicyVariables, PolicyImplicitVariables and
a PolicyExplicitVariable. The semantic difference between these classes PolicyExplicitVariables. The semantic difference between these classes
is based on modeling context. Explicit variables are bound to exact is based on modeling context. Explicit variables are bound to exact
model constructs, while implicit variables are defined and evaluated model constructs, while implicit variables are defined and evaluated
outside of a model, in a more subjective context. For example, one can outside of a model. For example, one can imagine a PolicyCondition
imagine a PolicyCondition testing for a CIM ManagedSystemElement's Status testing whether a CIM ManagedSystemElement's Status property has the
property set to "Error." The Status property is an explicitly defined value "Error." The Status property is an explicitly defined
PolicyVariable (i.e., it is defined in the context of the CIM Schema and PolicyVariable (i.e., it is defined in the context of the CIM Schema, and
evaluated in the context of a specific instance). On the other hand, evaluated in the context of a specific instance). On the other hand,
network packets are not explicitly modeled or instantiated, since there network packets are not explicitly modeled or instantiated, since there
is no perceived value (at this time) in managing at the packet level. is no perceived value (at this time) in managing at the packet level.
Therefore, a PolicyCondition can make no explicit reference to a model Therefore, a PolicyCondition can make no explicit reference to a model
construct that represents a network packet's source address. In this construct that represents a network packet's source address. In this
case, an implicit PolicyVariable is defined to allow evaluation of a case, an implicit PolicyVariable is defined, to allow evaluation or
packet's source address. modification of a packet's source address.
4.8.6. Explicitly Bound Policy Variables 4.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 names
of the model construct to be evaluated or set. The CIM Schema defines of the model construct to be evaluated or set. The CIM Schema defines
and constrains "appropriate" values for the variable (i.e., model and constrains "appropriate" values for the variable (i.e., model
property) using data types and other information such as class/property property) using data types and other information such as class/property
qualifiers. qualifiers.
A PolicyExplicitVariable is "explicit" because its model semantics are A PolicyExplicitVariable is "explicit" because its model semantics are
exactly defined. It is NOT explicit due to an exact binding to a exactly defined. It is NOT explicit due to an exact binding to a
particular object. If PolicyExplicitVariable is only tied to instances particular object instance. If PolicyExplicitVariables were tied to
(either via association or by a object identification property in the instances (either via associations or by an object identification
class itself), then we are forcing element-specific rules. On the other property in the class itself), then we would be forcing element-specific
hand, if we only specify the object's model context (class and property rules. On the other hand, if we only specify the object's model context
name), but leave the binding to the policy framework (for example, using (class and property name), but leave the binding to the policy framework
policy roles), then greater flexibility results for either general or (for example, using policy roles), then greater flexibility results for
element-specific rules. 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/operator/value triplet) that defines, for example, CIM ((<variable>, <value>) pair) that defines CIM LogicalDevice
LogicalDevice DeviceID="12345". Alternately, if a PolicyRule's DeviceID="12345". Alternately, if a PolicyRule's PolicyRoles is "edge
PolicyRoles is "edge device" and your condition (variable/operator/value device" and the condition ((<variable>, <value>) pair) is Status="Error",
triplet) is Status="Error", then a general rule results for all edge then a general rule results for all edge devices in error.
devices in error.
Currently, the only binding for a PolicyExplicitVariable defined in PCIMe
is to the instances selected by policy roles. For each such instance, a
SimplePolicyCondition that aggregates the 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
ModelClass property, or of a subclass of this class.
o The instance selected has the property identified by the
variable's ModelProperty property.
o The value of this property in the instance matches the value
specified in the PolicyValue aggregated by the condition.
In all other cases, the SimplePolicyCondition evaluates to False.
For the case where a SimplePolicyAction aggregates a
PolicyExplicitVariable, the indicated property in the selected instance
is set to the value represented by the PolicyValue that the
SimplePolicyAction also aggregates. However, if the selected instance is
not of the class identified by the variable's ModelClass property, or of
a subclass of this class, then the action is not performed. In this case
the SimplePolicyAction is not treated either as a successfully executed
action (for the execution strategy Do Until Success) or as a failed
action (for the execution strategy Do Until Failure). Instead, the
remaining actions for the policy rule, if any, are executed as if this
SimplePolicyAction were not present at all in the list of actions
aggregated by the rule.
Explicit variables would be more powerful if they could reach beyond the
instances selected by policy roles, to related instances. However, to
represent a policy rule involving such variables in any kind of general
way requires something that starts to resemble very much a complete
policy language. Clearly such a language is outside the scope of PCIMe,
although it might be the subject of a future draft.
By restricting much of the generality, it would be possible for explicit
variables in PCIMe to reach slightly beyond a selected instance. For
example, if a selected instance were related to exactly one instance of
another class via a particular association class, and if the goal of the
policy rule were both to test a property of this related instance and to
set a property of that same instance, then it would be possible to
represent the condition and action of the rule using
PolicyExplicitVariables. Rather than handling this one specific case
with explicit variables, though, it was decided to lump them with the
more general case, and deal with them if and when a policy language is
defined.
Refer to Section 5.10 for the formal definition of the class Refer to Section 5.10 for the formal definition of the class
PolicyExplicitVariable. PolicyExplicitVariable.
4.8.7. Implicitly Bound Policy Variables 4.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 of a
variable. This determines how the variable is bound to a value in a variable. This determines how the variable is bound to a value in a
condition clause. Further instructions are provided for specifying data condition or an action. Further instructions are provided for specifying
type and/or value constraints for implicitly bound variables. data type and/or value constraints for implicitly bound variables.
Implicitly bound variables can be interpreted by different sub-models to
mean different things, depending on the particular context in which they
are used. For example, an implicitly bound variable named "SourceIP" may
be interpreted by a QoS policy information model to denote the source
address field in the IP header of a packet if a device is configured to
select certain packets for particular treatment. The same variable may
be bound to the sender address delivered by a RSVP PATH message for a
decision by a policy server. It is incumbent upon the particular domain-
specific information model to provide full and unambiguous interpretation
details (binding rules, type and value constraints) for the implicitly
bound variables it uses.
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 bound
variables introduced by PCIMe (and those that are introduced by domain- variables introduced by PCIMe (and those that are introduced by domain-
specific sub-models) MUST be derived from the PolicyImplicitVariable specific sub-models) MUST be derived from the PolicyImplicitVariable
class. The rationale for using this mechanism for modeling is explained class. The rationale for using this mechanism for modeling is explained
below in Section 4.8.9. below in Section 4.8.9.
A domain-specific policy information model that extends PCIMe may define A domain-specific policy information model that extends PCIMe may define
skipping to change at page 34, line 31 skipping to change at page 35, line 5
from the class PolicyImplicitVariable, or by further refining an existing from the class PolicyImplicitVariable, or by further refining an existing
variable class such as SourcePort. When refining a class such as variable class such as SourcePort. When refining a class such as
SourcePort, existing binding rules, type or value constraints may be SourcePort, existing binding rules, type or value constraints may be
narrowed. narrowed.
4.8.8. Structure and Usage of Pre-Defined Variables 4.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 depicts
the meaning of the variable. For example, a class defined to model the the meaning of the variable. For example, a class defined to model the
source port of a TCP/UDP flow SHOULD be named 'SourcePort'. 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 PolicyValueConstraintInVariable 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 the
SourcePort of incoming traffic. The ValueTypes property of an instance SourcePort of incoming traffic. The ValueTypes property of an instance
of this class will hold the class name PolicyIntegerValue. This by of this class will hold the class name PolicyIntegerValue. This by
itself constrains the data type of the SourcePort instance to be an itself constrains the data type of the SourcePort instance to be an
integer. However, we can further constrain the particular values that integer. However, we can further constrain the particular values that
the SourcePort variable can hold by entering valid ranges in the the SourcePort variable can hold by entering valid ranges in the
IntegerList property of the PolicyIntegerValue instance (0 - 65535 in IntegerList property of the PolicyIntegerValue instance (0 - 65535 in
this document). this document).
The combination of the VariableName and the The combination of the VariableName and the
PolicyValueConstraintInVariable 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 that
are used to form policy conditions. Since the are used to form policy conditions. Since the
PolicyValueConstraintInVariable association points to another class, any ExpectedPolicyValuesForVariable association points to a PolicyValue
of the properties in the PolicyValue class can be used to constrain instance, any of the values expressible in the PolicyValue class can be
values that the PolicyImplicitVariable can hold. For example: used to constrain values that the PolicyImplicitVariable can hold. 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 PolicyValueConstraintInVariable 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).
4.8.9. Rationale for Modeling Implicit Variables as Classes 4.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 implicitly including a single class with an enumerator for each individual
bound variable and an abstract class extended for each individual variable. implicitly bound variable and an abstract class extended for each
The reasons for using a class inheritance mechanism for specifying individual variable. The reasons for using a class inheritance mechanism
individual implicitly bound variables are these: 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
skipping to change at page 36, line 9 skipping to change at page 36, line 36
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 implemented, which the approach, it may be argued that data models derived from this
are mapped to this information model, may be more difficult to information model may be more difficult to optimize for
optimize for applications. This argument is rejected on the applications. This argument is rejected on the grounds that
grounds that application optimization is of lesser value for an application optimization is of lesser value for an information
information model than clarity and ease of extension. In model than clarity and ease of extension. In addition, it is hard
addition, it is hard to claim that the inheritance model places an to claim that the inheritance model places an absolute burden on
absolute burden on the optimization. For example, a data model the optimization. For example, a data model may still use
may still use enumeration to denote instances of pre-defined enumeration to denote instances of pre-defined variables and claim
variables and claim PCIMe compliance, as long as the data moel can PCIMe compliance, as long as the data model can be mapped
be mapped correctly to the definitions specified in this document. correctly to the definitions specified in this document.
Furthermore, the very nature of implicitly bound variables is to
be interpreted in context. This means that unless an additional
variable is required by a sub-model (in which case both approaches
result in some overhead), there's an upper limit on the class
explosion. After all, once properly documented, no need exists
for a sub-model to add a class definition. The implementation
needs only to cite and use the PCIMe variable, but impose the
documented context-dependent semantics.
4.8.10. Policy Values 4.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 constants
used in policy conditions. Different value types are derived from this used in policy conditions. Different value types are derived from this
class, to represent the various attributes required. Extensions of the class, to represent the various attributes required. Extensions of the
abstract class PolicyValue, defined in this document, provide a list of abstract class PolicyValue, defined in this document, provide a list of
values for representing basic network attributes. Values can be used to values for basic network attributes. Values can be used to represent
represent constants as named values. Named values can be kept in a constants as named values. Named values can be kept in a reusable policy
reusable policy container to be reused by multiple conditions. Examples container to be reused by multiple conditions. Examples of constants
of constants include well-known ports, well-known protocols, server include well-known ports, well-known protocols, server addresses, and
addresses, and other similar concepts. other similar concepts.
The PolicyValue subclasses define three basic types of values: scalars, The PolicyValue subclasses define three basic types of values: scalars,
ranges and sets. For example, a well-known port number could be defined ranges and sets. For example, a well-known port number could be defined
using the PolicyIntegerValue class, defining a single value (80 for using the PolicyIntegerValue class, defining a single value (80 for
HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively. HTTP), a range (80-88), or a set (80, 82, 8080) of ports, respectively.
For details, please see the class definition for each value type in For details, please see the class definition for each value type in
Section 5.12 of this document. Section 5.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.
skipping to change at page 37, line 17 skipping to change at page 37, line 37
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 5.14 of this document. Section 5.14 of this document.
4.9. Packet Filtering 4.9. Packet Filtering
PCIMe contains two mechanisms for representing packet filters. The more
general of these, termed here the domain-level model, expresses packet
filters in terms of policy variables and policy values. The other
mechanism, termed here the device-level model, expresses packet filters
in a way that maps more directly to the packet fields to which the
filters are being applied. While it is possible to map between these two
representations of packet filters, no mapping is provided in PCIMe
itself.
4.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 infrastructure,
PCIMe proposes a single mechanism for expressing packet filters in policy PCIMe proposes a single mechanism for expressing domain-level packet
conditions. This is being done in response to concerns that even though filters in policy conditions. This is being done in response to concerns
the initial "wave" of submodels derived from PCIM were all filtering on that even though the initial "wave" of submodels derived from PCIM were
IP packets, each was doing it in a slightly different way. PCIMe all filtering on IP packets, each was doing it in a slightly different
proposes a common way to express IP packet filters. The following figure way. PCIMe proposes a common way to express IP packet filters. The
illustrates how packet-filtering conditions are expressed in PCIMe. following figure illustrates 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 7. Packet Filtering in Policy Conditions Figure 9. Packet Filtering in Policy Conditions
In Figure 7, each SimplePolicyCondition represents a single field to be In Figure 9. , each SimplePolicyCondition represents a single field to be
filtered on: Source IP address, Destination IP address, Source port, etc. filtered on: Source IP address, Destination IP address, Source port, etc.
An additional SimplePolicyCondition indicates the direction that a packet An additional SimplePolicyCondition indicates the direction that a packet
is traveling on an interface: inbound or outbound. Because of the is traveling on an interface: inbound or outbound. Because of the
FlowDirection condition, care must be taken in aggregating a set of FlowDirection condition, care must be taken in aggregating a set of
SimplePolicyConditions into a CompoundFilterCondition. Otherwise, the SimplePolicyConditions into a CompoundFilterCondition. Otherwise, the
resulting CompoundPolicyCondition may match all inbound packets, or all 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 aggregated
by a CompoundFilterCondition. by a CompoundFilterCondition.
skipping to change at page 38, line 34 skipping to change at page 39, line 15
address = 9.1.1.1 and its Destination port = 80. 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.
4.9.2. Device-Level Packet Filters
At the device level, packet header filters are represented by two
subclasses of the abstract class FilterEntryBase: IPHeaderFilter and
8021Filter. Submodels of PCIMe may define other subclasses of
FilterEntryBase in addition to these two; ICIM [6], for example, defines
subclasses for IPsec-specific filters.
Instances of the subclasses of FilterEntryBase are not used directly as
filters. They are always aggregated into a FilterList, by the
aggregation EntriesInFilterList. For PCIMe and its submodels, the
EntrySequence property in this aggregation always takes its default value
'0', indicating that the aggregated filter entries are ANDed together.
The FilterList class includes an enumeration property Direction,
representing the direction of the traffic flow to which the FilterList is
to be applied. The value Mirrored(4) for Direction represents exactly
the same thing as the IsMirrored boolean does in CompoundFilterCondition.
See Section 4.9.1 for details.
5. Class Definitions 5. 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 the
overall Policy Core Information Model. overall Policy Core Information Model.
5.1. The Abstract Class "PolicySet" 5.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 structured
set of policies. set of policies.
skipping to change at page 39, line 22 skipping to change at page 40, line 24
TRUE. 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, however,
moved from the class Policy up to the superclass PolicySet. moved from the class Policy up to the superclass PolicySet.
5.2. Update PCIM's Class "PolicyGroup" 5.2. Update PCIM's Class "PolicyGroup"
The PolicyGroup class is modified to be 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)
5.3. Update PCIM's Class "PolicyRule" 5.3. Update PCIM's Class "PolicyRule"
The PolicyRule class is modified to be derived from PolicySet, and to The PolicyRule class is moved, so that it is now derived from PolicySet.
deprecate the use of Priority in the rule. PolicyRoles is now inherited The Priority property is also deprecated in PolicyRule, and PolicyRoles
from the parent class PolicySet. Finally, a new property is now inherited from the parent class PolicySet. Finally, a new
ExecutionStrategy is introduced, paralleling the property of the same property ExecutionStrategy is introduced, paralleling the property of the
name in the class CompoundPolicyAction. 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 rule.
DERIVED FROM PolicySet DERIVED FROM PolicySet
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Enabled PROPERTIES Enabled
ConditionListType ConditionListType
RuleUsage RuleUsage
Priority DEPRECATED FOR PolicySetComponent.Priority Priority DEPRECATED FOR PolicySetComponent.Priority
skipping to change at page 43, line 18 skipping to change at page 44, line 19
Do Until Success ū execute actions according to predefined order, until Do Until Success ū execute actions according to predefined order, until
successful execution of a single sub-action. 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. Continue
doing this, even if one or more of the sub-actions doing this, even if one or more of the sub-actions
fails. fails.
Do Until Failure - execute actions according to predefined order, until Do Until Failure - execute actions according to predefined order, until
the first failure in execution of a single sub- the first failure in execution of a single sub-
action. action.
The property definition is as follows: Since a CompoundPolicyAction may itself be aggregated either by a
PolicyRule or by another CompoundPolicyAction, its success or failure
will be an input to the aggregating entity's execution strategy.
Consequently, the following rules are specified, for determining whether
a CompoundPolicyAction succeeds or fails:
If the CompoundPolicyAction's ExecutionStrategy is Do Until Success,
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 all component actions succeed, then the CompoundPolicyAction
succeeds.
o If at least one component action fails, then the
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:
NAME ExecutionStrategy NAME ExecutionStrategy
DESCRIPTION An enumeration indicating how to interpret the action DESCRIPTION An enumeration indicating how to interpret the action
ordering for the actions aggregated by this 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)
5.9. The Abstract Class "PolicyVariable" 5.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 when
evaluating the condition. However, not every combination of a variable evaluating the condition. However, not every combination of a variable
and a value creates a meaningful condition. For example, a source IP and a value creates a meaningful condition. For example, a source IP
address variable can not be matched against a value that specifies a port address variable can not be matched against a value that specifies a port
number. A given variable selects the set of matchable value types. 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
skipping to change at page 43, line 43 skipping to change at page 45, line 19
and a value creates a meaningful condition. For example, a source IP and a value creates a meaningful condition. For example, a source IP
address variable can not be matched against a value that specifies a port address variable can not be matched against a value that specifies a port
number. A given variable selects the set of matchable value types. 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. For
example, a source-port variable limits the set of values to represent example, a source-port variable limits the set of values to represent
integers to the range of 0-65535. Integers outside this range cannot be integers to the range of 0-65535. Integers outside this range cannot be
matched to the source-port variable, even though they are of the correct matched to the source-port variable, even though they are of the correct
data type. Constraints for a given variable are indicated through the data type. Constraints for a given variable are indicated through the
PolicyValueConstraintInVariable association. ExpectedPolicyValuesForVariable association.
The PolicyVariable is an abstract class. Implicit and explicit context The PolicyVariable is an abstract class. Implicit and explicit context
variable classes are defined as sub classes of the PolicyVariable class. variable classes are defined as sub classes of the PolicyVariable class.
A set of implicit variables is defined in this document as well. 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
skipping to change at page 44, line 4 skipping to change at page 45, line 31
The PolicyVariable is an abstract class. Implicit and explicit context The PolicyVariable is an abstract class. Implicit and explicit context
variable classes are defined as sub classes of the PolicyVariable class. variable classes are defined as sub classes of the PolicyVariable class.
A set of implicit variables is defined in this document as well. 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)
5.10. The Class "PolicyExplicitVariable" 5.10. The Class "PolicyExplicitVariable"
Explicitly defined policy variables are evaluated within the context of Explicitly defined policy variables are evaluated within the context of
the CIM Schema and its modeling constructs. The PolicyExplicitVariable the CIM Schema and its modeling constructs. The PolicyExplicitVariable
class indicates the exact model property to be evaluated or manipulated. class indicates the exact model property to be evaluated or manipulated.
See Section 4.8.6 for a complete discussion of what happens when the
values of the ModelClass and ModelProperty properties in an instance of
this class do not 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
5.10.1. The Single-Valued Property "ModelClass" 5.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. The property is defined as evaluated or set as a PolicyVariable.
follows:
The property is defined as follows:
NAME ModelClass NAME ModelClass
SYNTAX String SYNTAX String
5.10.2. The Single-Valued Property ModelProperty 5.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 property
is defined as follows: is defined as follows:
skipping to change at page 45, line 21 skipping to change at page 47, line 4
as well as to ensure that the data type of the variable is of the correct as well as to ensure that the data type of the variable is of the correct
type. 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
5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe 5.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe
The following subclasses of PolicyImplicitVariable are defined in PCIMe. The following subclasses of PolicyImplicitVariable are defined in PCIMe.
5.12.1. The Class "PolicySourceIPv4Variable" 5.12.1. The Class "PolicySourceIPv4Variable"
NAME PolicySourceIPv4Variable NAME PolicySourceIPv4Variable
DESCRIPTION The source IPv4 address. of the outermost IP packet DESCRIPTION The source IPv4 address. of the outermost IP packet
header. 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: ALLOWED VALUE TYPES:
- PolicyIPv4AddrValue - PolicyIPv4AddrValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.2. The Class "PolicySourceIPv6Variable" 5.12.2. The Class "PolicySourceIPv6Variable"
NAME PolicySourceIPv6Variable NAME PolicySourceIPv6Variable
DESCRIPTION The source IPv6 address of the outermost IP packet DESCRIPTION The source IPv6 address of the outermost IP packet
header. 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: ALLOWED VALUE TYPES:
- PolicyIPv6AddrValue - PolicyIPv6AddrValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.3. The Class "PolicyDestinationIPv4Variable" 5.12.3. The Class "PolicyDestinationIPv4Variable"
NAME PolicyDestinationIPv4Variable NAME PolicyDestinationIPv4Variable
DESCRIPTION The destination IPv4 address of the outermost IP DESCRIPTION The destination IPv4 address of the outermost IP
packet header. 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: ALLOWED VALUE TYPES:
- PolicyIPv4AddrValue - PolicyIPv4AddrValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.4. The Class "PolicyDestinationIPv6Variable" 5.12.4. The Class "PolicyDestinationIPv6Variable"
NAME PolicyDestinationIPv6Variable NAME PolicyDestinationIPv6Variable
DESCRIPTION The destination IPv6 address of the outermost IP DESCRIPTION The destination IPv6 address of the outermost IP
packet header. 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: ALLOWED VALUE TYPES:
- PolicyIPv6AddrValue - PolicyIPv6AddrValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.5. The Class "PolicySourcePortVariable" 5.12.5. The Class "PolicySourcePortVariable"
NAME PolicySourcePortVariable NAME PolicySourcePortVariable
DESCRIPTION Ports are defined as the abstraction that transport DESCRIPTION Ports are defined as the abstraction that transport
protocols use to distinguish among multiple protocols use to distinguish among multiple
destinations within a given host computer. For TCP destinations within a given host computer. For TCP
and UDP flows, the PolicySourcePortVariable is and UDP flows, the PolicySourcePortVariable is
logically bound to the source port field of the logically bound to the source port field of the
outermost UDP or TCP packet header. 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: ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..65535) - PolicyIntegerValue (0..65535)
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.6. The Class "PolicyDestinationPortVariable" 5.12.6. The Class "PolicyDestinationPortVariable"
NAME PolicyDestinationPortVariable NAME PolicyDestinationPortVariable
DESCRIPTION Ports are defined as the abstraction that transport DESCRIPTION Ports are defined as the abstraction that transport
protocols use to distinguish among multiple protocols use to distinguish among multiple
destinations within a given host computer. For TCP destinations within a given host computer. For TCP
and UDP flows, the PolicyDestinationPortVariable is and UDP flows, the PolicyDestinationPortVariable is
logically bound to the destination port field of the logically bound to the destination port field of the
outermost UDP or TCP packet header. 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: ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..65535) - PolicyIntegerValue (0..65535)
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.7. The Class "PolicyIPProtocolVariable" 5.12.7. The Class "PolicyIPProtocolVariable"
NAME PolicyIPProtocolVariable NAME PolicyIPProtocolVariable
DESCRIPTION The IP protocol number. DESCRIPTION The IP protocol number.
ALLOWED VALUE TYPES: ALLOWED VALUE TYPES:
- PolicyIntegerValue - PolicyIntegerValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
skipping to change at page 48, line 4 skipping to change at page 49, line 50
PROPERTIES (none) PROPERTIES (none)
5.12.10. The Class "PolicyDSCPVariable" 5.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 - PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.11. The Class "PolicyFlowIdVariable" 5.12.11. The Class "PolicyFlowIdVariable"
NAME PolicyFlowIdVariable NAME PolicyFlowIdVariable
DESCRIPTION The flow identifer of the outermost IPv6 packet DESCRIPTION The flow identifer of the outermost IPv6 packet
header. 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: ALLOWED VALUE TYPES:
- PolicyIntegerValue - PolicyIntegerValue
- PolicyBitStringValue - PolicyBitStringValue
DERIVED FROM PolicyImplicitVariable DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.12.12. The Class "PolicySourceMACVariable" 5.12.12. The Class "PolicySourceMACVariable"
skipping to change at page 57, line 30 skipping to change at page 59, line 30
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 AdminDomain.
It does, however, participate in a number of unique It does, however, participate in a number of unique
associations. associations.
DERIVED FROM AdminDomain DERIVED FROM AdminDomain
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES (none) PROPERTIES (none)
5.18. The Abstract Class "FilterEntryBase"
FilterEntryBase is the abstract base class from which all filter entry
classes are derived. It serves as the endpoint for the
EntriesInFilterList aggregation, which groups filter entries into 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:
NAME FilterEntryBase
DESCRIPTION An abstract class representing a single
filter that is aggregated into a
FilterList via the aggregation
EntriesInFilterList.
DERIVED FROM LogicalElement
TYPE Abstract
PROPERTIES IsNegated
5.19. The Class "IPHeaderFilter"
This concrete class makes it possible to represent an entire IP header
filter in a single object. A property IpVersion identifies whether the
IP addresses in an instance are IPv4 or IPv6 addresses. (Since the
source and destination IP addresses come from the same packet header,
they will always be of the same type.)
The class definition is as follows:
NAME IPHeaderFilter
DESCRIPTION A class representing an entire IP
header filter, or any subset of one.
DERIVED FROM FilterEntryBase
TYPE Concrete
PROPERTIES IpVersion, SrcAddress, SrcMask,
DestAddress, DestMask, ProtocolID,
SrcPortStart, SrcPortEnd,
DestPortStart, DestPortEnd, DSCP,
FlowLabel
5.19.1. The Property IpVersion
This property is an 8-bit unsigned integer, identifying the version of
the IP addresses to be filtered on. IP versions are identified as they
are in the Version field of the IP packet header - IPv4 = 4, 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 four properties SrcAddress, SrcMask, DestAddress, and DestMask, as
follows:
o IPv4: OctetString(SIZE (4))
o IPv6: OctetString(SIZE (16|20)), depending on whether a scope
identifier is present
5.19.2. The Property SrcAddress
This property is an OctetString, of a size determined by the value of the
IpVersion property, representing a source IP address. This value is
compared to the source address in the IP header, subject to the mask
represented in the SrcMask property.
5.19.3. The Property SrcMask
This property is an OctetString, of a size determined by the value of the
IpVersion property, representing a mask to be used in comparing the
source address in the IP header with the value represented in the
SrcAddress property.
5.19.4. The Property DestAddress
This property is an OctetString, of a size determined by the value of the
IpVersion property, representing a destination IP address. This value is
compared to the destination address in the IP header, subject to the mask
represented in the DestMask property.
5.19.5. The Property DestMask
This property is an OctetString, of a size determined by the value of the
IpVersion property, representing a mask to be used in comparing the
destination address in the IP header with the value represented in the
DestAddress property.
5.19.6. The Property ProtocolID
This property is an 8-bit unsigned integer, representing an IP protocol
type. This value is compared to the Protocol field in the IP header.
5.19.7. The Property SrcPortStart
This property is a 16-bit unsigned integer, representing the lower end of
a range of UDP or TCP source ports. The upper end of the range is
represented by the SrcPortEnd property. The value of SrcPortStart MUST
be no greater than the value of SrcPortEnd. A single port is indicated
by equal values for SrcPortStart and SrcPortEnd.
A source port filter is evaluated by testing whether the source port
identified in the IP header falls within the range of values between
SrcPortStart and SrcPortEnd, including these two end points.
5.19.8. The Property SrcPortEnd
This property is a 16-bit unsigned integer, representing the upper end of
a range of UDP or TCP source ports. The lower end of the range is
represented by the SrcPortStart property. The value of SrcPortEnd MUST
be no less than the value of SrcPortStart. A single port is indicated by
equal values for SrcPortStart and SrcPortEnd.
A source port filter is evaluated by testing whether the source port
identified in the IP header falls within the range of values between
SrcPortStart and SrcPortEnd, including these two end points.
5.19.9. The Property DestPortStart
This property is a 16-bit unsigned integer, representing the lower end of
a range of UDP or TCP destination ports. The upper end of the range is
represented by the DestPortEnd property. The value of DestPortStart MUST
be no greater than the value of DestPortEnd. A single port is indicated
by equal values for DestPortStart and DestPortEnd.
A destination port filter is evaluated by testing whether the destination
port identified in the IP header falls within the range of values between
DestPortStart and DestPortEnd, including these two end points.
5.19.10. The Property DestPortEnd
This property is a 16-bit unsigned integer, representing the upper end of
a range of UDP or TCP destination ports. The lower end of the range is
represented by the DestPortStart property. The value of DestPortEnd MUST
be no less than the value of DestPortStart. A single port is indicated
by equal values for DestPortStart and DestPortEnd.
A destination port filter is evaluated by testing whether the destination
port identified in the IP header falls within the range of values between
DestPortStart and DestPortEnd, including these two end points.
5.19.11. The Property DSCP
The property DSCP is defined as a uint8, restricted to the range 0..63.
Since DSCPs are defined as discrete code points, with no inherent
structure, there is no semantically significant relationship between
different DSCPs. Consequently, there is no provision for specifying a
range of DSCPs in this property.
5.19.12. The Property FlowLabel
The 20-bit Flow Label field in the IPv6 header may be used by a source to
label sequences of packets for which it requests special handling by IPv6
devices, such as non-default quality of service or 'real-time' service.
This property is an octet string of size 3 (that is, 24 bits), in which
the 20-bit Flow Label appears in the rightmost 20 bits, padded on the
left with b'0000'.
5.20. The Class "8021Filter"
This concrete class allows 802.1.source and destination MAC addresses, as
well as the 802.1 protocol ID, priority, and VLAN identifier fields, to
be expressed in a single object
The class definition is as follows:
NAME 8021Filter
DESCRIPTION A class that allows 802.1 source
and destination MAC address and
protocol ID, priority, and VLAN
identifier filters to be
expressed in a single object.
DERIVED FROM FilterEntryBase
TYPE Concrete
PROPERTIES SrcMACAddr, SrcMACMask, DestMACAddr,
DestMACMask, ProtocolID, PriorityValue,
VLANID
5.20.1. The Property SrcMACAddr
This property is an OctetString of size 6, representing a 48-bit source
MAC address in canonical format. This value is compared to the
SourceAddress field in the MAC header, subject to the mask represented in
the SrcMACMask property.
5.20.2. The Property SrcMACMask
This property is an OctetString of size 6, representing a 48-bit mask to
be used in comparing the SourceAddress field in the MAC header with the
value represented in the SrcMACAddr property.
5.20.3. The Property DestMACAddr
This property is an OctetString of size 6, representing a 48-bit
destination MAC address in canonical format. This value is compared to
the DestinationAddress field in the MAC header, subject to the mask
represented in the DestMACMask property.
5.20.4. The Property DestMACMask
This property is an OctetString of size 6, representing a 48-bit mask to
be used in comparing the DestinationAddress field in the MAC header with
the value represented in the DestMACAddr property.
5.20.5. The Property ProtocolID
This property is a 16-bit unsigned integer, representing an Ethernet
protocol type. This value is compared to the Ethernet Type field in the
802.3 MAC header.
5.20.6. The Property PriorityValue
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
header. Since the 802.1Q Priority field consists of 3 bits, the values
for this property are limited to the range 0..7.
5.20.7. The Property VLANID
This property is a 32-bit unsigned integer, representing an 802.1Q VLAN
Identifier. This value is compared to the VLAN ID field in the 802.1Q
header. Since the 802.1Q VLAN ID field consists of 12 bits, the values
for this property are limited to the range 0..4095.
5.21. The Class FilterList
This is a concrete class that aggregates instances of (subclasses of)
FilterEntryBase via the aggregation EntriesInFilterList. It is possible
to aggregate different types of filters into a single FilterList - for
example, packet header filters (represented by the IPHeaderFilter class)
and security filters (represented by subclasses of FilterEntryBase
defined by IPsec).
The aggregation property EntriesInFilterList.EntrySequence serves to
order the filter entries in a FilterList. This is necessary when
algorithms such as "Match First" are used to identify traffic based on an
aggregated set of FilterEntries. In modeling QoS classifiers, however,
this property is always set to 0, to indicate that the aggregated filter
entries are ANDed together to form a selector for a class of traffic.
The class definition is as follows:
NAME FilterList
DESCRIPTION A concrete class representing
the aggregation of multiple filters.
DERIVED FROM LogicalElement
TYPE Concrete
PROPERTIES Direction
5.21.1. The Property Direction
This property is a 16-bit unsigned integer enumeration, representing the
direction of the traffic flow to which the FilterList is to be applied.
Defined enumeration values are
o NotApplicable(0)
o Input(1)
o Output(2)
o Both(3) - This value is used to indicate that the direction is
immaterial, e.g., to filter on a source subnet regardless of
whether the flow is inbound or outbound
o Mirrored(4) - This value is also applicable to both inbound and
outbound flow processing, but it indicates that the filter criteria
are applied asymmetrically to traffic in both directions and, thus,
specifies the reversal of source and destination criteria (as
opposed to the equality of these criteria as indicated by "Both").
The match conditions in the aggregated FilterEntryBase subclass
instances are defined from the perspective of outbound flows and
applied to inbound flows as well by reversing the source and
destination criteria. So, for example, consider a FilterList with
3 filter entries indicating destination port = 80, and source and
destination addresses of a and b, respectively. Then, for the
outbound direction, the filter entries match as specified and the
'mirror' (for the inbound direction) matches on source port = 80
and source and destination addresses of b and a, respectively.
6. Association and Aggregation Definitions 6. 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 the
overall Policy Core Information Model. overall Policy Core Information Model.
6.1. The Aggregation "PolicySetComponent" 6.1. The Aggregation "PolicySetComponent"
PolicySetComponent is a new aggregation class that collects instances of PolicySetComponent is a new aggregation class that collects instances of
PolicySet subclasses (PolicyGroups and PolicyRules) into coherent sets of PolicySet subclasses (PolicyGroups and PolicyRules) into coherent sets of
skipping to change at page 60, line 38 skipping to change at page 67, line 50
scope of exactly one System. 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 within
the scope of a System. Note that for any single instance of the the scope of a System. Note that for any single instance of the
association class PolicyRuleInSystem, this property (like all Reference association class PolicyRuleInSystem, this property (like all Reference
properties) is single-valued. The [0..n] cardinality indicates that a properties) is single-valued. The [0..n] cardinality indicates that a
given System may have 0, 1, or more than one PolicyRules defined within given System may have 0, 1, or more than one PolicyRules defined within
its scope. its scope.
6.7. The Abstract Aggregation "CompoundedPolicyCondition" 6.7. The Abstract Aggregation "PolicyConditionStructure"
NAME CompoundedPolicyCondition NAME PolicyConditionStructure
DESCRIPTION A class representing the aggregation of DESCRIPTION A class representing the aggregation of
PolicyConditions by an aggregating instance. PolicyConditions by an aggregating instance.
DERIVED FROM PolicyComponent DERIVED FROM PolicyComponent
ABSTRACT TRUE ABSTRACT TRUE
PROPERTIES PartComponent[ref PolicyCondition[0..n]] PROPERTIES PartComponent[ref PolicyCondition[0..n]]
GroupNumber GroupNumber
ConditionNegated ConditionNegated
6.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule" 6.8. Update PCIM's Aggregation "PolicyConditionInPolicyRule"
The PCIM aggregation "PolicyConditionInPolicyRule" is updated, to make it The PCIM aggregation "PolicyConditionInPolicyRule" is updated, to make it
a subclass of the new abstract aggregation CompoundedPolicyCondition. a subclass of the new abstract aggregation PolicyConditionStructure. The
The properties GroupNumber and ConditionNegated are now inherited, rather properties GroupNumber and ConditionNegated are now inherited, rather
than specified explicitly as they were in PCIM. 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 CompoundedPolicyCondition DERIVED FROM PolicyConditionStructure
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyRule[0..n]] PROPERTIES GroupComponent[ref PolicyRule[0..n]]
6.9. The Aggregation "PolicyConditionInPolicyCondition" 6.9. The Aggregation "PolicyConditionInPolicyCondition"
A second subclass of CompoundedPolicyCondition is defined, representing A second subclass of PolicyConditionStructure is defined, representing
the compounding of policy conditions into a higher-level policy the compounding of policy conditions into a higher-level policy
condition. 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 CompoundedPolicyCondition DERIVED FROM PolicyConditionStructure
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref CompoundPolicyCondition[0..n]] PROPERTIES GroupComponent[ref CompoundPolicyCondition[0..n]]
6.10. The Abstract Aggregation "CompoundedPolicyAction" 6.10. The Abstract Aggregation "PolicyActionStructure"
NAME CompoundedPolicyAction NAME PolicyActionStructure
DESCRIPTION A class representing the aggregation of PolicyActions DESCRIPTION A class representing the aggregation of PolicyActions
by an aggregating instance. 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
PCIM [3].
6.11. Update PCIM's Aggregation "PolicyActionInPolicyRule" 6.11. Update PCIM's Aggregation "PolicyActionInPolicyRule"
The PCIM aggregation "PolicyActionInPolicyRule" is updated, to make it a The PCIM aggregation "PolicyActionInPolicyRule" is updated, to make it a
subclass of the new abstract aggregation CompoundedPolicyAction. The subclass of the new abstract aggregation PolicyActionStructure. The
property ActionOrder is now inherited, rather than specified explicitly property ActionOrder is now inherited, rather than specified explicitly
as it was in PCIM. as it was in PCIM.
NAME PolicyActionInPolicyRule NAME PolicyActionInPolicyRule
DESCRIPTION A class representing the aggregation of PolicyActions DESCRIPTION A class representing the aggregation of PolicyActions
by a PolicyRule. by a PolicyRule.
DERIVED FROM CompoundedPolicyAction DERIVED FROM PolicyActionStructure
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyRule[0..n]] PROPERTIES GroupComponent[ref PolicyRule[0..n]]
6.12. The Aggregation "PolicyActionInPolicyAction" 6.12. The Aggregation "PolicyActionInPolicyAction"
A second subclass of CompoundedPolicyAction is defined, representing the A second subclass of PolicyActionStructure is defined, representing the
compounding of policy actions into a higher-level policy action. 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 PolicyActions
by another PolicyAction. by another PolicyAction.
DERIVED FROM CompoundedPolicyAction DERIVED FROM PolicyActionStructure
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref CompoundPolicyAction[0..n]] PROPERTIES GroupComponent[ref CompoundPolicyAction[0..n]]
6.13. The Aggregation "PolicyVariableInSimplePolicyCondition" 6.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 {variable,
operator, value}. This aggregation provides the linkage between a operator, value}. This aggregation provides the linkage between a
SimplePolicyCondition instance and a single PolicyVariable. The SimplePolicyCondition instance and a single PolicyVariable. The
aggregation PolicyValueInSimplePolicyCondition links the aggregation PolicyValueInSimplePolicyCondition links the
SimplePolicyCondition to a single PolicyValue. The Operator property of SimplePolicyCondition to a single PolicyValue. The Operator property of
skipping to change at page 65, line 31 skipping to change at page 72, line 46
NAME PolicyActionInPolicyRepository NAME PolicyActionInPolicyRepository
DEPRECATED FOR ReusablePolicy DEPRECATED FOR ReusablePolicy
DESCRIPTION A class representing the inclusion of a reusable DESCRIPTION A class representing the inclusion of a reusable
PolicyAction in a PolicyRepository. PolicyAction in a PolicyRepository.
DERIVED FROM PolicyInSystem DERIVED FROM PolicyInSystem
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Antecedent[ref PolicyRepository[0..1]] PROPERTIES Antecedent[ref PolicyRepository[0..1]]
Dependent[ref PolicyAction[0..n]] Dependent[ref PolicyAction[0..n]]
6.20. The Association PolicyValueConstraintInVariable 6.20. The Association ExpectedPolicyValuesForVariable
This association links a PolicyValue object to a PolicyVariable object, This association links a PolicyValue object to a PolicyVariable object,
modeling specific value constraints. Using this association, a variable modeling the set of expected values for that PolicyVariable. Using this
(instance) may be constrained to be bound-to/assigned only a set of association, a variable (instance) may be constrained to be bound-
allowed values. For example, modeling an enumerated source port to/assigned only a set of allowed values. For example, modeling an
variable, one creates an instance of the PolicySourcePortVariable class enumerated source port variable, one creates an instance of the
and associates it with the set of values (integers) representing the PolicySourcePortVariable class and associates with it the set of values
allowed enumeration, using appropriate number of instances of the (integers) representing the allowed enumeration, using appropriate number
PolicyValueConstraintInVariable association. of instances of the ExpectedPolicyValuesForVariable association.
Note that a single variable instance may be constrained by any number of Note that a single variable instance may be constrained by any number of
values and a single value may be used to constrain any number of values, and a single value may be used to constrain any number of
variables. These relationships are manifested by the n-to-m cardinality variables. These relationships are manifested by the n-to-m cardinality
of the association. of the association.
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 4.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 PolicyValueConstraintInVariable NAME ExpectedPolicyValuesForVariable
DESCRIPTION A class representing the association of a constraints DESCRIPTION A class representing the association of a set of
object 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 type
and cardinality are overridden to provide the semantics of a variable and cardinality are overridden to provide the semantics of a variable
optionally having value constraints. The [0..n] cardinality indicates optionally having value constraints. The [0..n] cardinality indicates
that any number of variables may be constrained by a given value. that any number of variables may be constrained by a given value.
The reference property "Dependent" is inherited from Dependency, and The reference property "Dependent" is inherited from Dependency, and
overridden to become an object reference to a PolicyValue that is used to overridden to become an object reference to a PolicyValue representing
constrain the values that a particular PolicyVariable can have. The the values that a particular PolicyVariable can have. The [0..n]
[0..n] cardinality indicates that a given policy variable may have 0, 1 cardinality indicates that a given policy variable may have 0, 1 or more
or more than one PolicyValues defined to model the constraints on the than one PolicyValues defined to model the set(s) of values that the
values that the policy variable can take. policy variable can take.
6.21. The Aggregation "PolicyContainerInPolicyContainer" 6.21. The Aggregation "PolicyContainerInPolicyContainer"
The aggregation PolicyContainerInPolicyContainer provides for nesting of The aggregation PolicyContainerInPolicyContainer provides for nesting of
one ReusablePolicyContainer inside another one. one ReusablePolicyContainer inside another one.
NAME PolicyContainerInPolicyContainer NAME PolicyContainerInPolicyContainer
DESCRIPTION A class representing the aggregation of DESCRIPTION A class representing the aggregation of
ReusablePolicyContainers by a higher-level ReusablePolicyContainers by a higher-level
ReusablePolicyContainer. ReusablePolicyContainer.
skipping to change at page 66, line 41 skipping to change at page 74, line 15
NAME PolicyRepositoryInPolicyRepository NAME PolicyRepositoryInPolicyRepository
DEPRECATED FOR PolicyContainerInPolicyContainer DEPRECATED FOR PolicyContainerInPolicyContainer
DESCRIPTION A class representing the aggregation of DESCRIPTION A class representing the aggregation of
PolicyRepositories by a higher-level PolicyRepository. PolicyRepositories by a higher-level PolicyRepository.
DERIVED FROM SystemComponent DERIVED FROM SystemComponent
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES GroupComponent[ref PolicyRepository[0..n]] PROPERTIES GroupComponent[ref PolicyRepository[0..n]]
PartComponent[ref PolicyRepository[0..n]] PartComponent[ref PolicyRepository[0..n]]
6.23. The Aggregation "ElementInPolicyRoleCollection" 6.23. The Aggregation "EntriesInFilterList"
This aggregation is a specialization of the Component aggregation; it is
used to define a set of filter entries (subclasses of FilterEntryBase)
that are aggregated by a FilterList.
The cardinalities of the aggregation itself are 0..1 on the FilterList
end, and 0..n on the FilterEntryBase end. Thus in the general case, a
filter entry can exist without being aggregated into any FilterList.
However, the only way a filter entry can figure in the PCIMe model is by
being aggregated into a FilterList by this aggregation.
The class definition for the aggregation is as follows:
NAME EntriesInFilterList
DESCRIPTION An aggregation used to define a set of
filter entries (subclasses of
FilterEntryBase) that are aggregated by
a particular FilterList.
DERIVED FROM Component
ABSTRACT False
PROPERTIES GroupComponent[ref
FilterList[0..1]],
PartComponent[ref
FilterEntryBase[0..n],
EntrySequence
6.23.1. The Reference GroupComponent
This property is overridden in this aggregation to represent an object
reference to a FilterList object (instead of to the more generic
ManagedSystemElement object defined in its superclass). It also
restricts the cardinality of the aggregate to 0..1 (instead of the more
generic 0-or-more), representing the fact that a filter entry always
exists within the context of at most one FilterList.
6.23.2. The Reference PartComponent
This property is overridden in this aggregation to represent an object
reference to a FilterEntryBase object (instead of to the more generic
ManagedSystemElement object defined in its superclass). This object
represents a single filter entry, which may be aggregated with other
filter entries to form the FilterList.
6.23.3. The Property EntrySequence
An unsigned 16-bit integer indicating the order of the filter entry
relative to all others in the FilterList. The default value '0'
indicates that order is not significant, because the entries in this
FilterList are ANDed together.
6.24. The Aggregation "ElementInPolicyRoleCollection"
The following aggregation is used to associate ManagedElements with a The following aggregation is used to associate ManagedElements with a
PolicyRoleCollection object that represents a role played by these PolicyRoleCollection object that represents a role played by these
ManagedElements. ManagedElements.
NAME ElementInPolicyRoleCollection NAME ElementInPolicyRoleCollection
DESCRIPTION A class representing the inclusion of a ManagedElement DESCRIPTION A class representing the inclusion of a ManagedElement
in a collection, specified as having a given role. in a collection, specified as having a given role.
All the managed elements in the collection share the All the managed elements in the collection share the
same role. same role.
DERIVED FROM MemberOfCollection DERIVED FROM MemberOfCollection
ABSTRACT FALSE ABSTRACT FALSE
PROPERTIES Collection[ref PolicyRoleCollection [0..n]] PROPERTIES Collection[ref PolicyRoleCollection [0..n]]
Member[ref ManagedElement [0..n]] Member[ref ManagedElement [0..n]]
6.24. The Weak Association "PolicyRoleCollectionInSystem" 6.25. The Weak Association "PolicyRoleCollectionInSystem"
A PolicyRoleCollection is defined within the scope of a System. This A PolicyRoleCollection is defined within the scope of a System. This
association links a PolicyRoleCollection to the System in whose scope it association links a PolicyRoleCollection to the System in whose scope it
is defined. is defined.
When associating a PolicyRoleCollection with a System, this should be When associating a PolicyRoleCollection with a System, this should be
done consistently with the system that scopes the policy rules/groups done consistently with the system that scopes the policy rules/groups
that are applied to the resources in that collection. A that are applied to the resources in that collection. A
PolicyRoleCollection is associated with the same system as the applicable PolicyRoleCollection is associated with the same system as the applicable
PolicyRules and/or PolicyGroups, or to a System higher in the tree formed PolicyRules and/or PolicyGroups, or to a System higher in the tree formed
skipping to change at page 68, line 43 skipping to change at page 77, line 18
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF [2] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF
Standards Process", BCP 11, RFC 2028, October 1996. Standards Process", BCP 11, RFC 2028, October 1996.
[3] Strassner, J., and E. Ellesson, B. Moore, A. Westerinen, "Policy Core [3] Strassner, J., and E. Ellesson, B. Moore, A. Westerinen, "Policy Core
Information Model -- Version 1 Specification", RFC 3060, February Information Model -- Version 1 Specification", RFC 3060, February
2001. 2001.
[4] Distributed Management Task Force, Inc., "DMTF Technologies: CIM [4] Distributed Management Task Force, Inc., "DMTF Technologies: CIM
Standards ū CIM Schema: Version 2.5", available via links on the Standards ū CIM Schema: Version 2.5", available at
following DMTF web page: http://www.dmtf.org/spec/cim_schema_v25.html. http://www.dmtf.org/standards/cim_schema_v25.php.
[5] Snir, Y., and Y. Ramberg, J. Strassner, R. Cohen, "Policy Framework [5] Snir, Y., and Y. Ramberg, J. Strassner, R. Cohen, "Policy QoS
QoS Information Model", work in progress, draft-ietf-policy-qos-info- Information Model", work in progress, draft-ietf-policy-qos-info-
model-02.txt, November 2000. model-04.txt, July 2001.
[6] Jason, J., and L. Rafalow, E. Vyncke, "IPsec Configuration Policy [6] Jason, J., and L. Rafalow, E. Vyncke, "IPsec Configuration Policy
Model", work in progress, draft-ietf-ipsp-config-policy-model-02.txt, Model", work in progress, draft-ietf-ipsp-config-policy-model-03.txt,
March 2001. July 2001.
[7] Chadha, R., and M. Brunner, M. Yoshida, J. Quittek, G. Mykoniatis, A. [7] Chadha, R., and M. Brunner, M. Yoshida, J. Quittek, G. Mykoniatis, A.
Poylisher, R. Vaidyanathan, A. Kind, F. Reichmeyer, "Policy Framework Poylisher, R. Vaidyanathan, A. Kind, F. Reichmeyer, "Policy Framework
MPLS Information Model for QoS and TE", work in progress, draft- MPLS Information Model for QoS and TE", work in progress, draft-
chadha-policy-mpls-te-01.txt, December 2000. chadha-policy-mpls-te-01.txt, December 2000.
[8] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: [8] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications:
ABNF", RFC 2234, November 1997. ABNF", RFC 2234, November 1997.
[9] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", [9] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC
RFC1035, November 1987. 1035, November 1987.
[10] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", [10] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC
RFC2373, July 1998. 2373, July 1998.
[11] M. Wahl, A. Coulbeck, "Lightweight Directory Access Protocol (v3): [11] M. Wahl, A. Coulbeck, "Lightweight Directory Access Protocol (v3):
Attribute Syntax Definitions", RFC 2252. Attribute Syntax Definitions", RFC 2252.
[12] A. Westerinen, et al., "Policy Terminology", <draft-ietf-policy- [12] A. Westerinen, et al., "Terminology for Policy-Based Management",
terminology-01.txt>, November 2000. <draft-ietf-policy-terminology-04.txt>, July 2001.
[13] S. Waldbusser, and J. Saperia, T. Hongal, "Policy Based Management [13] S. Waldbusser, and J. Saperia, T. Hongal, "Policy Based Management
MIB", <draft-ietf-snmpconf-pm-04.txt>, November 2000. MIB", <draft-ietf-snmpconf-pm-06.txt>, June 2001.
[14] B. Moore, and D. Durham, J. Halpern, J. Strassner, A. Westerinen, W.
Weiss, "Information Model for Describing Network Device QoS Datapath
Mechanisms", <draft-ietf-policy-qos-device-info-model-05.txt>, July
2001.
11. Authors' Addresses 11. Authors' Addresses
Bob Moore Bob Moore
IBM Corporation, BRQA/502 IBM Corporation, BRQA/502
4205 S. Miami Blvd. 4205 S. Miami Blvd.
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
Phone: +1 919-254-4436 Phone: +1 919-254-4436
Fax: +1 919-254-6243 Fax: +1 919-254-6243
E-mail: remoore@us.ibm.com E-mail: remoore@us.ibm.com
skipping to change at page 70, line 10 skipping to change at page 78, line 39
E-mail: yramberg@cisco.com E-mail: yramberg@cisco.com
Yoram Snir Yoram Snir
Cisco Systems Cisco Systems
4 Maskit Street 4 Maskit Street
Herzliya Pituach, Israel 46766 Herzliya Pituach, Israel 46766
Phone: +972-9-970-0085 Phone: +972-9-970-0085
Fax: +972-9-970-0366 Fax: +972-9-970-0366
E-mail: ysnir@cisco.com E-mail: ysnir@cisco.com
John Strassner
Cisco Systems
Building 20
725 Alder Drive
Milpitas, CA 95035
Phone: +1-408-527-1069
Fax: +1-408-527-2477
E-mail: johns@cisco.com
Andrea Westerinen Andrea Westerinen
Cisco Systems Cisco Systems
Building 20 Building 20
725 Alder Drive 725 Alder Drive
Milpitas, CA 95035 Milpitas, CA 95035
Phone: +1-408-853-8294 Phone: +1-408-853-8294
Fax: +1-408-527-6351 Fax: +1-408-527-6351
E-mail: andreaw@cisco.com E-mail: andreaw@cisco.com
Ritu Chadha Ritu Chadha
skipping to change at page 70, line 52 skipping to change at page 79, line 19
Phone: +49 (0)6221 9051129 Phone: +49 (0)6221 9051129
Fax: +49 (0)6221 9051155 Fax: +49 (0)6221 9051155
E-mail: brunner@ccrle.nec.de E-mail: brunner@ccrle.nec.de
Ron Cohen Ron Cohen
Ntear LLC Ntear LLC
Phone: Phone:
Fax: Fax:
E-mail: ronc@ntear.com E-mail: ronc@ntear.com
John Strassner
INTELLIDEN, Inc.
90 South Cascade Avenue
Colorado Springs, CO 80903
Phone: +1-719-785-0648
E-mail: john.strassner@intelliden.com
12. Full Copyright Statement 12. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
skipping to change at page 71, line 28 skipping to change at page 80, line 5
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
13. Appendix A: Open Issues 13. Appendix A: Closed Issues
The PCIMe authors do not all agree with everything included in the -00 EDITOR'S NOTE: The following list captures the major technical issues
draft of the document. Input is solicited from the working group as a that were resolved during the course of progressing PCIMe from initial
whole on the following open issues: draft to Proposed Standard. This appendix will be removed for submission
to the RFC Editor (unless there is a consensus to preserve it in the
RFC), but it should be archived somewhere.
1. Unrestricted use of DNF/CNF for CompoundPolicyConditions. 1. Unrestricted use of DNF/CNF for CompoundPolicyConditions.
Alternative: for the conditions aggregated by a Alternative: for the conditions aggregated by a
CompoundPolicyCondition, allow only ANDing, with negation of CompoundPolicyCondition, allow only ANDing, with negation of
individual conditions. Note that this is sufficient to build individual conditions. Note that this is sufficient to build
multi-field packet filters from single-field multi-field packet filters from single-field
SimplePolicyConditions. SimplePolicyConditions.
RESOLUTION: The same DNF/CNF capabilities present for aggregating RESOLUTION: The same DNF/CNF capabilities present for aggregating
PolicyConditions into a PolicyRule have been retained for PolicyConditions into a PolicyRule have been retained for
aggregating PolicyConditions into a CompoundPolicyCondition. aggregating PolicyConditions into a CompoundPolicyCondition.
2. For a PolicyVariable in a SimplePolicyCondition, restrict the set 2. For a PolicyVariable in a SimplePolicyCondition, restrict the set
of possible values both via associated PolicyValue objects (tied of possible values both via associated PolicyValue objects (tied
in with the PolicyValueConstraintInVariable association) and via in with the ExpectedPolicyValuesForVariable association) and via
the ValueTypes property in the PolicyVariable class. Alternative: the ValueTypes property in the PolicyVariable class. Alternative:
restrict values only via associated PolicyValue objects. restrict values only via associated PolicyValue objects.
RESOLUTION: PCIMe continues to allow both mechanisms for RESOLUTION: PCIMe continues to allow both mechanisms for
restricting the values of a PolicyVariable. restricting the values of a PolicyVariable.
3. Transactional semantics, including rollback, for the 3. Transactional semantics, including rollback, for the
ExecutionStrategy property in PolicyRule and in ExecutionStrategy property in PolicyRule and in
CompoundPolicyAction. Alternative: have only 'Do until success' CompoundPolicyAction. Alternative: have only 'Do until success'
and 'Do all'. and 'Do all'.
skipping to change at page 73, line 46 skipping to change at page 82, line 24
RESOLUTION: Each subclass of PolicyImplicitVariable will identify RESOLUTION: Each subclass of PolicyImplicitVariable will identify
the exact source of the variable data. For example, there will be the exact source of the variable data. For example, there will be
a subclass of PolicyImplicitVariable that specifically identifies a subclass of PolicyImplicitVariable that specifically identifies
the IPv4 source address in the outermost packet header. IPv4 and the IPv4 source address in the outermost packet header. IPv4 and
IPv6 addresses will require separate subclasses of IPv6 addresses will require separate subclasses of
PolicyImplicitVariable. We understand the downside of this PolicyImplicitVariable. We understand the downside of this
approach: a potential explosion in the number of subclasses of approach: a potential explosion in the number of subclasses of
PolicyImplicitVariable. PolicyImplicitVariable.
ALTERNATIVE: At this time the authors are still discussing an
alternative approach, in which variable types would be represented
by enumerated values rather than by separate subclasses of
PolicyImplicitVariable. This approach can greatly reduce the
number of classes in the model, but it introduces an IANA
dependency for managing the enumerated values.
11. Clarify PolicyExplicitVariables. 11. Clarify PolicyExplicitVariables.
NON-RESOLUTION: This issue is still not resolved at all. The NON-RESOLUTION (in PCIMe-01): This issue is still not resolved at
authors continue to believe that we need the capability of all. The authors continue to believe that we need the capability
indicating that a condition should compare against (or an action of indicating that a condition should compare against (or an
should set) a particular property in a particular object instance. action should set) a particular property in a particular object
But we do not believe that the current mechanism of specifying a instance. But we do not believe that the current mechanism of
target object class and property name is sufficient. For the next specifying a target object class and property name is sufficient.
version of PCIMe, we need to either find a way to make this work For the next version of PCIMe, we need to either find a way to
in general; or find a way to make it work in some cases, and then make this work in general; or find a way to make it work in some
describe clearly what these cases are; or remove cases, and then describe clearly what these cases are; or remove
PolicyExplicitVariables from PCIMe entirely. PolicyExplicitVariables from PCIMe entirely.
RESOLUTION (in PCIMe-02): From the list of choices above, we took
the path of making explicit variables work in a specific case, and
indicating clearly that they work only in this case. See section
4.8.6
 End of changes. 179 change blocks. 
666 lines changed or deleted 1088 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/