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. The Policy Framework is the component that is the source of truth for all policy decisions.
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 separates policies from the platform that is supporting them. The framework 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.
The ONAP Policy Framework for building, configuring and deploying PDPs is extendable. It allows the use of ONAP PDPs as is, the extension of ONAP PDPs, and lastly provides the capability for users to create and deploy their own PDPs.
2. Architecture
The diagram below shows the architecture of the ONAP Policy Framework at its highest level.
The PolicyDevelopment component implements the functionality for development of policies, policy templates, and configurations for policies. PolicyDeployment is responsible for the deployment life cycle of policies as well as interworking with the mechanisms required to orchestrate the nodes and containers on which policies run. PolicyExecution is responsible for policies at run time; ensuring that policies are available to users, that policies are executing correctly, and that the state and status of policies is monitored.
PolicyDevelopment creates policy artifacts in Nexus and supporting information in the Policy database. PolicyDeployment reads those artifacts from Nexus and the supporting information from the Policy database whilst deploying policy artifacts. Once the policy artifacts are deployed, they are handed over to PolicyExecution for run-time management. PolicyDeveloment interacts with ONAP design time components, and has no programmatic interface with PolicyDeployment, PolicyExecution or any other run-time ONAP components.
The diagram below shows a more detailed view of the architecture, as inspired by RFC-2753 and RFC-3198..
PolicyDevelopment creates sets of executable policies (ExecutablePolicySet) for a certain domain, which consist of policies (ExecutablePolicy) and parameters for those policies (PolicyParameters) that can execute on PDPs. Executable policies are created from domain policies (DomainPolicy) that have been created from template policies (ProtoPolicy).
PolicyDeployment uses the PAP to deploy an ExecutablePolicySet on a PDPGroup, a grouping of PDPs of a certain type using a certain deployment plan.
PolicyExecution uses the PAP and PDPs to monitor execution of the policies in the ExecutablePolicySet on the PDPGroup.
2.1 Policy Design Architecture
- Model Driven Service Design that captures Policies during Design Time
- 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
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
- Policies are be easy to specify
Discuss support for SDC.
The platform that could can policy models organically and not require any development work. The Policy GUI should be to interpret any TOSCA Model ingested and flexibly present a GUI for a user to create policies from.
2.2 Policy Deployment Architecture
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 PAP (Policy Administration Point) is resilient and able to support CRUD of Policies, Policy Deployment and PDP group management.
- 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
- Policies are be possible to specify and deploy at run time without restarting components or stopping policy processing
- PDPs scale horizontally
- Policies are upgradable with state preserved within the limitations of semantic versioning (State preserved for minor/patch version upgrades), see 2.
The long term architecture view is for policy artifacts to be located in a nexus repository that are pulled by appropriate PDP micro service engines. Dependencies would be set in the policy artifact jar files themselves and not hard coded into the platform as a JSON file.
- Policy API will support Lifecycle management for policies that are deployed such as modes and retirement. This additional requirement is better suited for the new proposed Policy Lifecycle API than the current API.
- The PAP will do life cycle monitoring of policy and context as well as deployment.
- PDPs of all type must scale horizontally under whatever containerization or virtual infrastructure is in use for a given ONAP deployment. Having the PAP scale horizontally probably not a very urgent requirement.
2.3 Policy Execution Architecture
- The PAP will do run time monitoring of policy and context .
- Policy does instance monitoring, monitoring of PDPs in real time etc.
- Inter-PDP protocol is the protocol that instances of any PDP type can use to communicate with each other to manage state and deployment
- Intra-PDP protocol is the protocol that instances of a particular PDP type use to communicate with each other, to manage state and deployment
- Load balancing of events towards PDP pools could be done with DMaap using the underlying Kafka consumer group mechanisms
3. APIs Provided by the Policy Framework and how to use them
- Should Policy Management Protocol/Policy Deployment Protocol/Policy Monitoring Protocol/Policy Persistence Protocol use DMaaP?
3.1 Policy Design APIs
3.2 Policy Deployment APIs
PAP to all PDPs in PDP group
| Deploy Policy | Deploy a policy artifact version taken from Nexus to all PDPs in the PDP group |
| Retire Policy | Remove a policy artifact from all PDPs in the PDP group |
| Activate Policy in Safe Mode | Activate a policy version in safe mode, no updates made to the network/system |
| Activate Policy in Live Mode | Activate a policy version running live |
| Upgrade Policy | Replace an active policy with a more recent version of the same policy |
| Rollback Policy | Replace an active policy with an older version of the same policy |
- Update of policies across PDPs in a PDP group use "eventually consistent" semantics, transactions or ACID semantics will not be supported
- Event though PDPs could listen or monitor Nexus for updates to policies, the PAP should be the component responsible for deciding if and what policy upgrades are propagated to the entire PDP group.
PDP Group Admin in PAP
| Create PDP group | Define the parameters for the PDP group including the type of PDP |
| Update PDP group | Change the parameters of the PDP group |
| Delete PDP group | - |
| Add PDP to PDP Group | Add a PDP to the PDP group, is the PDP spun up separately or does the PAP initiate the spinning up of the PDP? |
| Update PDP in PDP group | Update parameters of the PDP in the PDP group |
| Remove PDP from PDP group | - |
- Can a PDP be in more than one PDP group??? .....I hope not!
- We'll assume a single PAP for now.
3.3 Policy Execution APIs
PAP to all PDPs in PDP group
| Modify Policy Parameters* | Change the parameters of a policy |
| Get Status | Report on the state of the policy artifacts running in the PDPs |
| Get State | Report on the execution status of the policies running on the PDPs |
- *A policy may be parameterized. There are two ways to handle this
- Combine a raw policy into a parameterized policy and deploy the parameterized policy at run time
- Have the raw policy and its parameters as separate artifacts and deploy them separately
- Do not consider the parameters as an artifact but allow them to be modified directly by users setting them using an interface towards the PAP at run time
Policy Execution (Users to PDP Group pr PDP)
| Execute policy on PDP group synchronously | Run a policy on any PDP in a PDP group and await the response |
| Execute policy on PDP group asynchronously | Run a policy on any PDP in a PDP group, fire and forget |
| Execute policy on PDP synchronously** | Run a policy on a specific PDP and await the response (Deprecate) |
| Execute policy on PDP asynchronously** | Run a policy on a specific PDP, fire and forget (Deprecate) |
- **Applications using the Policy Framework should not be aware of specific PDPs, we should only support this behaviour for existing users and deprecate this usage.
- Load Balancing across PDP group......Stateless PDPs no problem.....set up stateful transfer between PDPs if supported....Address specific PDPs
4. The Policy Framework Implementation
- Database off PAP (PDPs report back to PAP, don’t access database directly)
- Database could be replaced by/interchangeable with some ONAP persistence system (DMaaP or DCAE)?