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. The ONAP Policy Framework provides distributed policy management for all policies in ONAP at run time. Not only does this provide unified policy access and version control, it provides life cycle control for policies and allows detection of conflicts across all policies running in an ONAP installation.

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.

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. Policies are pulled and loaded into PDPs that are started and run as micro services. Dependencies are set in the policy artifact jar files themselves and not hard coded in the platform.

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. The output of Policy Design is deployment-ready artifacts in Maven and Policy metadata in the Policy Framework database.

Policies that are expressed via natural language or a model require some development work ahead of time for them to be translated into concrete 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.

2.1.1 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, rules, and tasks 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, implementation specific rules or tasks, the flow of the policy, and other relevant information.

The ONAP Policy Framework provides the RESTful Policy Design API, which allows other components to query policy templates, to determine the model information, rules, or tasks that they require, to specialize policy flow, and to generate concrete policies from policy templates. This API is used by the ONAP Policy Framework and other components such as SDC to create 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 generic 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, rules and tasks for that vendor model of vCPE.

2.1.1.1 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.

2.1.1.2 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.

2.1.2 Policy Design

Policy Design creates a concrete policy from a policy template. Policy Design is a Design Time framework for ingestion of models for policies and any optional support code, rules, tasks, or flow specifications. Policy Design can consume policy models organically and not require any development work.

Policy Design can occur in several ways during a "design" process. At design time, a service designer and/or operations team can use the models specified on a policy template to express and capture a policy at its highest abstraction level. Alternatively, the logic of the policy can be expressed 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 number of mechanisms for  policy design that are supported in ONAP. The process in the ONAP Policy Framework for generating a concrete policy is the same for all mechanisms. The most general mechanism for creating a concrete policy is using the RESTful Policy Design API, which provides a full interface to the templating and concrete policy generation support of the Policy Framework. This API may be exercised directly using utilities such as curl. The Policy Framework provides a command line tool that is a loose wrapper around the API. It also provides a general purpose Policy GUI in the ONAP Portal for policy generation, which again is a general purpose wrapper around the Policy Design API. The Policy GUI can interpret any TOSCA Model ingested and flexibly presents a GUI for a user to create policies from.

A number of ONAP components use policy in manners which are specific to their particular needs. The manner in which the policy creation process is triggered and the way in which information required to specialize a policy template is specified and accessed is specialized for these ONAP components.

The following subsections outline the mechanisms for policy creation and modification supported by the ONAP Policy Framework.

2.1.2.1 Policy Design in the ONAP Policy Framework

Policy Design in the ONAP framework follows the general sequence shown in the sequence diagram below. An API_USER is any component that wants to specialize a policy template into a concrete policy. The ONAP Policy Framework supplies a REST interface that exposes the API and also provides a command line tool and general purpose client that wraps the API.

An API_User first gets a reference to and the metadata for the Policy Template for the policy they want to work on from PolicyDesign. PolicyDesign reads the metadata for the template from the database and reads the policy template artifact from Nexus. The API_User then asks for a reference and the metadata for the policy. PolicyDesign looks up the policy in the database. If the policy already exists, PolicyDesign reads the artifact from Nexus and returns the reference of the existing policy to the APIUser with the metadata for the existing policy. If the policy does not exist, PolicyDesign creates and new reference and metadata and returns that to the API_User.

The API_User may now proceed with a policy specification session, where the models, rules, tasks, and flow for the policy are specified on the policy template. Many actual API calls may occur during the session to specify information on the policy.

Once the API_User is happy that the policy is completely and correctly specified, it requests PolicyDesign to generate the policy. PolicyDesign generates the policy, stores the generated policy artifact in Nexus and stores its metadata of the policy in the database.

2.1.2.2 Model Driven VF (Virtual Function) 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. The SDC Distribution APIs are used to interact with SDC. For example, SLA and placement policies may be captured via TOSCA specification. License policies can be captured via TOSCA or an XACML specification. Run-time metric vendor recommendations can be captured via VES Standard specification.

The sequence diagram below is a high level view of SDC-triggered concrete policy generation for some arbitrary entity EntityA.

