Figure 1P-4. The Concept of Model Mapping

MODA / Information Framework / Business Entity / Patterns Domain / Policy ABE / Figure 1P-4. The Concept of Model Mapping

Project:

Figure 1P-4. The Concept of Model Mapping : Object diagram

Created:	5/11/2022 11:04:43 AM
Modified:	6/7/2022 9:17:05 PM
Project:
Author:	Natha Paquette
Version:	1.0.0
Advanced:
ID:	{99B706E1-E841-40f7-8899-BC62E2A3CF41}

Fundamental Policy Terminology The purpose of this section is to define important policy terminology as used in the rest of this Addendum. Basic Terminology The purpose of this section is to define basic terminology that this Addendum depends on and uses. Information Model An information model is an abstraction and representation of the entities in a managed environment. This includes definition of their attributes, operations and relationships. It is independent of any specific type of repository, software usage, or access protocol. Data Model A data model is a concrete implementation of an information model in terms appropriate to a specific type of repository that uses a specific access protocol or protocols. It includes data structures, operations, and rules that define how the data is stored, accessed and manipulated. Model Mapping A model mapping is a translation from one type of model to another type of model. Model mapping changes the representation and/or level of abstraction used in one model to another representation and/or level of abstraction in another model. Model mapping is an important concept and is used to enable different types of models to be related to each other. The most common form of model mapping is from an information model to a data model; another important form is from a vendor-neutral data model to a vendor-specific data model. Figure 1P- 1 below illustrates the concept of model mapping. The Figure below shows one form of model mapping. In this Figure, a particular Data Model (for example, a Directory) is defined as a mapping from an information model (for example, the SID). This mapping produces a directory implementation that is conformant with the appropriate standards (e.g., LDAP or X.500 as well as the SID). The second tier of mapping accounts for the fact that different vendors provide varying degrees of compliance with the directory standards. Thus, from the TM Forum point-of-view, a mapping must be able to integrate the standard system aspects (in this case, LDAP and/or X.500) with the Frameworx entity representations (as defined by the SID). Terms Defining the Representation of Policy The purpose of this section is to define terms that are used in the Policy model to build a standard representation of policy. Policy Policy is a set of rules that are used to manage and control the state and state transitions of one or more managed objects. PolicyRule A PolicyRule is an intelligent data container. It contains data that define how the PolicyRule is used in a managed environment as well as a specification of behavior that dictates how the managed entities that it applies to will interact. The contained data is of four types: (1) data and metadata that define the semantics and behavior of the policy rule and the behavior that it imposes on the rest of the system, (2) a group of events that can be used to trigger the evaluation of the condition clause of a policy rule, (3) a group of conditions aggregated by the PolicyRule, and (4) a group of actions aggregated by the PolicyRule. The Policy model is deceptively simple. It is a triplet, defined as an event clause, a condition clause, and an action clause. Here, “clause” simply means that one or more expressions can be used to define events, conditions and actions. Simply put, events are used to trigger the evaluation of one or more conditions. If the set of conditions evaluates to TRUE, then one or more of the set of actions associated with this PolicyRule may be executed. PolicyEvent A PolicyEvent is an occurrence of an important event, and can be used to trigger the evaluation of a PolicyCondition or PolicyCondition clause in a PolicyRule. #lt;what is an event, who generates them – alarms, inserting a card, etc.#gt; PolicySet This class represents an aggregation of PolicyEvents, constrained according to the eventConstraint attribute of the EventDetails aggregation class. This set of PolicyEvents is then presented to one or more PolicyRules to trigger the evaluation of their condition clauses. This enables an external application, such as a Policy Server, to dynamically adjust the set of events that are being used to trigger the evaluation of a PolicyRule. PolicyCondition A PolicyCondition clause is an aggregation of individual PolicyConditions, and is treated as an atomic object that is aggregated by a PolicyRule. It is represented as a Boolean expression, and defines the necessary state and/or prerequisites that define whether the actions aggregated by that same PolicyRule should be performed. This is signified when the PolicyCondition clause associated with a PolicyRule evaluates to TRUE. Policy Action A PolicyAction clause is an aggregation of individual PolicyActions, and is treated as an atomic object that is aggregated by a PolicyRule. It represents the necessary actions that should be performed if the PolicyCondition clause evaluates to TRUE. These actions are applied to a set of managed objects, and have the effect of either maintaining an existing state, or transitioning to a new state, of those managed objects. Terms Defining the Usage of Policy The purpose of this section is to define terms that are used in the Policy model to represent how policies are used in a policy based management system. Policy Domain A PolicyDomain is a collection of managed entities that are operated on using a set of policies. The policies are used to administer and control the set of characteristics and behavior of these managed entities. The purpose of defining a Domain is to define a set of managed entities that are all operated on in the same way. While administration is important, it is only one of a set of operations that are targeted on entities in a domain. Policy Conflict A policy conflict occurs when the conditions of two or more PolicyRules that apply to the same set of managed objects are simultaneously satisfied, but the actions of two or more of these PolicyRules conflict with each other. Policy Decision A Policy Decision is the determination that one or more PolicyActions that are aggregated by a PolicyRule should be applied to a set of managed objects. These PolicyActions correspond to either maintaining the current state, or transitioning to a new state, of each of the managed objects that it is affecting. Policy Decision Point (PDP) A PDP is an entity that makes Policy Decisions for itself or for other entities that request such decisions. <ul>
<li>Note that a PDP is not a role. Rather, it is an architectural concept.</li></ul>
Policy Enforcement Point (PEP) An entity that is used to verify that a prescribed set of PolicyActions have been successfully executed on a collection of PolicyTargets. <ul>
<li>Note that a PEP is not a role. Rather, it is an architectural concept.</li></ul>
Policy Evaluation A Policy Evaluation is the set of computations necessary to determine if the PolicyCondition clause is satisfied. Policy Execution Point (PXP) An entity that is used to execute a prescribed set of PolicyActions on a set of PolicyTargets. <ul>
<li>Note that a PXP is not a role. Rather, it is an architectural concept.</li></ul>
Policy Repository A policy repository is an administratively-defined logical container that is used to hold policy information. For the purposes of this definition: <ul>
<li>logical container means that it may be implemented as either a separate data store, or a special area of a data store that is used expressly to contain policy information</li><li>policy information means policy rules and groups, their constituent elements, and related data that may be used in the evaluation and/or execution of policy conditions and actions</li></ul>
Policy Server A Policy Server is a collective set of entities that can be used to replicate core policy management functionality in a distributed implementation. It consists of at least one Policy Decision Point, one Policy Execution Point, control logic to detect and resolve policy conflicts, and optionally one or more proxies to communicate to the external world. Policy Subject A policy subject is a set of entities that is the focus of the policy. The subject can make policy decision and information requests, and it can direct policies to be enforced at a set of policy targets. <ul>
<li>Note that a Policy Subject is an architectural concept, as defined in the literature. However, SID model defines a role to implement the concept of a PolicySubject.</li></ul>
Policy Target A policy target is a set of entities that a set of policies will be applied to. The objective of applying policy is to manage the state transitions of the policy target. A policy target could be a device (e.g., power it on), a device interface (e.g., check if it is up or down) or a device configuration (e.g., define traffic conditioning, protocols, and other operations). Note that this definition uses the notion of using a finite state machine to control the behavior of the policy target. Note that a Policy Subject is an architectural concept, as defined in the literature. However, SID defines a role to implement the concept of a PolicySubject. Policy-Aware Entity A policy-aware entity is one that can understand and use policies to make present and future decisions. These decisions are used to manage and control the changing and/or maintaining of the state of one or more managed objects that are the targets of the policy. Policy-Unaware Entity A policy-unaware entity is one that can neither understand nor use policies to make present and future decisions. A policy-unaware entity cannot use policies to manage and control the changing and/or maintaining of the state of one or more managed objects. Policy-Enabled System A policy-enabled system is one that can operate using policies to make present and future decisions. These decisions are used to manage and control the changing and/or maintaining of the state of one or more managed objects that are the targets of the policy. Terms Defining the Use of Roles With Respect to Policy The purpose of this section is to define terms that are used in the Policy model to represent how roles are used in conjunction with policies in a policy-based management system. Role Object A role object is an object that is not meant to stand on its own; rather, it is meant to supply a combination of common and unique functionality that can augment the basic definition of another object. The unique functionality may be supplied in the form of additional attributes, methods, constraints, and/or relationships. Roles are contextual and define behavior in a context, and are not absolute. Role-Combination A role-combination is a set of Roles that exist as an atomic entity. <ul>
<li>Note that when a role-combination is queried on, the entities selected are those which have ALL roles in the specified role-combination. This concept is included for compatibility with the DMTF CIM and IETF policy models. This represents the special case of using multiple role attributes to function as a role-selector.</li></ul>
Role-Selector A role-selector is a means of grouping together a set of objects, so that a set of policies can be applied to them. Multiple role-selectors can be combined to select a set of objects, in which case only those objects that contain all attributes specified by the role-selector will be selected.