Network Working Group B. Moore, Ed.
Request for Comments: 3460 IBM
Updates: 3060 January 2003
Category: Standards Track
Policy Core Information Model (PCIM) Extensions
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document specifies a number of changes to the Policy Core
Information Model (PCIM, RFC3060). Two types of changes are
included. First, several completely new elements are introdUCed, for
example, classes for header filtering, that extend PCIM into areas
that it did not previously cover. Second, there are cases where
elements of PCIM (for example, policy rule priorities) are
deprecated, and replacement elements are defined (in this case,
priorities tied to associations that refer to policy rules). Both
types of changes are done in such a way that, to the extent possible,
interoperability with implementations of the original PCIM model is
preserved. This document updates RFC3060.
Table of Contents
1. Introduction....................................................5
2. Changes since RFC3060..........................................5
3. Overview of the Changes.........................................6
3.1. How to Change an Information Model.........................6
3.2. List of Changes to the Model...............................6
3.2.1. Changes to PolicyRepository.........................6
3.2.2. Additional Associations and Additional Reusable
Elements............................................7
3.2.3. Priorities and Decision Strategies..................7
3.2.4. Policy Roles........................................8
3.2.5. CompoundPolicyConditions and
CompoundPolicyActions...............................8
3.2.6. Variables and Values................................9
3.2.7. Domain-Level Packet Filtering.......................9
3.2.8. Device-Level Packet Filtering.......................9
4. The Updated Class and Association Class Hierarchies............10
5. Areas of Extension to PCIM.....................................13
5.1. Policy Scope..............................................13
5.1.1. Levels of Abstraction: Domain- and Device-Level
Policies...........................................13
5.1.2. Administrative and Functional Scopes...............14
5.2. Reusable Policy Elements..................................15
5.3. Policy Sets...............................................16
5.4. Nested Policy Rules.......................................16
5.4.1. Usage Rules for Nested Rules.......................17
5.4.2. Motivation.........................................17
5.5. Priorities and Decision Strategies........................18
5.5.1. Structuring Decision Strategies....................19
5.5.2. Side Effects.......................................21
5.5.3. Multiple PolicySet Trees For a Resource............21
5.5.4. Deterministic Decisions............................22
5.6. Policy Roles..............................................23
5.6.1. Comparison of Roles in PCIM with Roles in
snmpconf...........................................23
5.6.2. Addition of PolicyRoleCollection to PCIMe..........24
5.6.3. Roles for PolicyGroups.............................25
5.7. Compound Policy Conditions and Compound Policy Actions....27
5.7.1. Compound Policy Conditions.........................27
5.7.2. Compound Policy Actions............................27
5.8. Variables and Values......................................28
5.8.1. Simple Policy Conditions...........................29
5.8.2. Using Simple Policy Conditions.....................29
5.8.3. The Simple Condition Operator......................31
5.8.4. SimplePolicyActions................................33
5.8.5. Policy Variables...................................35
5.8.6. EXPlicitly Bound Policy Variables..................36
5.8.7. Implicitly Bound Policy Variables..................37
5.8.8. Structure and Usage of Pre-Defined Variables.......38
5.8.9. Rationale for Modeling Implicit Variables
as Classes.........................................39
5.8.10. Policy Values.....................................40
5.9. Packet Filtering..........................................41
5.9.1. Domain-Level Packet Filters........................41
5.9.2. Device-Level Packet Filters........................42
5.10. Conformance to PCIM and PCIMe............................43
6. Class Definitions..............................................44
6.1. The Abstract Class "PolicySet"............................44
6.2. Update PCIM"s Class "PolicyGroup".........................45
6.3. Update PCIM"s Class "PolicyRule"..........................45
6.4. The Class "SimplePolicyCondition".........................46
6.5. The Class "CompoundPolicyCondition".......................47
6.6. The Class "CompoundFilterCondition".......................47
6.7. The Class "SimplePolicyAction"............................48
6.8. The Class "CompoundPolicyAction"..........................48
6.9. The Abstract Class "PolicyVariable".......................50
6.10. The Class "PolicyExplicitVariable".......................50
6.10.1. The Single-Valued Property "ModelClass"...........51
6.10.2. The Single-Valued Property ModelProperty..........51
6.11. The Abstract Class "PolicyImplicitVariable"..............51
6.11.1. The Multi-Valued Property "ValueTypes"............52
6.12. Subclasses of "PolicyImplicitVariable" Specified
in PCIMe.................................................52
6.12.1. The Class "PolicySourceIPv4Variable"..............52
6.12.2. The Class "PolicySourceIPv6Variable"..............52
6.12.3. The Class "PolicyDestinationIPv4Variable".........53
6.12.4. The Class "PolicyDestinationIPv6Variable".........53
6.12.5. The Class "PolicySourcePortVariable"..............54
6.12.6. The Class "PolicyDestinationPortVariable".........54
6.12.7. The Class "PolicyIPProtocolVariable"..............54
6.12.8. The Class "PolicyIPVersionVariable"...............55
6.12.9. The Class "PolicyIPToSVariable"...................55
6.12.10. The Class "PolicyDSCPVariable"...................55
6.12.11. The Class "PolicyFlowIdVariable".................56
6.12.12. The Class "PolicySourceMACVariable"..............56
6.12.13. The Class "PolicyDestinationMACVariable".........56
6.12.14. The Class "PolicyVLANVariable"...................56
6.12.15. The Class "PolicyCoSVariable"....................57
6.12.16. The Class "PolicyEthertypeVariable"..............57
6.12.17. The Class "PolicySourceSAPVariable"..............57
6.12.18. The Class "PolicyDestinationSAPVariable".........58
6.12.19. The Class "PolicySNAPOUIVariable"................58
6.12.20. The Class "PolicySNAPTypeVariable"...............59
6.12.21. The Class "PolicyFlowDirectionVariable"..........59
6.13. The Abstract Class "PolicyValue".........................59
6.14. Subclasses of "PolicyValue" Specified in PCIMe...........60
6.14.1. The Class "PolicyIPv4AddrValue"...................60
6.14.2. The Class "PolicyIPv6AddrValue....................61
6.14.3. The Class "PolicyMACAddrValue"....................62
6.14.4. The Class "PolicyStringValue".....................63
6.14.5. The Class "PolicyBitStringValue"..................63
6.14.6. The Class "PolicyIntegerValue"....................64
6.14.7. The Class "PolicyBooleanValue"....................65
6.15. The Class "PolicyRoleCollection".........................65
6.15.1. The Single-Valued Property "PolicyRole"...........66
6.16. The Class "ReusablePolicyContainer".................66
6.17. Deprecate PCIM"s Class "PolicyRepository"................66
6.18. The Abstract Class "FilterEntryBase".....................67
6.19. The Class "IpHeadersFilter"..............................67
6.19.1. The Property HdrIpVersion.........................68
6.19.2. The Property HdrSrcAddress........................68
6.19.3. The Property HdrSrcAddressEndOfRange..............68
6.19.4. The Property HdrSrcMask...........................69
6.19.5. The Property HdrDestAddress.......................69
6.19.6. The Property HdrDestAddressEndOfRange.............69
6.19.7. The Property HdrDestMask..........................70
6.19.8. The Property HdrProtocolID........................70
6.19.9. The Property HdrSrcPortStart......................70
6.19.10. The Property HdrSrcPortEnd.......................70
6.19.11. The Property HdrDestPortStart....................71
6.19.12. The Property HdrDestPortEnd......................71
6.19.13. The Property HdrDSCP.............................72
6.19.14. The Property HdrFlowLabel.................... ...72
6.20. The Class "8021Filter"...................................72
6.20.1. The Property 8021HdrSrcMACAddr....................73
6.20.2. The Property 8021HdrSrcMACMask....................73
6.20.3. The Property 8021HdrDestMACAddr...................73
6.20.4. The Property 8021HdrDestMACMask...................73
6.20.5. The Property 8021HdrProtocolID....................74
6.20.6. The Property 8021HdrPriorityValue.................74
6.20.7. The Property 8021HdrVLANID........................74
6.21. The Class FilterList.....................................74
6.21.1. The Property Direction............................75
7. Association and Aggregation Definitions........................75
7.1. The Aggregation "PolicySetComponent"......................75
7.2. Deprecate PCIM"s Aggregation "PolicyGroupInPolicyGroup"...76
7.3. Deprecate PCIM"s Aggregation "PolicyRuleInPolicyGroup"....76
7.4. The Abstract Association "PolicySetInSystem"..............77
7.5. Update PCIM"s Weak Association "PolicyGroupInSystem"......77
7.6. Update PCIM"s Weak Association "PolicyRuleInSystem".......78
7.7. The Abstract Aggregation "PolicyConditionStructure".......79
7.8. Update PCIM"s Aggregation "PolicyConditionInPolicyRule"...79
7.9. The Aggregation "PolicyConditionInPolicyCondition"........79
7.10. The Abstract Aggregation "PolicyActionStructure".........80
7.11. Update PCIM"s Aggregation "PolicyActionInPolicyRule".....80
7.12. The Aggregation "PolicyActionInPolicyAction".............80
7.13. The Aggregation "PolicyVariableInSimplePolicyCondition"..80
7.14. The Aggregation "PolicyValueInSimplePolicyCondition".....81
7.15. The Aggregation "PolicyVariableInSimplePolicyAction".....82
7.16. The Aggregation "PolicyValueInSimplePolicyAction"........83
7.17. The Association "ReusablePolicy".........................83
7.18. Deprecate PCIM"s "PolicyConditionInPolicyRepository".....84
7.19. Deprecate PCIM"s "PolicyActionInPolicyRepository"........84
7.20. The Association ExpectedPolicyValuesForVariable..........84
7.21. The Aggregation "ContainedDomain"........................85
7.22. Deprecate PCIM"s "PolicyRepositoryInPolicyRepository"....86
7.23. The Aggregation "EntriesInFilterList"....................86
7.23.1. The Reference GroupComponent......................86
7.23.2. The Reference PartComponent.......................87
7.23.3. The Property EntrySequence........................87
7.24. The Aggregation "ElementInPolicyRoleCollection"..........87
7.25. The Weak Association "PolicyRoleCollectionInSystem"......87
8. Intellectual Property..........................................88
9. Acknowledgements..............................................89
10. Contributors..................................................89
11. Security Considerations.......................................91
12. Normative References..........................................91
13. Informative References........................................91
Author"s Address..................................................92
Full Copyright Statement..........................................93
1. Introduction
This document specifies a number of changes to the Policy Core
Information Model (PCIM), RFC3060 [1]. Two types of changes are
included. First, several completely new elements are introduced, for
example, classes for header filtering, that extend PCIM into areas
that it did not previously cover. Second, there are cases where
elements of PCIM (for example, policy rule priorities) are
deprecated, and replacement elements are defined (in this case,
priorities tied to associations that refer to policy rules). Both
types of changes are done in such a way that, to the extent possible,
interoperability with implementations of the original PCIM model is
preserved.
The key Words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC2119 [8].
2. Changes since RFC3060
Section 3.2 contains a short discussion of the changes that this
document makes to the RFC3060 information model. Here is a very
brief list of the changes:
1. Deprecate and replace PolicyRepository and its associations.
2. Clarify and expand the ways that PolicyRules and PolicyGroups are
aggregated.
3. Change how prioritization for PolicyRules is represented, and
introduce administrator-specified decision strategies for rule
evaluation.
4. Expand the role of PolicyRoles, and introduce a means of
associating a PolicyRole with a resource.
5. Introduce compound policy conditions and compound policy actions
into the model.
6. Introduce variables and values into the model.
7. Introduce variable and value subclasses for packet-header
filtering.
8. Introduce classes for device-level packet-header filtering.
3. Overview of the Changes
3.1. How to Change an Information Model
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 for specifying IETF information models such as PCIM, it is
reasonable to look to the CIM specifications for guidance on how to
modify and extend the model. Among the CIM rules for changing an
information model are the following. Note that everything said here
about "classes" applies to association classes (including
aggregations) as well as to non- association classes.
o Properties may be added to existing classes.
o Classes, and individual properties, may be marked as DEPRECATED.
If there is a replacement feature for the deprecated class or
property, it is identified explicitly. Otherwise the notation "No
value" is used. In this document, the notation "DEPRECATED FOR
<feature-name>" is used to indicate that a feature has been
deprecated, and to identify its replacement feature.
o Classes may be inserted into the inheritance hierarchy above
existing classes, and properties from the existing classes may
then be "pulled up" into the new classes. The net effect is that
the existing classes have exactly the same properties they had
before, but the properties are inherited rather than defined
explicitly in the classes.
o New subclasses may be defined below existing classes.
3.2. List of Changes to the Model
The following subsections provide a very brief overview of the
changes to PCIM defined in PCIMe. In several cases, the origin of
the change is noted, as QPIM [11], ICPM [12], or QDDIM [15].
3.2.1. Changes to PolicyRepository
Because of the potential for confusion with the Policy Framework
component Policy Repository (from the four-box picture: Policy
Management Tool, Policy Repository, PDP, PEP), "PolicyRepository" is
a bad name for the PCIM class representing a container of reusable
policy elements. Thus the class PolicyRepository is being replaced
with the class ReusablePolicyContainer. To accomplish this change,
it is necessary to deprecate the PCIM class PolicyRepository and its
three associations, and replace them with a new class
ReusablePolicyContainer and new associations. As a separate change,
the associations for ReusablePolicyContainer are being broadened, to
allow a ReusablePolicyContainer to contain any reusable policy
elements. In PCIM, the only associations defined for a
PolicyRepository were for it to contain reusable policy conditions
and policy actions.
3.2.2. Additional Associations and Additional Reusable Elements
The PolicyRuleInPolicyRule and PolicyGroupInPolicyRule aggregations
have, in effect, been imported from QPIM. ("In effect" because these
two aggregations, as well as PCIM"s two aggregations
PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup, are all being
combined into a single aggregation PolicySetComponent.) These
aggregations make it possible to define larger "chunks" of reusable
policy to place in a ReusablePolicyContainer. These aggregations
also introduce new semantics representing the contextual implications
of having one PolicyRule executing within the scope of another
PolicyRule.
3.2.3. Priorities and Decision Strategies
Drawing from both QPIM and ICPM, the Priority property has been
deprecated in PolicyRule, and placed instead on the aggregation
PolicySetComponent. The QPIM rules for resolving relative priorities
across nested PolicyGroups and PolicyRules have been incorporated
into PCIMe as well. With the removal of the Priority property from
PolicyRule, a new modeling dependency is introduced. In order to
prioritize a PolicyRule/PolicyGroup relative to other
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
conflicts, the PCIM restriction stating that priorities are relevant
only in the case of conflicts is being removed. In its place, a
PolicyDecisionStrategy property has been added to the PolicyGroup and
PolicyRule classes. This property allows policy administrator to
select one of two behaviors with respect to rule evaluation: either
perform the actions for all PolicyRules whose conditions evaluate to
TRUE, or perform the actions only for the highest-priority PolicyRule
whose conditions evaluate to TRUE. (This is accomplished by placing
the PolicyDecisionStrategy property in an abstract class PolicySet,
from which PolicyGroup and PolicyRule are derived.) The QPIM rules
for applying decision strategies to a nested set of PolicyGroups and
PolicyRules have also been imported.
3.2.4. Policy Roles
The concept of policy roles is added to PolicyGroups (being present
already in the PolicyRule class). This is accomplished via a new
superclass for both PolicyRules and PolicyGroups - PolicySet. For
nested PolicyRules and PolicyGroups, any roles associated with the
outer rule or group are automatically "inherited" by the nested one.
Additional roles may be added at the level of a nested rule or group.
It was also observed that there is no mechanism in PCIM for assigning
roles to resources. For example, while it is possible in PCIM to
associate a PolicyRule with the role "FrameRelay&&WAN", there is no
way to indicate which interfaces match this criterion. A new
PolicyRoleCollection class has been defined in PCIMe, representing
the collection of resources associated with a particular role. The
linkage between a PolicyRule or PolicyGroup and a set of resources is
then represented by an instance of PolicyRoleCollection. Equivalent
values should be defined in the PolicyRoles property of PolicyRules
and PolicyGroups, and in the PolicyRole property in
PolicyRoleCollection.
3.2.5. CompoundPolicyConditions and CompoundPolicyActions
The concept of a CompoundPolicyCondition has also been imported into
PCIMe from QPIM, and broadened to include a parallel
CompoundPolicyAction. In both cases the idea is to create reusable
"chunks" of policy that can exist as named elements in a
ReusablePolicyContainer. The "Compound" classes and their
associations incorporate the condition and action semantics that PCIM
defined at the PolicyRule level: DNF/CNF for conditions, and ordering
for actions.
Compound conditions and actions are defined to work with any
component conditions and actions. In other words, while the
components may be instances, respectively, of SimplePolicyCondition
and SimplePolicyAction (discussed immediately below), they need not
be.
3.2.6. Variables and Values
The SimplePolicyCondition / PolicyVariable / PolicyValue structure
has 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 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
structure is also defined. While the semantics of a
SimplePolicyCondition are "variable matches value", a
SimplePolicyAction has the semantics "set variable to value".
3.2.7. Domain-Level Packet Filtering
For packet filtering specified at the domain level, a set of
PolicyVariables and PolicyValues are defined, corresponding to the
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 header fields will be expressed in terms of
CompoundPolicyConditions built up from SimplePolicyConditions that
use these variables and values. An additional PolicyVariable,
PacketDirection, is also defined, to indicate whether a packet being
filtered is traveling inbound or outbound on an interface.
3.2.8. Device-Level Packet Filtering
For packet filtering expressed at the device level, including the
packet classifier filters modeled in QDDIM, the variables and values
discussed in Section 3.2.7 need not be used. Filter classes derived
from the CIM 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-related headers (IP, UDP, and
TCP) and the 802 MAC headers are defined, respectively, in Sections
6.19 and 6.20.
4. The Updated Class and Association Class Hierarchies
The following figure shows the class inheritance hierarchy for PCIMe.
Changes from the PCIM hierarchy are noted parenthetically.
ManagedElement (abstract)

