|
DMTF Tutorial
> CIM > CIM
Schema > Common Models > Policy Model
 |
CIM Schema - Policy Model
|
 |
Overview | CIM Specification | CIM Schema | Extension Schema
Core Model
| Common Models
When used in the context of computer
systems, "policy" is a term that is frequently used to describe
any system configuration that controls system behaviors such as
in "security policies" or "quality of service policies." In general,
a "policy" is a "definite goal, course or method of action to guide
and determine present and future decisions." Policies
can specify resource management directives and, at a higher level
of abstraction such as in a service-level objective, policies can
also specify user experience management directives. The DMTF Policy
Model provides a common framework for specifying system behaviors
that are both sufficiently abstract to be independent of implementation-specific
details and scalable to configuring large complexes of computer
systems, i.e., the DMTF Policy Model is a specific model for expressing
such policies in a general and scalable way.
Developed jointly 1
by the IETF and the DMTF, the Policy Model is an object-oriented
model that enables constructing policy rules of the form:
if <condition(s)> then <action(s)>.
The <condition(s)> term is a Boolean expression used to specify
the rule selection criteria. These criteria may include temporal
conditions (when does the rule apply), scoping conditions (to what
does the rule apply) and state-related conditions (under what circumstances
should the action(s) of the rule be attempted). When, for a resource
under management, the <condition(s)> expression evaluates
to True, the <action(s)> portion of the rule is attempted.
These conditional directives are an implementation-independent description
for the common aspects of system administration. However, the Policy
Model does not, by itself, provide the abstracted specification.
For a discipline, e.g., IPsec-based VPN, network quality of service,
etc., a set of subclasses are defined to capture the necessary semantics
to express rules in that discipline.
The scalability is provided, in part, by the abstractions that
also enable implementation-independence and, in part, by a role-based
deployment framework. A policy role is an administratively
assigned name for the enforcement role played by an entity that
consumes sets of policy rules. The sets of rules are flagged with
one or more policy roles for which they apply and the enforcement
points know the roles that they play. The deployment infrastructure,
then, delivers the appropriate policy rules to the enforcement points
based on these named relationships. For example, rules marked with
the policy role “DMZ Web Server” would be delivered to those web
servers that are located in the DMZ of the administrative domain.
Similarly, rules that are intended for use with Ethernet interfaces
facing the Internet in the DMZ might be flagged with the policy
role "DMZ External Ethernet" and the security gateways playing that
role, i.e., in the DMZ and with externally facing Ethernet interfaces,
would be recipients of these rules.
The CIM PolicyRule class is the central class used to aggregate
PolicyCondition and PolicyAction object instances. PolicyRule instances
may be aggregated into instances of PolicyGroup instances to form
coherent sets with the same Policy Role value(s). Actually, a PolicySet
is a common abstraction for PolicyRule and PolicyGroup because both
classes can aggregate PolicySet (PolicyRule and PolicyGroup) instances.
A PolicySet, then, forms a coherent set with a common set of PolicyRole
values and a decision strategy for selecting, based upon priority,
which of the rules or sets of rules in the aggregation are to be
evaluated. The PolicyRoleCollection class (not shown here) is used
to identify the roles played by enforcement points that need to
consume the PolicySets identified by PolicyRole. The PolicyRole,
and therefore the elements collected in the PolicyRoleCollection,
identifies the resource(s) to be managed using the PolicySet. So,
for example, if the PolicyRole is "Ethernet Interface" the enforcement
points that consume these PolicySets are the enforcement points
that manage Ethernet interfaces and it is the Ethernet interfaces
that are collected into the PolicyRoleCollection instance.
For CIM 2.7, there is only one decision strategy defined, FirstMatching,
for which the aggregated PolicySet instances are evaluated by priority
and the actions of only the highest priority PolicySet that matches
(conditions evaluate to True) are attempted. Clearly, when the aggregated
policy set is a PolicyGroup instance, it doesn't have conditions
that can be evaluated, but it is selected in turn by priority and
then, recursively, its decision strategy and priorities are applied.
For further details, the Policy White Paper, UML diagram and MOF
should be consulted.
-
The IETF Policy Core Information Model [RFC3060]
and Policy Core Information Model Extensions [RFC3460] is a
superset of the CIM 2.7 Policy Model. There are a few functions
included in the IETF specifications that are not included in
the DMTF model pending further analysis.
|
