The Policy component of OpenECOMP Policy subsystem of OpenECOMP maintains, distributes, and operates on the set of rules that underlie OpenECOMP’s control, orchestration, and management functions. Policy provides a centralized environment for the creation and management of easily-updatable conditional rules. This subsystem It enables enables users to validate policies and rules, identify and resolve overlaps and conflicts, and derive additional policies where needed. Policies can support infrastructure, products and services, operation automation, and security. Users, who can be a variety of stakeholders such as network and service designers, operations engineers, and security experts, can easily create, change, and manage policy rules from the Policy Manager in the OpenECOMP Portal.
...
Once validated and corrected for any conflicts, the policies are placed in an appropriate repository, and are made available to the other subsystems and components that might make use of them. In addition, the decisions and actions taken by the policy are distributed. Policies are distributed either in conjunction with installation packages (if for example, the policy is related to service instantiation) or independently, if the policy is unrelated to a particular service. With this methodology, policies will already be available when needed by a component, minimizing real-time requests to a central policy engine or PDP (Policy Decision Point). This improves scalability and reduces latency.
Figure 1 depicts the Policy architecture.
*****
The function of Policy is to maintain, distribute and/or operate on the set of rules that underlie ECOMP’s control, orchestration, and management functions.
ECOMP Policy is composed of subcomponents: the Policy Administration Point (PAP)<<Link to PAP top page>>, which offers interfaces for policy creation, and two types of Policy Decision Point (PDP), each based on a specific rules technology. PDP-X<<Link to PDP-X top page>> is based on XacML technology [1] and PDP-D<<Link to PDP-D top page>> is based on Drools technology [2]. PDP-X is stateless and can be implemented using a resource pool of PDP-X servers. The number of servers can be grown to increase capacity (horizontal scalability) and, also, to increase availability. The PDP-D is stateful, as it utilizes Drools in its native, stateful way and transactions persist so long as the PDP-D is active. Persistent Drools sessions, state management, local and geo-redundancy have been deactivated for this initial release of ECOMP Policy and will be turned on when testing is completed.
As illustrated in Figure 1, the Policy components are supported by a number of interfaces and subsystems. The ECOMP Portal <<Link to Policy User Guide top page>> provides a human interface for the creation, management and deployment of policies. It is a web-based system that utilizes internal APIs in the PAP.
The PAP provides interfaces and management of policy definitions. It utilizes the XACML DB to store policy definitions which are then distributed to the PDPs.
The XACML and Drools databases<<Link to database top page>> are hosted in a Maria DB cluster. The XACML DB is used to persist policy definitions and provide a point for PDPs to retrieve policy definitions. The XACML DB also has tables used for node state management<<Link to state management top page>>, detection of node failure and failover<<Link to system integrity top page>>. As indicated above, the state management tables will only include entries for the PAP and PDP-X as the testing is not yet complete for the PDP-D.
The PDP-X receives deployed policies and has interfaces to handle XACML policy transactions<<Link to XACML transaction interface top page>>. These transactions are stateless and once complete are removed from memory. If a policy deployed to the PDP-X is of an operational nature it will contain Drools rules and Java executables. These artifacts are processed into Maven artifacts and pushed to the Maven Repository<<Link to the Maven Repository top page>>. The PDP-D is then notified a new policy has been deployed.
When the PDP-D is notified a new policy has been deployed, it downloads it from the Maven repository and assigns it to an internal controller. This controller provides the external Closed Loop<<Link to Closed Loop transactions top page>> interfaces to the UEB/DMaaP message bus over which events and messages are exchanged with external systems. As events or messages arrive at the PDP-D, they are assigned to the appropriate controller and a Drools session is either created or retrieved from memory. The events, messages or facts are passed to the Drools session and the rule engine is fired resulting in a change of internal session state and/or actions taken in response to the rule processing. Response messages and requests are passed by the controller back over the UEB/DMaaP message bus to the appropriate system. The Drools session can also have timers and autonomous events. In a future release the PDP-D will enable the node state management and session persistence in the Drools DB.
*************
Policy Creation
The Policy Creation component of the Policy subsystem enables creation of new policies and modification of existing polices, both online and offline.
...
Run-time policy enforcement is performed by OpenECOMP subsystems that are called from the policy. For example, policy rules for data collection are enforced by the data collection functionality of DCAE. Analytic policy rules, identification of anomalous or abnormal conditions, and publication of events signaling detection of such conditions are enforced by DCAE analytic applications. Policy rules for associated remedial actions, or for further diagnostics, are enforced by the correct component in a control loop such as the MSO, a Controller, or DCAE.
...
.
...
Policy Unification and Organization
Because the policy framework is expandable and multipurpose, it might contain many types of policies, which users might want to organize according to some useful dimensions. Users can define attributes that specify the scope of policies, and these attributes can be extended to the policy-enabled functions and components. Useful policy organizing dimensions might include:
- Policy type or category (taxonomical)
- Policy ownership or administrative domain
- Geographic area or location,
- Technology type
- Policy language and version
- Security level or other security-related values, specifiers, or limiters
Attributes can be specified for each dimension. In addition to being defined for individual policies themselves, these attributes can be used to define the scope of these additional additional policy-related functions:
- Policy events or requests/triggers
- Policy decision, enforcement, or other functions
- Virtual functions of any type
Policy-writers can define attributes so that policy events or requests self-indicate their scope. The scope is then examined by a suitable function and subsequently acted upon accordingly. Policy decisions and enforcement functions can self-indicate their scope of decision-making, enforcement, or other capabilities. Virtual functions can be automatically attached to the appropriate Policy Framework and distribution mechanisms.
Policy Use
At runtime, policies that were previously distributed to policy-enabled components are used by those components to control or influence their functionality and behavior, including any actions that are taken.
In many cases, those policies will be used to make decisions, where these decisions will often be conditional upon the current situation. An example of this approach is the feedback/control loop pattern that is driven by DCAE. Many specific control loops can be defined. Each component in a particular control loop (for example, orchestrator, controller, DCAE, virtual function) receives policies that determine how it should function as part of that loop. All of the policies for that loop will have been previously created together, ensuring correct and coordinated closed-loop action. DCAE can receive specific policies for data collection (for example, what data to collect, how to collect, and how often), data analysis (for example, what type and depth of analysis to perform), and signature and event publishing (for example., what analysis results to look for as well as the specifics of the event to be published upon detecting those results). Remaining components of the loop (such as orchestrators and controllers) can receive specific policies that determining the actions to take upon receiving the triggered event from DCAE. Each component in the loop can also receive policies that specify the events to which the component subscribes.
...