+--Policy (abstract)

+---PolicySet (abstract -- new - 5.3)

+---PolicyGroup (moved - 5.3)

+---PolicyRule (moved - 5.3)

+---PolicyCondition (abstract)

+---PolicyTimePeriodCondition

+---VendorPolicyCondition

+---SimplePolicyCondition (new - 5.8.1)

+---CompoundPolicyCondition (new - 5.7.1)

+---CompoundFilterCondition (new - 5.9)

+---PolicyAction (abstract)

+---VendorPolicyAction

+---SimplePolicyAction (new - 5.8.4)

+---CompoundPolicyAction (new - 5.7.2)

+---PolicyVariable (abstract -- new - 5.8.5)

+---PolicyExplicitVariable (new - 5.8.6)

+---PolicyImplicitVariable (abstract -- new - 5.8.7)

+---(suBTree of more specific classes -- new - 6.12)

+---PolicyValue (abstract -- new - 5.8.10)

+---(subtree of more specific classes -- new - 6.14)

+--Collection (abstract -- newly referenced)

+--PolicyRoleCollection (new - 5.6.2)
ManagedElement(abstract)

+--ManagedSystemElement (abstract)

+--LogicalElement (abstract)

+--System (abstract)

+--AdminDomain (abstract)

+---ReusablePolicyContainer (new - 5.2)

