Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3460

Policy Core Information Model (PCIM) Extensions

Pages: 93
Proposed Standard
Updates:  3060
Part 2 of 4 – Pages 13 to 44
First   Prev   Next

Top   ToC   RFC3460 - Page 13   prevText

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:
Top   ToC   RFC3460 - Page 14
   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
Top   ToC   RFC3460 - Page 15
   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.
Top   ToC   RFC3460 - Page 16

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.
Top   ToC   RFC3460 - Page 17

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.
Top   ToC   RFC3460 - Page 18
   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
Top   ToC   RFC3460 - Page 19
   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
Top   ToC   RFC3460 - Page 20
   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
Top   ToC   RFC3460 - Page 21
      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
Top   ToC   RFC3460 - Page 22
   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.
Top   ToC   RFC3460 - Page 23
   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
Top   ToC   RFC3460 - Page 24
   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
Top   ToC   RFC3460 - Page 25
   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.
Top   ToC   RFC3460 - Page 26
   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.
Top   ToC   RFC3460 - Page 27

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
Top   ToC   RFC3460 - Page 28
   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.
Top   ToC   RFC3460 - Page 29

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
Top   ToC   RFC3460 - Page 30
   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.
Top   ToC   RFC3460 - Page 31

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
Top   ToC   RFC3460 - Page 32
   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.
Top   ToC   RFC3460 - Page 33
                          +-----------------------+
                          | 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.
Top   ToC   RFC3460 - Page 34
   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.
Top   ToC   RFC3460 - Page 35
                              +-----------------------+
                              | 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.
Top   ToC   RFC3460 - Page 36

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
Top   ToC   RFC3460 - Page 37
   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
Top   ToC   RFC3460 - Page 38
   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.
Top   ToC   RFC3460 - Page 39
   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
Top   ToC   RFC3460 - Page 40
      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.
Top   ToC   RFC3460 - Page 41

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
Top   ToC   RFC3460 - Page 42
   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.
Top   ToC   RFC3460 - Page 43
   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
Top   ToC   RFC3460 - Page 44
   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.



(page 44 continued on part 3)

Next Section