...
PolicyDevelopment creates policy artifacts and supporting information in the policy database. PolicyAdministration reads those artifacts and the supporting information from the 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.
...
| Drawio | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The UML class diagram above shows the portion of the Policy Framework Object Model that applies to PolicyDeployment and PolicyExecution.
| Drawio | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The UML class diagram above shows the portion of the Policy Framework Object Model that applies to PolicyDevelopment and PolicyDeployment.
...
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.
...
See also Sectino 2 of the Policy Design and API Flow for Model Driven Control Loop - Draft TO BE DELETED - refer to Dublin Documentation page, where the mechanisms for PDP Deployment and Registration with PAP are explained.
...
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.
...
| Service | Endpoint | Description |
|---|---|---|
| PAP | https://policy-pap | The PAP service, used for policy administration and deployment. See Policy Design and API Flow for Model Driven Control Loop - Draft 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 |
...
The sequence diagram below shows the actions of the PDP at startup. See also Section 4 of the Policy Design and API Flow for Model Driven Control Loop - Draft TO BE DELETED - refer to Dublin Documentation page for the API used to implement this sequence.
...
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 Policy Design and API Flow for Model Driven Control Loop - Draft TO BE DELETED - refer to Dublin Documentation for more information on the Decision APIs.
3. APIs Provided by the Policy Framework
See the Policy Design and API Flow for Model Driven Control Loop - Draft TO BE DELETED - refer to Dublin Documentation page.
4. 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 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 |
| 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 |
...