+---PolicyRepository (deprecated - 5.2)

+--FilterEntryBase (abstract -- new - 6.18)

+--IpHeadersFilter (new - 6.19)

+--8021Filter (new - 6.20)

+--FilterList (new - 6.21)
Figure 1. Class Inheritance Hierarchy for PCIMe
The following figure shows the association class hierarchy for PCIMe.
As before, changes from PCIM are noted parenthetically.
[unrooted]

+---PolicyComponent (abstract)

+---PolicySetComponent (new - 5.3)

+---PolicyGroupInPolicyGroup (deprecated - 5.3)

+---PolicyRuleInPolicyGroup (deprecated - 5.3)

+---PolicyConditionStructure (abstract -- new - 5.7.1)

+---PolicyConditionInPolicyRule (moved - 5.7.1)

+---PolicyConditionInPolicyCondition (new - 5.7.1)

+---PolicyRuleValidityPeriod

+---PolicyActionStructure (abstract -- new - 5.7.2)

+---PolicyActionInPolicyRule (moved - 5.7.2)

+---PolicyActionInPolicyAction (new - 5.7.2)

+---PolicyVariableInSimplePolicyCondition (new - 5.8.2)

+---PolicyValueInSimplePolicyCondition (new - 5.8.2)

+---PolicyVariableInSimplePolicyAction (new - 5.8.4)

