Abstract
This document describes the ONAP Policy Framework. It lays out the architecture of the framework and specifies the APIs provided to other components that interwork with the framework. It describes the implementation of the framework, mapping out the components, software strucure, and execution ecosystem of the framework. It goes on to provide examples that illustrate how to write, deploy, and run policies of various types using the framework.
1. Overview
The ONAP Policy Framework is a comprehensive policy design, deployment, and execution environment. The Policy Framework is the decision making component in an ONAP system. It allows you to specify, deploy, and execute the governance of the features and functions in your ONAP system, be they closed loop, orchestration, or more traditional open loop use case implementations.
One of the most important goals of the Policy Framework is to support Policy Driven Operational Management during the execution of ONAP control loops at run time. In addition, use case implementations such as orchestration and control benefit from the ONAP policy Framework because they can use the capabilities of the framework to manage and execute their policies rather than embedding the decision making in their applications.
The Policy Framework is deployment agnostic, the Policy Framework manages Policy Execution (in PDPs) and Enforcement (in PEPs) regardless of how the PDPs and PEPs are deployed. This allows policy execution and enforcement can be deployed in a manner that meets the performance requirements of a given application or use case. In one deployment, policy execution could be deployed in a separate executing entity in a Docker container. In another, policy execution could be co-deployed with an application to increase performance.
The ONAP Policy Framework architecture supports development, deployment, and execution of any type of policy in ONAP. The Policy Framework is metadata (model) driven so that policy development, deployment, and execution is as flexible as possible and can support modern rapid development ways of working such as DevOps. A metadata driven approach also allows the amount of programmed support required for policies to be reduced or ideally eliminated.
Another important aim of the architecture of a model driven policy framework is that it enables much more flexible policy specification.
- A Proto Policy is designed by a skilled policy developer in consultation with domain experts. The Proto Policy is a general implementation of a policy template for a feature. For example, a proto policy could be written to manage Service Level Agreements for VPNs.
- A Domain Policy is designed by a domain expert who uses the Proto Policy to create a domain policy for their specific domain.
- For example, the VPN Proto Policy template is used to create VPN policies for a bank network, a car dealership network, or a university with many campuses.
- In ONAP, specific ONAP Proto Policies are templated to create specific policies that drive the ONAP Platform and Components.
- A Customer Facing Policy allows specific policy instances to be configured with parameters. For example, the SLA values in the car dealership VPN policy instance in a particular dealership are configured with values appropriate for the expected level of activity in that dealership.
2. Architecture
The diagram below shows the architecture of the ONAP Policy Framework at its highest level.
Design Time Capabilities
- Design Time policies should be easy to specify and capture from either the SDC GUI or the Policy GUI
- High-level Conflict Detection and Resolution tools will be utilized to help identify possible conflicts
- Provide a model-driven Design Time framework for ingestion of models for policies and any optional support code
- Policy Development Environment for designing models and their support code
- Conflict Detection and Resolution for Policies should be available during development and testing phases
Platform Capabilities
- The Policy Framework Platform components should be designed as micro services that are easy to configure and deploy via Docker images and K8S both supporting resiliency and scalability if required
- The Policy GUI Dashboard is created from the ONAP Portal SDK to create a consistent user experience
- The Policy GUI Designer is created from the ONAP SDC SDK to create a consistent user experience
- The PAP (Policy Administration Point) is resilient and able to support CRUD of Policies, Policy Deployment and PDP group management.
- The framework for building, configuring and deploying PDP's is extendable and provides the ability for companies to use the ONAP PDP's as is, extend the ONAP PDP's and lastly be able to create and use their own internal PDP's.
- Runtime capability to upgrade Policies, change mode of operation for policies (for example: safe mode, test mode) and ability to preserve state for minor/patch version upgrades
- Runtime modes for safe mode, test mode will be implemented as another line of defense against policy conflicts and resolution
- The Policy Framework is the centralized component that is the source of truth for all policy decisions.
Original from Liam:
In this section, we capture the high level aspirations that we have for the ONAP Policy Framework
- Policy is an integral part of ONAP's vision for Closed Loop Automation, Network->Analytics->Policy→Controls and Orchestration→Network, therefore it supports CLAMP
- Policies are be possible to specify and deploy at run time without restarting components or stopping policy processing
- Policies are be easy to specify
- PDPs scale horizontally
- The Policy Framework is model driven
- Policies are upgradable with state preserved within the limitations of semantic versioning (State preserved for minor/patch version upgrades), see 2.
2.1 Policy Design Architecture
- Model Driven Service Design that captures Policies during Design Time