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