RFC 3060
Policy Core Information Model -- Version 1 Specification
3. Overview of the Policy Core Information Model
The following diagram provides an overview of the five central classes comprising the Policy Core Information Model, their associations to each other, and their associations to other classes in the overall CIM model. Note that the abstract class Policy and the two extension classes VendorPolicyCondition and VendorPolicyAction are not shown. NOTE: For cardinalities, "*" is an abbreviation for "0..n".
+-----------+ | System | ..... +--^-----^--+ ..... . . 1. 1. . . *.(a).* .(b) .(c) *.(d).* +--v---v---------+ . . +-v---v------------+ | PolicyGroup <........ . | PolicyRepository | | | w * . | | +------^---------+ . +-----^---------^--+ *. . 0..1 . 0..1 . .(e) . .(f) .(g) *. . . . +------v------+ w * . . . | <................. . . | PolicyRule | . . | | . . | | . . | <........................ . . | |* (h) . . . | | . . . | | . . . | | . . . | | . . . | | . . . | | . . . | | .* .* . | | +---------v-------v--+ . | | | PolicyCondition | . | | *+--------------------+ . | | (i) ^ . | <.............. I . | |* . I . | | .* ^ . | | +----v----------------------+ . | | | PolicyTimePeriodCondition | . | | +---------------------------+ . | | (j) . | <......................... . | |* . . | | .* . | | +----------v---------+* . | | | PolicyAction <....... +-------------+ +--------------------+ Figure 1. Overview of the Core Policy Classes and Relationships
In this figure the boxes represent the classes, and the dotted arrows
represent the associations. The following associations appear:
(a) PolicyGroupInPolicyGroup
(b) PolicyGroupInSystem
(c) PolicyRuleInSystem
(d) PolicyRepositoryInPolicyRepository
(e) PolicyRuleInPolicyGroup
(f) PolicyConditionInPolicyRepository
(g) PolicyActionInPolicyRepository
(h) PolicyConditionInPolicyRule
(i) PolicyRuleValidityPeriod
(j) PolicyActionInPolicyRule
An association always connects two classes. The "two" classes may,
however, be the same class, as is the case with the
PolicyGroupInPolicyGroup association, which represents the recursive
containment of PolicyGroups in other PolicyGroups. The
PolicyRepositoryInPolicyRepository association is recursive in the
same way.
An association includes cardinalities for each of the related
classes. These cardinalities indicate how many instances of each
class may be related to an instance of the other class. For example,
the PolicyRuleInPolicyGroup association has the cardinality range "*'
(that is, "0..n") for both the PolicyGroup and PolicyRule classes.
These ranges are interpreted as follows:
o The "*" written next to PolicyGroup indicates that a PolicyRule
may be related to no PolicyGroups, to one PolicyGroup, or to more
than one PolicyGroup via the PolicyRuleInPolicyGroup association.
In other words, a PolicyRule may be contained in no PolicyGroups,
in one PolicyGroups, or in more than one PolicyGroup.
o The "*" written next to PolicyRule indicates that a PolicyGroup
may be related to no PolicyRules, to one PolicyRule, or to more
than one PolicyRule via the PolicyRuleInPolicyGroup association.
In other words, a PolicyGroup may contain no PolicyRules, one
PolicyRule, or more than one PolicyRule.
The "w" written next to the PolicyGroupInSystem and PolicyRuleInSystem indicates that these are what CIM terms "aggregations with weak references", or more briefly, "weak aggregations". A weak aggregation is simply an indication of a naming scope. Thus these two aggregations indicate that an instance of a PolicyGroup or PolicyRule is named within the scope of a System object. A weak aggregation implicitly has the cardinality 1..1 at the end opposite the 'w'. The associations shown in Figure 1 are discussed in more detail in Section 7.4. Inheritance Hierarchies for the Policy Core Information Model
The following diagram illustrates the inheritance hierarchy for the core policy classes: ManagedElement (abstract) | +--Policy (abstract) | | | +---PolicyGroup | | | +---PolicyRule | | | +---PolicyCondition (abstract) | | | | | +---PolicyTimePeriodCondition | | | | | +---VendorPolicyCondition | | | +---PolicyAction (abstract) | | | +---VendorPolicyAction | +--ManagedSystemElement (abstract) | +--LogicalElement (abstract) | +--System (abstract) | +--AdminDomain (abstract) | +---PolicyRepository Figure 2. Inheritance Hierarchy for the Core Policy Classes
ManagedElement, ManagedSystemElement, LogicalElement, System, and AdminDomain are defined in the CIM schema [1]. These classes are not discussed in detail in this document. In CIM, associations are also modeled as classes. For the Policy Core Information Model, the inheritance hierarchy for the associations is as follows: [unrooted] | +---PolicyComponent (abstract) | | | +---PolicyGroupInPolicyGroup | | | +---PolicyRuleInPolicyGroup | | | +---PolicyConditionInPolicyRule | | | +---PolicyRuleValidityPeriod | | | +---PolicyActionInPolicyRule | +---Dependency (abstract) | | | +---PolicyInSystem (abstract) | | | +---PolicyGroupInSystem | | | +---PolicyRuleInSystem | | | +---PolicyConditionInPolicyRepository | | | +---PolicyActionInPolicyRepository | +---Component (abstract) | +---SystemComponent | +---PolicyRepositoryInPolicyRepository Figure 3. Inheritance Hierarchy for the Core Policy Associations The Dependency, Component, and SystemComponent associations are defined in the CIM schema [1], and are not discussed further in this document.
4.1. Implications of CIM Inheritance
From the CIM schema, both properties and associations are inherited to the Policy classes. For example, the class ManagedElement is referenced in the associations Dependency, Statistics and MemberOfCollection. And, the Dependency association is in turn referenced in the DependencyContext association. At this very abstract and high level in the inheritance hierarchy, the number of these associations is very small and their semantics are quite general. Many of these inherited associations convey additional semantics that are not needed in understanding the Policy Core Information Model. In fact, they are defined as OPTIONAL in the CIM Schema - since their cardinality is "0..n" on all references. The PCIM document specifically discusses what is necessary to support and instantiate. For example, through subclassing of the Dependency association, the exact Dependency semantics in PCIM are described. So, one may wonder what to do with these other inherited associations. The answer is "ignore them unless you need them". You would need them to describe additional information and semantics for policy data. For example, it may be necessary to capture statistical data for a PolicyRule (either for the rule in a repository or for when it is executing in a policy system). Some examples of statistical data for a rule are the number of times it was downloaded, the number of times its conditions were evaluated, and the number of times its actions were executed. (These types of data would be described in a subclass of CIM_StatisticalInformation.) In these cases, the Statistics association inherited from ManagedElement to PolicyRule may be used to describe the tie between an instance of a PolicyRule and the set of statistics for it.5. Details of the Model
The following subsections discuss several specific issues related to the Policy Core Information Model.5.1. Reusable versus Rule-Specific Conditions and Actions
Policy conditions and policy actions can be partitioned into two groups: ones associated with a single policy rule, and ones that are reusable, in the sense that they may be associated with more than one policy rule. Conditions and actions in the first group are termed "rule-specific" conditions and actions; those in the second group are characterized as "reusable".
It is important to understand that the difference between a rule- specific condition or action and a reusable one is based on the intent of the policy administrator for the condition or action, rather than on the current associations in which the condition or action participates. Thus a reusable condition or action (that is, one that a policy administrator has created to be reusable) may at some point in time be associated with exactly one policy rule, without thereby becoming rule-specific. There is no inherent difference between a rule-specific condition or action and a reusable one. There are, however, differences in how they are treated in a policy repository. For example, it's natural to make the access permissions for a rule-specific condition or action identical to those for the rule itself. It's also natural for a rule-specific condition or action to be removed from the policy repository at the same time the rule is. With reusable conditions and actions, on the other hand, access permissions and existence criteria must be expressible without reference to a policy rule. The preceding paragraph does not contain an exhaustive list of the ways in which reusable and rule-specific conditions should be treated differently. Its purpose is merely to justify making a semantic distinction between rule-specific and reusable, and then reflecting this distinction in the policy model itself. An issue is highlighted by reusable and rule-specific policy conditions and policy actions: the lack of a programmatic capability for expressing complex constraints involving multiple associations. Taking PolicyCondition as an example, there are two aggregations to look at. PolicyConditionInPolicyRule has the cardinality * at both ends, and PolicyConditionInPolicyRepository has the cardinality * at the PolicyCondition end, and [0..1] at the PolicyRepository end. Globally, these cardinalities are correct. However, there's more to the story, which only becomes clear if we examine the cardinalities separately for the two cases of a rule-specific PolicyCondition and a reusable one. For a rule-specific PolicyCondition, the cardinality of PolicyConditionInPolicyRule at the PolicyRule end is [1..1], rather than [0..n] (recall that * is an abbreviation for [0..n]), since the condition is unique to one policy rule. And the cardinality of PolicyConditionInPolicyRepository at the PolicyRepository end is [0..0], since the condition is not in the "re-usable" repository. This is OK, since these are both subsets of the specified cardinalities.
For a reusable PolicyCondition, however, the cardinality of PolicyConditionInPolicyRepository at the PolicyRepository end is [1..1], since the condition must be in the repository. And, the cardinality of PolicyConditionInPolicyRule at the PolicyRule end is [0..n]. This last point is important: a reusable PolicyCondition may be associated with 0, 1, or more than 1 PolicyRules, via exactly the same association PolicyConditionInPolicyRule that binds a rule- specific condition to its PolicyRule. Currently the only way to document constraints of this type is textually. More formal methods for documenting complex constraints are needed.5.2. Roles
5.2.1. Roles and Role Combinations
The concept of role is central to the design of the entire Policy Framework. The idea behind roles is a simple one. Rather than configuring, and then later having to update the configuration of, hundreds or thousands (or more) of resources in a network, a policy administrator assigns each resource to one or more roles, and then specifies the policies for each of these roles. The Policy Framework is then responsible for configuring each of the resources associated with a role in such a way that it behaves according to the policies specified for that role. When network behavior must be changed, the policy administrator can perform a single update to the policy for a role, and the Policy Framework will ensure that the necessary configuration updates are performed on all the resources playing that role. A more formal definition of a role is as follows: A role is a type of attribute that is used to select one or more policies for a set of entities and/or components from among a much larger set of available policies. Roles can be combined together. Here is a formal definition of a "role- combination": A role-combination is a set of attributes that are used to select one or more policies for a set of entities and/or components from among a much larger set of available policies. As the examples below illustrate, the selection process for a role combination chooses policies associated with the combination itself, policies associated with each of its sub-combinations, and policies associated with each of the individual roles in the role- combination.
It is important to note that a role is more than an attribute. A
role defines a particular function of an entity or component that can
be used to identify particular behavior associated with that entity
or component. This difference is critical, and is most easily
understood by thinking of a role as a selector. When used in this
manner, one role (or role-combination) selects a different set of
policies than a different role (or role-combination) does.
Roles and role-combinations are especially useful in selecting which
policies are applicable to a particular set of entities or components
when the policy repository can store thousands or hundreds of
thousands of policies. This use emphasizes the ability of the role
(or role- combination) to select the small subset of policies that
are applicable from a huge set of policies that are available.
An example will illustrate how role-combinations actually work.
Suppose an installation has three roles defined for interfaces:
"Ethernet", "Campus", and "WAN". In the Policy Repository, some
policy rules could be associated with the role "Ethernet"; these
rules would apply to all Ethernet interfaces, regardless of whether
they were on the campus side or the WAN side. Other rules could be
associated with the role-combination "Campus"+"Ethernet"; these rules
would apply to the campus-side Ethernet interfaces, but not to those
on the WAN side. Finally, a third set of rules could be associated
with the role-combination "Ethernet"+"WAN"; these rules would apply
to the WAN-side Ethernet interfaces, but not to those on the campus
side. (The roles in a role-combination appear in alphabetical order
in these examples, because that is how they appear in the information
model.)
If we have a specific interface A that's associated with the role-
combination "Ethernet"+"WAN", we see that it should have three
categories of policy rules applied to it: those for the "Ethernet"
role, those for the "WAN" role, and those for the role-combination
"Ethernet"+"WAN". Going one step further, if interface B is
associated with the role- combination "branch-
office"+"Ethernet"+"WAN", then B should have seven categories of
policy rules applied to it - those associated with the following
role-combinations:
o "branch-office"
o "Ethernet"
o "WAN"
o "branch-office"+"Ethernet"
o "branch-office"+"WAN"
o "Ethernet"+"WAN"
o "branch-office"+"Ethernet"+"WAN".
In order to get all of the right policy rules for a resource like
interface B, a PDP must expand the single role-combination it
receives for B into this list of seven role-combinations, and then
retrieve from the Policy Repository the corresponding seven sets of
policy rules. Of course this example is unusually complicated: the
normal case will involve expanding a two-role combination into three
values identifying three sets of policy rules.
Role-combinations also help to simplify somewhat the problem of
identifying conflicts between policy rules. With role-combinations,
it is possible for a policy administrator to specify one set of
policy rules for campus-side Ethernet interfaces, and a second set of
policy rules for WAN-side Ethernet interfaces, without having to
worry about conflicts between the two sets of rules. The policy
administrator simply "turns off" conflict detection for these two
sets of rules, by telling the policy management system that the roles
"Campus" and "WAN" are incompatible with each other. This indicates
that the role combination will never occur, and therefore conflicts
will never occur. In some cases the technology itself might identify
incompatible roles: "Ethernet" and "FrameRelay", for example. But
for less precise terms like "Campus" and "WAN", the policy
administrator must say whether they identify incompatible roles.
When the policy administrator does this, there are three effects:
1. If an interface has assigned to it a role-combination involving
both "Campus" and "WAN", then the policy management system can
flag it as an error.
2. If a policy rule is associated with a role-combination involving
both "Campus" and "WAN", then the policy management system can
flag it as an error.
3. If the policy management system sees two policy rules, where one
is tied to the role "Campus" (or to a role-combination that
includes the role "Campus") and the other is tied to the role
"WAN" (or to a role- combination that includes the role "WAN"),
then the system does not need to look for conflicts between the
two policy rules: because of the incompatible roles, the two
rules cannot possibly conflict.
+-------------------+ | Policy Repository | +-------------------+ V V retrieval of policy V +---------+ | PDP/PEP | +---------+ v v application of policy v +----------------+ | Network Entity | +----------------+ Figure 4. Retrieval and Application of a Policy Figure 4, which is introduced only as an example of how the Policy Framework might be implemented by a collection of network components, illustrates how roles operate within the Policy Framework. Because the distinction between them is not important to this discussion, the PDP and the PEP are combined in one box. The points illustrated here apply equally well, though, to an environment where the PDP and the PEP are implemented separately. A role represents a functional characteristic or capability of a resource to which policies are applied. Examples of roles include Backbone interface, Frame Relay interface, BGP-capable router, web server, firewall, etc. The multiple roles assigned to a single resource are combined to form that resource's role combination. Role combinations are represented in the PCIM by values of the PolicyRoles property in the PolicyRule class. A PDP uses policy roles as follows to identify the policies it needs to be aware of: 1. The PDP learns in some way the list of roles that its PEPs play. This information might be configured at the PDP, the PEPs might supply it to the PDP, or the PDP might retrieve it from a repository. 2. Using repository-specific means, the PDP determines where to look for policy rules that might apply to it. 3. Using the roles and role-combinations it received from its PEPs as indicated in the examples above, the PDP is able to locate and retrieve the policy rules that are relevant to it.
5.2.2. The PolicyRoles Property
As indicated earlier, PolicyRoles is a property associated with a policy rule. It is an array holding "role combinations" for the policy rule, and correlates with the roles defined for a network resource. Using the PolicyRoles property, it is possible to mark a policy rule as applying, for example, to a Frame Relay interface or to a backbone ATM interface. The PolicyRoles property take strings of the form: <RoleName>[&&<RoleName>]* Each value of this property represents a role combination, including the special case of a "combination" containing only one role. As the format indicates, the role names in a role combination are ANDed together to form a single selector. The multiple values of the PolicyRoles property are logically ORed, to make it possible for a policy rule to have multiple selectors. The individual role names in a role combination must appear in alphabetical order (according to the collating sequence for UCS-2 characters), to make the string matches work correctly. The role names used in an environment are specified by the policy administrator.5.3. Local Time and UTC Time in PolicyTimePeriodConditions
An instance of PolicyTimePeriodCondition has up to five properties that represent times: TimePeriod, MonthOfYearMask, DayOfMonthMask, DayOfWeekMask, and TimeOfDayMask. All of the time-related properties in an instance of PolicyTimePeriodCondition represent one of two types of times: local time at the place where a policy rule is applied, or UTC time. The property LocalOrUtcTime indicates which time representation applies to an instance of PolicyTimePeriodCondition. Since the PCIM provides only for local time and UTC time, a Policy Management Tool that provides for other time representations (for example, a fixed time at a particular location) will need to map from these other representations to either local time or UTC time. An example will illustrate the nature of this mapping. Suppose a policy rule is tied to the hours of operation for a Help Desk: 0800 to 2000 Monday through Friday [US] Eastern Time. In order to express these times in PolicyTimePeriodCondition, a management tool must convert them to UTC times. (They are not local times, because they refer to a single time interval worldwide, not to intervals tied to the local clocks at the locations where the
PolicyRule is being applied.) As reference [10] points out, mapping from [US] Eastern Time to UTC time is not simply a matter of applying an offset: the offset between [US] Eastern Time and UTC time switches between -0500 and -0400 depending on whether Daylight Savings Time is in effect in the US. Suppose the policy administrator's goal is to have a policy rule be valid from 0800 until 1200 [US] Eastern Time on every Monday, within the overall time period from the beginning of 2000 until the end of 2001. The Policy Management Tool could either be configured with the definition of what [US] Eastern Time means, or it could be configured with knowledge of where to go to get this information. Reference [10] contains further discussion of time zone definitions and where they might reside. Armed with knowledge about [US] Eastern Time, the Policy Management Tool would create however many instances of PolicyTimePeriodCondition it needed to represent the desired intervals. Note that while there is an increased number of PolicyTimePeriodCondition instances, there is still just one PolicyRule, which is tied to all the PolicyTimePeriodCondition instances via the aggregation PolicyRuleValidityPeriod. Here are the first two of these instances: 1. TimePeriod: 20000101T050000/20000402T070000 DayOfWeekMask: { Monday } TimeOfDayMask: T130000/T170000 LocalOrUtcTime: UTC 2. TimePeriod: 20000402T070000/20001029T070000 DayOfWeekMask: { Monday } TimeOfDayMask: T120000/T160000 LocalOrUtcTime: UTC There would be three more similar instances, for winter 2000-2001, summer 2001, and winter 2001 up through December 31. Had the example been chosen differently, there could have been even more instances of PolicyTimePeriodCondition. If, for example, the time interval had been from 0800 - 2200 [US] Eastern Time on Mondays, instance 1 above would have split into two instances: one with a UTC time interval of T130000/T240000 on Mondays, and another with a UTC time interval of T000000/T030000 on Tuesdays. So the end result would have been ten instances of PolicyTimePeriodCondition, not five. By restricting PolicyTimePeriodCondition to local time and UTC time, the PCIM places the difficult and expensive task of mapping from "human" time representations to machine-friendly ones in the Policy
Management Tool. Another approach would have been to place in PolicyTimePeriodCondition a means of representing a named time zone, such as [US] Eastern Time. This, however, would have passed the difficult mapping responsibility down to the PDPs and PEPs. It is better to have a mapping such as the one described above done once in a Policy Management Tool, rather than having it done over and over in each of the PDPs (and possibly PEPs) that need to apply a PolicyRule.5.4. CIM Data Types
Since PCIM extends the CIM Schema, a correspondence between data types used in both CIM and PCIM is needed. The following CIM data types are used in the class definitions that follow in Sections 6 and 7: o uint8 unsigned 8-bit integer o uint16 unsigned 16-bit integer o boolean Boolean o string UCS-2 string. Strings in CIM are stored as UCS-2 characters, where each character is encoded in two octets. Thus string values may need to be converted when moving between a CIM environment and one that uses a different string encoding. For example, in an LDAP-accessible directory, attributes of type DirectoryString are stored in UTF-8 format. RFC 2279 [7] explains how to convert between these two formats. When it is applied to a CIM string, a MaxLen value refers to the maximum number of characters in the string, rather than to the maximum number of octets. In addition to the CIM data types listed above, the association classes in Section 7 use the following type: o <classname> ref strongly typed reference. There is one obvious omission from this list of CIM data types: octet strings. This is because CIM treats octet strings as a derived data type. There are two forms of octet strings in CIM - an ordered uint8 array for single-valued strings, and a string array for multi- valued properties. Both are described by adding an "OctetString" qualifier (meta-data) to the property. This qualifier functions exactly like an SMIv2 (SNMP) Textual Convention, refining the syntax and semantics of the existing CIM data type.
The first four numeric elements of both of the "OctetString"
representations are a length field. (The reason that the "numeric"
adjective is added to the previous sentence is that the string
property also includes '0' and 'x', as its first characters.) In
both cases, these 4 numeric elements (octets) are included in
calculating the length. For example, a single-valued octet string
property having the value X'7C' would be represented by the uint8
array, X'00 00 00 05 7C'.
The strings representing the individual values of a multi-valued
property qualified with the "OctetString" qualifier are constructed
similarly:
1. Take a value to be encoded as an octet string (we'll use X'7C' as
above), and prepend to it a four-octet length. The result is the
same, X'00 00 00 05 7C'.
2. Convert this to a character string by introducing '0' and 'x' at
the front, and removing all white space. Thus we have the 12-
character string "0x000000057C". This string is the value of one
of the array elements in the CIM string array. Since CIM uses the
UCS-2 character set, it will require 24 octets to encode this 12-
character string.
Mappings of the PCIM to particular data models are not required to
follow this CIM technique of representing multi-valued octet strings
as length- prefixed character strings. In an LDAP mapping, for
example, it would be much more natural to simply use the Octet String
syntax, and omit the prepended length octets.
5.5. Comparison between CIM and LDAP Class Specifications
There are a number of differences between CIM and LDAP class
specifications. The ones that are relevant to the abbreviated class
specifications in this document are listed below. These items are
included here to help introduce the IETF community, which is already
familiar with LDAP, to CIM modeling, and by extension, to information
modeling in general.
o Instead of LDAP's three class types (abstract, auxiliary,
structural), CIM has only two: abstract and instantiable. The
type of a CIM class is indicated by the Boolean qualifier
ABSTRACT.
o CIM uses the term "property" for what LDAP terms an "attribute".
o CIM uses the array notation "[ ]" to indicate that a property is
multi-valued. CIM defines three types of arrays: bags (contents
are unordered, duplicates allowed), ordered bags (contents are
ordered but duplicates are allowed) and indexed arrays (contents
are ordered and no duplicates are allowed).
o CIM classes and properties are identified by name, not by OID.
o CIM classes use a different naming scheme for native
implementations, than LDAP. The CIM naming scheme is documented
in Appendix A since it is not critical to understanding the
information model, and only applies when communicating with a
native CIM implementation.
o In LDAP, attribute definitions are global, and the same attribute
may appear in multiple classes. In CIM, a property is defined
within the scope of a single class definition. The property may
be inherited into subclasses of the class in which it is defined,
but otherwise it cannot appear in other classes. One side effect
of this difference is that CIM property names tend to be much
shorter than LDAP attribute names, since they are implicitly
scoped by the name of the class in which they are defined.
There is also a notational convention that this document follows, to
improve readability. In CIM, all class and property names are
prefixed with the characters "CIM_". These prefixes have been
omitted throughout this document, with one exception regarding
naming, documented in Appendix A.
For the complete definition of the CIM specification language, see
reference [2].
(page 25 continued on part 3)
