The Policy subsystem of OpenECOMP ONAP maintains, distributes, and operates on the set of rules that underlie OpenECOMP’s ONAP’s control, orchestration, and management functions. Policy provides a centralized environment for the creation and management of easily-updatable conditional rules. It 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 ONAP Portal.

Policies are used to control, to influence, and to help ensure compliance with goals. A policy can be defined at a high level to create a condition, requirement, constraint, or need that must be provided, maintained, and enforced. A policy can also be defined at a lower or functional level, such as a machine-readable rule or software condition/assertion which enables actions to be taken based on a trigger or request, specific to particular selected conditions in effect at that time.  Some examples of types of policies are

• VM placement — rules governing where VNFs should be placed, including affinity rules
• Data and feed management — what data to collect and when, retention periods, and when to send alarms about issues
• Access control — who (or what) can have access to which data
• Trigger conditions and actions — what conditions are actionable, and what to do under those conditions
• Interactions — how interactions between change management and fault/performance management are handled (for example, should closed loops be disabled during maintenance?)

OpenECOMP ONAP supports XACML policies and Drools rules.  Several configuration and operational policies are pre-loaded.

...

Figure 1. Policy high-level architecture

System Architecture

OpenECOMP ONAP Policy is composed of several subcomponents: the Policy Administration Point (PAP), which offers interfaces for policy creation, and two types of Policy Decision Point (PDP), each based on a specific rules technology.  PDP-X is based on XACML technology  and PDP-D is based on Drools technology.  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 both capacity (horizontal scalability) and 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 the initial release of OpenECOMP ONAP Policy and will be turned on in a future release.

As illustrated in Figure 2, the Policy components are supported by a number of interfaces and subsystems.  The OpenECOMP ONAP Portal 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.

...

Run-time policy enforcement is performed by OpenECOMP ONAP 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.

...