Purpose of the PCIM

1. Purpose of the PCIM • Provide a set of classes and relationships that provide an extensible means for defining policy control of managed objects • Represents the structure, not the contents, of a policy • Content provided by subclassing classes to derive technology- and vendor-specific conditions, actions, and other elements

2. PCIM Overview (1) • Policy-based management assumes that the network is modeled as a state machine • Classes and relationships are used to model: • the state of an entity • settings to be applied to an entity that either maintain an entity’s state or move the entityto a new state • policies that control the application of settings

3. PCIM Overview (2) • Thus, policy is applied using a set of rules • Each rule has a set of conditions that specify when the policy should be applied • Conditions can be specified in CNF or DNF • Each rule has a set of actions that are executed if the conditions are TRUE • Execution order can be specified • Rules may be prioritized and grouped together to model an administrative hierarchy

4. Policy Core Model: Groups & Rules

5. Policy Class • Policy Class (Abstract) • Root of the policy tree • Carries common attributes to all policy classes • Caption, Description from CIM ME • OrderedCIMKeys to represent CIM hierarchy • cn from X.520 • PolicyKeywords • PolicyElementAuxClass is an aux class to represent this class and enables any object in the DIT to be identified as a policy class

6. PolicyRule • A PolicyRule consists of a set of conditions and a set of actions • Boolean logic assumed • If condition clause is TRUE, then action clause may execute • Rule-specific and reusable policy rules are supported by using the PolicyConditionInPolicyRule and PolicyActionInPolicyRule aggregations • Multiple time periods may be used to define a schedule for which this PolicyRule is active by using the PolicyRuleValidityPeriod aggregation • Rules may be prioritized

7. Types of PolicyRules • Rule-specific PolicyRules are those whose components are embedded in the PolicyRule itself. • The terms making up the PolicyRule can NOT be reused by other PolicyRules • Reusable PolicyRules share one or more components with other PolicyRules • PolicyRule components are stored in a common Policy Repository and referenced by the PolicyRules using them • Each has implementation implications

8. PolicyGroup • PolicyRules may be aggregated into PolicyGroups, which may be nested • Enables hierarchical representation of policy(per-user, per-domain, etc.) • Special semantics defined in QoS information model to represent different administrative scopes and groupings of rules

9. PolicyRepository • Represents an administratively-defined container for holding REUSABLE policy conditions and actions • May be extended to hold other types of reusable policy “building blocks” • May be nested to provide more granular domain control

10. PCIM: Conditions & Actions

11. Policy Conditions • Abstract base class for domain-specific conditions that will be defined by domain-specific models(e.g., QoS model, IPSec model) • Boolean condition expressed in CNF or DNF • Individual condition terms can be negated • Only defines keys (7 - System, PolicyRule, and its own CCN, Name, and a user-friendly name)

12. Expressing Policy Conditions • PolicyRule.ConditionListType defines how to interpret the condition (e.g., CNF or DNF) • PolicyConditionInPolicyRule contains two additional properties: • GroupNumber indicates the group to which the PolicyCondition belongs • ConditionNegated is a boolean that, if TRUE, indicates that this condition is negated

13. Reusable PolicyConditions • Stored in a PolicyRepository and referenced using the association PolicyConditionInPolicyRepository • Rule-specific PolicyConditions do NOT use this association; thus: • Cardinality is 0 for rule-specific, 1 for reusable • QPIM extends this so that different conditions can be stored in different portions of the repository • Different portions implies different scopes and application

14. PolicyTimePeriodCondition • Subclass of PolicyCondition to represent time when PolicyRule is active • If not specified, then rule is always active • PolicyRuleValidityPeriod is an aggregation that defines the set of time periods for a given PolicyRule • Instances may have up to 5 properties that together specify the time period • Property values are ANDed to determine the validity period; properties not present are treated as having their value always enabled

15. Policy Actions • Abstract base class for domain-specific actions that will be defined by domain-specific models • Deployed actions are bound to a System; reusable actions exist in a PolicyRepository • Only defines keys (7 - System, PolicyRule, and its own CCN and Name, and a user-friendly name) • Stored in a PolicyRepository and referenced using PolicyActionInPolicyRepository association • Rule-specific PolicyConditions do NOT use this association; thus, cardinality is 0 for rule-specific, 1 for reusable

16. Policy Actions (2) • PolicyActionInPolicyRule aggregation contains the set of action clauses for a given PolicyRule • ActionOrder property indicates relative position of an action in the sequence of actions associated with a PolicyRule • If n is a positive integer, it defines the order, with smaller integers being ordered first • 0 is a special value that indicates “don’t care” • Two or more properties with the same value can be executed in any order, as long as they are executed in the correct overall order in the sequence

