blob: 28215dedc8eedd785ade21e463af9cae2c2a264f [file] [log] [blame]
Pamela Dragosh5ed4e852017-09-22 12:26:16 -04001.. This work is licensed under a Creative Commons Attribution 4.0 International License.
2.. http://creativecommons.org/licenses/by/4.0
3
4
5Architecture
6------------
Saryu Shah84e9e3b2017-09-29 15:53:37 +00007
8.. contents::
9 :depth: 3
10
Saryu Shah1e2f68b2017-09-26 17:14:12 +000011POLICY is a subsystem of ONAP that maintains, distributes, and operates on the set of rules that underlie ONAPs control, orchestration, and management functions.
12
Saryu Shah1a307682017-09-29 00:31:12 +000013POLICY provides a logically centralized environment for the creation and management of policies, including conditional rules. This provides the capability to **create** and **validate** policies/rules, **identify overlaps**, **resolve conflicts**, and **derive** additional policies as needed. Policies are used to **control**, **influence**, and help **ensure compliance** with goals. Policies can support infrastructure, products and services, operation automation, and security. Users, including network and service designers, operations engineers, and security experts, can easily **create**, **change**, and **manage** policy rules from the POLICY Manager in the ONAP Portal.
Saryu Shah1e2f68b2017-09-26 17:14:12 +000014
15The figure below represents the target POLICY Architecture.
16
Saryu Shah3eddd582017-10-12 22:03:55 +000017.. image:: PolicyTargetArchitecture.png
Saryu Shah1e2f68b2017-09-26 17:14:12 +000018
19
20The figure below represents the current POLICY Architecture.
21
Saryu Shah3eddd582017-10-12 22:03:55 +000022.. image:: PolicyR1Architecture.png
Saryu Shah1e2f68b2017-09-26 17:14:12 +000023
24
Saryu Shah1a307682017-09-29 00:31:12 +000025A policy is defined to create a condition, requirement, constraint, decision, or a need that must be provided, evaluated, maintained, and/or enforced. The policy is validated and corrected for any conflicts, and then placed in the appropriate repository, and made available for use by other subsystems and components. Alternately, some policies are directly distributed to policy decision engines such as Drools or XACML. In this manner, the constraints, decisions and actions to be taken are distributed.
Saryu Shah1e2f68b2017-09-26 17:14:12 +000026
Saryu Shah1e2f68b2017-09-26 17:14:12 +000027
28System Architecture
29^^^^^^^^^^^^^^^^^^^
30
Saryu Shah1a307682017-09-29 00:31:12 +000031ONAP POLICY is composed of several subcomponents: the **Policy Administration Point (PAP)**, which offers interfaces for policy creation, and two types of **Policy Decision Point (PDP)**, each based on a specific rules technology. PDP-X is based on XACML technology and PDP-D is based on Drools technology. PDP-X is **stateless** and can be deployed as a resource pool of PDP-X servers. The number of servers can be grown to increase both capacity (horizontal scalability) and to increase availability. The PDP-D is **stateful**, as it utilizes Drools in its native, stateful way and transactions persist so long as the PDP-D is active. Persistent Drools sessions, state management, local and geo-redundancy have been deactivated for the initial release of ONAP POLICY and can be turned on in a future release. Additional instances of XACML/Drools engines and assigned roles/purposes may also be added in the future to provide a flexible, expandable policy capability.
Saryu Shah1e2f68b2017-09-26 17:14:12 +000032
33As illustrated in the Figure below, the POLICY components are supported by a number of interfaces and subsystems. The ONAP Portal provides a human interface for the creation, management and deployment of policies. It is a web-based system that utilizes internal APIs in the PAP.
34
Saryu Shah3eddd582017-10-12 22:03:55 +000035.. image:: PolicyArchitectureDetails.png
Saryu Shah1e2f68b2017-09-26 17:14:12 +000036
37
Saryu Shah1a307682017-09-29 00:31:12 +000038The PAP provides interfaces for the management of policies. It utilizes the XACML database to store policies, which are then distributed to the PDPs.
Saryu Shah1e2f68b2017-09-26 17:14:12 +000039
Saryu Shah1a307682017-09-29 00:31:12 +000040The XACML and Drools databases are hosted in a MariaDB cluster. The XACML database is used to persist policies and policy dictionaries and provide a point for PDPs to retrieve policies. The XACML database also has tables used for node state management, detection of node failure and failover. As indicated above, the state management tables will only include entries for the PAP and PDP-X as the testing is not yet complete for the PDP-D.
Saryu Shah1e2f68b2017-09-26 17:14:12 +000041
42The PDP-X receives deployed policies and has interfaces to handle XACML policy transactions. These transactions are stateless and once complete, they are removed from memory. If a policy that is deployed to the PDP-X is of an operational nature it will contain Drools rules and Java executables. These artifacts are processed into Maven artifacts and pushed to the Maven repository. The PDP-D is then notified a new policy has been deployed.
43
Saryu Shah1a307682017-09-29 00:31:12 +000044When the PDP-D is notified a new policy has been deployed, it downloads it from the Maven repository and assigns it to an internal controller. This controller provides the external Closed Loop interfaces to the DMaaP message bus over which events and messages are exchanged with external systems. As events or messages arrive at the PDP-D, they are assigned to the appropriate controller and a Drools session is either created or retrieved from memory. The events, messages or facts are passed to the Drools session and the corresponding rule is fired, resulting in a change of internal session state and possibly actions taken in response to the rule processing. Response messages and requests are passed by the controller back over the DMaaP message bus to the appropriate system. The Drools session can also have timers and autonomous events. In a future release the PDP-D can enable the node state management and session persistence in the Drools DB.
Saryu Shah1e2f68b2017-09-26 17:14:12 +000045
46
47Policy Creation
48^^^^^^^^^^^^^^^
Saryu Shah1a307682017-09-29 00:31:12 +000049The Policy Creation component of the Policy subsystem enables creation of new policies and modification of existing polices, both during the design phase and during runtime. Policy Creation is targeted to be integrated to a unified Service Design and Creation (SDC) environment.
Saryu Shah1e2f68b2017-09-26 17:14:12 +000050
Saryu Shah1a307682017-09-29 00:31:12 +000051A policy can be defined at a high level to create a condition, requirement, constraint, decision or a need that must be provided, evaluated, maintained, and/or enforced. A policy can also be defined at a lower or functional level, such as a machine-readable rule or software condition/assertion which enables actions to be taken based on a trigger or request, specific to particular selected conditions in effect at that time.
Saryu Shah1e2f68b2017-09-26 17:14:12 +000052
53Some examples of types of policies are:
54
55* VNF placement rules governing where VNFs should be placed, including affinity rules
56* Data and feed management what data to collect and when, retention periods, and when to send alarms about issues
57* Access control who (or what) can have access to which data
58* Trigger conditions and actions what conditions are actionable, and what to do under those conditions
59* Interactions how interactions between change management and fault/performance management are handled (for example, should closed loops be disabled during maintenance?)
60
61
62Policy Distribution
63^^^^^^^^^^^^^^^^^^^
Saryu Shah1a307682017-09-29 00:31:12 +000064
65After a policy has been initially created or an existing policy has been modified, the Policy Distribution Framework sends the policy from the repository to its points of use, which include Policy Decision Points (PDPs) and Policy enforcement points (DCAE, Controllers, etc), before the policy is actually needed.
Saryu Shah1e2f68b2017-09-26 17:14:12 +000066
67The decisions and actions taken by the policy are distributed. Policies are distributed either in conjunction with installation packages (for example, related to service instantiation) or independently, if unrelated to a particular service. Some policies can be configured (e.g., configuring policy parameters within microservices), while other polices are delivered to policy engines such as XAMCL and Drools. With this methodology, policies will already be available when needed by a component, minimizing real-time requests to a central policy engine or PDP (Policy Decision Point). This improves scalability and reduces latency.
68
69Separate notifications or events communicate the link or URL for a policy to the components that need it. Then, when a component needs the policy, it uses the link to fetch it. Components in some cases might also publish events indicating that they need new policies, eliciting a response with updated links or URLs. Also, in some cases, policies can indicate to components that they should subscribe to one or more policies, so that they receive automatic updates to those policies as they become available.
70
71
72Policy Decision and Enforcement
73^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
74
Saryu Shah1a307682017-09-29 00:31:12 +000075Run-time policy enforcement is performed by ONAP subsystems that are policy-enabled or can respond to commands from a policy-enabled element such as a PDP. For example, policy rules for data collection are enforced by the data collection functionality of DCAE. Analytic policy rules, identification of anomalous or abnormal conditions, and publication of events signaling detection of such conditions are enforced by DCAE analytic applications. Policy rules for associated remedial actions, or for further diagnostics, are enforced by the correct component in a control loop such as the MSO, a Controller, or DCAE. Policy engines such as XACML and Drools also enforce policies and can trigger other components as a result (for example, causing a controller to take specific actions specified by the policy). Additionally, some policies (“Guard Policies”) may enforce checks against decided actions.
Saryu Shah1e2f68b2017-09-26 17:14:12 +000076
77
78Policy Unification and Organization
79^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
80Because the POLICY framework is expandable and multipurpose, it is likely to contain many types of policies which require organization according to some useful dimensions. Users can define attributes that specify the scope of policies, and these attributes can be extended to the policy-enabled functions and components. Useful policy organizing dimensions might include:
81
82* Policy type or category (taxonomical)
Saryu Shah1a307682017-09-29 00:31:12 +000083* Policy life cycle
Saryu Shah1e2f68b2017-09-26 17:14:12 +000084* Policy ownership or administrative domain
85* Geographic area or location,
86* Technology type
87* Policy language and version
88* Security level or other security-related values, specifiers, or limiters
89
90Attributes can be specified for each dimension. In addition to being defined for individual policies themselves, these attributes can be used to define the scope of these additional additional policy-related functions:
91
92* Policy events or requests/triggers
93* Policy decision, enforcement, or other functions
94* Virtual functions of any type
95
Saryu Shah1a307682017-09-29 00:31:12 +000096Policy writers can define attributes so that policy events or requests self-indicate their scope. The scope is then examined by a suitable function and subsequently acted upon accordingly. Policy decisions and enforcement functions can self-indicate their scope of decision-making, enforcement, or other capabilities. Virtual functions can be automatically attached to the appropriate POLICY Framework and distribution mechanisms.
Saryu Shah1e2f68b2017-09-26 17:14:12 +000097
98
Saryu Shah3198d6d2017-11-07 21:40:27 +000099End of Document
100