Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 1 | .. This work is licensed under a |
| 2 | .. Creative Commons Attribution 4.0 International License. |
Pamela Dragosh | 5ed4e85 | 2017-09-22 12:26:16 -0400 | [diff] [blame] | 3 | .. http://creativecommons.org/licenses/by/4.0 |
| 4 | |
| 5 | |
| 6 | Architecture |
| 7 | ------------ |
Saryu Shah | 84e9e3b | 2017-09-29 15:53:37 +0000 | [diff] [blame] | 8 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 9 | .. contents:: |
Saryu Shah | 84e9e3b | 2017-09-29 15:53:37 +0000 | [diff] [blame] | 10 | :depth: 3 |
| 11 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 12 | POLICY is a subsystem of ONAP that maintains, distributes, and operates on the |
| 13 | set of rules that underlie ONAP’s control, orchestration, and management |
| 14 | functions. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 15 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 16 | POLICY provides a logically centralized environment for the creation and |
| 17 | management of policies, including conditional rules. This provides the |
| 18 | capability to **create** and **validate** policies/rules, **identify |
| 19 | overlaps**, **resolve conflicts**, and **derive** additional policies as |
| 20 | needed. Policies are used to **control**, **influence**, and help **ensure |
| 21 | compliance** with goals. Policies can support infrastructure, products and |
| 22 | services, operation automation, and security. Users, including network and |
| 23 | service designers, operations engineers, and security experts, can easily |
| 24 | **create**, **change**, and **manage** policy rules from the POLICY Manager |
| 25 | in the ONAP Portal. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 26 | |
| 27 | The figure below represents the target POLICY Architecture. |
| 28 | |
Saryu Shah | 3eddd58 | 2017-10-12 22:03:55 +0000 | [diff] [blame] | 29 | .. image:: PolicyTargetArchitecture.png |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 30 | |
| 31 | |
| 32 | The figure below represents the current POLICY Architecture. |
| 33 | |
Saryu Shah | 3eddd58 | 2017-10-12 22:03:55 +0000 | [diff] [blame] | 34 | .. image:: PolicyR1Architecture.png |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 35 | |
| 36 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 37 | A policy is defined to create a condition, requirement, constraint, decision, |
| 38 | or a need that must be provided, evaluated, maintained, and/or enforced. The |
| 39 | policy is validated and corrected for any conflicts, and then placed in the |
| 40 | appropriate repository, and made available for use by other subsystems and |
| 41 | components. Alternately, some policies are directly distributed to policy |
| 42 | decision engines such as Drools or XACML. In this manner, the constraints, |
| 43 | decisions and actions to be taken are distributed. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 44 | |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 45 | |
| 46 | System Architecture |
| 47 | ^^^^^^^^^^^^^^^^^^^ |
| 48 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 49 | ONAP POLICY is composed of several subcomponents: the **Policy Administration |
| 50 | Point (PAP)**, which offers interfaces for policy creation, and two types of |
| 51 | **Policy Decision Point (PDP)**, each based on a specific rules technology. |
| 52 | PDP-X is based on XACML technology and PDP-D is based on Drools technology. |
| 53 | PDP-X is **stateless** and can be deployed as a resource pool of PDP-X servers. |
| 54 | The number of servers can be grown to increase both capacity (horizontal |
| 55 | scalability) and to increase availability. The PDP-D is **stateful**, as it |
| 56 | utilizes Drools in its native, stateful way and transactions persist so long as |
| 57 | the PDP-D is active. Persistent Drools sessions, state management, local and |
| 58 | geo-redundancy have been deactivated for the initial release of ONAP POLICY |
| 59 | and can be turned on in a future release. Additional instances of XACML/Drools |
| 60 | engines and assigned roles/purposes may also be added in the future to |
| 61 | provide a flexible, expandable policy capability. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 62 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 63 | As illustrated in the Figure below, the POLICY components are supported by a |
| 64 | number of interfaces and subsystems. The ONAP Portal provides a human |
| 65 | interface for the creation, management and deployment of policies. It is a |
| 66 | web-based system that utilizes internal APIs in the PAP. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 67 | |
Saryu Shah | 3eddd58 | 2017-10-12 22:03:55 +0000 | [diff] [blame] | 68 | .. image:: PolicyArchitectureDetails.png |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 69 | |
| 70 | |
Saryu Shah | 82b62ca | 2018-03-19 22:18:13 +0000 | [diff] [blame] | 71 | .. image:: PolicyArchitectureDetailsKey.png |
| 72 | |
| 73 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 74 | The PAP provides interfaces for the management of policies. It utilizes the |
| 75 | XACML database to store policies, which are then distributed to the PDPs. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 76 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 77 | The XACML and Drools databases are hosted in a MariaDB cluster. The XACML |
| 78 | database is used to persist policies and policy dictionaries and provide a |
| 79 | point for PDPs to retrieve policies. The XACML database also has tables used |
| 80 | for node state management, detection of node failure and failover. As indicated |
| 81 | above, the state management tables will only include entries for the PAP and |
| 82 | PDP-X as the testing is not yet complete for the PDP-D. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 83 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 84 | The PDP-X receives deployed policies and has interfaces to handle XACML policy |
| 85 | transactions. These transactions are stateless and once complete, they are |
| 86 | removed from memory. If a policy that is deployed to the PDP-X is of an |
| 87 | operational nature it will contain Drools rules and Java executables. These |
| 88 | artifacts are processed into Maven artifacts and pushed to the Maven |
| 89 | repository. The PDP-D is then notified a new policy has been deployed. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 90 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 91 | When the PDP-D is notified a new policy has been deployed, it downloads it from |
| 92 | the Maven repository and assigns it to an internal controller. This controller |
| 93 | provides the external Closed Loop interfaces to the DMaaP message bus over |
| 94 | which events and messages are exchanged with external systems. As events or |
| 95 | messages arrive at the PDP-D, they are assigned to the appropriate controller |
| 96 | and a Drools session is either created or retrieved from memory. The events, |
| 97 | messages or facts are passed to the Drools session and the corresponding rule |
| 98 | is fired, resulting in a change of internal session state and possibly actions |
| 99 | taken in response to the rule processing. Response messages and requests are |
| 100 | passed by the controller back over the DMaaP message bus to the appropriate |
| 101 | system. The Drools session can also have timers and autonomous events. In a |
| 102 | future release the PDP-D can enable the node state management and session |
| 103 | persistence in the Drools DB. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 104 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 105 | Casablanca Additions to Architecture |
| 106 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 107 | The Casablanca Release introduced two new applications into the Architecture: |
| 108 | The Policy SDC Distribution Application and the Apex PDP Engine. These are not |
| 109 | depicted in the picture above. |
| 110 | |
| 111 | The Policy SDC Service Distribution application connects to SDC Service |
| 112 | Distribution notification flow to automatically create policies. It is |
| 113 | integrated with the current API. For more details on this applications |
| 114 | documentation, please see :ref:`apex-doc` for more information. |
| 115 | |
| 116 | The Apex PDP Engine was ingested into the platform. This integration was as is |
| 117 | and did not formalize the Apex engine into the current policy API creation and |
| 118 | distribution flows. For more details on the Apex PDP Engine, please see |
| 119 | :ref:`policy-ssd-doc` for more information. |
| 120 | |
| 121 | Further integration of these components is planned for Dublin release. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 122 | |
| 123 | Policy Creation |
| 124 | ^^^^^^^^^^^^^^^ |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 125 | The Policy Creation component of the Policy subsystem enables creation of new |
| 126 | policies and modification of existing polices, both during the design phase |
| 127 | and during runtime. Policy Creation is targeted to be integrated to a unified |
| 128 | Service Design and Creation (SDC) environment. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 129 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 130 | A policy can be defined at a high level to create a condition, requirement, |
| 131 | constraint, decision or a need that must be provided, evaluated, maintained, |
| 132 | and/or enforced. A policy can also be defined at a lower or functional level, |
| 133 | such as a machine-readable rule or software condition/assertion which enables |
| 134 | actions to be taken based on a trigger or request, specific to particular |
| 135 | selected conditions in effect at that time. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 136 | |
| 137 | Some examples of types of policies are: |
| 138 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 139 | * VNF placement — rules governing where VNFs should be placed, including |
| 140 | affinity rules |
| 141 | * Data and feed management — what data to collect and when, retention periods, |
| 142 | and when to send alarms about issues |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 143 | * Access control — who (or what) can have access to which data |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 144 | * Trigger conditions and actions — what conditions are actionable, and what to |
| 145 | do under those conditions |
| 146 | * Interactions — how interactions between change management and |
| 147 | fault/performance management are handled (for example, should closed loops be |
| 148 | disabled during maintenance?) |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 149 | |
| 150 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 151 | Policy Distribution To PDPs |
| 152 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
Saryu Shah | 1a30768 | 2017-09-29 00:31:12 +0000 | [diff] [blame] | 153 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 154 | After a policy has been initially created or an existing policy has been |
| 155 | modified, the Policy Distribution Framework sends the policy from the |
| 156 | repository to its points of use, which include Policy Decision Points (PDPs) |
| 157 | and Policy enforcement points (DCAE, Controllers, etc), before the policy is |
| 158 | actually needed. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 159 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 160 | The decisions and actions taken by the policy are distributed. Policies are |
| 161 | distributed either in conjunction with installation packages (for example, |
| 162 | related to service instantiation) or independently, if unrelated to a |
| 163 | particular service. Some policies can be configured (e.g., configuring policy |
| 164 | parameters within microservices), while other polices are delivered to policy |
| 165 | engines such as XAMCL and Drools. With this methodology, policies will already |
| 166 | be available when needed by a component, minimizing real-time requests to a |
| 167 | central policy engine or PDP (Policy Decision Point). This improves scalability |
| 168 | and reduces latency. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 169 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 170 | Separate notifications or events communicate the link or URL for a policy to |
| 171 | the components that need it. Then, when a component needs the policy, it uses |
| 172 | the link to fetch it. Components in some cases might also publish events |
| 173 | indicating that they need new policies, eliciting a response with updated links |
| 174 | or URLs. Also, in some cases, policies can indicate to components that they |
| 175 | should subscribe to one or more policies, so that they receive automatic |
| 176 | updates to those policies as they become available. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 177 | |
| 178 | |
| 179 | Policy Decision and Enforcement |
| 180 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 181 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 182 | Run-time policy enforcement is performed by ONAP subsystems that are |
| 183 | policy-enabled or can respond to commands from a policy-enabled element such as |
| 184 | a PDP. For example, policy rules for data collection are enforced by the data |
| 185 | collection functionality of DCAE. Analytic policy rules, identification of |
| 186 | anomalous or abnormal conditions, and publication of events signaling detection |
| 187 | of such conditions are enforced by DCAE analytic applications. Policy rules for |
| 188 | associated remedial actions, or for further diagnostics, are enforced by the |
| 189 | correct component in a control loop such as the MSO, a Controller, or DCAE. |
| 190 | Policy engines such as XACML and Drools also enforce policies and can trigger |
| 191 | other components as a result (for example, causing a controller to take |
| 192 | specific actions specified by the policy). Additionally, some policies |
| 193 | (“Guard Policies”) may enforce checks against decided actions. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 194 | |
| 195 | |
| 196 | Policy Unification and Organization |
| 197 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 198 | Because the POLICY framework is expandable and multipurpose, it is likely to |
| 199 | contain many types of policies which require organization according to some |
| 200 | useful dimensions. Users can define attributes that specify the scope of |
| 201 | policies, and these attributes can be extended to the policy-enabled functions |
| 202 | and components. Useful policy organizing dimensions might include: |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 203 | |
| 204 | * Policy type or category (taxonomical) |
Saryu Shah | 1a30768 | 2017-09-29 00:31:12 +0000 | [diff] [blame] | 205 | * Policy life cycle |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 206 | * Policy ownership or administrative domain |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 207 | * Geographic area or location, |
| 208 | * Technology type |
| 209 | * Policy language and version |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 210 | * Security level or other security-related values, specifiers, or limiters |
| 211 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 212 | Attributes can be specified for each dimension. In addition to being defined |
| 213 | for individual policies themselves, these attributes can be used to define the |
| 214 | scope of these additional additional policy-related functions: |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 215 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 216 | * Policy events or requests/triggers |
| 217 | * Policy decision, enforcement, or other functions |
| 218 | * Virtual functions of any type |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 219 | |
Pamela Dragosh | 0cc4c8f | 2018-11-23 09:44:00 -0500 | [diff] [blame^] | 220 | Policy writers can define attributes so that policy events or requests |
| 221 | self-indicate their scope. The scope is then examined by a suitable function |
| 222 | and subsequently acted upon accordingly. Policy decisions and enforcement |
| 223 | functions can self-indicate their scope of decision-making, enforcement, or |
| 224 | other capabilities. Virtual functions can be automatically attached to the |
| 225 | appropriate POLICY Framework and distribution mechanisms. |
Saryu Shah | 1e2f68b | 2017-09-26 17:14:12 +0000 | [diff] [blame] | 226 | |
| 227 | |
Saryu Shah | 82b62ca | 2018-03-19 22:18:13 +0000 | [diff] [blame] | 228 | .. image:: PolicySummary.png |
| 229 | |
Saryu Shah | 3198d6d | 2017-11-07 21:40:27 +0000 | [diff] [blame] | 230 | End of Document |
| 231 | |