...
- Most obviously, the framework must be capable of being triggered by an event or invoked, and making decisions at run time.
- It must be deployment agnostic; capable of managing policies for various Policy Decision Points (PDPs) or policy engines.
- It must be metadata driven, allowing policies to be deployed, modified, upgraded, and removed as the system executes.
- It must provide a flexible template model driven policy design approach for template policy type programming and specification of policies.
- It must be extensible, allowing straightforward integration of new PDPs, policy formats, and policy development environments.
Another important aim of the architecture of a model driven policy framework is that it enables much more flexible policy specification. The ONAP Policy Framework complies with the TOSCA modelling approach for policies, see the TOSCA Policy Primer for more information on how policies are modelled in TOSCA.
- A Policy Type 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 Policy Type could be written to manage Service Level Agreements for VPNs. A Domain The Policy Type is designed by a domain expert who uses the Policy Tempate to create a domain policy for their specific domain., who specifies the parameters, triggers, and actions that the Policy Type will have. The implementation (the logic, rules, and tasks of the Policy Type) is implemented by a skilled policy developer in consultation with domain experts.
- For example, the VPN Policy Type
- 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.
- In ONAP, specific ONAP Policy Templates Types are used to create specific policies that drive the ONAP Platform and Components.
- A Customer Facing Policy allows specific policy instances to be configured Policy is created by configuring a Policy Type with parameters. For example, the SLA values in the car dealership VPN policy instance in for a particular dealership are configured with values appropriate for the expected level of activity in that dealership.
...
draw.io Diagram | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The PolicyDevelopment component implements the functionality for development of policies, policy templates, types and configurations for policies. PolicyAdministration 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. PolicyAdministration is also responsible for the administration of 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. PolicyExecution is the set of PDPs running in the ONAP system and is responsible for making policy decisions and for managing the administrative state of the PDPs as directed by PolicyAdministration.
PolicyDevelopment creates policy artifacts in Nexus and supporting information in the Policy policy database. PolicyAdministration reads those artifacts from Nexus and the supporting information from the Policy policy database whilst deploying policy artifacts. Once the policy artifacts are deployed, PolicyAdministration handles the run-time management of the PDPs on which the policies are running. PolicyDeveloment PolicyDevelopment interacts with ONAP design time components, and has no programmatic interface with PolicyAdministration, 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.
draw.io Diagram | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
draw.io Diagram | ||||||||||||||||||
border | true | |||||||||||||||||
viewerToolbar | true | |||||||||||||||||
fitWindow | false | |||||||||||||||||
diagramName | PolicyExecution | |||||||||||||||||
simpleViewer | false | width | ||||||||||||||||
diagramWidth | 539 | |||||||||||||||||
revision | 2 | |||||||||||||||||
draw.io Diagram | ||||||||||||||||||
border | true | |||||||||||||||||
viewerToolbar | true | |||||||||||||||||
fitWindow | false | |||||||||||||||||
diagramName | ClassStructure | |||||||||||||||||
simpleViewer | false | width | ||||||||||||||||
diagramWidth | 721 | |||||||||||||||||
revision | 1 |
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.
...
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.
Note that SDC provides a wrapper for the SDC API as a Java Client and also provides a TOSCA parser. See Policy Platform - SDC Service Distribution Software Architecture
In Step 4 above, the PolicyDesignSDCHandler must download the CSAR file. If the policy is to be composed from the TOSCA definition, it must also parse the TOSCA definition.
In Step 9 above, the PolicyDesignSDCHandler must send back/publish status events to SDC such as DOWNLOAD_OK, DOWNLOAD_ERROR, DEPOLY_OK, DEPOLY_ERROR, NOTIFIED.
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. In the case of design-time via the SDC application, it is assumed the lifecycle being implemented by SDC will suffice for any policies that are declared within the ONAP Service CSAR. For Policy Templates and raw policies, the lifecycle associated with software development process will suffice. Since models, templates and raw policies will be deployed to a Nexus repository, software development best practices can utilized and configured for various environments (eg. development, testing, production) as desired.
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:
...
|
PolicyDevelopment provides a CRUD API for policy types and policies. The policy types and policy artifacts and their metadata (Information about policies, policy types, and their interrelations ) are stored in the PolicyDB. The PolicyDevGUI, PolicyDistribution, and other applications such as Portal can use the PolicyDevelopment API to create, update, and delete policy types and policies.
PolicyAdministration has two important functions:
- Management of the life cycle of PDPs in an ONAP installation. PDPs register with PolicyAdministration when they come up. PolicyAdministration handles the allocation of PDPs to a PDP Groups and PDP Subgroups, so that they can be managed as microservices in Kubernetes.
- Management of the deployment of policies to PDPs in an ONAP installation. PolicyAdministration gives each PDP group a set of domain policies to execute.
PolicyAdministration handles PDPs and policy allocation to PDPs using asynchronous messaging over DMaaP.
PolicyAdministation provides three APIs:
- a CRUD API for policy groups and subgroups
- an API that allows the allocation of policies PDP groups and subgroups to be controlled
- an API allows policy execution to be managed, showing the status of policy execution on PDP Groups, subgroups, and individual PDPs as well as the life cycle state of PDPs
PolicyExecution is the set of running PDPs that are executing policies, logically partitioned into PDP groups and subgroups.
draw.io Diagram | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The figure above shows how PolicyExecution looks at run time with PDPs running in Kubernetes. A PDPGroup is a purely logical construct that collects all the PDPs that are running policies for a particular domain together. A PDPSubGroup is a group of PDPs of the same type that are running the same policies. A PDPSubGroup is deployed as a Kubernetes Deployment. PDPs are defined as Kubernetes Pods. At run time, the actual number of PDPs in each PDPSubGroup is specified in the configuration of the Deployment of that PDPSubGroup in Kubernetes. This structuring of PDPs is required because, in order to simplify deployment and scaling of PDPs in Kubernetes, we gather all the PDPs of the same type that are running the same policies together for deployment.
For example, assume we have policies for the SON (Self Organizing Network) and ACPE (Advanced Customer Premises Service) domains. For SON, we have XACML, Drools, and APEX policies, and for ACPE we have XACML and Drools policies. The table below shows the resultingPDPGroup, PDPSubGroup, and PDP allocations:
PDP Group | PDP Subgroup | Kubernetes Deployment | Kubernetes Deployment Strategy | PDPs in Pods |
---|---|---|---|---|
SON | SON-XACML | SON-XACML-Dep | Always 2, be geo redundant | 2 PDP-X |
SON-Drools | SON-Drools-Dep | At Least 4, scale up on 70% load, scale down on 40% load, be geo-redundant | >= 4 PDP-D | |
SON-APEX | SON-APEX-Dep | At Least 3, scale up on 70% load, scale down on 40% load, be geo-redundant | >= 3 PDP-A | |
ACPE | ACPE-XACML | ACPE-XACML-Dep | Always 2 | 2 PDP-X |
ACPE-Drools | ACPE-Drools-Dep | At Least 2, scale up on 80% load, scale down on 50% load | >=2 PDP-D |
2.1 Policy Framework Object Model
This section describes the structure of and relations between the main concepts in the Policy Framework. This model is implemented as a common model and is used by PolicyDevelopment, PolicyDeployment, and PolicyExecution.
draw.io Diagram | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The UML class diagram above shows the portion of the Policy Framework Object Model that applies to PolicyDeployment and PolicyExecution.
draw.io Diagram | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The UML class diagram above shows the portion of the Policy Framework Object Model that applies to PolicyDevelopment and PolicyDeployment.
2.2 Policy Design Architecture
This section describes the architecture of the model driven system used to develop policy types and to create concrete policies using policy types. The output of Policy Design is deployment-ready artifacts 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 type implementation development is done by an experienced developer.
2.2.1 Policy Type Design
Policy Type Design is the task of creating policy types that capture the generic and vendor independent aspects of a policy for a particular domain use case. The policy type implementation specifies the model information, rules, and tasks that a policy type requires to generate concrete policies.
All policy types must implement the ONAP Policy Framework PolicyType interface. This interface allows PolicyDevelopment to manage policy types and to generate policies from these policy types in a uniform way regardless of the domain that the policy type is addressing or the PDP technology that will execute the policy. The interface is used by PolicyDevelopment to determine the PDP technology of the policy type, the structure, type, and definition of the model information that must be supplied to the policy type to generate a concrete policy.
A PolicyTypeImpl 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 type is specific for the type of policy being designed.
The PolicyTypeImpl implementation (or raw policy) is the specification of the specific rules or tasks, the flow of the policy, its internal states and data structures and other relevant information. A PolicyTypeImpl is specific to a PDP technology, that is XACML, Drools, or APEX. A PolicyTypeImpl can be specific to a particular policy type, it can be more general, providing the implementation of a class of policy types, or the same policy type may have many implementations.
PolicyDevelopment provides the RESTful Policy Design API, which allows other components to query policy types and policy type implementations, to determine the model information, rules, or tasks that they require, to specialize policy flow, and to generate policies from policy types. This API is used by the ONAP Policy Framework and other components such as PolicyDistribution to create policies from policy types.
Consider a policy type created for managing faults on vCPE equipment in a vendor independent way. The policy type captures the generic logic required to manage the faults and specifies the vendor specific information that must be supplied to the type for specific vendor vCPE VFs. The actual vCPE policy that is used for managing particular vCPE equipment is created by setting the parameters specified in the policy type together with the specific modeled information, rules and tasks in the policy type implementation for that vendor model of vCPE.
2.2.1 Generating Policy Types
It is possible to generate policy types using MDD (Model Driven Development) techniques. Policy types are expressed using a DSL (Domain Specific Language) or a policy specification environment for a particular application domain. For example, policy types for specifying SLAs could be expressed in a SLA DSL and policy types 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 types. SDC uses this approach for generating Policy Types in the Policy Framework, see the Model driven Control Loop Design page.
The SDC GUI supports several types of policies that can be captured at design time. DCAE micro service configuration policies can be onboarded via the DCAE-DS (DCAE Design Studio).
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant DCAE_DS <<API_User >>
box "PolicyDesign" #LightBlue
participant PolicyTypeDesign
end box
autonumber
DCAE_DS --> PolicyTypeDesign : Get Policy Type Reference and Metadata
PolicyTypeDesign --> PolicyDB : Get Policy Type Metadata\nand Artifact
alt Policy Type Artifact exists
PolicyTypeDesign --> DCAE_DS : Return Policy Type Reference and Metadata
else Policy Artifact does not exist
PolicyTypeDesign --> DCAE_DS : Return New Policy Type Reference and Empty Metadata
end
DCAE_DS --> DCAE_DS : Policy Type Editing and Generation Session
activate DCAE_DS
deactivate DCAE_DS
DCAE_DS --> PolicyTypeDesign : Create Policy Type and Metadata
PolicyTypeDesign --> DCAE_DS : Policy Generation Result
@enduml |
The GUI implementation in another ONAP component such as SDC DCAE-DS uses the API_User API to create and edit ONAP policy types.
2.2.1.2 Programming Policy Type Implementations
For skilled developers, the most straightforward way to create a policy type is to program it. Programming a policy type might simply mean creating and editing text files, thus manually creating the TOSCA Policy Type Yaml file and the policy type implementation for the policy type.
A more formal approach is preferred. For policy type implementations, programmers use a specific Eclipse project type for developing each type of implementation, a Policy Type Implementation SDK. The project is under source control in git. This Eclipse project is structured correctly for creating implementations for a specific type of PDP. It includes the correct POM files for generating the policy type implementation and has editors and perspectives that aid programmers in their work
2.2.2 Policy Design
The PolicyCreation function of PolicyDevelopment creates policies from a policy type. The information expressed during policy type design is used to parameterize a policy type to create an executable policy. A service designer and/or operations team can use tooling that reads the TOSCA Policy Type specifications to express and capture a policy at its highest abstraction level. Alternatively, the parameter for the policy can be expressed in a raw JSON or YAML file and posted over the policy design API described on the Model driven Control Loop Design page.
A number of mechanisms for policy creation are supported in ONAP. The process in PolicyDevelopment for creating a policy is the same for all mechanisms. The most general mechanism for creating a policy is using the RESTful Policy Design API, which provides a full interface to the policy creation support of PolicyDevelopment. This API may be exercised directly using utilities such as curl. PolicyDevelopment 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 creation, which again is a general purpose wrapper around the policy creation API. The Policy GUI can interpret any TOSCA Model ingested and flexibly presents a GUI for a user to create policies from. The development of these mechanisms will be phased over a number of ONAP releases.
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 create a policy 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.2.2.1 Policy Design in the ONAP Policy Framework
Policy creation in PolicyDevelopment follows the general sequence shown in the sequence diagram below. An API_USER is any component that wants to create a policy from a policy type. PolicyDevelopment supplies a REST interface that exposes the API and also provides a command line tool and general purpose client that wraps the API.
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant API_User
box "PolicyDesign" #LightBlue
participant PolicyDesign
database PolicyDB
end box
autonumber
API_User --> PolicyDesign : Get Policy Type Reference
PolicyDesign --> PolicyDB : Get Policy Type Artifact and Metadata
PolicyDesign --> API_User : Return Policy Type Reference and Metadata
API_User --> PolicyDesign : Get Policy Reference and Metadata
PolicyDesign --> PolicyDB : Get Policy Metadata
alt Policy Artifact exists
PolicyDesign --> API_User : Return Policy Reference and Metadata
else Policy Artifact does not exist
PolicyDesign --> API_User : Return New Policy Reference and Empty Metadata
end
API_User --> API_User : Policy Editing and Generation Session\nto get Policy Parameters from user
activate API_User
deactivate API_User
loop
API_User --> PolicyDesign : Use Policy Type specification
API_User --> PolicyDesign : Create Policy
PolicyDesign --> PolicyDesign : Create Policy
activate PolicyDesign
deactivate PolicyDesign
PolicyDesign --> PolicyDB : Save Policy Artifact and Metadata
PolicyDesign --> API_User : Policy Creation Result
@enduml |
A PolicyDevAPIUser first gets a reference to and the metadata for the Policy type for the policy they want to work on from PolicyDevelopment. PolicyDevelopment reads the metadata and artifact for the policy type from the database. The API_User then asks for a reference and the metadata for the policy. PolicyDevelopment looks up the policy in the database. If the policy already exists, PolicyDevelopment reads the artifact and returns the reference of the existing policy to the PolicyDevAPIUser with the metadata for the existing policy. If the policy does not exist, PolicyDevelopment creates and new reference and metadata and returns that to the API_User.
The PolicyDevAPIUser may now proceed with a policy specification session, where the parameters are set for the policy using the policy type specification. Once the PolicyDevAPIUser is happy that the policy is completely and correctly specified, it requests PolicyDevelopment to create the policy. PolicyDevelopment creates the policy, stores the created policy artifact and its metadata in the database.
2.2.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. The parameters to create a policy are read from a TOSCA Policy specification read from a CSAR received from SDC.
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant SDC
participant DMaaP
box "PolicyDesign" #LightBlue
participant PolicyDistribution << API_User >>
participant PolicyDesign
end box
autonumber
PolicyDistribution --> DMaaP : Subscribe for SDC Notifications\non Entries of Interest
SDC --> DMaaP : New Entry of Interest: EntityA
DMaaP --> PolicyDistribution : New Entry of Interest: EntityA
PolicyDistribution --> PolicyDesign : Get Policy Reference
PolicyDesign --> PolicyDistribution : Return Policy Reference and Metadata
PolicyDistribution --> PolicyDistribution : Create Policy Editing and Generation Session
activate PolicyDistribution
loop
PolicyDistribution --> PolicyDesign : Use Policy Type specification to\nread Policy Parameters\nfrom TOSCA specification in CSAR
end
PolicyDistribution --> PolicyDesign : Create Policy
PolicyDesign --> PolicyDistribution : Policy Creation Result
deactivate PolicyDistribution
@enduml |
PolicyDesign uses the PolicyDistribution component for managing SDC-triggered policy creation and update requests. PolicyDistribution is an API_User, it uses the Policy Design API for policy creation and update. It reads the information it needs to populate the policy type from a TOSCA specification in a CSAR received from SDC and then uses this information to automatically generate a policy.
Note that SDC provides a wrapper for the SDC API as a Java Client and also provides a TOSCA parser. See Policy Platform - SDC Service Distribution Software Architecture
In Step 4 above, the PolicyDesign must download the CSAR file. If the policy is to be composed from the TOSCA definition, it must also parse the TOSCA definition.
In Step 9 above, the PolicyDesign must send back/publish status events to SDC such as DOWNLOAD_OK, DOWNLOAD_ERROR, DEPLOY_OK, DEPLOY_ERROR, NOTIFIED.
2.2.2.4 Scripted Model Driven Policy Design
Service policies such as optimization and placement policies can be specified as a TOSCA Policy at design time. These policies use a TOSCA Policy Type specification as their schemas. Therefore, scripts can be used to create TOSCA policies using TOSCA Policy Types.
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant Script <<API_User >>
collections DirectiveFile
box "PolicyDesign" #LightBlue
participant PolicyTypeDesign
participant PolicyDesign
end box
autonumber
activate Script
loop
Script --> DirectiveFile : Read next directive from script file
Script --> PolicyTypeDesign : Read Policy Type for directive
Script --> Script : Create TOSCA Policy
Script --> Script : Read parameters from script file directive
Script --> Script : Set Parameters in TOSCA Policy
Script --> PolicyDesign : Generate Policy
PolicyDesign --> Script : Policy Generation Resultend
Script --> ConcretePolicyDesign : Generate Policy
ConcretePolicyDesign --> Script : Policy Generation Result
end
deactivate Script
@enduml |
One straightforward way of generating policies from Policy types is to use directives specified in a script file. The command line utility is an API_User. The script reads directives from a file. For each directive, it reads the policy type using the Policy Type API, and uses the parameters of the directive to create a TOSCA Policy. It then uses the Policy API to create the policy.
2.2.3 Policy Design Process
All policy types must be certified as being fit for deployment prior to run time deployment. In the case of design-time via the SDC application, it is assumed the lifecycle being implemented by SDC will suffice for any policy types that are declared within the ONAP Service CSAR. For other policy types and policy type implementations, the lifecycle associated with software development process will suffice. Since policy types and their implementations will be designed and implemented using software development best practices, they can be utilized and configured for various environments (eg. development, testing, production) as desired.
2.3 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 the Policy database and transfers policy sets to PDPs, and may cache the policy sets for PDP groups.
See also Sectino 2 of the TO BE DELETED - refer to Dublin Documentation page, where the mechanisms for PDP Deployment and Registration with PAP are explained.
2.3.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 and is specified for the full ONAP Kuberentes installation.
The following services will be required for the ONAP Policy Framework:
Service | Endpoint | Description |
---|---|---|
PAP | https://policy-pap | The PAP service, used for policy administration and deployment. See TO BE DELETED - refer to Dublin Documentation for details of the API for this service |
PDP-X-domain | https://policy-pdpx-domain | A PDP service is defined for each PDP group. A PDP group is identified by the domain on which it operates. For example, there could be two PDP-X domains, one for admission policies for ONAP proper and another for admission policies for VNFs of operator Supacom. Two PDP-X services are defined: https://policy-pdpx-onap |
PDP-D-domain | https://policy-pdpd-domain | |
PDP-A-domain | https://policy-pdpa-domain |
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.3.2 The Policy Framework Information Structure
The following diagram captures the relationship between Policy Framework concepts at run time.
PlantUML Macro | ||
---|---|---|
| ||
@startuml
object PDPSubGroup
object PDPService
object PolicySet
object PDP
object PolicyImpl
PDPSubGroup "1" -- "1" PDPService : > Lifecycle\nManaged\nBy
PDPService "1" -- "*" PDP : > Manages\nLifecycle\nOf
PDPService "1" -- "1" PolicySet : > Executes
PolicySet "1" -- "*" PDP : > Executes\nOn
PolicySet "1" -- "*" PolicyImpl : > Contains
@enduml |
There is a one to one relationship between a PDP SubGroup, a Kubernetes PDP service, and the set of policies assigned to run in the PDP subgroup. Each PDP service runs a single PDP subgroup with multiple PDPs, which executes a specific Policy Set containing a number of policies that have been assigned to that PDP subgroup. Having and maintaining this principle makes policy deployment and administration much more straightforward than it would be if complex relationships between PDP services, PDP subgroups, 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.
PlantUML Macro | ||
---|---|---|
| ||
@startuml
!define table(x) class x << (T,#FFAAAA) >>
!define primary_key(x) <u>x</u>
hide methods
hide stereotypes
table(PDP_SUBGROUP) {
primary_key(PDP_SUBGROUP_ID)
PDP_SUBGROUP_NAME
PDP_SUBGROUP_VERSION
PDP_TYPE
PDP_SERVICE_ENDPOINT
POLICY_SET_ID
PDP_SUBGROUP_STATE
}
table(PDP) {
primary_key(PDP_ID)
PDP_NAME
PDP_VERSION
PDP_TYPE
PDP_ENDPOINT
PDP_SUBGROUP_ID
POLICY_SET_ID
PDP_STATE
}
table(POLICY_SET) {
primary_key(POLICY_SET_ID)
POLICY_SET_NAME
POLICY_SET_VERSION
}
table(POLICYIMPL) {
primary_key(POLICY_IMPL_ID)
POLICY_NAME
POLICY_VERSION
PDP_TYPE
POLICY_ARTIFACT
}
table(POLICY_SET_TO_POLICY_IMPL) {
POLICY_SET_ID
POLICY_IMPL_ID
}
PDP_SUBGROUP::POLICY_SET_ID --> POLICY_SET::POLICY_SET_ID
PDP::PDP_SUBGROUP_ID --> PDP_SUBGROUP::PDP_SUBGROUP_ID
PDP::POLICY_SET_ID --> POLICY_SET::POLICY_SET_ID
POLICY_SET_TO_POLICY_IMPL::POLICY_SET_ID --> POLICY_SET::POLICY_SET_ID
POLICY_SET_TO_POLICY_IMPL::POLICY_IMPLID --> POLICY::POLICY_IMPL_ID
@endum |
The diagram above gives an indicative structure of the run time topology information in the Policy Framework database. Note that the PDP_SUBGROUP_STATE and PDP_STATE fields hold state information for life cycle management of PDP groups and PDPs.
2.3.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.3.3.1 PAP Startup and Shutdown
The sequence diagram below shows the actions of the PAP at startup.
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant K8S
participant PAP
database PolicyDB
autonumber
K8S --> PAP : Start PAP
PAP --> PolicyDB : Read Initial Data
PAP --> PAP : Initialize Policy Administration
activate PAP
deactivate PAP
loop forever
ref over PAP: Wait for and\nHandle PDP\nStatus Updates
ref over PAP: Wait for and\nHandle\nAdmin Requests
end
@enduml |
The PAP is the run time point of coordination for the ONAP Policy Framework. When it is started, it initializes itself using data from the database. 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.3.3.2 PDP Startup and Shutdown
The sequence diagram below shows the actions of the PDP at startup. See also Section 4 of the TO BE DELETED - refer to Dublin Documentation page for the API used to implement this sequence.
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant K8S
participant PDP
participant DMaaP
participant PAP
autonumber
K8S --> PDP : Start PDP
PDP --> PAP: Send Status (initial status) to PAP
ref over PAP, PDP: PAP downloads Policy Set to PDP
loop forever
PDP --> PAP: Send Status to PAP
end
@enduml |
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.
On receipt or a shutdown request, the PDP completes or aborts any ongoing policy executions and shuts down gracefully.
2.3.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.
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant REQUESTOR
participant RESPONDEE
participant PDP
autonumber
alt Synchronous Invocation
REQUESTOR --> PDP: Execute Policy
activate PDP
hnote over REQUESTOR : wait
PDP --> REQUESTOR: Policy Execution Result
deactivate PDP
else Asynchronous Invocation
REQUESTOR --> PDP: Execute Policy
activate PDP
PDP --> RESPONDEE: Policy Execution Result
deactivate PDP
end
@enduml |
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 and PDP-A use 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 and PDP-A use 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:
Lifecycle Mode | Behaviour |
---|---|
PASSIVE MODE | Policy execution is always rejected irrespective of PDP type. |
ACTIVE MODE | Policy execution is executed in the live environment by the PDP. |
SAFE MODE | Policy execution proceeds, but changes to domain state or context are not carried out. The PDP returns an indication that it is running in SAFE mode together with the action it would have performed if it was operating in ACTIVE mode. The PDP type and the policy types it is running must support SAFE mode operation. |
TEST MODE | Policy execution proceeds and changes to domain and state are carried out in a test or sandbox environment. The PDP returns an indication it is running in TEST mode together with the action it has performed on the test environment. The PDP type and the policy types it is running must support TEST mode operation. |
2.3.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.3.5.1 Load/Update Policies on PDP
The sequence diagram below shows how policies are loaded or updated on a PDP.
PlantUML Macro | ||
---|---|---|
| ||
@startuml
actor User
database PolicyDB
participant PAP
participant DMaaP
participant PDP
autonumber
alt PDP Startup
PDP --> PAP: Send Status (initial status) to PAP
else Update Request from User
User --> PAP : Update Policy on PDP
end
PAP --> PolicyDB: Read PDP metadata and Policy Set
PAP -> PAP: Prepare for PDP update
activate PAP
deactivate PAP
PAP --> PDP: Set PDP mode as PASSIVE
PAP --> PDP: Transfer Policy Set Policies to PDP
activate PDP
PDP --> PDP: Load Policies
deactivate PDP
alt PDP Mode should be ACTIVE
PAP --> PDP : Set PDP mode as ACTIVE
ref over PDP: Execute Policies in\nACTIVE Mode
else PDP Mode should be SAFE
PAP --> PDP : Set PDP mode as SAFE
ref over PDP: Execute Policies in\nSAFE Mode
else PDP Mode should be TEST
PAP --> PDP : Set PDP mode as TEST
ref over PDP: Execute Policies in\nTEST Mode
end
PAP --> PolicyDB: Update PDP metadata
@enduml |
This sequence can be initiated in two ways; from the PDP or from a user action.
- A PDP sends regular status update messages to the PAP. If this message indicates that the PDP has no policies or outdated policies loaded, then this sequence is initiated
- A user may explicitly trigger this sequence to load policies on a PDP
The PAP controls the entire process. The PAP reads the current PDP metadata and the required policy and policy set artifacts from the database. It then builds the policy set for the PDP. Once the policies are ready, 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 in the policy implementations.
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.3.4).
2.3.5.2 Policy Rollout
A policy set steps through a number of life cycle modes when it is rolled out.
PlantUML Macro | ||
---|---|---|
| ||
@startuml
actor User
participant PAP
participant PDP
autonumber
User --> PAP: Create Policy Set for PDP Group
loop over PDP Group
ref over PAP, PDP: PAP downloads Policy Set to PDP
end
User --> PAP: Set PDP Group in Test Mode
loop over PDP Group
PAP --> PDP: Set PDP in TEST mode
end
PDP --> PAP: Report test results
PAP --> User: Report consolidated test results
User --> PAP: Set PDP Group in Safe Mode
loop over PDP Group
PAP --> PDP: Set PDP in SAFE mode
end
PDP --> PAP: Report safe mode operation results
PAP --> User: Report consolidated safe mode operation results
User --> PAP: Set PDP Group in Active Mode
loop over PDP Group
PAP --> PDP: Set PDP in Active mode
end
loop forever
PDP --> PAP: Report active mode operation results
PAP --> User: Report consolidated active mode operation results
end
@enduml |
The user defines the set of policies for a PDP group. 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.3.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.3.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:
Field | Description |
---|---|
State | Lifecycle State (PASSIVE/TEST/SAFE/ACTIVE) |
Timestamp | Time the report record was generated |
InvocationCount | The number of execution invocations the PDP has processed since the last report |
LastInvocationTime | The time taken to process the last execution invocation |
AverageInvocationTime | The average time taken to process an invocation since the last report |
StartTime | The start time of the PDP |
UpTime | The length of time the PDP has been executing |
RealTimeInfo | Real time information on running policies. |
2.3.7 PEP Registration and Enforcement Guidelines
In ONAP there are several applications outside the Policy Framework that enforce policy decisions based on models provided to the Policy Framework. These applications are considered Policy Enforcement Engines (PEP) and roles will be provided to those applications using AAF/CADI to ensure only those applications can make calls to the Policy Decision API's. Some example PEP's are: DCAE, OOF, and SDNC.
See Section 3.4 of the TO BE DELETED - refer to Dublin Documentation for more information on the Decision APIs.
3. APIs Provided by the Policy Framework
See the TO BE DELETED - refer to Dublin Documentation page.
4
A PDP service is defined for each PDP group. A PDP group is identified by the domain on which it operates.
For example, there could be two PDP-X domains, one for admission policies for ONAP proper and another for admission policies for VNFs of operator Supacom. Two PDP-X services are defined:
https://policy-pdpx-onap
https://policy-pdpx-supacom
...
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.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.
- 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
- 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.
- 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
In ONAP there are several applications outside the Policy Framework that enforce policy decisions based on models provided to the Policy Framework. These applications are considered Policy Enforcement Engines (PEP) and roles will be provided to those applications using AAF/CADI to ensure only those applications can make calls to the Policy Decision API's. Some example PEP's are: DCAE, OOF, and SDNC.
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
Policy framework provides various APIs for users to create, update, delete (CRUD) various types of policies which include configuration (CONFIG) policies, XACML policies, Drools policies, APEX policies, etc. as well as CRUD of event schemas which are closed tied to policies in an event-driven fashion. CONFIG policies are the ones that contain detailed configurations of policy-enabled components in particular domains, which are basically in the format of key-value pairs. They will be subscribed by DCAE Micro-Services or other policy-enabled components. It is an important area the framework should provide backwards compatibility support when APIs are redesigned and evolving. XACML policies are typically access/admission control policies thus can be seamlessly specified for policy guard. Drools/APEX policies are action policies which will make runtime decisions reacting to particular network events via concrete actions or action guidance. They play a critical role in control loop implementation and management. Event schemas are as important as policies since all the policies are event-driven. Context/situation information are embedded in the input events. By knowing the semantics of events, policy rules can capture the logic of parsing the events, decide what reaction to come up with and how. Changing event schema will somehow impact policy logic. Hence, CRUD of event schemas are taken into account along with policy design.
Policy framework provides multiple options of creating policies to various types of users. Some users might be domain experts with proficient programming skills. They would probably like to compose the policies from scratch (a.k.a. raw policies) and are able to write templates for parametrized policies in particular domains. Providing policy CRUD option for such users is inevitable. There is another type of users who are not capable of writing raw policies and templates but have good understanding of existing templates and know what template they should use and what data to populate into the template in order to support real-world use cases. Hence, exposing APIs for CRUDing template-based policies to such users should also be considered. In addition, designing APIs for CRUDing event schemas is needed as well given event schema design can also be taken as a part of policy design. When user designs a policy, they also design the input and output events to/from the policy. Hence, event schemas will be included in policy payload. To ease re-usability of event schema, in each policy payload, user just needs to specify the names of new/existing schemas they want to use in current policy. Eligibility of specified schemas will be validated by the framework before the policy is being processed.
3.1.1 Data Model for APIs
The very first step of API design is to come up with data models for various API objects. Hence, data models for policy, policy template and event schema are in our scope here.
Data models for the APIs can be downloaded from here: API-MODEL-Policy.json, API-MODEL-Policy_Template.json, API-MODEL-Event_Schema.json
It is worth noting that above listed models are generic ones to support CRUD of various types of policies by various types of users (i.e. DEV users who know how to program policies/templates and know how to package/generate maven artifact and do maven deployment; GUI users who will CRUD template-based policies via GUI only), and have backwards compatibility with existing CONFIG policies and XACML guard policies.
3.1.2 Raw Policy Creation
An important API is to support CRUD of raw policy. The "raw" here means the policy is composed from scratch, not based on any template. We assume such API users are all DEV users who master policy programming using native policy language provided by each policy engine and know how to do maven compilation, artifact generation and deployment given policy will be stored as maven artifact. The sequence diagram is shown below.
The first step is for DEV user to wrap up policy artifact with details included in the note below, submit it to governance process for validation, then deploy it to nexus repository. Next, POST /policy/raw is invoked to create raw policy with payload populated (payload format is in the note below). It is worth noting that since policy contents/rules are already included in the artifact which has been deployed to nexus, there is no need to put them again in the payload "data" field. Hence, only "metadata" is meaningful for the payload here.
After the API is invoked, the first thing is to check the eligibility of event schemas specified in the payload, checking whether each event schema name has one matching entry in DB SCHEMA table. If yes, save policy metadata to Database to keep a record.
3.1.3 Policy Template Creation
DEV users are capable of not only programming raw policies, but programming policy templates which expose several parameters to be populated by GUI users. In other words, we assume templates are being created by only DEV users. The sequence diagram is shown below. Given DEV users know programming and maven deployment, similarly, we require them to deploy template archetype artifact to nexus by themselves as the first step. It is worth noting that template contents would be different for various types of policy. It is also noted below. For example, Drools policy template would be Drools rules with configurable parameters in .drl file; XACML policy template would be xacml policies/rules with configurable parameters in .xml file; APEX policy template would be APEX policy model with configurable parameters in .apex file; CONFIG policy template can be defined as a JSON file with configurable parameters.
Different from policy artifact, in addition to template metadata and contents, template archetype artifact also contains the descriptor of configurable parameters to populate the template, which is stored in archetype.xml, noted below. Also, a new field called "populateDataSchema" is specified in payload which is used to indicate the schema type such as JSON, YAML, TOSCA and so on. TOSCA is referred to existing TOSCA policy schema for backwards compatibility with CONFIG policy.
The rest of the flows are similar. After POST /template API is invoked, event schema eligibility will be checked first. Then template metadata will be saved to Database as a record.
3.1.4 Template-Based Policy Creation by DEV user
Given template archetype artifact is created and deployed to nexus, for the users who want to base the template to create concrete policies, the first step is to review existing templates and select one to work on. The key to create policy based upon a template is to populate the template by required parameter values. It can be done by maven archetype plugin - archetype:generate given template is stored as archetype artifact. Here, we design different flows for different types of users. The sequence diagram for DEV users is shown below. For DEV users who master maven and would like to do programming, they can do API calls GET /templates and GET /template/{template-id} to review existing templates and select one to work on, then use maven archetype generate plugin to populate the template by their own. After wrapping up the policy artifact, DEV users should deploy it to nexus as before, followed by invoking template-based policy creation API to save policy metadata to Database.
3.1.5 Template-Based Policy Creation by GUI user
TBD - No Resources to work on the GUI
Another type of users who prefer to manipulate template-based policies through GUI. Thus, we call them GUI users here, without loss of generality. The sequence diagram is shown below. Basically, all such users' operations are through GUI, including reviewing/selecting existing templates and populating selected template by providing values to fill out configurable parameters in the template. The options to fill configurable parameters should be rendered by GUI. The configurable parameters here include those embedded in the template and the ones in policy metadata like "artifactId", "version" and so on. GUI backend will invoke corresponding API calls and pass in API arguments upon users' input in the GUI. It is worth noting that, in this scenario, all parameter values used to populate the template are specified in the "data" field of the payload and passed in to the API call. PAP will call maven archetype generation plugin to package a policy artifact on top of a populated template and do nexus deployment.
3.1.6 Event Schema Creation
Since all the policies are event-driven, which means they will be triggered by input events and generate necessary output events to downstream actioning systems that will enforce the policies. Thus, designing event schemas is a part of policy design. Corresponding API is provided to CRUD event schema. Sequence diagram is shown below. Note that event schemas need to be specified during policy creation, and their eligibility will be checked. Thus, for the users who want to create a new policy, it is preferred that they know what event schemas are existing and ready to be used or they can create new event schemas to support particular policies and user cases. It is worth noting that before saving new schema to Database, it will be checked if it is a new schema that has not been created before so that it is guaranteed every event schema stored in Database is unique and will not cause ambiguity.
3.1.7 Policy Query via API
Policy query design is still WIP. Initial thoughts are collected in the sequence diagram shown below.
3.1.8 Policy Query via GUI
WIP. Initial results are shown below.
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
...
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
...
Unused in Casablanca
...
The XACML PDP implementation
...
This repo will hold the next generation Apex PDP engine
...
. Terminology
PAP (Policy Administration Point) | A component that administers and manages policies | ||
PDP (Policy Deployment Point) | A component that executes a policy artifact (One or many?) | ||
PDP_<> | A specific type of PDP | PDP Group | A group of PDPs that execute the same (set of?) policy artifact(s) |
Policy Development | The development environment for policies | ||
PolicyTemplate | A generic prototype policy that may or may not be executable. It can be stored in Nexus and support a maven archetype interface to be to generate other policy templates and/or concrete policies. They are a way to organize a common set of rules into one place for re-usability. | ||
DomainPolicy | A specialization of a generic policy for application to a specific domain | ||
PolicyParameters | Parameters that configure a policy for execution in a PDP group | ||
Executable Policy | A policy that can be stored in Nexus and can execute on a certain type of PDP. An executable policy is a parameterized policy template or domain policy | ||
A specific type of PDP | |||
PDP Group | A group of PDPs that execute the same set of policies | ||
Policy Development | The development environment for policies | ||
Policy Type | A generic prototype definition of a type of policy in TOSCA, see the TOSCA Policy Primer | ||
Policy | An executable policy defined in TOSCA and created using a Policy Type, see the TOSCA Policy Primer | ||
Executable Policy Set | A set of policies that are deployed on a PDP group. One and only one Policy Set is deployed on a PDP group |
...