1 .. This work is licensed under a
2 .. Creative Commons Attribution 4.0 International License.
3 .. http://creativecommons.org/licenses/by/4.0
5 .. DO NOT REMOVE THIS LABEL - EVEN IF IT GENERATES A WARNING
8 .. THIS IS USED INTERNALLY IN POLICY ONLY
9 .. _architecture-label:
11 Policy Framework Architecture
12 #############################
16 This document describes the ONAP Policy Framework. It lays out the architecture of the framework and shows the APIs
17 provided to other components that interwork with the framework. It describes the implementation of the framework,
18 mapping out the components, software structure, and execution ecosystem of the framework.
33 The ONAP Policy Framework is a comprehensive policy design, deployment, and execution environment. The Policy Framework
34 is the decision making component in `an ONAP system
35 <https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_Architecture_112918FNL.pdf>`__.
36 It allows you to specify, deploy, and execute the governance of the features and functions in your ONAP system, be they
37 closed loop, orchestration, or more traditional open loop use case implementations. The Policy Framework is the
38 component that is the source of truth for all policy decisions.
40 One of the most important goals of the Policy Framework is to support Policy Driven Operational Management during the
41 execution of ONAP control loops at run time. In addition, use case implementations such as orchestration and control
42 benefit from the ONAP policy Framework because they can use the capabilities of the framework to manage and execute
43 their policies rather than embedding the decision making in their applications.
45 The Policy Framework is deployment agnostic, it manages Policy Execution (in PDPs) and Enforcement (in PEPs) regardless
46 of how the PDPs and PEPs are deployed. This allows policy execution and enforcement to be deployed in a manner that
47 meets the performance requirements of a given application or use case. In one deployment, policy execution could be
48 deployed in a separate executing entity in a Docker container. In another, policy execution could be co-deployed with
49 an application to increase performance. An example of co-deployment is the Drools PDP Control Loop image, which is a
50 Docker image that combines the ONAP Drools use case application and dependencies with the Drools PDP engine.
52 The ONAP Policy Framework architecture separates policies from the platform that is supporting them. The framework
53 supports development, deployment, and execution of any type of policy in ONAP. The Policy Framework is metadata (model)
54 driven so that policy development, deployment, and execution is as flexible as possible and can support modern rapid
55 development ways of working such as `DevOps
56 <https://en.wikipedia.org/wiki/DevOps>`__. A metadata driven approach also allows the amount of programmed support
57 required for policies to be reduced or ideally eliminated.
59 We have identified five capabilities as being essential for the framework:
61 1. Most obviously, the framework must be capable of being triggered by an event or invoked, and making decisions at run
64 2. It must be deployment agnostic; capable of managing policies for various Policy Decision Points (PDPs) or policy
67 3. It must be metadata driven, allowing policies to be deployed, modified, upgraded, and removed as the system executes.
69 4. It must provide a flexible model driven policy design approach for policy type programming and specification of
72 5. It must be extensible, allowing straightforward integration of new PDPs, policy formats, and policy development
75 Another important aim of the architecture of a model driven policy framework is that it enables much more flexible
76 policy specification. The ONAP Policy Framework complies with the `TOSCA
77 <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.1/TOSCA-Simple-Profile-YAML-v1.1.pdf>`__ modelling
78 approach for policies, see the :ref:`TOSCA Policy Primer <tosca-label>` for more information on how policies are modeled
81 1. A *Policy Type* describes the properties, targets, and triggers that the policy for a feature can have. A Policy type is
82 implementation independent. It is the metadata that specifies:
84 - the *configuration* data that the policy can take. The Policy Type describes each property that a policy of a
85 given type can take. A Policy Type definition also allows the default value, optionality, and the ranges of properties
88 - the *targets* such as network element types, functions, services, or resources on which a policy of the given type
91 - the *triggers* such as the event type, filtered event, scheduled trigger, or conditions that can activate a policy
94 Policy Types are hierarchical, A Policy Type can inherit from a parent Policy Type, inheriting the properties, targets,
95 and triggers of its parent. Policy Types are developed by domain experts in consultation with the developers that
96 implement the logic and rules for the Policy Type.
98 2. A *Policy* is defined using a Policy Type. The Policy defines:
100 - the values for each property of the policy type
101 - the specific targets (network elements, functions, services, resources) on which this policy will act
102 - the specific triggers that trigger this policy.
104 3. A *Policy Type Implementation* or *Raw Policy*, is the logic that implements the policy. It is implemented by a
105 skilled policy developer in consultation with domain experts. The implementation has software that reads the Policy
106 Type and parses the incoming configuration properties. The software has domain logic that is triggered when one of the
107 triggers described in the Policy Type occurs. The software logic executes and acts on the targets specified in the
111 For example, a Policy Type could be written to describe how to manage Service Level Agreements for VPNs. The VPN Policy
112 Type can be used to create VPN policies for a bank network, a car dealership network, or a university with many campuses.
113 The Policy Type has two parameters:
115 - The *maximumDowntime* parameter allows the maximum downtime allowed per year to be specified
116 - The *mitigationStrategy* parameter allows one of three strategies to be selected for downtime breaches
118 - *allocateMoreResources*, which will automatically allocate more resources to mitigate the problem
119 - *report*, which report the downtime breach to a trouble ticketing system
120 - *ignore*, which logs the breach and takes no further action
122 The Policy Type defines a trigger event, an event that is received from an analytics system when the maximum downtime
123 value for a VPN is breached. The target of the policy type is an instance of the VPN service.
125 The Policy Type Implementation is developed that can configure the maximum downtime parameter in an analytics system,
126 can receive a trigger from the analytics system when the maximum downtime is breached, and that can either request more
127 resources, report an issue to a trouble ticketing system, and can log a breach.
129 VPN Policies are created by specifying values for the properties, triggers, and targets specified in VPN Policy Type.
131 In the case of the bank network, the *maximumDowntime* threshold is specified as 5 minutes downtime per year and the
132 *mitigationStrategy* is defined as *allocateMoreResources*, and the target is specified as being the bank's VPN service
133 ID. When a breach is detected by the analytics system, the policy is executed, the target is identified as being the
134 bank's network, and more resources are allocated by the policy.
136 For the car dealership VPN policy, a less stringent downtime threshold of 60 minutes per year is specified, and the
137 mitigation strategy is to issue a trouble ticket. The university network is best effort, so a downtime of 4 days per
138 year is specified. Breaches are logged and mitigated as routine network administration tasks.
140 In ONAP, specific ONAP Policy Types are used to create specific policies that drive the ONAP Platform and Components.
141 For more detailed information on designing Policy Types and developing an implementation for that policy type, see
142 :ref:`Policy Design and Development <design-label>`.
144 The ONAP Policy Framework for building, configuring and deploying PDPs is extendable. It allows the use of ONAP PDPs as
145 is, the extension of ONAP PDPs, and lastly provides the capability for users to create and deploy their own PDPs. The
146 ONAP Policy Framework provides distributed policy management for **all** policies in ONAP at run time. Not only does
147 this provide unified policy access and version control, it provides life cycle control for policies and allows detection
148 of conflicts across all policies running in an ONAP installation.
153 The diagram below shows the architecture of the ONAP Policy Framework at its highest level.
155 .. image:: images/PFHighestLevel.svg
157 The *PolicyDevelopment* component implements the functionality for development of policy types and policies.
158 *PolicyAdministration* is responsible for the deployment life cycle of policies as well as interworking with the
159 mechanisms required to orchestrate the nodes and containers on which policies run. *PolicyAdministration* is also
160 responsible for the administration of policies at run time; ensuring that policies are available to users, that policies
161 are executing correctly, and that the state and status of policies is monitored. *PolicyExecution* is the set of PDPs
162 running in the ONAP system and is responsible for making policy decisions and for managing the administrative state of
163 the PDPs as directed by \ *PolicyAdministration.*
165 *PolicyDevelopment* provides APIs that allow creation of policy artifacts and supporting information in the policy
166 database. *PolicyAdministration* reads those artifacts and the supporting information from the policy database whilst
167 deploying policy artifacts. Once the policy artifacts are deployed, *PolicyAdministration* handles the run-time
168 management of the PDPs on which the policies are running. *PolicyDevelopment* interacts with the database, and has
169 no programmatic interface with *PolicyAdministration*, *PolicyExecution* or any other run-time ONAP components.
171 The diagram below shows a more detailed view of the architecture, as inspired by
172 `RFC-2753 <https://tools.ietf.org/html/rfc2753>`__ and `RFC-3198 <https://tools.ietf.org/html/rfc3198>`__.
174 .. image:: images/PFDesignAndAdmin.svg
176 *PolicyDevelopment* provides a `CRUD <https://en.wikipedia.org/wiki/Create,_read,_update_and_delete>`__ API for policy
177 types and policies. The policy types and policy artifacts and their metadata (information about policies, policy types,
178 and their interrelations) are stored in the *PolicyDB*. The *PolicyDevGUI*, PolicyDistribution, and other applications
179 such as *CLAMP* can use the *PolicyDevelopment* API to create, update, delete, and read policy types and policies.
181 *PolicyAdministration* has two important functions:
183 - Management of the life cycle of PDPs in an ONAP installation. PDPs register with *PolicyAdministration* when they come
184 up. *PolicyAdministration* handles the allocation of PDPs to PDP Groups and PDP Subgroups, so that they can be
185 managed as microservices in infrastructure management systems such as Kubernetes.
187 - Management of the deployment of policies to PDPs in an ONAP installation. *PolicyAdministration* gives each PDP group
188 a set of domain policies to execute.
190 *PolicyAdministration* handles PDPs and policy allocation to PDPs using asynchronous messaging over DMaaP. It provides
193 - a CRUD API for policy groups and subgroups
195 - an API that allows the allocation of policies to PDP groups and subgroups to be controlled
197 - an API allows policy execution to be managed, showing the status of policy execution on PDP Groups, subgroups, and
198 individual PDPs as well as the life cycle state of PDPs
200 *PolicyExecution* is the set of running PDPs that are executing policies, logically partitioned into PDP groups and
203 .. image:: images/PolicyExecution.svg
205 The figure above shows how *PolicyExecution* looks at run time with PDPs running in Kubernetes. A *PDPGroup* is a purely
206 logical construct that collects all the PDPs that are running policies for a particular domain together. A *PDPSubGroup*
207 is a group of PDPs of the same type that are running the same policies. *A PDPSubGroup* is deployed as a Kubernetes
208 `Deployment <https://kubernetes.io/docs/concepts/workloads/controllers/deployment/>`__. PDPs are defined as Kubernetes
209 `Pods <https://kubernetes.io/docs/concepts/workloads/pods/pod/>`__. At run time, the actual number of PDPs in each
210 *PDPSubGroup* is specified in the configuration of the *Deployment* of that *PDPSubGroup* in Kubernetes. This
211 structuring of PDPs is required because, in order to simplify deployment and scaling of PDPs in Kubernetes, we gather
212 all the PDPs of the same type that are running the same policies together for deployment.
214 For example, assume we have policies for the SON (Self Organizing Network) and ACPS (Advanced Customer Premises Service)
215 domains. For SON,we have XACML, Drools, and APEX policies, and for ACPS we have XACML and Drools policies. The table
216 below shows the resulting \ *PDPGroup*, *PDPSubGroup*, and PDP allocations:
218 ============= ================ ========================= ======================================== ================
219 **PDP Group** **PDP Subgroup** **Kubernetes Deployment** **Kubernetes Deployment Strategy** **PDPs in Pods**
220 ============= ================ ========================= ======================================== ================
221 SON SON-XACML SON-XACML-Dep Always 2, be geo redundant 2 PDP-X
222 \ SON-Drools SON-Drools-Dep At Least 4, scale up on 70% load, >= 4 PDP-D
223 scale down on 40% load, be geo-redundant
224 \ SON-APEX SON-APEX-Dep At Least 3, scale up on 70% load, scale >= 3 PDP-A
225 down on 40% load, be geo-redundant
226 ACPS ACPS-XACML ACPS-XACML-Dep Always 2 2 PDP-X
227 \ ACPS-Drools ACPS-Drools-Dep At Least 2, scale up on 80% load, scale >=2 PDP-D
229 ============= ================ ========================= ======================================== ================
231 For more details on *PolicyAdministration* APIs and management of *PDPGroup* and *PDPSubGroup*, see the documentation
232 for :ref:`Policy Administration Point (PAP) Architecture <pap-label>`.
234 2.1 Policy Framework Object Model
235 ---------------------------------
237 This section describes the structure of and relations between the main concepts in the Policy Framework. This model is
238 implemented as a common model and is used by *PolicyDevelopment*, *PolicyDeployment,* and *PolicyExecution.*
240 .. image:: images/ClassStructure.svg
242 The UML class diagram above shows thePolicy Framework Object Model.
244 2.2 Policy Design Architecture
245 ------------------------------
247 This section describes the architecture of the model driven system used to develop policy types and to create
248 policies using policy types. The output of Policy Design is deployment-ready artifacts and Policy metadata in the Policy
251 Policy types that are expressed via natural language or a model require an implementation that allows them to be
252 translated into runtime policies. Some Policy Type implementations are set up and available in the platform during
253 startup such as Control Loop Operational Policy Models, OOF placement Models, DCAE microservice models. Policy type
254 implementations can also be loaded and deployed at run time.
256 2.2.1 Policy Type Design
257 ^^^^^^^^^^^^^^^^^^^^^^^^
259 Policy Type Design is the task of creating policy types that capture the generic and vendor independent aspects of a
260 policy for a particular domain use case.
262 All policy types are specified in TOSCA service templates. Once policy types are defined and created in the system,
263 *PolicyDevelopment* manages them and uses them to allow policies to be created from these policy types in a uniform
264 way regardless of the domain that the policy type is addressing or the PDP technology that will execute the policy.
266 A *PolicyTypeImpl* is developed for a policy type for a certain type of PDP (for example XACML oriented for decision
267 policies, Drools rules or Apex state machines oriented for ECA policies). While a policy type is implementation
268 independent, a policy type implementation for a policy type is specific for the technology of the PDP on which
269 policies that use that policy type implementation will execute. A Policy Type may have many implementations. A
270 *PolicyTypeImpl* is the specification of the specific rules or tasks, the flow of the policy, its internal states
271 and data structures and other relevant information. A *PolicyTypeImpl* can be specific to a particular policy type
272 or it can be more general, providing the implementation of a class of policy types. Further, the design environment
273 and tool chain for implementing implementations of policy types is specific to the technology of the PDP on which
274 the implementation will run.
276 In the *xacml-pdp* and *drools-pdp*, an *application* is written for a given category of policy types. Such an
277 application may have logic written in Java or another programming language, and may have additional artifacts such
278 as scripts and SQL queries. The *application* unmarshals and marshals events going into and out of policies as well
279 as handling the sequencing of events for interactions of the policies with other components in ONAP. For example,
280 *drools-applications* handles the interactions for operational policies running in the drools PDP. In the
281 *apex-pdp*, all unmarshaling, marshaling, and component interactions are captured in the state machine, logic, and
282 configuraiton of the policy, a Java application is not used.
284 *PolicyDevelopment* provides the RESTful :ref:`Policy Design API <design-label>`, which allows other components to query
285 policy types, Those components can then create policies that specify values for the properties, triggers, and targets
286 specified in a policy type. This API is used by components such as *CLAMP* and *PolicyDistribution* to create policies
289 Consider a policy type created for managing faults on vCPE equipment in a vendor independent way. The policy type
290 implementation captures the generic logic required to manage the faults and specifies the vendor specific information
291 that must be supplied to the type for specific vendor vCPE VFs. The actual vCPE policy that is used for managing
292 particular vCPE equipment is created by setting the properties specified in the policy type for that vendor model
295 2.2.1.1 Generating Policy Types
296 """""""""""""""""""""""""""""""
298 It is possible to generate policy types using MDD (Model Driven Development) techniques. Policy types are expressed
299 using a DSL (Domain Specific Language) or a policy specification environment for a particular application domain. For
300 example, policy types for specifying SLAs could be expressed in a SLA DSL and policy types for managing SON features
301 could be generated from a visual SON management tool. The ONAP Policy framework provides an API that allows tool chains
302 to create policy types, see the :ref:`Policy Design and Development <design-label>` page.
304 .. image:: images/PolicyTypeDesign.svg
306 A GUI implementation in another ONAP component (a *PolicyTypeDesignClient*) may use the *API_User* API to create and
307 edit ONAP policy types.
309 2.2.1.2 Programming Policy Type Implementations
310 """""""""""""""""""""""""""""""""""""""""""""""
312 For skilled developers, the most straightforward way to create a policy type is to program it. Programming a policy type
313 might simply mean creating and editing text files, thus manually creating the TOSCA Policy Type YAML file and the policy
314 type implementation for the policy type.
316 A more formal approach is preferred. For policy type implementations, programmers use a specific Eclipse project type
317 for developing each type of implementation, a Policy Type Implementation SDK. The project is under source control in
318 git. This Eclipse project is structured correctly for creating implementations for a specific type of PDP. It includes
319 the correct POM files for generating the policy type implementation and has editors and perspectives that aid
320 programmers in their work
325 The *PolicyCreation* function of *PolicyDevelopment* creates policies from a policy type. The information expressed
326 during policy type design is used to parameterize a policy type to create an executable policy. A service designer
327 and/or operations team can use tooling that reads the TOSCA Policy Type specifications to express and capture a policy
328 at its highest abstraction level. Alternatively, the parameter for the policy can be expressed in a raw JSON or YAML
329 file and posted over the policy design API described on the :ref:`Policy Design and Development <design-label>` page.
331 A number of mechanisms for policy creation are supported in ONAP. The process in *PolicyDevelopment* for creating a
332 policy is the same for all mechanisms. The most general mechanism for creating a policy is using the RESTful
333 *Policy Design API*, which provides a full interface to the policy creation support of *PolicyDevelopment*. This API may
334 be exercised directly using utilities such as *curl*.
336 In future releases, the Policy Framework may provide a command line tool that will be a loose wrapper around the API. It
337 may also provide a general purpose Policy GUI in the ONAP Portal for policy creation, which again would be a general
338 purpose wrapper around the policy creation API. The Policy GUI would interpret any TOSCA Model that has been loaded into
339 it and flexibly presents a GUI for a user to create policies from. The development of these mechanisms will be phased
340 over a number of ONAP releases.
342 A number of ONAP components use policy in manners which are specific to their particular needs. The manner in which the
343 policy creation process is triggered and the way in which information required to create a policy is specified and
344 accessed is specialized for these ONAP components.
346 For example, *CLAMP* provides a GUI for creation of Control Loop policies, which reads the Policy Type associated
347 with a control loop, presents the properties as fields in its GUI, and creates a policy using the property values entered
350 The following subsections outline the mechanisms for policy creation and modification supported by the ONAP Policy
353 2.2.2.1 Policy Design in the ONAP Policy Framework
354 """"""""""""""""""""""""""""""""""""""""""""""""""
356 Policy creation in *PolicyDevelopment* follows the general sequence shown in the sequence diagram below. An *API_USER*
357 is any component that wants to create a policy from a policy type. *PolicyDevelopment* supplies a REST interface that
358 exposes the API and also provides a command line tool and general purpose client that wraps the API.
360 .. image:: images/PolicyDesign.svg
362 An *API_User* first gets a reference to and the metadata for the Policy type for the policy they want to work on from
363 *PolicyDevelopment*. *PolicyDevelopment* reads the metadata and artifact for the policy type from the database. The
364 *API_User* then asks for a reference and the metadata for the policy. *PolicyDevelopment* looks up the policy in the
365 database. If the policy already exists, *PolicyDevelopment* reads the artifact and returns the reference of the existing
366 policy to the *API_User* with the metadata for the existing policy. If the policy does not exist, *PolicyDevelopment*
367 informs the *API_User*.
369 The *API_User* may now proceed with a policy specification session, where the parameters are set for the policy using
370 the policy type specification. Once the *API_User* is happy that the policy is completely and correctly specified, it
371 requests *PolicyDevelopment* to create the policy. *PolicyDevelopment* creates the policy, stores the created policy
372 artifact and its metadata in the database.
374 2.2.2.2 Model Driven VF (Virtual Function) Policy Design via VNF SDK Packaging
375 """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
377 VF vendors express policies such as SLA, Licenses, hardware placement, run-time metric suggestions, etc. These details
378 are captured within the VNF SDK and uploaded into the SDC Catalog. The `SDC Distribution APIs
379 <https://wiki.onap.org/display/DW/SDC+Distribution+client+AID>`__ are used to interact with SDC. For example, SLA and
380 placement policies may be captured via TOSCA specification. License policies can be captured via TOSCA or an XACML
381 specification. Run-time metric vendor recommendations can be captured via the VES Standard specification.
383 The sequence diagram below is a high level view of SDC-triggered concrete policy generation for some arbitrary entity
384 *EntityA*. The parameters to create a policy are read from a TOSCA Policy specification read from a CSAR received from
387 .. image:: images/ModelDrivenPolicyDesign.svg
389 *PolicyDesign* uses the *PolicyDistribution* component for managing SDC-triggered policy creation and update requests.
390 *PolicyDistribution* is an *API_User*, it uses the Policy Design API for policy creation and update. It reads the
391 information it needs to populate the policy type from a TOSCA specification in a CSAR received from SDC and then uses
392 this information to automatically generate a policy.
394 Note that SDC provides a wrapper for the SDC API as a Java Client and also provides a TOSCA parser. See the
395 documentation for the `Policy Distribution Component
396 <https://docs.onap.org/projects/onap-policy-parent/en/latest/distribution/distribution.html>`__.
398 In Step 4 above, the \ *PolicyDesign* must download the CSAR file. If the policy is to be composed from the TOSCA
399 definition, it must also parse the TOSCA definition.
401 In Step 11 above, the \ *PolicyDesign* must send back/publish status events to SDC such as DOWNLOAD_OK, DOWNLOAD_ERROR,
402 DEPLOY_OK, DEPLOY_ERROR, NOTIFIED.
404 2.2.2.3 Scripted Model Driven Policy Design
405 """""""""""""""""""""""""""""""""""""""""""
407 Service policies such as optimization and placement policies can be specified as a TOSCA Policy at design time. These
408 policies use a TOSCA Policy Type specification as their schemas. Therefore, scripts can be used to create TOSCA policies
409 using TOSCA Policy Types.
411 .. image:: images/ScriptedPolicyDesign.svg
413 One straightforward way of generating policies from Policy types is to use commands specified in a script file. A
414 command line utility such as *curl* is an *API_User*. Commands read policy types using the Policy Type API, parse the
415 policy type and uses the properties of the policy type to prepare a TOSCA Policy. It then issues further commands to use
416 the Policy API to create policies.
418 2.2.3 Policy Design Process
419 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
421 All policy types must be certified as being fit for deployment prior to run time deployment. Where design is executed
422 using the SDC application, it is assumed the life cycle being implemented by SDC certifies any policy types that
423 are declared within the ONAP Service CSAR. For other policy types and policy type implementations, the life cycle
424 associated with the applied software development process suffices. Since policy types and their implementations are
425 designed and implemented using software development best practices, they can be utilized and configured for various
426 environments (eg. development, testing, production) as desired.
428 2.3 Policy Runtime Architecture
429 -------------------------------
431 The Policy Framework Platform components are themselves designed as microservices that are easy to configure and deploy
432 via Docker images and K8S both supporting resiliency and scalability if required. PAPs and PDPs are deployed by the
433 underlying ONAP management infrastructure and are designed to comply with the ONAP interfaces for deploying containers.
435 The PAPs keep track of PDPs, support the deployment of PDP groups and the deployment of a *policy set* across those PDP
436 groups. A PAP is stateless in a RESTful sense. Therefore, if there is more than one PAP deployed, it does not matter
437 which PAP a user contacts to handle a request. The PAP uses the database (persistent storage) to keep track of ongoing
438 sessions with PDPs. Policy management on PDPs is the responsibility of PAPs; management of policy sets or policies by
439 any other manner is not permitted.
441 In the ONAP Policy Framework, the interfaces to the PDP are designed to be as streamlined as possible. Because the PDP
442 is the main unit of scalability in the Policy Framework, the framework is designed to allow PDPs in a PDP group to
443 arbitrarily appear and disappear and for policy consistency across all PDPs in a PDP group to be easily maintained.
444 Therefore, PDPs have just two interfaces; an interface that users can use to execute policies and interface to the PAP
445 for administration, life cycle management and monitoring. The PAP is responsible for controlling the state across the
446 PDPs in a PDP group. The PAP interacts with the Policy database and transfers policy sets to PDPs, and may cache the
447 policy sets for PDP groups.
449 See also Section 2 of the :ref:`Policy Design and Development <design-label>` page, where the mechanisms for PDP
450 Deployment and Registration with PAP are explained.
452 2.3.1 Policy Framework Services
453 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
455 The ONAP Policy Framework follows the architectural approach for microservices recommended by the `ONAP Architecture
456 Subcommittee <https://wiki.onap.org/display/DW/Architecture+Subcommittee>`__.
458 The ONAP Policy Framework uses an infrastructure such as Kubernetes `Services
459 <https://kubernetes.io/docs/concepts/services-networking/service/>`__ to manage the life cycle of Policy Framework
460 executable components at runtime. A Kubernetes service allows, among other parameters, the number of instances (*pods*
461 in Kubernetes terminology) that should be deployed for a particular service to be specified and a common endpoint for
462 that service to be defined. Once the service is started in Kubernetes, Kubernetes ensures that the specified number of
463 instances is always kept running. As requests are received on the common endpoint, they are distributed across the
464 service instances. More complex call distribution and instance deployment strategies may be used; please see the
465 `Kubernetes Services <https://kubernetes.io/docs/concepts/services-networking/service/>`__ documentation for those
468 If, for example, a service called *policy-pdpd-control-loop* is defined that runs 5 PDP-D instances. The service has the
469 end point *https://policy-pdpd-control-loop.onap/<service-specific-path>*. When the service is started, Kubernetes spins
470 up 5 PDP-Ds. Calls to the end point *https://policy-pdpd-control-loop.onap/<service-specific-path>* are distributed
471 across the 5 PDP-D instances. Note that the *.onap* part of the service endpoint is the namespace being used and is
472 specified for the full ONAP Kubernetes installation.
474 The following services will be required for the ONAP Policy Framework:
476 ================ ============================== =======================================================================
477 **Service** **Endpoint** **Description**
478 ================ ============================== =======================================================================
479 PAP https://policy-pap The PAP service, used for policy administration and deployment. See
480 :ref:`Policy Design and Development <design-label>` for details of the
482 PDP-X-\ *domain* https://policy-pdpx-\ *domain* A PDP service is defined for each PDP group. A PDP group is identified
483 by the domain on which it operates.
485 For example, there could be two PDP-X domains, one for admission
486 policies for ONAP proper and another for admission policies for VNFs of
487 operator *Supacom*. Two PDP-X services are defined:
489 | https://policy-pdpx-onap
490 | https://policy-pdpx-\ *supacom*
491 PDP-D-\ *domain* https://policy-pdpd-\ *domain*
492 PDP-A-\ *domain* https://policy-pdpa-\ *domain*
493 ================ ============================== =======================================================================
495 There is one and only one PAP service, which handles policy deployment, administration, and monitoring for all policies
496 in all PDPs and PDP groups in the system. There are multiple PDP services, one PDP service for each domain for which
499 2.3.2 The Policy Framework Information Structure
500 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
502 The following diagram captures the relationship between Policy Framework concepts at run time.
504 .. image:: images/RuntimeRelationships.svg
506 There is a one to one relationship between a PDP SubGroup, a Kubernetes PDP service, and the set of policies assigned to
507 run in the PDP subgroup. Each PDP service runs a single PDP subgroup with multiple PDPs, which executes a specific
508 Policy Set containing a number of policies that have been assigned to that PDP subgroup. Having and maintaining this
509 principle makes policy deployment and administration much more straightforward than it would be if complex relationships
510 between PDP services, PDP subgroups, and policy sets.
512 The topology of the PDPs and their policy sets is held in the Policy Framework database and is administered by the PAP service.
514 .. image:: images/PolicyDatabase.svg
516 The diagram above gives an indicative structure of the run time topology information in the Policy Framework database.
517 Note that the *PDP_SUBGROUP_STATE* and *PDP_STATE* fields hold state information for life cycle management of PDP groups
520 2.3.3 Startup, Shutdown and Restart
521 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
523 This section describes the interactions between Policy Framework components themselves and with other ONAP components at
524 startup, shutdown and restart.
526 2.3.3.1 PAP Startup and Shutdown
527 """"""""""""""""""""""""""""""""
529 The sequence diagram below shows the actions of the PAP at startup.
531 .. image:: images/PAPStartStop.svg
533 The PAP is the run time point of coordination for the ONAP Policy Framework. When it is started, it initializes itself
534 using data from the database. It then waits for periodic PDP status updates and for administration requests.
536 PAP shutdown is trivial. On receipt or a shutdown request, the PAP completes or aborts any ongoing operations and shuts
539 2.3.3.2 PDP Startup and Shutdown
540 """"""""""""""""""""""""""""""""
542 The sequence diagram below shows the actions of the PDP at startup. See also Section 4 of the
543 :ref:`Policy Design and Development <design-label>` page for the API used to implement this sequence.
545 .. image:: images/PDPStartStop.svg
547 At startup, the PDP initializes itself. At this point it is in PASSIVE mode. The PDP begins sending periodic Status
548 messages to the PAP. The first Status message initializes the process of loading the correct Policy Set on the PDP in
551 On receipt or a shutdown request, the PDP completes or aborts any ongoing policy executions and shuts down gracefully.
553 2.3.4 Policy Execution
554 ^^^^^^^^^^^^^^^^^^^^^^
556 Policy execution is the execution of a policy in a PDP. Policy enforcement occurs in the component that receives a
559 .. image:: images/PolicyExecutionFlow.svg
561 Policy execution can be *synchronous* or *asynchronous*. In *synchronous* policy execution, the component requesting a
562 policy decision requests a policy decision and waits for the result. The PDP-X and PDP-A implement synchronous policy
563 execution. In *asynchronous* policy execution, the component that requests a policy decision does not wait for the
564 decision. Indeed, the decision may be passed to another component. The PDP-D and PDP-A implement asynchronous polic
567 Policy execution is carried out using the current life cycle mode of operation of the PDP. While the actual
568 implementation of the mode may vary somewhat between PDPs of different types, the principles below hold true for all
571 ================== =====================================================================================================
572 **Lifecycle Mode** **Behaviour**
573 ================== =====================================================================================================
574 PASSIVE MODE Policy execution is always rejected irrespective of PDP type.
575 ACTIVE MODE Policy execution is executed in the live environment by the PDP.
576 SAFE MODE* Policy execution proceeds, but changes to domain state or context are not carried out. The PDP
577 returns an indication that it is running in SAFE mode together with the action it would have
578 performed if it was operating in ACTIVE mode. The PDP type and the policy types it is running must
579 support SAFE mode operation.
580 TEST MODE* Policy execution proceeds and changes to domain and state are carried out in a test or sandbox
581 environment. The PDP returns an indication it is running in TEST mode together with the action it has
582 performed on the test environment. The PDP type and the policy types it is running must support TEST
584 ================== =====================================================================================================
586 \* SAFE Mode and TEST Mode will be implemented in future versions of the Policy Framework.
588 2.3.5 Policy Lifecycle Management
589 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
591 Policy lifecycle management manages the deployment and life cycle of policies in PDP groups at run time. Policy sets can
592 be deployed at run time without restarting PDPs or stopping policy execution. PDPs preserve state for minor/patch
593 version upgrades and rollbacks.
595 2.3.5.1 Load/Update Policies on PDP
596 """""""""""""""""""""""""""""""""""
598 The sequence diagram below shows how policies are loaded or updated on a PDP.
600 .. image:: images/DownloadPoliciesToPDP.svg
602 This sequence can be initiated in two ways; from the PDP or from a user action.
604 1. A PDP sends regular status update messages to the PAP. If this message indicates that the PDP has no policies or
605 outdated policies loaded, then this sequence is initiated
607 2. A user may explicitly trigger this sequence to load policies on a PDP
609 The PAP controls the entire process. The PAP reads the current PDP metadata and the required policy and policy set
610 artifacts from the database. It then builds the policy set for the PDP. Once the policies are ready, the PAP sets the
611 mode of the PDP to PASSIVE. The Policy Set is transparently passed to the PDP by the PAP. The PDP loads all the policies
612 in the policy set including any models, rules, tasks, or flows in the policy set in the policy implementations.
614 Once the Policy Set is loaded, the PAP orders the PDP to enter the life cycle mode that has been specified for it
615 (ACTIVE/SAFE*/TEST*). The PDP begins to execute policies in the specified mode (see section 2.3.4).
617 \* SAFE Mode and TEST Mode will be implemented in future versions of the Policy Framework.
621 2.3.5.2 Policy Rollout
622 """"""""""""""""""""""
624 A policy set steps through a number of life cycle modes when it is rolled out.
626 .. image:: images/PolicyRollout.svg
628 The user defines the set of policies for a PDP group. It is deployed to a PDP group and is initially in PASSIVE mode.
629 The user sets the PDP Group into TEST mode. The policies are run in a test or sandboxed environment for a period of
630 time. The test results are passed back to the user. The user may revert the policy set to PASSIVE mode a number of times
631 and upgrade the policy set during test operation.
633 When the user is satisfied with policy set execution and when quality criteria have been reached for the policy set, the
634 PDP group is set to run in SAFE mode. In this mode, the policies run on the target environment but do not actually
635 exercise any actions or change any context in the target environment. Again, as in TEST mode, the operator may decide to
636 revert back to TEST mode or even PASSIVE mode if issues arise with a policy set.
638 Finally, when the user is satisfied with policy set execution and when quality criteria have been reached, the PDP group
639 is set into ACTIVE state and the policy set executes on the target environment. The results of target operation are
640 reported. The PDP group can be reverted to SAFE, TEST, or even PASSIVE mode at any time if problems arise.
642 \* SAFE Mode and TEST Mode will be implemented in future versions of the Policy Framework. In current versions, policies
643 transition directly from PASSIVE mode to ACTIVE mode.
645 2.3.5.3 Policy Upgrade and Rollback
646 """""""""""""""""""""""""""""""""""
648 There are a number of approaches for managing policy upgrade and rollback. Upgrade and rollback will be implemented in
649 future versions of the Policy Framework.
651 The most straightforward approach is to use the approach described in section :ref:`policy-rollout` for upgrading and
652 rolling back policy sets. In order to upgrade a policy set, one follows the process in :ref:`policy-rollout` with the
653 new policy set version. For rollback, one follows the process in :ref:`policy-rollout` with the older policy set, most
654 probably setting the old policy set into ACTIVE mode immediately. The advantage of this approach is that the approach is
655 straightforward. The obvious disadvantage is that the PDP group is not executing on the target environment while the new
656 policy set is in PASSIVE, TEST, and SAFE mode.
658 A second manner to tackle upgrade and rollback is to use a spare-wheel approach. An special upgrade PDP group service is
659 set up as a K8S service in parallel with the active one during the upgrade procedure. The spare wheel service is used to
660 execute the process described in :ref:`policy-rollout`. When the time comes to activate the policy set, the references
661 for the active and spare wheel services are simply swapped. The advantage of this approach is that the down time during
662 upgrade is minimized, the spare wheel PDP group can be abandoned at any time without affecting the in service PDP group,
663 and the upgrade can be rolled back easily for a period simply by preserving the old service for a time. The disadvantage
664 is that this approach is more complex and uses more resources than the first approach.
666 A third approach is to have two policy sets running in each PDP, an active set and a standby set. However such an
667 approach would increase the complexity of implementation in PDPs significantly.
669 2.3.6 Policy Monitoring
670 ^^^^^^^^^^^^^^^^^^^^^^^
672 PDPs provide a periodic report of their status to the PAP. All PDPs report using a standard reporting format that is
673 extended to provide information for specific PDP types. PDPs provide at least the information below:
675 ===================== ===============================================================================
676 **Field** **Description**
677 ===================== ===============================================================================
678 State Lifecycle State (PASSIVE/TEST*/SAFE*/ACTIVE)
679 Timestamp Time the report record was generated
680 InvocationCount The number of execution invocations the PDP has processed since the last report
681 LastInvocationTime The time taken to process the last execution invocation
682 AverageInvocationTime The average time taken to process an invocation since the last report
683 StartTime The start time of the PDP
684 UpTime The length of time the PDP has been executing
685 RealTimeInfo Real time information on running policies.
686 ===================== ===============================================================================
688 \* SAFE Mode and TEST Mode will be implemented in future versions of the Policy Framework.
690 Currently, policy monitoring is supported by PAP and by pdp-apex. Policy monitoring for all PDPs will be supported in
691 future versions of the Policy Framework.
693 2.3.7 PEP Registration and Enforcement Guidelines
694 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
696 In ONAP there are several applications outside the Policy Framework that enforce policy decisions based on models
697 provided to the Policy Framework. These applications are considered Policy Enforcement Engines (PEP) and roles will be
698 provided to those applications using AAF/CADI to ensure only those applications can make calls to the Policy Decision
699 APIs. Some example PEPs are: DCAE, OOF, and SDNC.
701 See Section 3.4 of the :ref:`Policy Design and Development <design-label>`
702 for more information on the Decision APIs.
704 2.3.8 Multi-Cluster Support
705 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
707 Multi-cluster support was added to the Policy Framework during the Istanbul release,
708 enabling redundancy, load-sharing, and inter-site failover.
710 **Note:** *multi-cluster support has only been minimally tested, and is thus still
716 Multi-cluster support requires a shared DB. Rather than spinning up a
717 separate DB for each cluster, all of the clusters are pointed to a common DB.
718 Policy-API adds policy types and policies, while Policy-PAP manages PDP Groups and
719 Subgroups, as well as policy deployments. The information in these tables is not
720 segregated, but is, instead, shared across the API and PAP components across all of
723 .. image:: images/MCSharedDB.svg
725 2.3.8.2 DMaaP Arrangement
726 """""""""""""""""""""""""
728 As in prior releases, communication between the PAPs and PDPs still takes place via
729 DMaaP. Two arrangements, described below, are supported.
731 2.3.8.2.1 Local DMaaP
732 ~~~~~~~~~~~~~~~~~~~~~
734 In this arrangement, each cluster is associated with its own, local
735 DMaaP, and communication only happens between PAPs and PDPs within the same cluster.
737 .. image:: images/MCLocalDmaap.svg
740 limitation with this approach is that, when a PAP in cluster A deploys a policy, PAP
741 is only able to inform the PDPs in the local cluster; the PDPs in the other clusters
742 are not made aware of the new deployment until they generate a heartbeat, at which
743 point, their local PAP will inform them of the new deployment. The same is true of
744 changes made to the state of a PDP Group; changes only propagate to PDPs in other
745 clusters in response to heartbeats generated by the PDPs.
747 .. image:: images/MCLocalHB.svg
749 2.3.8.2.2 Shared DMaaP
750 ~~~~~~~~~~~~~~~~~~~~~~
752 In this arrangement, the PAPs and PDPs in all of the clusters are
753 pointed to a common DMaaP. Because the PAP and PDPs all communicate via the same
754 DMaaP, when a PAP deploys a policy, all PDPs are made aware, rather than having to
755 wait for a heartbeat.
757 .. image:: images/MCSharedDmaap.svg
759 2.3.8.3 Missed Heartbeat
760 """"""""""""""""""""""""
762 To manage the removal of terminated PDPs from the DB, a record, containing a
763 "last-updated" timestamp, is maintained within the DB for each PDP. Whether using a
764 local or shared DMaaP, any PAP receiving a message from a PDP will update the timestamp
765 in the associated record, thus keeping the records “current”.
767 .. image:: images/MCSharedHB.svg
769 Periodically, each PAP will sweep the DB of PDP records whose timestamp has not been
770 updated recently. The frequency with which it is checked is based on the value of
771 the "heartbeatMs" configuration parameter, with a record considered expired if no
772 heartbeat has been received for three cycles.
774 .. image:: images/MCMissedHB.svg
777 3. APIs Provided by the Policy Framework
778 ========================================
780 See the :ref:`Policy Design and Development <design-label>` page.
785 ================================= ==================================================================================
786 PAP (Policy Administration Point) A component that administers and manages policies
787 ================================= ==================================================================================
788 PDP (Policy Deployment Point) A component that executes a policy artifact (One or many?)
789 PDP_<> A specific type of PDP
790 PDP Group A group of PDPs that execute the same set of policies
791 Policy Development The development environment for policies
792 Policy Type A generic prototype definition of a type of policy in TOSCA, see the
793 :ref:`TOSCA Policy Primer <tosca-label>`
794 Policy An executable policy defined in TOSCA and created using a Policy Type, see the
795 :ref:`TOSCA Policy Primer <tosca-label>`
796 Policy Set A set of policies that are deployed on a PDP group. One and only one Policy Set is
797 deployed on a PDP group
798 ================================= ==================================================================================