PolicyDesign contains a component PolicyDesignSDCHandler for managing SDC-triggered concrete policy creation and update requests. PolicyDesignSDCHandler is an API_User, it uses the Policy Design API to execution policy creation and update. It reads the information it needs to populate the policy template from SDC and then uses this information to automatically generate a policy.

2.1.2.3 Model Driven Policy Design via another ONAP Component's 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).

The GUI implementation in another ONAP component such as SDC or the DCAE-DS uses the API_User API to create and edit ONAP policies. Note that this puts an impact on those components.

2.1.2.4 Scripted Model Driven Policy Design

Service policies such as optimization and placement policies can be captured via TOSCA models during design time. These models can be used to generate concrete policies.

One straightforward way of generating concrete policies from Policy metadata in TOSCA, YAML, or other such modelling languages combined with directives specified in a script file is to use a command line utility. The command line utility is an API_User. It reads the policy model from the model file, and/or the directives from a script file and uses the information from those files to drive the concrete policy generation process.

2.1.3 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.

2.2 Policy Runtime 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 permitted.

In the ONAP Policy Framework, the interfaces to the PDP are designed to be as streamlined as possible. Because the PDP is the main unit of scalability in the Policy Framework, the PF is designed to allow PDPs in a PDP group to arbitrarily appear and disappear and for policy consistency across all PDPs in a PDP group to be easily maintained. Therefore, PDPs have just two interfaces; an interface that users can use to execute policies and interface to the PAP for administration, life cycle management and monitoring. The PAP is responsible for controlling the state across the PDPs in a PDP group. The PAP interacts with Nexus and transfers policy sets to PDPs, and may cache the policy sets for PDP groups. If PDPs individually interact directly with Nexus, then a complex three-way consistency between the PDPs, PAP, and Nexus must be maintained. it is much more difficult to maintain consistency across all the PDPs in the PDP group as PDPs spontaneously appear and disappear.

2.2.1 Policy Framework Services

The ONAP Policy Framework follows the architectural approach for micro services recommended by the ONAP Architecture Subcommittee.

The ONAP Policy Framework defines Kubernetes Services to manage the life cycle of Policy Framework executable components at runtime. A Kubernetes service allows, among other parameters,  the number of instances (pods in Kubernetes terminology) that should be deployed for a particular service to be specified and a common endpoint for that service to be defined. Once the service is started in Kubernetes, Kubernetes ensures that the specified number of instances is always kept running. As requests are received on the common endpoint, they are distributed across the service instances. More complex call distribution and instance deployment strategies may be used; please see the Kubernetes Services documentation for those details.

If, for example, a service called policy-pdpd-control-loop is defined that runs 5 PDP-D instances. The service has the end point https://policy-pdpd-control-loop.onap/<service-specific-path>. When the service is started, Kubernetes spins up 5 PDP-Ds. Calls to the end point https://policy-pdpd-control-loop.onap/<service-specific-path> are distributed across the 5 PDP-D instances. Note that the .onap part of the service endpoint is the namespace being used ans is specified for the full ONAP Kuberentes installation.

The following services will be required for the ONAP Policy Framework:

There is one and only one PAP service, which handles policy deployment, administration, and monitoring for all policies in all PDPs and PDP groups in the system. There are multiple PDP services, one PDP service for each domain for which there are policies.

2.2.2 The Policy Framework Information Structure

The following diagram captures the relationship between Policy Framework concepts at run time.

There is a one to one relationship between a policy service and the policies for a certain domain. Each PDP service is used for a particular policy domain, runs a single PDP group with multiple PDPs, which executes a specific Policy Set containing a number of policies. Having and maintaining this principle makes policy deployment and administration much more straightforward than it would be if complex relationships between PDP services, groups, and policy sets.

The topology of the PDPs and their policy sets is held in the Policy Framework database and is administered by the PAP service.

The diagram above outlines the structure of the run time topology information in the Policy Framework database. Note that the PDP_GROUP_STATE and PDP_STATE fields hold state information for life cycle management of PDP groups and PDPs. The POLICY_MAVEN_ARTIFACT field holds a reference that a PAP can use to fetch the policy artifact from Maven.

