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.