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.
Observations (Requirements??? use thesaurus)
- Policy Monitoring Protocol starts with lifecycle management, can be extended to do instance monitoring, monitoring of PDPs in real time etc.
- PAP must manage (or at least be aware of) deployment of PDPs as well as deployment of policies and versions of policies
- 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.
- 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)?
- Should Policy Management Protocol/Policy Deployment Protocol/Policy Monitoring Protocol/Policy Persistence Protocol use DMaaP?
- 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
TODO: How to create policies? models? templates?
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.
2.3 Policy Execution Architecture
- The PAP will do run time monitoring of policy and context .