Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

...

  1. 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.
  2. A Domain Policy is designed by a domain expert who uses the Proto Policy to create a domain policy for their specific domain.
    1. 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.
    2. In ONAP, specific ONAP Proto Policies are templated 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.

Image RemovedImage Added

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.

Platform Capabilities

  • 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 modes for safe mode, test mode will be implemented as another line of defense against policy conflicts and resolution

...

Original from Liam:

In this section, we capture the high level aspirations that we have for the ONAP Policy Framework

...

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.

2.1 Policy Design Architecture

...

  • 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 be easy to specify

Discuss support for SDC.

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


  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.

2.3 Policy Execution Architecture

...