17. Rule-Specific Policy Structure • PolicyRule is a container that holds PolicyConditions and PolicyActions • QPIM extends this so that a condition is treated as a container • To do this attachment • PolicyRule is a structural class • PolicyCondition and PolicyAction are both auxiliary classes

18. Rule-Specific Example Rule 1(structural) DN Pointer DN Pointer Represents associationbetween Rule 1and Condition 1 Represents associationbetween Rule 1and Action 1 Condition 1(structural) Action 1(structural) DITContainment Condition 1(aux attached) Action 1(aux attached) Represents the actionitself Represents the conditionitself

19. Reusable Components • Policy components can be specific to a rule or reusable among many rules • Rule-specific information is attached to the rule itself • Reusable information is stored in a container that is referenced by the rule • The only difference between a reusable and a rule-specific component is in the intent of the administrator • No difference in functionality

20. Reusable Components (2) • PCIM defines a policy repository to store reusable information. This causes some subtle differences, including: • access control can be specified for rule-specific conditions and actions, but not for reusable ones • referential integrity should be enforced for rule-specific elements; harder to due in the reusable case • mapping to a data model is more difficult

21. Reusable Rule Example Rule 1(structural) DIT Containment DIT Containment Represents associationbetween Rule 1and Condition 1 Represents associationbetween Rule 1and Action 1 Condition 1(structural) Action 1(structural) DN Pointer DN Pointer Represents theconditionitself Represents theactionitself Condition 1 Aux(aux attachment) Action 1 Aux(aux attachment) ConditionInstance(structural) ActionInstance(structural) DIT Containment DIT Containment PolicyRepository(structural)

22. PolicyInstance • Uses DIT content rules to allow a PolicyConditionAuxClass or a PolicyActionAuxClass to be attached to it • Uses DIT structure rules to enable it to be named using either PolicyInstanceName, cn, or OrderedCIMKeys

23. PolicySubtreesPtrAuxClass • This aux class provides a single multi-valued attribute to point to the root of a set of subtrees that contain policy information • Attaching this attribute to other class instances enables the administrator to define entry points to related policy information • Can be used to define the order of visiting information in the policy tree (e.g., for a PDP) • Can be used to tie different subtrees together

24. PolicyElementAuxClass • This class is the aux equivalent of the Policy class • Enables tagging of selected instances that are outside of the policy class hierarchy, but are nevertheless policy-related • This works through searching on oc=policy • Note that some directories don’t support this, so in these cases, policy-related entries must be tagged with the keyword Policy and searched on using an attribute search

25. Aux Containment Classes • PolicyGroupContainmentAuxClass and PolicyRuleContainmentAuxClass • Each contains a single multi-valued attribute that points to a set of PolicyGroups and PolicyRules, respectively • Enables the administrator to bind PolicyGroups/PolicyRules to a container

26. PCIM Extensions • New draft to simplify and encourage use of PCIM • PolicyRepository broadened & renamed • Rules may contain groups & other rules (context) • Priorities & decision strategies clarified • Refinements in the use of PolicyRoles • Compound conditions & actions (reusable) • Transactional semantics for action execution • Variables & values, for conditions & actions • Packet filtering in policy conditions based on variables/values

27. Building PolicyConditions • The PolicyConditionInPolicyRule association has properties that require special mapping • PolicyRuleConditionAssociation represents the properties and is attached via DIT containment • The conditions themselves are represented by the PolicyConditionAuxClass (and its subclasses) which are either • attached directly to instances of the PolicyRuleConditionAssociation for rule-specific classes, or • indirectly, using a DN pointer to refer to an instance of a PolicyConditionInstance class

28. PolicyRuleConditionAssociation (1) • Contains properties characterizing the relationship between a rule and a condition • PolicyConditionGroupNumber - used to group conditions according to CNF or DNF • PolicyConditionNegated - flag defining if a condition is negated or not • PolicyConditionDN - pointer to a reusable PolicyCondition (should be NULL if rule-specific)

29. PolicyRuleConditionAssociation (2) • Semantics defined using DIT structure and content rules • PolicyConditionAuxClass subclasses are attached using DIT content rules • Structure rules define naming, scoped by a PolicyRule, using either the OrderedCIMKeys, cn, or PolicyConditionName

30. PolicyConditionAuxClass • Used to bind conditions to rules • Rule-specific conditions defined by attaching this aux class to either an instance of the PolicyRuleConditionAssociation or the PolicyRule classes • Reusable conditions defined by attaching this aux class to an instance of the PolicyConditionInstance class • Note: this class is derived from Top because it attaches to classes already derived from Policy • otherwise we have property conflict!

31. Building PolicyActions • The PolicyConditionInPolicyRule association has properties that require special mapping • PolicyRuleActionAssociation represents the property and is attached via DIT containment • The actions themselves are represented by the PolicyActionAuxClass (and its subclasses) which are either • attached directly to instances of the PolicyRuleActionAssociation for rule-specific classes, or • indirectly, using a DN pointer to refer to an instance of a PolicyActionInstance class