2.2.3 Startup, Shutdown and Restart

This section describes the interactions between Policy Framework components themselves and with other ONAP components at startup, shutdown and restart.

2.2.3.1 PAP Startup and Shutdown

The sequence diagram below shows the actions of the PAP at startup.

The PAP is the run time point of coordination for the ONAP Policy Framework. When it is started, it initializes itself. It then waits for periodic PDP status updates and for administration requests.

PAP shutdown is trivial. On receipt or a shutdown request, the PAP completes or aborts any ongoing operations and shuts down gracefully.

2.2.3.2 PDP Startup and Shutdown

The sequence diagram below shows the actions of the PDP at startup.

At startup, the PDP initializes itself. At this point it is in PASSIVE mode. The PDP begins sending periodic Status messages to the PAP.

The first Status message initializes the process of loading the correct Policy Set on the PDP in the PAP (see Section 2.2.5.1).

On receipt or a shutdown request, the PDP completes or aborts any ongoing policy executions and shuts down gracefully.

2.2.3.3 Embedded PDP Startup and Shutdown

ONAP components may execute policies in their own run time environment or container. It is very important that policies executed by components in this way are administered by the PAP exactly as if they were executed in a standalone PDP. Providing a embedded PDP allows for policy administration to be carried out for embedded PDPs in exactly the same manner as for standalone PDPs. It also allows for context overlaps and conflicts to be detected across all policies running in ONAP.

The sequence for starting an embedded PDP is very similar to starting a standalone PDP. The difference is that the embedded PDP is started over a Java API by the component in which the PDP is embedded.

2.2.4 Policy Execution

Policy execution is the execution of a policy in a PDP. Policy enforcement occurs in the component that receives a policy decision.

Policy execution can be synchronous or asynchronous. In synchronous policy execution, the component requesting a policy decision requests a policy decision and waits for the result. The PDP-X uses synchronous policy execution. In asynchronous policy execution, the component that requests a policy decision does not wait for the decision. Indeed, the decision may be passed to another component. The PDP-D uses asynchronous policy execution.

Policy execution is carried out using the current life cycle mode of operation of the PDP. While the actual implementation of the mode may vary somewhat between PDPs of different types, the principles below hold true for all PDP types:

2.2.5 Policy Lifecycle Management

Policy lifecycle management manages the deployment and life cycle of policies in PDP groups at run time. Policy sets can be deploy at run time without restarting PDPs or stopping policy execution. PDPs preserve state for minor/patch version upgrades and rollbacks.

2.2.5.1 Download Policy Set to PDP

The sequence diagram below shows how a Policy Set is loaded into a PDP.

This sequence can be initiated in three ways; from the PDP, from Nexus, or from a user action.

1. A PDP sends regular status update messages to the PAP. If this message indicates that the PDP has no Policy Set or an outdated Policy Set loaded, then this sequence is initiated
2. Nexus triggers the PAP when a new policy set becomes available. The PAP initiates this sequence to upgrade the policy set on all PDPs running that policy set.
3. A user may explicitly trigger this sequence to load a policy set on a PDP

The PAP controls the entire process. The PAP reads the current  PDP metadata from the database and reads the required policy and policy set artifacts from Nexus. It then uses a PDP Plugin for the specific type of PDP to unpack the artifacts and build the policy set for the PDP in whatever form this type of PDP requires. The PAP supports a Java API that allows plugins to be developed for unpacking and building policies for arbitrary PDPs.

Once the Policy Set has been unpacked and built, the PAP sets the mode of the PDP to PASSIVE. The Policy Set is transparently passed to the PDP by the PAP. The PDP loads all the policies in the policy set including any models, rules, tasks, or flows in the policy set.

Once the Policy Set is loaded, the PAP orders the PDP to enter the life cycle mode that has been specified for it (ACTIVE/SAFE/TEST). The PDP beings to execute policies in the specified mode (see section 2.2.4).

2.2.5.2 Policy Rollout

A policy set steps through a number of life cycle modes when it is rolled out.