+---PolicyValueInSimplePolicyAction (new - 5.8.4)
[unrooted]

+---Dependency (abstract)

+---PolicyInSystem (abstract)

+---PolicySetInSystem (abstract, new - 5.3)

+---PolicyGroupInSystem

+---PolicyRuleInSystem

+---ReusablePolicy (new - 5.2)

+---PolicyConditionInPolicyRepository (deprecated - 5.2)

+---PolicyActionInPolicyRepository (deprecated - 5.2)

+---ExpectedPolicyValuesForVariable (new - 5.8)

+---PolicyRoleCollectionInSystem (new - 5.6.2)

+---Component (abstract)

+---SystemComponent

+---ContainedDomain (new - 5.2)

+---PolicyRepositoryInPolicyRepository (deprecated - 5.2)

+---EntriesInFilterList (new - 7.23)

+---MemberOfCollection (newly referenced)

+--- ElementInPolicyRoleCollection (new - 5.6.2)
Figure 2. Association Class Inheritance Hierarchy for PCIMe
In addition to these changes that show up at the class and
association class level, there are other changes from PCIM involving
individual class properties. In some cases new properties are
introduced into existing classes, and in other cases existing
properties are deprecated (without deprecating the classes that
contain them).
5. Areas of Extension to PCIM
The following subsections describe each of the areas for which PCIM
extensions are being defined.
5.1. Policy Scope
Policy scopes may be thought of in two dimensions: 1) the level of
abstraction of the policy specification and 2) the applicability of
policies to a set of managed resources.
5.1.1. Levels of Abstraction: Domain- and Device-Level Policies
Policies vary in level of abstraction, from the business-level
expression of service level agreements (SLAs) to the specification of
a set of rules that apply to devices in a network. Those latter
policies can, themselves, be classified into at least two groups:
those policies consumed by a Policy Decision Point (PDP) that specify
the rules for an administrative and functional domain, and those
policies consumed by a Policy Enforcement Point (PEP) that specify
the device-specific rules for a functional domain. The higher-level
rules consumed by a PDP, called domain-level policies, may have late
binding variables unspecified, or specified by a classification,
whereas the device-level rules are likely to have fewer unresolved
bindings.
There is a relationship between these levels of policy specification
that is out of scope for this standards effort, but that is necessary
in the development and deployment of a usable policy-based
configuration system. An SLA-level policy transformation to the
domain-level policy may be thought of as analogous to a visual
builder that takes human input and develops a programmatic rule
specification. The relationship between the domain-level policy and
the device-level policy may be thought of as analogous to that of a
compiler and linkage editor that translates the rules into specific
instructions that can be executed on a specific type of platform.
PCIM and PCIMe may be used to specify rules at any and all of these
levels of abstraction. However, at different levels of abstraction,
different mechanisms may be more or less appropriate.
5.1.2. Administrative and Functional Scopes
Administrative scopes for policy are represented in PCIM and in these
extensions to PCIM as System subclass instances. Typically, a
domain-level policy would be scoped by an AdminDomain instance (or by
a hierarchy of AdminDomain instances) whereas a device-level policy
might be scoped by a System instance that represents the PEP (e.g.,
an instance of ComputerSystem, see CIM [2]). In addition to
collecting policies into an administrative domain, these System
classes may also aggregate the resources to which the policies apply.
Functional scopes (sometimes referred to as functional domains) are
generally defined by the submodels derived from PCIM and PCIMe, and
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, or Diffserv and Intserv may each be thought of as functional
scopes. These scoping decisions are represented by the structure of
the submodels derived from PCIM and PCIMe, and may be reflected in
the number and types of PEP policy client(s), services, and the
interaction between policies. Policies in different functional
scopes are organized into disjoint sets of policy rules. Different
functional domains may share some roles, some conditions, and even
some actions. The rules from different functional domains may even
be enforced at the same managed resource, but for the purposes of
policy evaluation they are separate. See section 5.5.3 for more
information.
The functional scopes MAY be reflected in administrative scopes.
That is, deployments of policy may have different administrative
scopes for different functional scopes, but there is no requirement
to do so.
5.2. Reusable Policy Elements
In PCIM, a distinction was drawn between reusable PolicyConditions
and PolicyActions and rule-specific ones. The PolicyRepository class
was also defined, to serve as a container for these reusable
elements. The name "PolicyRepository" has proven to be an
unfortunate choice for the class that serves as a container for
reusable policy elements. This term is already used in documents
like the Policy Framework, to denote the location from which the PDP
retrieves all policy specifications, and into which the Policy
Management Tool places all policy specifications. Consequently, the
PolicyRepository class is being deprecated, in favor of a new class
ReusablePolicyContainer.
When a class is deprecated, any associations that refer to it must
also be deprecated. So replacements are needed for the two
associations PolicyConditionInPolicyRepository and
PolicyActionInPolicyRepository, as well as for the aggregation
PolicyRepositoryInPolicyRepository. In addition to renaming the
PolicyRepository class to ReusablePolicyContainer, however, PCIMe is
also broadening the types of policy elements that can be reusable.
Consequently, rather than providing one-for-one replacements for the
two associations, a single higher-level association ReusablePolicy is
defined. This new association allows any policy element (that is, an
instance of any subclass of the abstract class Policy) to be placed
in a ReusablePolicyContainer.
Summarizing, the following changes in Sections 6 and 7 are the result
of this item:
o The class ReusablePolicyContainer is defined.
o PCIM"s PolicyRepository class is deprecated.
o The association ReusablePolicy is defined.
o PCIM"s PolicyConditionInPolicyRepository association is
deprecated.
o PCIM"s PolicyActionInPolicyRepository association is deprecated.
o The aggregation ContainedDomain is defined.
o PCIM"s PolicyRepositoryInPolicyRepository aggregation is
deprecated.
5.3. Policy Sets
A "policy" can be thought of as a coherent set of rules to
administer, manage, and control Access to network resources ("Policy
Terminology", reference [10]). The structuring of these coherent
sets of rules into subsets is enhanced in this document. In Section
5.4, we discuss the new options for the nesting of policy rules.
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 the inheritance hierarchy above both PolicyGroup and
PolicyRule. This reflects the additional structural flexibility and
semantic capability of both subclasses.
Two properties are defined in PolicySet: PolicyDecisionStrategy and
PolicyRoles. The PolicyDecisionStrategy property is included in
PolicySet to define the evaluation relationship among the rules in
the policy set. See Section 5.5 for more information. The
PolicyRoles property is included in PolicySet to characterize the
resources to which the PolicySet applies. See Section 5.6 for more
information.
Along with the definition of the PolicySet class, a new concrete
aggregation class is defined that will also be discussed in the
following sections. PolicySetComponent is defined as a subclass of
PolicyComponent; it provides the containment relationship for a
PolicySet in a PolicySet. PolicySetComponent replaces the two PCIM
aggregations PolicyGroupInPolicyGroup and PolicyRuleInPolicyGroup, so
these two aggregations are deprecated.
A PolicySet"s relationship to an AdminDomain or other administrative
scoping system (for example, a ComputerSystem) is represented by the
PolicySetInSystem abstract association. This new association is
derived from PolicyInSystem, and the PolicyGroupInSystem and
PolicyRuleInSystem associations are now derived from
PolicySetInSystem instead of directly from PolicyInSystem. The
PolicySetInSystem.Priority property is discussed in Section 5.5.3.
5.4. Nested 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
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
document interchangeably. The aggregation PolicySetComponent is used
to represent the nesting of a policy rule in another policy rule.
5.4.1. Usage Rules for Nested Rules
The relationship between rules and sub-rules is defined as follows:
o The parent rule"s condition clause is a condition for evaluation
of all nested rules; that is, the conditions of the parent are
logically ANDed to the conditions of the sub-rules. If the parent
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-
rules SHALL BE evaluated according to the decision strategy and
priorities as discussed in Section 5.5.
o If the parent rule"s condition evaluates to TRUE, the parent
rule"s set of actions is executed BEFORE execution of the sub-
rules actions. The parent rule"s actions are not to be confused
with default actions. A default action is one that is to be
executed only if none of the more specific sub-rules are executed.
If a default action needs to be specified, it needs to be defined
as an action that is part of a catchall sub-rule associated with
the parent rule. The association linking the default action(s) in
this special sub-rule should have the lowest priority relative to
all other sub-rule associations:
if parent-condition then parent rule"s action
if condA then actA
if condB then ActB
if True then default action
Such a default action functions as a default when FirstMatching
decision strategies are in effect (see section 5.5). If
AllMatching applies, the "default" action is always performed.
o Policy rules have a context in which they are executed. The rule
engine evaluates and applies the policy rules in the context of
the managed resource(s) that are identified by the policy roles
(or by an explicit association). Submodels MAY add additional
context to policy rules based on rule structure; any such
additional context is defined by the semantics of the action
classes of the submodel.
5.4.2. Motivation
Rule nesting enhances Policy readability, expressiveness and
reusability. The ability to nest policy rules and form sub-rules is
important for manageability and scalability, as it enables complex
policy rules to be constructed from multiple simpler policy rules.
These enhancements ease the policy management tools" task, allowing
policy rules to be expressed in a way closer to how humans think.
Although rule nesting can be used to suggest optimizations in the way
policy rules are evaluated, as discussed in section 5.5.2 "Side
Effects," nesting does not specify nor does it require any particular
order of evaluation of conditions. Optimization of rule evaluation
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 optimizer can create a more efficient
machine code than any optimization done by the programmer within the
source code. Nevertheless, if the PEP or PDP does not do
optimization, the administrator writing the policy may be able to
influence the evaluation of the policy rules for execution using rule
nesting.
Nested rules are not designed for policy repository retrieval
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 enforced. Optimizing the number of rules retrieved
should be done by clever selection of roles.
5.5. Priorities and Decision Strategies
A "decision strategy" is used to specify the evaluation method for
the policies in a PolicySet. Two decision strategies are defined:
"FirstMatching" and "AllMatching." The FirstMatching strategy is
used to 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 rule (that is, the rule with the highest priority) that
has its 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 conditions evaluate to TRUE, the actions are enforced.
Implementations MUST support the FirstMatching decision strategy;
implementations MAY support the AllMatching decision strategy.
As previously discussed, the PolicySet subclasses are PolicyGroup and
PolicyRule: either subclass may contain PolicySets of either
subclass. Loops, including the degenerate case of a PolicySet that
contains itself, are not allowed when PolicySets contain other
PolicySets. The containment relationship is specified using the
PolicySetComponent aggregation.
The relative priority within a PolicySet is established by the
Priority property of the PolicySetComponent aggregation of the
contained PolicyGroup and PolicyRule instances. The use of PCIM"s
PolicyRule.Priority property is deprecated in favor of this new
property. The separation of the priority property from the rule has
two advantages. First, it generalizes the concept of priority, so
that it can be used for both groups and rules. Second, it places the
priority on the relationship between the parent policy set and the
subordinate policy group or rule. The assignment of a priority value
then becomes much easier, in that the value is used only in
relationship to other priorities in the same set.
Together, the PolicySet.PolicyDecisionStrategy and
PolicySetComponent.Priority determine the processing for the rules
contained in a PolicySet. As before, the larger priority value
represents the higher priority. Unlike the earlier definition,
PolicySetComponent.Priority MUST have a unique value when compared
with others defined for the same aggregating PolicySet. Thus, the
evaluation of rules within a set is deterministically specified.
For a FirstMatching decision strategy, the first rule (that is, the
one with the highest priority) in the set that evaluates to True, is
the only rule whose actions are enforced for a particular evaluation
pass through the PolicySet.
For an AllMatching decision strategy, all of the matching rules are
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: the actions of the higher priority rules are executed first.
Since the actions of higher priority rules are executed first, lower
priority rules 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, 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 executed later and, therefore, will
"win," in this example, setting the DSCP to 4. Thus, conflicts
between rules are resolved by this execution order.
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
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 provided by the service configured by the rule engine. See
Section 5.5.2 for a discussion of side effects.
5.5.1. Structuring Decision Strategies
As discussed in Sections 5.3 and 5.4, PolicySet instances may be
nested arbitrarily. For a FirstMatching decision strategy on a
PolicySet, any contained PolicySet that matches satisfies the
termination criteria for the FirstMatching strategy. A PolicySet is
considered to match if it is a PolicyRule and its conditions evaluate
to True, or if the PolicySet is a PolicyGroup and at least one of its
contained PolicyGroups or PolicyRules match. The priority associated
with contained PolicySets, then, determines when to terminate rule
evaluation in the structured set of rules.
In the example shown in Figure 3, the relative 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 PolicyGroup 1B
and PolicyRule 1C, but with different priorities.) Of course, which
rules are enforced is also dependent on which rules, if any, match.
PolicyGroup 1: FirstMatching

