[ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ]
Alternate Formats: rfc3460.txt | rfc3460.txt.pdf
RFC 3460 - Policy Core Information Model (PCIM) Extensions
|
 |
RFC3460 - Policy Core Information Model (PCIM) Extensions
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, RFC 3060). 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 RFC 3060.
Table of Contents
1. Introduction....................................................5
2. Changes since RFC 3060..........................................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), RFC 3060 [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, RFC 2119 [8].
2. Changes since RFC 3060
Section 3.2 contains a short discussion of the changes that this
document makes to the RFC 3060 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, with the same
ActionOrder property as PolicyActionInPolicyRule. The cleanest
way to do this is to move the property up to a new abstract
aggregation superclass PolicyActionStructure, from which the
existing aggregation PolicyActionInPolicyRule and a new
aggregation PolicyActionInPolicyAction are derived.
o It is also necessary to define a concrete subclass
CompoundPolicyAction of PolicyAction, to introduce the
SequencedActions 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.
o Finally, a new property ExecutionStrategy is needed for both the
PCIM class PolicyRule and the new class CompoundPolicyAction. This
property allows the policy administrator to specify how the PEP
should behave in the case where there are multiple actions
aggregated by a PolicyRule or by a CompoundPolicyAction.
The class and property definitions for representing compound policy
actions are below, in Section 6.
5.8. Variables and Values
The following subsections introduce several related concepts,
including PolicyVariables and PolicyValues (and their numerous
subclasses), SimplePolicyConditions, and SimplePolicyActions.
5.8.1. Simple Policy Conditions
The SimplePolicyCondition class models elementary Boolean expressions
of the form: "(<variable> MATCH <value>)". The relationship 'MATCH',
which is implicit in the model, is interpreted based on the variable
and the value. Section 5.8.3 explains the semantics of the 'MATCH'
operator. Arbitrarily complex Boolean expressions can be 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 5.7.1).
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 binding of the variable. Section 5.8.5 describes
variables and their binding rules.
The SimplePolicyCondition class refines the basic structure of the
PolicyCondition class defined in PCIM by using the pair (<variable>,
<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 the formal notation.
The variable specifies the attribute of an object that should be
matched when evaluating the condition. For example, for a QoS model,
this object could represent the flow that is being conditioned. A
set of predefined variables that cover network attributes commonly
used for filtering is introduced in PCIMe, to encourage
interoperability. This list covers layer 3 IP attributes such as IP
network addresses, protocols and ports, as well as a set of layer 2
attributes (e.g., MAC addresses).
The bound variable is matched against a value to produce the Boolean
result. For example, in the condition "The source IP address of the
flow belongs to the 10.1.x.x subnet", a source IP address variable is
matched against a 10.1.x.x subnet value.
5.8.2. Using Simple Policy Conditions
Simple conditions can be used in policy rules directly, or as
building blocks for creating compound policy conditions.
Simple condition composition MUST enforce the following data-type
conformance rule: The ValueTypes property of the variable must be
compatible with the type of the value class used. The simplest (and
friendliest, from a user point-of-view) way to do this is to equate
the type of the value class with the name of the class. By ensuring
that the ValueTypes property of the variable matches the name of the
value class used, we know that the variable and value instance values
are compatible with each other.
Composing a simple condition requires that an instance of the class
SimplePolicyCondition be created, and that instances of the variable
and value classes that it uses also exist. Note that the variable
and/or value instances may already exist as reusable objects in an
appropriate ReusablePolicyContainer.
Two aggregations are used in order to create the pair (<variable>,
<value>). The aggregation PolicyVariableInSimplePolicyCondition
relates a SimplePolicyCondition to a single variable instance.
Similarly, the aggregation PolicyValueInSimplePolicyCondition relates
a SimplePolicyCondition to a single value instance. Both
aggregations are defined in this document.
Figure 6. depicts a SimplePolicyCondition with its associated
variable and value. Also shown are two PolicyValue instances that
identify the values that the variable can assume.
+-----------------------+
| SimplePolicyCondition |
+-----------------------+
* @
* @
+------------------+ * @ +---------------+
| (PolicyVariable) |*** @@@| (PolicyValue) |
+------------------+ +---------------+
# #
# ooo #
# #
+---------------+ +---------------+
| (PolicyValue) | ooo | (PolicyValue) |
+---------------+ +---------------+
Aggregation Legend:
**** PolicyVariableInSimplePolicyCondition
@@@@ PolicyValueInSimplePolicyCondition
#### ExpectedPolicyValuesForVariable
Figure 6. SimplePolicyCondition
Note: The class names in parenthesis denote subclasses. The classes
named in the figure are abstract, and thus cannot themselves be
instantiated.
5.8.3. The Simple Condition Operator
A simple condition models an elementary Boolean expression of the
form "variable MATCHes value". However, the formal notation of the
SimplePolicyCondition, together with its associations, models only a
pair, (<variable>, <value>). The 'MATCH' operator is not directly
modeled -- it is implied. Furthermore, this implied 'MATCH' operator
carries overloaded semantics.
For example, in the simple condition "DestinationPort MATCH '80'",
the interpretation of the 'MATCH' operator is equality (the 'equal'
operator). Clearly, a different interpretation is needed in the
following cases:
o "DestinationPort MATCH {'80', '8080'}" -- operator is 'IS SET
MEMBER'
o "DestinationPort MATCH {'1 to 255'}" -- operator is 'IN INTEGER
RANGE'
o "SourceIPAddress MATCH 'MyCompany.com'" -- operator is 'IP ADDRESS
AS RESOLVED BY DNS'
The examples above illustrate the implicit, context-dependent nature
of the 'MATCH' operator. The interpretation depends on the actual
variable and value instances in the simple condition. The
interpretation is always derived from the bound variable and the
value instance associated with the simple condition. Text
accompanying the value class and implicit variable definition is used
for interpreting the semantics of the 'MATCH' relationship. In the
following list, we define generic (type-independent) matching.
PolicyValues may be multi-fielded, where each field may contain a
range of values. The same equally holds for PolicyVariables.
Basically, we have to deal with single values (singleton), ranges
([lower bound .. 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' operator are defined.
o singleton matches singleton -> the matching rule is defined in the
type
o singleton matches range [lower bound .. upper bound] -> the
matching evaluates to true, if the singleton matches the lower
bound or the upper bound or a value in between
o singleton matches set -> the matching evaluates to true, if the
value of the singleton matches one of the components in the set,
where a component may be a singleton or range again
o ranges [A..B] matches singleton -> is true if A matches B matches
singleton
o range [A..B] matches range [X..Y] -> the matching evaluates to
true, if all values of the range [A..B] are also in the range
[X..Y]. For instance, [3..5] match [1..6] evaluates to true,
whereas [3..5] match [4..6] evaluates to false.
o range [A..B] matches set (a,b,c, ...) -> the matching evaluates to
true, if all values in the range [A..B] are part of the set. For
instance, range [2..3] match set ([1..2],3) evaluates to true, as
well as range [2..3] match set (2,3), and range [2..3] match set
([1..2],[3..5]).
o set (a,b,c, ...) match singleton -> is true if a match b match c
match ... match singleton
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
range [1..4] evaluates to true.
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
(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
false.
Variables may contain various types (Section 6.11.1). When not
stated 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 of the same type. If they differ, then the
condition evaluates to FALSE.
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.
+-----------------------+
| SimplePolicyCondition |
+-----------------------+
* @
* @
* @
+-----------------------------------+ +--------------------------+
| Name=SmallSourcePorts | | Name=Port300 |
| Class=PolicySourcePortVariable | | Class=PolicyIntegerValue |
| ValueTypes=[PolicyIntegerValue] | | IntegerList = [300] |
+-----------------------------------+ +--------------------------+
#
#
#
+-------------------------+
|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.
5.8.4. SimplePolicyActions
The SimplePolicyAction class models the elementary set operation.
"SET <variable> TO <value>". The set operator MUST overwrite an old
value of the variable. In the case where the variable to be updated
is multi- 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
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 bits). The complete interpretation of a simple action
depends on the binding of the variable.
The SimplePolicyAction class refines the basic structure of the
PolicyAction class defined in PCIM, by specifying the contents of the
action using the (<variable>, <value>) pair to form the action. The
variable specifies the attribute of an object. The value of this
attribute is set to the value specified in <value>. Selection of the
object is a function of the type of variable involved. See Sections
5.8.6 and 5.8.7, respectively, for details on object selection for
explicitly bound and implicitly bound policy variables.
SimplePolicyActions can be used in policy rules directly, or as
building blocks for creating CompoundPolicyActions.
The set operation is only valid if the list of types of the variable
(ValueTypes property of PolicyImplicitVariable) includes the
specified type of the value. Conversion of values from one
representation into another is not defined. For example, a variable
of IPv4Address type may not be set to a string containing a DNS name.
Conversions are part of an 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
SimplePolicyAction be created, and that instances of the variable and
value classes that it uses also exist. Note that the variable and/or
value instances may already exist as reusable objects in an
appropriate ReusablePolicyContainer.
Two aggregations are used in order to create the pair (<variable>,
<value>). The aggregation PolicyVariableInSimplePolicyAction relates
a SimplePolicyAction to a single variable instance. Similarly, the
aggregation PolicyValueInSimplePolicyAction relates a
SimplePolicyAction to a single value instance. Both aggregations are
defined in this document.
Figure 8. depicts a SimplePolicyAction with its associated variable
and value.
+-----------------------+
| SimplePolicyAction |
| |
+-----------------------+
* @
* @
+------------------+ * @ +---------------+
| (PolicyVariable) |*** @@@| (PolicyValue) |
+------------------+ +---------------+
# #
# ooo #
# #
+---------------+ +---------------+
| (PolicyValue) | ooo | (PolicyValue) |
+---------------+ +---------------+
Aggregation Legend:
**** PolicyVariableInSimplePolicyAction
@@@@ PolicyValueInSimplePolicyAction
#### ExpectedPolicyValuesForVariable
Figure 8. SimplePolicyAction
5.8.5. Policy Variables
A variable generically represents information that changes (or
"varies"), and that is set or evaluated by software. In policy,
conditions and actions can abstract information as "policy variables"
to be evaluated in logical expressions, or set by actions.
PCIMe defines two types of PolicyVariables, PolicyImplicitVariables
and PolicyExplicitVariables. The semantic difference between these
classes is based on modeling context. Explicit variables are bound
to exact model constructs, while implicit variables are defined and
evaluated outside of a model. For example, one can imagine a
PolicyCondition testing whether a CIM ManagedSystemElement's Status
property has the value "Error." The Status property is an explicitly
defined 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, network packets are not explicitly modeled or
instantiated, since there is no perceived value (at this time) in
managing at the packet level. Therefore, a PolicyCondition can make
no explicit reference to a model construct that represents a network
packet's source address. In this case, an implicit PolicyVariable is
defined, to allow evaluation or modification of a packet's source
address.
5.8.6. Explicitly Bound Policy Variables
Explicitly bound policy variables indicate the class and property
names of the model construct to be evaluated or set. The CIM Schema
defines and constrains "appropriate" values for the variable (i.e.,
model property) using data types and other information such as
class/property qualifiers.
A PolicyExplicitVariable is "explicit" because its model semantics
are exactly defined. It is NOT explicit due to an exact binding to a
particular object instance. If PolicyExplicitVariables were tied to
instances (either via associations or by an object identification
property in the class itself), then we would be forcing element-
specific rules. On the other hand, if we only specify the object's
model context (class and property name), but leave the binding to the
policy framework (for example, using policy roles), then greater
flexibility results for either general or element-specific rules.
For example, an element-specific rule is obtained by a condition
((<variable>, <value>) pair) that defines CIM LogicalDevice
DeviceID="12345". Alternately, if a PolicyRule's PolicyRoles is
"edge device" and the condition ((<variable>, <value>) pair) is
Status="Error", then a general rule results for all edge 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
document.
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 6.10 for the formal definition of the class
PolicyExplicitVariable.
5.8.7. Implicitly Bound Policy Variables
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 condition or an action. Further instructions are provided for
specifying data type and/or value constraints for implicitly bound
variables.
PCIMe introduces an abstract class, PolicyImplicitVariable, to model
implicitly bound variables. This class is derived from the abstract
class PolicyVariable also defined in PCIMe. Each of the implicitly
bound variables introduced by PCIMe (and those that are introduced by
domain- specific sub-models) MUST be derived from the
PolicyImplicitVariable class. The rationale for using this mechanism
for modeling is explained below in Section 5.8.9.
A domain-specific policy information model that extends PCIMe may
define additional implicitly bound variables either by deriving them
directly from the class PolicyImplicitVariable, or by further
refining an existing variable class such as SourcePort. When
refining a class such as SourcePort, existing binding rules, type or
value constraints may be narrowed.
5.8.8. Structure and Usage of Pre-Defined Variables
A class derived from PolicyImplicitVariable to model a particular
implicitly bound variable SHOULD be constructed so that its name
depicts the meaning of the variable. For example, a class defined to
model the source port of a TCP/UDP flow SHOULD have 'SourcePort' in
its name.
PCIMe defines one association and one general-purpose mechanism that
together characterize each of the implicitly bound variables that it
introduces:
1. The ExpectedPolicyValuesForVariable association defines the set of
value classes that could be matched to this variable.
2. The list of constraints on the values that the PolicyVariable can
hold (i.e., values that the variable must match) are defined by
the appropriate properties of an associated PolicyValue class.
In the example presented above, a PolicyImplicitVariable represents
the SourcePort of incoming traffic. The ValueTypes property of an
instance of this class will hold the class name PolicyIntegerValue.
This by itself constrains the data type of the SourcePort instance to
be an integer. However, we can further constrain the particular
values that the SourcePort variable can hold by entering valid ranges
in the IntegerList property of the PolicyIntegerValue instance (0 -
65535 in this document).
The combination of the VariableName and the
ExpectedPolicyValuesForVariable association provide a consistent and
extensible set of metadata that define the semantics of variables
that are used to form policy conditions. Since the
ExpectedPolicyValuesForVariable association points to a PolicyValue
instance, any of the values expressible in the PolicyValue class can
be used to constrain values that the PolicyImplicitVariable can hold.
For example:
o The ValueTypes property can be used to ensure that only proper
classes are used in the expression. For example, the SourcePort
variable will not be allowed to ever be of type
PolicyIPv4AddrValue, since source ports have different semantics
than IP addresses and may not be matched. However, integer value
types are allowed as the property ValueTypes holds the string
"PolicyIntegerValue", which is the class name for integer values.
o The ExpectedPolicyValuesForVariable association also ensures that
variable-specific semantics are enforced (e.g., the SourcePort
variable may include a constraint association to a value object
defining a specific integer range that should be matched).
5.8.9. Rationale for Modeling Implicit Variables as Classes
An implicitly bound variable can be modeled in one of several ways,
including a single class with an enumerator for each individual
implicitly bound variable and an abstract class extended for each
individual variable. The reasons for using a class inheritance
mechanism for specifying individual implicitly bound variables are
these:
1. It is easy to extend. A domain-specific information model can
easily extend the PolicyImplicitVariable class or its subclasses
to define domain-specific and context-specific variables. For
example, a domain-specific QoS policy information model may
introduce an implicitly bound variable class to model applications
by deriving a qosApplicationVariable class from the
PolicyImplicitVariable abstract class.
2. Introduction of a single structural class for implicitly bound
variables would have to include an enumerator property that
contains all possible individual implicitly bound variables. This
means that a domain-specific information model wishing to
introduce an implicitly bound variable must extend the enumerator
itself. This results in multiple definitions of the same class,
differing in the values available in the enumerator class. One
definition, in this document, would include the common implicitly
bound variables' names, while a second definition, in the domain-
specific information model document, may include additional values
('qosApplicationVariable' in the example above). It wouldn't even
be obvious to the application developer that multiple class
definitions existed. It would be harder still for the application
developer to actually find the correct class to use.
3. In addition, an enumerator-based definition would require each
additional value to be registered with IANA to ascertain adherence
to standards. This would make the process cumbersome.
4. A possible argument against the inheritance mechanism would cite
the fact that this approach results in an explosion of class
definitions compared to an enumerator class, which only introduces
a single class. While, by itself, this is not a strike against
the approach, it may be argued that data models derived from this
information model may be more difficult to optimize for
applications. This argument is rejected on the grounds that
application optimization is of lesser value for an information
model than clarity and ease of extension. In addition, it is hard
to claim that the inheritance model places an absolute burden on
the optimization. For example, a data model may still use
enumeration to denote instances of pre-defined variables and claim
PCIMe compliance, as long as the data model can be mapped
correctly to the definitions specified in this document.
5.8.10. Policy Values
The abstract class PolicyValue is used for modeling values and
constants used in policy conditions. Different value types are
derived from this class, to represent the various attributes
required. Extensions of the abstract class PolicyValue, defined in
this document, provide a list of values for basic network attributes.
Values can be used to represent constants as named values. Named
values can be kept in a reusable policy container to be reused by
multiple conditions. Examples of constants include well-known ports,
well-known protocols, server addresses, and other similar concepts.
The PolicyValue subclasses define three basic types of values:
scalars, ranges and sets. For example, a well-known port number
could be defined using the PolicyIntegerValue class, defining a
single value (80 for 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 Section 6.14 of this document.
PCIMe defines the following subclasses of the abstract class
PolicyValue:
Classes for general use:
- PolicyStringValue,
- PolicyIntegerValue,
- PolicyBitStringValue
- PolicyBooleanValue.
Classes for layer 3 Network values:
- PolicyIPv4AddrValue,
- PolicyIPv6AddrValue.
Classes for layer 2 Network values:
- PolicyMACAddrValue.
For details, please see the class definition section of each class in
Section 6.14 of this document.
5.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.
5.9.1. Domain-Level Packet Filters
In addition to filling in the holes in the overall Policy
infrastructure, PCIMe proposes a single mechanism for expressing
domain-level packet filters in policy conditions. This is being done
in response to concerns that even though the initial "wave" of
submodels derived from PCIM were all filtering on IP packets, each
was doing it in a slightly different way. PCIMe proposes a common
way to express IP packet filters. The following figure illustrates
how packet-filtering conditions are expressed in PCIMe.
+---------------------------------+
| CompoundFilterCondition |
| - IsMirrored boolean |
| - ConditionListType (DNF|CNF) |
+---------------------------------+
+ + +
+ + +
+ + +
SimplePC SimplePC SimplePC
* @ * @ * @
* @ * @ * @
* @ * @ * @
FlowDirection "In" SrcIP <addr1> DstIP <addr2>
Aggregation Legend:
++++ PolicyConditionInPolicyCondition
**** PolicyVariableInSimplePolicyCondition
@@@@ PolicyValueInSimplePolicyCondition
Figure 9. Packet Filtering in Policy Conditions
In Figure 9., each SimplePolicyCondition represents a single field to
be filtered on: Source IP address, Destination IP address, Source
port, etc. An additional SimplePolicyCondition indicates the
direction that a packet is traveling on an interface: inbound or
outbound. Because of the FlowDirection condition, care must be taken
in aggregating a set of SimplePolicyConditions into a
CompoundFilterCondition. Otherwise, the resulting
CompoundPolicyCondition may match all inbound packets, or all
outbound packets, when this is probably not what was intended.
Individual SimplePolicyConditions may be negated when they are
aggregated by a CompoundFilterCondition.
CompoundFilterCondition is a subclass of CompoundPolicyCondition. It
introduces one additional property, the Boolean property IsMirrored.
The purpose of this property is to allow a single
CompoundFilterCondition to match packets traveling in both directions
on a higher-level connection such as a TCP session. When this
property is TRUE, additional packets match a filter, beyond those
that would ordinarily match it. An example will illustrate how this
property works.
Suppose we have a CompoundFilterCondition that aggregates the
following three filters, which are ANDed together:
o FlowDirection = "In"
o Source IP = 9.1.1.1
o Source Port = 80
Regardless of whether IsMirrored is TRUE or FALSE, inbound packets
will match this CompoundFilterCondition if their Source IP address =
9.1.1.1 and their Source port = 80. If IsMirrored is TRUE, however,
an outbound packet will also match the CompoundFilterCondition if its
Destination IP address = 9.1.1.1 and its Destination port = 80.
IsMirrored "flips" the following Source/Destination packet header
fields:
o FlowDirection "In" / FlowDirection "Out"
o Source IP address / Destination IP address
o Source port / Destination port
o Source MAC address / Destination MAC address
o Source [layer-2] SAP / Destination [layer-2] SAP.
5.9.2. Device-Level Packet Filters
At the device level, packet header filters are represented by two
subclasses of the abstract class FilterEntryBase: IpHeadersFilter and
8021Filter. Submodels of PCIMe may define other subclasses of
FilterEntryBase in addition to these two; ICPM [12], 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 5.9.1 for details.
5.10. Conformance to PCIM and PCIMe
Because PCIM and PCIMe provide the core classes for modeling
policies, they are not in general sufficient by themselves for
representing actual policy rules. Submodels, such as QPIM and ICPM,
provide the means for expressing policy rules, by defining subclasses
of the classes defined in PCIM and PCIMe, and/or by indicating how
the PolicyVariables and PolicyValues defined in PCIMe can be used to
express conditions and actions applicable to the submodel.
A particular submodel will not, in general, need to use every element
defined in PCIM and PCIMe. For the elements it does not use, a
submodel SHOULD remain silent on whether its implementations must
support the element, must not support the element, should support the
element, etc. For the elements it does use, a submodel SHOULD
indicate which elements its implementations must support, which
elements they should support, and which elements they may support.
PCIM and PCIMe themselves simply define elements that may be of use
to submodels. These documents remain silent on whether
implementations are required to support an element, should support
it, etc.
This model (and derived submodels) defines conditions and actions
that are used by policy rules. While the conditions and actions
defined herein are straightforward and may be presumed to be widely
supported, as submodels are developed it is likely that situations
will arise in which specific conditions or actions are not supported
by some part of the policy execution system. Similarly, situations
may also occur where rules contain syntactic or semantic errors.
It should be understood that the behavior and effect of undefined or
incorrectly defined conditions or actions is not prescribed by this
information model. While it would be helpful if it were prescribed,
the variations in implementation restrict the ability for this
information model to control the effect. For example, if an
implementation only detected that a PEP could not enforce a given
action on that PEP, it would be very difficult to declare that such a
failure should affect other PEPs, or the PDP process. On the other
hand, if the PDP determines that it cannot properly evaluate a
condition, that failure may well affect all applications of the
containing rules.
6. Class Definitions
The following definitions supplement those in PCIM itself. PCIM
definitions that are not DEPRECATED here are still current parts of
the overall Policy Core Information Model.
6.1. The Abstract Class "PolicySet"
PolicySet is an abstract class that may group policies into a
structured set of policies.
NAME PolicySet
DESCRIPTION An abstract class that represents a set of policies
that form a coherent set. The set of contained
policies has a common decision strategy and a
common set of policy roles. Subclasses include
PolicyGroup and PolicyRule.
DERIVED FROM Policy
ABSTRACT TRUE
PROPERTIES PolicyDecisionStrategy
PolicyRoles
The PolicyDecisionStrategy property specifies the evaluation method
for policy groups and rules contained within the policy set.
NAME PolicyDecisionStrategy
DESCRIPTION The evaluation method used for policies contained in
the PolicySet. FirstMatching enforces the actions
of the first rule that evaluates to TRUE;
All Matching enforces the actions of all rules
that evaluate to TRUE.
SYNTAX uint16
VALUES 1 [FirstMatching], 2 [AllMatching]
DEFAULT VALUE 1 [FirstMatching]
The definition of PolicyRoles is unchanged from PCIM. It is,
however, moved from the class Policy up to the superclass PolicySet.
6.2. Update PCIM's Class "PolicyGroup"
The PolicyGroup class is moved, so that it is now derived from
PolicySet.
NAME PolicyGroup
DESCRIPTION A container for a set of related PolicyRules and
PolicyGroups.
DERIVED FROM PolicySet
ABSTRACT FALSE
PROPERTIES (none)
6.3. Update PCIM's Class "PolicyRule"
The PolicyRule class is moved, so that it is now derived from
PolicySet. The Priority property is also deprecated in PolicyRule,
and PolicyRoles is now inherited from the parent class PolicySet.
Finally, a new property ExecutionStrategy is introduced, paralleling
the property of the same name in the class CompoundPolicyAction.
NAME PolicyRule
DESCRIPTION The central class for representing the "If Condition
then Action" semantics associated with a policy
rule.
DERIVED FROM PolicySet
ABSTRACT FALSE
PROPERTIES Enabled
ConditionListType
RuleUsage
Priority DEPRECATED FOR PolicySetComponent.Priority
AND FOR PolicySetInSystem.Priority
Mandatory
SequencedActions
ExecutionStrategy
The property ExecutionStrategy defines the execution strategy to be
used upon the sequenced actions aggregated by this PolicyRule. (An
equivalent ExecutionStrategy property is also defined for the
CompoundPolicyAction class, to provide the same indication for the
sequenced actions aggregated by a CompoundPolicyAction.) This
document defines three execution strategies:
Do Until Success - execute actions according to predefined order,
until successful execution of a single action.
Do All - execute ALL actions which are part of the modeled
set, according to their predefined order.
Continue doing this, even if one or more of the
actions fails.
Do Until Failure - execute actions according to predefined order,
until the first failure in execution of a single
sub-action.
The property definition is as follows:
NAME ExecutionStrategy
DESCRIPTION An enumeration indicating how to interpret the
action ordering for the actions aggregated by this
PolicyRule.
SYNTAX uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do
Until Failure} )
DEFAULT VALUE Do All (2)
6.4. The Class "SimplePolicyCondition"
A simple policy condition is composed of an ordered triplet:
<Variable> MATCH <Value>
No formal modeling of the MATCH operator is provided. The 'match'
relationship is implied. Such simple conditions are evaluated by
answering the question:
Does <variable> match <value>?
The 'match' relationship is to be interpreted by analyzing the
variable and value instances associated with the simple condition.
Simple conditions are building blocks for more complex Boolean
Conditions, modeled by the CompoundPolicyCondition class.
The SimplePolicyCondition class is derived from the PolicyCondition
class defined in PCIM.
A variable and a value must be associated with a simple condition to
make it a meaningful condition, using, respectively, the aggregations
PolicyVariableInSimplePolicyCondition and
PolicyValueInSimplePolicyCondition.
The class definition is as follows:
NAME SimplePolicyCondition
DERIVED FROM PolicyCondition
ABSTRACT False
PROPERTIES (none)
6.5. The Class "CompoundPolicyCondition"
This class represents a compound policy condition, formed by
aggregation of simpler policy conditions.
NAME CompoundPolicyCondition
DESCRIPTION A subclass of PolicyCondition that introduces the
ConditionListType property, used for assigning DNF /
CNF semantics to subordinate policy conditions.
DERIVED FROM PolicyCondition
ABSTRACT FALSE
PROPERTIES ConditionListType
The ConditionListType property is used to specify whether the list of
policy conditions associated with this compound policy condition is
in disjunctive normal form (DNF) or conjunctive normal form (CNF).
If this property is not present, the list type defaults to DNF. The
property definition is as follows:
NAME ConditionListType
DESCRIPTION Indicates whether the list of policy conditions
associated with this policy rule is in disjunctive
normal form (DNF) or conjunctive normal form (CNF).
SYNTAX uint16
VALUES DNF(1), CNF(2)
DEFAULT VALUE DNF(1)
6.6. The Class "CompoundFilterCondition"
This subclass of CompoundPolicyCondition introduces one additional
property, the boolean IsMirrored. This property turns on or off the
"flipping" of corresponding source and destination fields in a filter
specification.
NAME CompoundFilterCondition
DESCRIPTION A subclass of CompoundPolicyCondition that
introduces the IsMirrored property.
DERIVED FROM CompoundPolicyCondition
ABSTRACT FALSE
PROPERTIES IsMirrored
The IsMirrored property indicates whether packets that "mirror" a
compound filter condition should be treated as matching the filter.
The property definition is as follows:
NAME IsMirrored
DESCRIPTION Indicates whether packets that mirror the specified
filter are to be treated as matching the filter.
SYNTAX boolean
DEFAULT VALUE FALSE
6.7. The Class "SimplePolicyAction"
The SimplePolicyAction class models the elementary set operation.
"SET <variable> TO <value>". The set operator MUST overwrite an old
value of the variable.
Two aggregations are used in order to create the pair <variable>
<value>. The aggregation PolicyVariableInSimplePolicyAction relates
a SimplePolicyAction to a single variable instance. Similarly, the
aggregation PolicyValueInSimplePolicyAction relates a
SimplePolicyAction to a single value instance. Both aggregations are
defined in this document.
NAME SimplePolicyAction
DESCRIPTION A subclass of PolicyAction that introduces the
notion of "SET variable TO value".
DERIVED FROM PolicyAction
ABSTRACT FALSE
PROPERTIES (none)
6.8. The Class "CompoundPolicyAction"
The CompoundPolicyAction class is used to represent an expression
consisting of an ordered sequence of action terms. Each action term
is represented as a subclass of the PolicyAction class, defined in
[PCIM]. Compound actions are constructed by associating dependent
action terms together using the PolicyActionInPolicyAction
aggregation.
The class definition is as follows:
NAME CompoundPolicyAction
DESCRIPTION A class for representing sequenced action terms.
Each action term is defined to be a subclass of the
PolicyAction class.
DERIVED FROM PolicyAction
ABSTRACT FALSE
PROPERTIES SequencedActions
ExecutionStrategy
This is a concrete class, and is therefore directly instantiable.
The Property SequencedActions is identical to the SequencedActions
property defined in PCIM for the class PolicyRule.
The property ExecutionStrategy defines the execution strategy to be
used upon the sequenced actions associated with this compound action.
(An equivalent ExecutionStrategy property is also defined for the
PolicyRule class, to provide the same indication for the sequenced
actions associated with a PolicyRule.) This document defines three
execution strategies:
Do Until Success - execute actions according to predefined order,
until successful execution of a single sub-action.
Do All - execute ALL actions which are part of the modeled
set, according to their predefined order.
Continue doing this, even if one or more of the
sub-actions fails.
Do Until Failure - execute actions according to predefined order,
until the first failure in execution of a single
sub-action.
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
DESCRIPTION An enumeration indicating how to interpret the
action ordering for the actions aggregated by this
CompoundPolicyAction.
SYNTAX uint16 (ENUM, {1=Do Until Success, 2=Do All, 3=Do
Until Failure} )
DEFAULT VALUE Do All (2)
6.9. The Abstract Class "PolicyVariable"
Variables are used for building individual conditions. The variable
specifies the property of a flow or an event that should be matched
when evaluating the condition. However, not every combination of a
variable 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 number. A given variable selects the set of
matchable value types.
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 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 matched to the source-port variable, even though they
are of the correct data type. Constraints for a given variable are
indicated through the ExpectedPolicyValuesForVariable association.
The PolicyVariable is an abstract class. Implicit and explicit
context variable classes are defined as sub classes of the
PolicyVariable class. A set of implicit variables is defined in this
document as well.
The class definition is as follows:
NAME PolicyVariable
DERIVED FROM Policy
ABSTRACT TRUE
PROPERTIES (none)
6.10. The Class "PolicyExplicitVariable"
Explicitly defined policy variables are evaluated within the context
of the CIM Schema and its modeling constructs. The
PolicyExplicitVariable class indicates the exact model property to be
evaluated or manipulated. See Section 5.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:
NAME PolicyExplicitVariable
DERIVED FROM PolicyVariable
ABSTRACT False
PROPERTIES ModelClass, ModelProperty
6.10.1. The Single-Valued Property "ModelClass"
This property is a string specifying the class name whose property is
evaluated or set as a PolicyVariable.
The property is defined as follows:
NAME ModelClass
SYNTAX String
6.10.2. The Single-Valued Property ModelProperty
This property is a string specifying the property name, within the
ModelClass, which is evaluated or set as a PolicyVariable. The
property is defined as follows:
NAME ModelProperty
SYNTAX String
6.11. The Abstract Class "PolicyImplicitVariable"
Implicitly defined policy variables are evaluated outside of the
context of the CIM Schema and its modeling constructs. Subclasses
specify the data type and semantics of the PolicyVariables.
Interpretation and evaluation of a PolicyImplicitVariable can vary,
depending on the particular context in which it is used. For
example, a "SourceIP" address may denote the source address field of
an IP packet header, or the sender address delivered by an RSVP PATH
message.
The class definition is as follows:
NAME PolicyImplicitVariable
DERIVED FROM PolicyVariable
ABSTRACT True
PROPERTIES ValueTypes[ ]
6.11.1. The Multi-Valued Property "ValueTypes"
This property is a set of strings specifying an unordered list of
possible value/data types that can be used in simple conditions and
actions, with this variable. The value types are specified by their
class names (subclasses of PolicyValue such as PolicyStringValue).
The list of class names enables an application to search on a
specific name, as well as to ensure that the data type of the
variable is of the correct type.
The list of default ValueTypes for each subclass of
PolicyImplicitVariable is specified within that variable's
definition.
The property is defined as follows:
NAME ValueTypes
SYNTAX String
6.12. Subclasses of "PolicyImplicitVariable" Specified in PCIMe
The following subclasses of PolicyImplicitVariable are defined in
PCIMe.
6.12.1. The Class "PolicySourceIPv4Variable"
NAME PolicySourceIPv4Variable
DESCRIPTION The source IPv4 address. of the outermost IP 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:
- PolicyIPv4AddrValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.2. The Class "PolicySourceIPv6Variable"
NAME PolicySourceIPv6Variable
DESCRIPTION The source IPv6 address of the outermost IP 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:
- PolicyIPv6AddrValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.3. The Class "PolicyDestinationIPv4Variable"
NAME PolicyDestinationIPv4Variable
DESCRIPTION The destination IPv4 address of the outermost IP
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:
- PolicyIPv4AddrValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.4. The Class "PolicyDestinationIPv6Variable"
NAME PolicyDestinationIPv6Variable
DESCRIPTION The destination IPv6 address of the outermost IP
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:
- PolicyIPv6AddrValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.5. The Class "PolicySourcePortVariable"
NAME PolicySourcePortVariable
DESCRIPTION Ports are defined as the abstraction that transport
protocols use to distinguish among multiple
destinations within a given host computer. For TCP
and UDP flows, the PolicySourcePortVariable is
logically bound to the source port field of the
outermost UDP or TCP packet header. "Outermost"
here refers to the IP packet as it flows on the
wire, before any headers have been stripped from
it.
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..65535)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.6. The Class "PolicyDestinationPortVariable"
NAME PolicyDestinationPortVariable
DESCRIPTION Ports are defined as the abstraction that transport
protocols use to distinguish among multiple
destinations within a given host computer. For TCP
and UDP flows, the PolicyDestinationPortVariable is
logically bound to the destination port field of the
outermost UDP or TCP packet header. "Outermost"
here refers to the IP packet as it flows on the
wire, before any headers have been stripped from it.
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..65535)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.7. The Class "PolicyIPProtocolVariable"
NAME PolicyIPProtocolVariable
DESCRIPTION The IP protocol number.
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..255)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.8. The Class "PolicyIPVersionVariable"
NAME PolicyIPVersionVariable
DESCRIPTION The IP version number. The well-known values are 4
and 6.
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..15)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.9. The Class "PolicyIPToSVariable"
NAME PolicyIPToSVariable
DESCRIPTION The IP TOS octet.
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..255)
- PolicyBitStringValue (8 bits)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.10. The Class "PolicyDSCPVariable"
NAME PolicyDSCPVariable
DESCRIPTION The 6 bit Differentiated Service Code Point.
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..63)
- PolicyBitStringValue (6 bits)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.11. The Class "PolicyFlowIdVariable"
NAME PolicyFlowIdVariable
DESCRIPTION The flow identifier of the outermost IPv6 packet
header. "Outermost" here refers to the IP packet as
it flows on the wire, before any headers have been
stripped from it.
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..1048575
- PolicyBitStringValue (20 bits)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.12. The Class "PolicySourceMACVariable"
NAME PolicySourceMACVariable
DESCRIPTION The source MAC address.
ALLOWED VALUE TYPES:
- PolicyMACAddrValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.13. The Class "PolicyDestinationMACVariable"
NAME PolicyDestinationMACVariable
DESCRIPTION The destination MAC address.
ALLOWED VALUE TYPES:
- PolicyMACAddrValue
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.14. The Class "PolicyVLANVariable"
NAME PolicyVLANVariable
DESCRIPTION The virtual Bridged Local Area Network Identifier, a
12-bit field as defined in the IEEE 802.1q standard.
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..4095)
- PolicyBitStringValue (12 bits)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.15. The Class "PolicyCoSVariable"
NAME PolicyCoSVariable
DESCRIPTION Class of Service, a 3-bit field, used in the layer 2
header to select the forwarding treatment. Bound to
the IEEE 802.1q user-priority field.
ALLOWED VALUE TYPES:
- PolicyIntegerValue (0..7)
- PolicyBitStringValue (3 bits)
DERIVED FROM PolicyImplicitVariable
ABSTRACT FALSE
PROPERTIES (none)
6.12.16. The Class "PolicyEthertypeVariable"
NAME PolicyEthertypeVariable
DESCRIPTION The Ethertype protocol number of Ethernet frames.
ALLOWED VALUE TYPES: