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.

1. A Policy Template is designed by a skilled policy developer in consultation with domain experts. The Policy template is a general implementation of a policy template for a feature. For example, a policy template could be written to manage Service Level Agreements for VPNs.
2. A Domain Policy is designed by a domain expert who uses the Policy Tempate to create a domain policy for their specific domain.
   1. For example, the VPN Policy Template is used to create VPN policies for a bank network, a car dealership network, or a university with many campuses.
   2. In ONAP, specific ONAP Policy Templates are used to create specific policies that drive the ONAP Platform and Components.
3. 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 concrete policies (ConcretePolicy) that have been created from template policies (PolicyTemplate).

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

This section describes the architecture of the model driven system used to develop policy templates, to derive concrete policies from those policy templates, and to parameterize concrete policies as executable policies.

Policy Template Design

Policy Template Design is the task of creating policy templates that capture the generic and vendor independent aspects of a policy for a particular domain use case. The policy template also specifies and publishes the model information that it requires to generate concrete policies.

A policy template is written for a certain type of PDP. A policy template is developed for a certain type of PDP (for example XACML oriented for decision policies or Drools rules oriented for ECA policies). The design environment and tool chain for a policy template is specific for the type of policy being designed. The policy template is available as a Maven artifact once it has been designed.

All policy templates must implement the ONAP Policy Framework PolicyTemplate interface. This interface allows the Policy Framework to manage policy templates and to generate concrete policies from policy templates in a uniform way regardless of the domain that the policy template is addressing or the PDP technology that will execute the policy. The interface is used by the Policy Framework to determine the PDP technology of the policy template, the structure, type, and definition of the model information that must be supplied to the policy template to generate a concrete policy, and other relevant information.

The ONAP Policy Framework provides an API that allows other components to query policy templates, to determine the model information that they require, and to generate concrete policies from policy templates.

Consider a policy template created for managing faults on vCPE equipment in a vendor independent way. The policy template captures the logic required to manage the faults and specifies the vendor specific information that must be supplied to te template for specific vendor vCPE VFs. The actual concrete vCPE policy that is used for managing particular vCPE equipment is generated using the policy template together with the specific modeled information for that vendor model of vCPE.

Programming Policy Templates

The most straightforward way to create a policy template is to program it. Programming a policy template might simply mean creating and editing text files and manually generating the Maven artifact for the policy template.

A more formal approach is preferred. Programmers use a specific Eclipse project type for developing each type of policy template, a Policy Template SDK. The project is under source control in git. This Eclipse project is structured correctly for creating policies for a specific type of PDP. It includes the correct POM files for generating the policy template as a Maven artifact. It has editors and perspectives that aid the programmer in their work.

Generating Policy Templates

It is also possible to generate policy templates using MDD (Model Driven Development) techniques. Policies are expressed using a DSL (Domain Specific Language) or a policy specification environment for a particular application domain. For example, policies for specifying SLAs could be expressed in a SLA DSL and policies for managing SON features could be generated from a visual SON management tool. The ONAP Policy framework provides an API that allows tool chains to create policy templates.

Policy Design

Policy Design can occur in several places during a "design" process. During design time the models should allow a service designer and/or operations team to be able to express and capture policy both at its highest abstraction as well as using a specific policy language if desired.

The information expressed during policy design is used to specialize a policy template to create an executable policy. A policy can be designed in many ways.

Model Driven VF Policy Design via VNF SDK Packaging

VF vendors express policies such as SLA, Licenses, hardware placement, run-time metric suggestions, etc. These details are captured within the VNF SDK and uploaded into the SDC Catalog.

For example, SLA and placement policies may be captured via TOSCA specification. License policies can be captured via TOSCA or XACML specification (TBD). Run-time metric vendor recommendations can be captured via VES Standard specification.

(High level architectural sequence diagram on how this works)

Model Driven Policy Design via SDC GUI

The SDC GUI supports several types of policies that can be captured during design time. DCAE micro service configuration policies can be onboarded via the DCAE-DS (DCAE Design Studio). Service policies such as Optimization, Placement policies can also be captured via TOSCA model during design time.

(High level architectural sequence diagram on how this works)

Model Driven Policy Design via Policy Dashboard (exposed via ONAP Portal SDK)

(High level architectural sequence diagram on how this works)

Policy Design Process

All policies must be certified as being fit for deployment prior to run time deployment. This certification may be performed over the ONAP Policy Framework APIs in the case where other ONAP components such as SDC crete policies. For Policies created directly in the PF, governance of policy certification and testing is supported in the system.

*******

• 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