The user rolls out a policy set. It is deployed to a PDP group and is initially in PASSIVE mode. The user sets the PDP Group into TEST mode. The policies are run in a test or sandboxed environment for a period of time. The test results are passed back to the user. The user may revert the policy set to PASSIVE mode a number of times and upgrade the policy set during test operation.

When the user is satisfied with policy set execution and when quality criteria have been reached for the policy set, the PDP group is set to run in SAFE mode. In this mode, the policies run on the actual target environment but do not actually exercise any actions or change any context in the target environment. Again, as in TEST mode, the operator may decide to revert back to TEST mode or even PASSIVE mode if issues arise with a policy set.

Finally, when the user is satisfied with policy set execution and when quality criteria have been reached, the PDP group is set into ACTIVE state and the policy set executes on the target environment. The results of target operation are reported. The PDP group can be reverted to SAFE, TEST, or even PASSIVE mode at any time if problems arise.

2.2.5.3 Policy Upgrade and Rollback

There are a number of approaches for managing policy upgrade and rollback.

The most straightforward approach is to use the approach described in section 2.2.5.2 for upgrading and rolling back policy sets. In order to upgrade a policy set, one follows the process in 2.2.5.2 with the new policy set version. For rollback, one follows the process in section 2.2.5.2 with the older policy set, most probably setting the old policy set into ACTIVE mode immediately. The advantage of this approach is that the approach is straightforward. The obvious disadvantage is that the PDP group is not executing on the target environment while the new policy set is in PASSIVE, TEST, and SAFE mode. 

A second manner to tackle upgrade and rollback is to use a spare-wheel approach. An special upgrade PDP group service is set up as a K8S service in parallel with the active one during the upgrade procedure. The spare wheel service is used to execute the process described in section 2.2.5.2. When the time comes to activate the policy set, the references for the active and spare wheel services are simply swapped. The advantage of this approach is that the down time during upgrade is minimized, the spare wheel PDP group can be abandoned at any time without affecting the in service PDP group, and the upgrade can be rolled back easily for a period simply by preserving the old service for a time. The disadvantage is that this approach is more complex than the first approach.

A third approach is to have two policy sets running in each PDP, an active set and a standby set. However such an approach would increase the complexity of implementation in PDPs significantly.

2.2.6 Policy Monitoring

PDPs provide a periodic report of their status to the PAP. All PDPs report using a standard reporting format that is extended to provide information for specific PDP types. PDPs provide at least the information below:

2.2.7 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

How does the Policy framework work with OOF? Somehow the sequence diagram on the Optimization Service Design Framework page below looks a bit odd. One would have thought that SO should call maybe DCAE analytics to find out the current situation, then call Policy to decide what sort of optimization algorithm to run, then call OOF with instructions to run a particular optimization algorithm, and then implement the optimization towards the network (APPC/SDC/VFC). In other words, SO acts on a set of tools that provide certain metadata driven capabilities to SO. Then in SO, the appropriate set of tools can be called int he appropriate order to orchestrate services. In the sequence diagram, it looks like OOF is really in control of the orchestration and not SO.

Pamela Dragosh - No SO should never call DCAE it should only call OOF (which is considered a part of DCAE). OOF is the project where optimization is performed. OOF calls Policy for a policy decision on how to calculate the optimization. OOF then goes through that calculation. OOF returns the optimization to SO which has all the logic and implementation to perform the orchestration. Its debatable as to whether that optimization logic should be done in SO and/or Policy. But having it be the responsibility of OOF is where it is right now.

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

• 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

4.2 Policy Deployment Implementation

4.3 Policy Execution Implementation

4.4 Policy Repository Layout

Questions

1. What is the relationship between policy/common and policy/core?
   1. Pamela Dragosh - I don't see much "common" in policy/common. I think that majority of code is for drools-pdp and should be moved. The rest can go into policy/core
2. What is the relationship between policy/models and policy/api?
   1. Pamela Dragosh - Models are models for building policies agnostic to the PDPs. Can be used by the PAP. The API supports the code for our API.
3. How does policy/pap play with policy/distribution?
   1. Pamela Dragosh - current thought is policy/distribution uses the API to call the policy/pap to create and push policies. This needs more thought on this flow.

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

10. Open Questions

11. Scope not covered in this document