32. PolicyRuleActionAssociation • Two properties • PolicyActionOrder determines the order of executing actions associated with a policy rule • PolicyActionDN - pointer to a reusable PolicyAction (should be NULL if rule-specific) • Semantics • PolicyActionAuxClass subclasses are attached using DIT content rules • Structure rules define naming, scoped by a PolicyRule, using either the OrderedCIMKeys, cn, or PolicyActionName

33. PolicyActionAuxClass • Used to bind actions to rules • Rule-specific conditions defined by attaching this aux class to either an instance of the PolicyRuleActionAssociation or the PolicyRule classes • Reusable conditions defined by attaching this aux class to an instance of the PolicyActionInstance class • Note: this class is derived from Top because it attaches to classes already derived from Policy • otherwise we have property conflict!

34. PolicyTimePeriodConditionAuxClass • Built as an aux class so it can be attached directly to a policy rule • Represents periods of time that define when a condition is valid • time period, plus month, day of month and week, and time of day masks

35. Structure of a Rule-Specific Policy • PolicyRule is a container that holds PolicyConditions and PolicyActions • QPIM extends this so that a condition is treated as a container • To do this attachment • PolicyRule is a structural class • PolicyCondition and PolicyAction are both auxiliary classes

36. Attachment • Info model defines PolicyRule relationships • PolicyConditionInPolicyRule attaches conditions to a PolicyRule • PolicyActionInPolicyRule attaches actions to a PolicyRule • PolicyRuleInPolicyGroup groups PolicyRules • PolicyRuleInSystem associates a PolicyRule with a System (e.g., a router or server) • There can be as many attached conditions and actions as required

37. Example Rule 1(structural) DN Pointer DN Pointer Represents associationbetween Rule 1and Condition 1 Represents associationbetween Rule 1and Action 1 Condition 1(structural) Action 1(structural) DITContainment Condition 1(aux attached) Action 1(aux attached) Represents the actionitself Represents the conditionitself

38. Defining Reusable Elements • Reusable elements are always stored in a special part of the DIT • Modeled using the PolicyRepository class • Attached (indirectly) using DN pointers to a rule • Since conditions and actions are aux classes, they need something to attach to • Rule-specific uses the PolicyRule itself • Reusable uses this class, which is stored in the PolicyRepository

39. PolicyInstance • Uses DIT content rules to allow a PolicyConditionAuxClass or a PolicyActionAuxClass to be attached to it • Uses DIT structure rules to enable it to be named using either PolicyInstanceName, cn, or OrderedCIMKeys

40. PolicyInstance Subclasses • Two subclasses, PolicyConditionInstance and PolicyActionInstance, are defined • Defines additional naming attributes (PolicyConditionName and PolicyActionName) • DIT content rules enable condition and action aux classes to be attached to it • DIT structure rules enable it to be named under an instance of PolicyRepository using any of its four attributes

41. PolicyRepository • This is a container for holding reusable policy elements • DIT structure rules enable it to be named under an instance of PolicyRepository using any of its four attributes

42. PolicySubtreesPtrAuxClass • This aux class provides a single multi-valued attribute to point to the root of a set of subtrees that contain policy information • Attaching this attribute to other class instances enables the administrator to define entry points to related policy information • Can be used to define the order of visiting information in the policy tree (e.g., for a PDP) • Can be used to tie different subtrees together

43. Aux Containment Classes • PolicyGroupContainmentAuxClass and PolicyRuleContainmentAuxClass • Each contains a single multi-valued attribute that points to a set of PolicyGroups and PolicyRules, respectively • Enables the administrator to bind PolicyGroups/PolicyRules to a container

44. PolicyElementAuxClass • This class is the aux equivalent of the Policy class • Enables tagging of selected instances that are outside of the policy class hierarchy, but are nevertheless policy-related • This works through searching on oc=policy • Note that some directories don’t support this, so in these cases, policy-related entries must be tagged with the keyword Policy and searched on using an attribute search

45. Example Rule 1(structural) DIT Containment DIT Containment Represents associationbetween Rule 1and Condition 1 Represents associationbetween Rule 1and Action 1 Condition 1(structural) Action 1(structural) DN Pointer DN Pointer Represents theconditionitself Represents theactionitself Condition 1 Aux(aux attachment) Action 1 Aux(aux attachment) ConditionInstance(structural) ActionInstance(structural) DIT Containment DIT Containment PolicyRepository(structural)

46. PolicyRepository • Used to define a “repository within a repository” for storing reusable data • DIT structure rules enable it to be named under an instance of PolicyRepository using any of its three attributes