1. Policies are easy to specify

Discuss support for SDC.

The platform can consume 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.

Policy Model/Template/Rule Development and Orchestration - Pamela Dragosh 

Policies that are expressed via natural language or a model require some development work ahead of time for them to be translated into runtime policies. Some Policy Domains will be setup and available in the platform during startup such as Control Loop Operational Policy Models, OOF placement Models, DCAE microservice models. Policy Model/Template/Rule Development is done by an experienced developer.

Policy models/templates/rules will be stored in a Nexus OSS Repository which has the ability to support all major package types and has the flexibility to be configured for various environments such as development vs production. Thus, the production environment can be configured in a strict manner to allow only artifacts being pulled from specific repositories and block other repositories. While the development environment can be separately configured so offline development/testing can be performed with or without production policies.

Model Development

Template Development

Rule Development

TODO: How does an Policy get updated? How the nexus is going to work? How does template development work?

2.2 Policy Deployment Architecture

The Policy Framework Platform components are themselves designed as micro services that are easy to configure and deploy via Docker images and K8S both supporting resiliency and scalability if required. PAPs and PDPs are deployed by the underlying ONAP management infrastructure and are designed to comply with the ONAP interfaces for deploying containers.

The PAPs keep track of PDPs, support the deployment of PDP groups and the deployment of a policy set across those PDP groups. A PAP is stateless in a RESTful sense. Therefore, if there is more than one PAP deployed, it does not matter which PAP a user contacts to handle a request. The PAP uses the database (persistent storage) to keep track of ongoing sessions with clients. Policy management on PDPs is the responsibility of PAPs; management of policy sets or policies by any other manner is not supported. The PAPs are identified in the system using a well known address; in the case where a pool of PAPs exist, requests to PAPs are load balanced across the PAPs.

*******

• 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

1. Policies are be possible to specify and deploy at run time without restarting components or stopping policy processing

1. PDPs scale horizontally
2. 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

PEP Registration and Enforcement Guidelines - Pamela Dragosh

How do we set that up?

How do we ensure the API's allow flexibility for getting policy decisions?

PDP specific? May not relevant to drools or apex?

https://ericsson.github.io/apex-docs/policy-guide/pg-policy-matrix.html

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

• 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

• 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

• *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)

• **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)?

Observations

• Policy-core has definitions of the Policy protocols and the interfaces for all the interactions between the policy components. It doesn’t have much functional code, it’s mainly the model of the system and to enforce the overall structure and interactions in the system. Some of the current engine goes in there. Implementation of the protocols is in this modules including the Inter-PDP protocol and the generic parts of the Intra-PDP protocol
• PAP functionality extended to do life cycle monitoring and run time monitoring of PDPs, moves out of engine to separate git repository. The Deployment and Monitoring could be separate modules
• Generic PDP functionality is in a separate PDP module, the current generic PDP functionality moves there and is extended to provide generic model driven PDP support for arbitrary PDPs
• PDP-X specific functionality goes to the PDP-X module
• PDP-D and BRMSGW combined in PDP-D (PDP-D related functions in engine and the current drools-pdp combined)
• The drools-applications module generalized to provide interfaces for all the Policy Framework including arbitrary PDPs towards the other ONAP components in the Policy Interactions module. This must have a mechanism to allow model-driven interactions, in other words define interfaces at run time rather than at design time in Java or JAXB.
• All persistence is In the Policy Persistence module in order to keep persistence nastiness out of the other modules, state from PDPs can be persisted by reading state over the Policy Management Protocol. The Policy Management Protocol could use Distributed Hash Maps to share state with Persistence.
• All PDP implementations specialize the generic interfaces from Policy-core and PDP and can extend the Intra-PDP protocol with PDP-specific support, for example for state and context sharing
• Not much thought gone into the Portal as yet except that it will use REST interfaces for interactions.

4.1 Policy Design Implementation

4.2 Policy Deployment Implementation

4.3 Policy Execution Implementation

5. Writing, Deploying, and Running Policies

How to create policies (how the customers use the platform) - Chenfei Gao will collect details on this regarding current problems

5.1 Writing a policy

5.2 Deploying a Policy

5.3 Running a Policy

6. The PDP SDK: Designing and Deploying your own PDP

PDP Microservice Architecture??

TODO: How to build your own PDP and/or how to extend existing PDP.

TOOD: How a PDP expresses its capabilities and configurability

6.1 Configuring the ONAP PDPs

6.2 Customizing the ONAP PDPs

6.3 Developing your own PDP

7. Summary and Conclusions

8. Terminology

9. References