+-- Pri=6 -- PolicyRule 1A

+-- Pri=5 -- PolicyGroup 1B: AllMatching

+-- Pri=5 -- PolicyGroup 1B1: AllMatching

+---- etc.

+-- Pri=4 -- PolicyRule 1X2

+-- Pri=3 -- PolicyRule 1B3: FirstMatching

+---- etc.

+-- Pri=4 -- PolicyRule 1C: FirstMatching

+-- Pri=4 -- PolicyRule 1C1

+-- Pri=3 -- PolicyRule 1X2

+-- Pri=2 -- PolicyRule 1C3
Figure 3. Nested PolicySets with Different Decision Strategies
o Because PolicyGroup 1 has a FirstMatching decision strategy, if
the conditions of PolicyRule 1A match, its actions are enforced
and the evaluation stops.
o If it does not match, PolicyGroup 1B is evaluated using an
AllMatching strategy. Since PolicyGroup 1B1 also has an
AllMatching strategy all of the rules and groups of rules
contained in PolicyGroup 1B1 are evaluated and enforced as
appropriate. PolicyRule 1X2 and PolicyRule 1B3 are also evaluated
and enforced as appropriate. If any of the sub-rules in the
subtrees of PolicyGroup 1B evaluate to True, then PolicyRule 1C is
not evaluated because the FirstMatching strategy of PolicyGroup 1
has been satisfied.
o If neither PolicyRule 1A nor PolicyGroup 1B yield a match, then
PolicyRule 1C is evaluated. Since it is first matching, rules
1C1, 1X2, and 1C3 are evaluated until the first match, if any.
5.5.2. Side Effects
Although evaluation of conditions is sometimes discussed as an
ordered set of operations, the rule engine need not be implemented as
a procedural language interpreter. Any side effects of condition
evaluation or the execution of actions MUST NOT affect the result of
the evaluation of other conditions evaluated by the rule engine in
the same evaluation pass. That is, an implementation of a rule
engine MAY evaluate all conditions in any order before applying the
priority and determining which actions are to be executed.
So, regardless of how a rule engine is implemented, it MUST NOT
include any side effects of condition evaluation in the evaluation of
conditions for either of the decision strategies. For both the
AllMatching decision 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 side effects of the enforcement of
actions MUST NOT be included in condition evaluation on the same
evaluation pass.
5.5.3. Multiple PolicySet Trees For a Resource
As shown in the example in Figure 3., PolicySet trees are defined by
the PolicySet subclass instances and the PolicySetComponent
aggregation instances between them. Each PolicySet tree has a
defined set of decision strategies and evaluation priorities. In
section 5.6 we discuss some improvements in the use of PolicyRoles
that cause the parent PolicySet.PolicyRoles to be applied to all
contained PolicySet instances. However, a given resource may still
have multiple, disjoint PolicySet trees regardless of how they are
collected. These top-level PolicySet instances are called "unrooted"
relative to the given resource.
So, a PolicySet instance is defined to be rooted or unrooted in the
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 5.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. These
PolicySetComponent aggregations are traversed up the tree without
regard to how a PolicySet instance came to be related with the
ManagedElement. 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, instances B, and C are unrooted and instances D, E,
and F are all rooted. In the context of interface Y, instance A is
unrooted and instances B, C, D, E and F are all rooted.
+---+ +-----------+ +-----------+
A I/F X I/F Y
+---+ has roles has roles
/ B & C A & B
/ +-----------+ +-----------+
+---+ +---+
B C
+---+ +---+
/
/
+---+ +---+ +---+
D E F
+---+ +---+ +---+
Figure 4. 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
PolicySetComponent tree), the decision strategy among these disjoint
PolicySet instances is the FirstMatching strategy. The priority used
with this FirstMatching strategy is defined in the PolicySetInSystem
association. The PolicySetInSystem subclass instances are present
for all PolicySet instances (it is a required association) but the
priority is only used as a default for unrooted PolicySet instances
in a given ManagedElement context.
The FirstMatching strategy is used among all unrooted PolicySet
instances that apply to a given resource for a given functional
domain. So, for example, the PolicySet instances that are used for
QoS policy and the instances that are used for IKE policy, although
they are disjoint, are not joined in a FirstMatching decision
strategy. Instead, they are evaluated independently of one another.
5.5.4. Deterministic Decisions
As previously discussed, PolicySetComponent.Priority values MUST be
unique within a containing PolicySet and PolicySetInSystem.Priority
values MUST be unique for an associated System. Each PolicySet,
then, has a deterministic behavior based upon the decision strategy
and uniquely defined priority.
There are certainly cases where rules need not have a unique priority
value (i.e., where evaluation and execution priority is not
important). However, it is believed that the flexibility gained by
this capability is not sufficiently beneficial to justify the
possible variations in implementation behavior and the resulting
confusion that might occur.
5.6. Policy Roles
A policy role is defined in [10] as "an administratively specified
characteristic of a managed element (for example, an interface). It
is a selector for policy rules and PRovisioning Classes (PRCs), to
determine the applicability of the rule/PRC to a particular managed
element."
In PCIMe, PolicyRoles is defined as a property of PolicySet, which is
inherited by both PolicyRules and PolicyGroups. In this document, we
also add PolicyRole as the identifying name of a collection of
resources (PolicyRoleCollection), where each element in the
collection has the specified role characteristic.
5.6.1. Comparison of Roles in PCIM with Roles in snmpconf
In the Configuration Management with SNMP (snmpconf) working group"s
Policy Based Management MIB [14], policy rules are of the form
if <policyFilter> then <policyAction>
where <policyFilter> is a set of conditions that are used to
determine whether or not the policy applies to an object instance.
The policy filter can perform comparison operations on SNMP variables
already defined in MIBS (e.g., "ifType == ethernet").
The policy management MIB defined in [14] defines a Role table that
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 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 Role group.
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 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 applied to the elements with the appropriate
roles). In [14], however, no special processing is required for
realizing the semantics of roles; roles are treated just as any other
SNMP variables and comparisons of role values can be included in the
policy filter of a policy rule.
Secondly, in PCIM, there is no formally defined way of associating a
role with an object instance, whereas in [14] this is done via the
use of the Role tables (pmRoleESTable and pmRoleSETable). The Role
tables associate Role values with elements.
5.6.2. Addition of PolicyRoleCollection to PCIMe
In order to remedy the latter shortcoming in PCIM (the lack of a way
of associating a role with an object instance), PCIMe has a new class
PolicyRoleCollection derived from the CIM Collection class.
Resources that share a common role are aggregated by a
PolicyRoleCollection instance, via the ElementInPolicyRoleCollection
aggregation. The role is specified in the PolicyRole property of the
aggregating PolicyRoleCollection instance.
A PolicyRoleCollection always exists in the context of a system. As
was done in PCIM for PolicyRules and PolicyGroups, an association,
PolicyRoleCollectionInSystem, captures this relationship. Remember
that in CIM, System is a base class for describing network devices
and administrative domains.
The association between a PolicyRoleCollection and a system should be
consistent with the associations that scope the policy rules/groups
that are applied to the resources in that collection. Specifically,
a PolicyRoleCollection should be associated with the same System as
the applicable PolicyRules and/or PolicyGroups, or to a System higher
in the tree formed by the SystemComponent association. When a PEP
belongs to multiple Systems (i.e., AdminDomains), and scoping by a
single domain is impractical, two alternatives exist. One is to
arbitrarily limit domain membership to one System/AdminDomain. The
other option is to define a more global AdminDomain that simply
includes the others, and/or that spans the business or enterprise.
As an example, suppose that there are 20 traffic trunks in a network,
and that an administrator would like to assign three of them to
provide "gold" service. Also, the administrator has defined several
policy rules which specify how the "gold" service is delivered. For
these rules, the PolicyRoles property (inherited from PolicySet) is
set to "Gold Service".
In order to associate three traffic trunks with "gold" service, an
instance of the PolicyRoleCollection class is created and its
PolicyRole property is also set to "Gold Service". Following this,
the administrator associates three traffic trunks with the new
instance of PolicyRoleCollection via the
ElementInPolicyRoleCollection aggregation. This enables a PDP to
determine that the "Gold Service" policy rules apply to the three
aggregated traffic trunks.
Note that roles are used to optimize policy retrieval. It is not
mandatory to implement roles or, if they have been implemented, to
group elements in a PolicyRoleCollection. However, if roles are
used, then either the collection approach should be implemented, or
elements should be capable of reporting their "pre-programmed" roles
(as is done in COPS).
5.6.3. Roles for PolicyGroups
In PCIM, role(s) are only associated with policy rules. However, it
may be desirable to associate role(s) with groups of policy rules.
For example, a network administrator may want to define a group of
rules that apply only to Ethernet interfaces. A policy group can be
defined with a role-combination="Ethernet", and all the relevant
policy rules can be 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 PolicyRoles property up from PolicyRule
to the new abstract class PolicySet. The property is then inherited
by both PolicyGroup and PolicyRule.) Then every policy rule in this
policy group implicitly inherits this role-combination from the
containing policy group. A similar implicit inheritance applies to
nested policy groups.
There is no explicit copying of role(s) from container to contained
entity. Obviously, this implicit inheritance of role(s) leads to the
possibility of defining inconsistent role(s) (as explained in the
example below); the handling of such inconsistencies is beyond the
scope of PCIMe.
As an example, suppose that there is a PolicyGroup PG1 that contains
three PolicyRules, PR1, PR2, and PR3. Assume that PG1 has the roles
"Ethernet" and "Fast". Also, assume that the contained policy rules
have the role(s) shown below:
+------------------------------+
PolicyGroup PG1
PolicyRoles = Ethernet, Fast
+------------------------------+

