The Policy Creation subsystem provides a centralized environment for the creation and management of easily-updatable conditional rules. This subsystem enables users to validate policies and rules, identify and resolve overlaps & 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, access the Policy Creation subsystem from the OpenECOMP 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. Software policies that are supported include XACML policies, Drools policies, and lower level policies that are embodied in modeling languages such as YANG and TOSCA.
The Policy Creation subsystem also provides additional functionality once policies are initially created:
- Offline analysis of performance, fault, and closed-loop actions, enabling the discovery of new and signatures and refinement of existing ones
- Derivation of lower-level policies from higher-level policies
- Identification of conflicts and mitigation of them before deployment
Once validated and corrected for any conflicts, the policies are placed in an appropriate registry, and 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. Distribution occurs either in conjunction with the distribution of recipes (if for example they are 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.