+------------------------+
PolicyRule PR1
-------- PolicyRoles = Ethernet
+------------------------+

+--------------------------+
PolicyRule PR2
-------- PolicyRoles = <undefined>
+--------------------------+

+------------------------+
PolicyRule PR3
-------- PolicyRoles = Slow
+------------------------+
Figure 5. Inheritance of Roles
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
value of PolicyRoles for PR2 is undefined. Its roles are implicitly
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. However, whether these roles are actually in
conflict is not clear. In one scenario, the policy administrator
may have wanted only "Fast"- "Ethernet" rules in the policy group.
In another scenario, the administrator may be indicating that PR3
applies to all "Ethernet" interfaces regardless of whether they are
"Fast" or "Slow." Only in the former scenario (only "Fast"-
"Ethernet" rules in the policy group) is there a role conflict.
Note that it is possible to override implicitly inherited roles via
appropriate conditions on a PolicyRule. For example, suppose that
PR3 above had defined the following conditions:
(interface is not "Fast") and (interface is "Slow")
This results in unambiguous semantics for PR3.
5.7. Compound Policy Conditions and Compound Policy Actions
Compound policy conditions and compound policy actions are introduced
to provide additional reusable "chunks" of policy.
5.7.1. Compound Policy Conditions
A CompoundPolicyCondition is a PolicyCondition representing a Boolean
combination of simpler conditions. The conditions being combined may
be SimplePolicyConditions (discussed below in Section 6.4), but the
utility of reusable combinations of policy conditions is not
necessarily limited to the case where the component conditions are
simple ones.
The PCIM extensions to introduce compound policy conditions are
relatively straightforward. Since the purpose of the extension is to
apply the DNF / CNF logic from PCIM"s PolicyConditionInPolicyRule
aggregation to a compound condition that aggregates simpler
conditions, the following changes are required:
o Create a new aggregation PolicyConditionInPolicyCondition, with
the same GroupNumber and ConditionNegated properties as
PolicyConditionInPolicyRule. The cleanest way to do this is to
move the properties up to a new abstract aggregation superclass
PolicyConditionStructure, from which the existing aggregation
PolicyConditionInPolicyRule and a new aggregation
PolicyConditionInPolicyCondition are derived. For now there is no
need to re-document the properties themselves, since they are
already documented in PCIM as part of the definition of the
PolicyConditionInPolicyRule aggregation.
o It is also necessary to define a concrete subclass
CompoundPolicyCondition of PolicyCondition, to introduce the
ConditionListType property. This property has the same function,
and works in exactly the same way, as the corresponding property
currently defined in PCIM for the PolicyRule class.
The class and property definitions for representing compound policy
conditions are below, in Section 6.
5.7.2. Compound Policy Actions
A compound action is a convenient construct to represent a sequence
of actions to be applied as a single atomic action within a policy
rule. In many cases, actions are related to each other and should be
looked upon as sub-actions of one "logical" action. An example of
such a logical action is "shape & mark" (i.e., shape a certain stream
to a set of predefined bandwidth characteristics and then mark these
packets with a certain DSCP value). This logical action is actually
composed of two different QoS actions, which should be performed in a
well-defined order and as a complete set.
The CompoundPolicyAction construct allows one to create a logical
relationship between a number of actions, and to define the
activation logic associated with this logical action.
The CompoundPolicyAction construct allows the reusability of these
complex actions, by storing them in a ReusablePolicyContainer and
reusing them in different policy rules. Note that a compound action
may also be aggregated by another compound action.
As was the case with CompoundPolicyCondition, the PCIM extensions to
introduce compound policy actions are relatively straightforward.
This time the goal is to apply the property ActionOrder from PCIM"s
PolicyActionInPolicyRule aggregation to a compound action that
aggregates simpler actions. The following changes are required:
o Create a new aggregation PolicyActionInPolicyAction, wi