...
| draw.io Diagram | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The PolicyDevelopment component implements the functionality for development of policies, policy templates, and configurations for policies. PolicyAdministration is responsible for the deployment life cycle of policies as well as interworking with the mechanisms required to orchestrate the nodes and containers on which policies run. PolicyAdministration is also responsible for the administration of policies at run time; ensuring that policies are available to users, that policies are executing correctly, and that the state and status of policies is monitored. PolicyExecution is the set of PDPs running in the ONAP system and is responsible for making policy decisions and for managing the administrative state of the PDPs as directed by PolicyAdministration.
...
For example, assume we have policies for the SON (Self Organizing Network) and BBS (Boradband Service) domains. For SON, we have XACML, Drools, and APEX policies, and for BBS we have XACML and Drools policies. The table below shows the resultingPDPGroup, PDPSubGroup, and PDP allocations:
| PDP Group | PDP Subgroup | Kubernetes Deployment | Kubernetes Deployment Strategy | PDPs in Pods |
|---|---|---|---|---|
| SON | SON-XACML | SON-XACML-Dep | Always 2, be geo redundant | 2 PDP-X |
SON-Drools | SON-Drools-Dep | At Least 4, scale up on 70% load, scale down on 40% load, be geo-redundant | >= 4 PDP-D | |
| SON-APEX | SON-APEX-Dep | At Least 3, scale up on 70% load, scale down on 40% load, be geo-redundant | >= 3 PDP-A | |
| BBS | BBS-XACML | BBS-XACML-Dep | Always 2 | 2 PDP-X |
| BBS-Drools | BBS-Drools-Dep | At Least 2, scale up on 80% load, scale down on 50% load | >=2 PDP-D |
2.1 Policy Framework Object Model
Policy Framework Object Model
| draw.io Diagram | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Creation of policy templates is not covered yet.
2.
...
2 Policy Design Architecture
This section describes the architecture of the model driven system used to develop policy templates, to derive concrete policies from those policy templates, and to parameterize concrete policies as executable policies. The output of Policy Design is deployment-ready artifacts in Maven and Policy metadata in the Policy Framework database.
Policies that are expressed via natural language or a model require some development work ahead of time for them to be translated into concrete runtime policies. Some Policy Domains will be setup and available in the platform during startup such as Control Loop Operational Policy Models, OOF placement Models, DCAE microservice models. Policy Model/Template/Rule Development is done by an experienced developer.
2.
...
2.1 Policy Template Design
Policy Template Design is the task of creating policy templates that capture the generic and vendor independent aspects of a policy for a particular domain use case. The policy template also specifies and publishes the model information, rules, and tasks that it requires to generate concrete policies.
...
Consider a policy template created for managing faults on vCPE equipment in a vendor independent way. The policy template captures the generic logic required to manage the faults and specifies the vendor specific information that must be supplied to te template for specific vendor vCPE VFs. The actual concrete vCPE policy that is used for managing particular vCPE equipment is generated using the policy template together with the specific modeled information, rules and tasks for that vendor model of vCPE.
2.
...
2.1.1 Programming Policy Templates
The most straightforward way to create a policy template is to program it. Programming a policy template might simply mean creating and editing text files and manually generating the Maven artifact for the policy template.
A more formal approach is preferred. Programmers use a specific Eclipse project type for developing each type of policy template, a Policy Template SDK. The project is under source control in git. This Eclipse project is structured correctly for creating policies for a specific type of PDP. It includes the correct POM files for generating the policy template as a Maven artifact. It has editors and perspectives that aid the programmer in their work.
2.
...
2.1.2 Generating Policy Templates
It is also possible to generate policy templates using MDD (Model Driven Development) techniques. Policies are expressed using a DSL (Domain Specific Language) or a policy specification environment for a particular application domain. For example, policies for specifying SLAs could be expressed in a SLA DSL and policies for managing SON features could be generated from a visual SON management tool. The ONAP Policy framework provides an API that allows tool chains to create policy templates.
2.
...
2.2 Policy Design
Policy Design creates a concrete policy from a policy template. Policy Design is a Design Time framework for ingestion of models for policies and any optional support code, rules, tasks, or flow specifications. Policy Design can consume policy models organically and not require any development work.
...
The following subsections outline the mechanisms for policy creation and modification supported by the ONAP Policy Framework.
2.
...
2.2.1 Policy Design in the ONAP Policy Framework
Policy Design in the ONAP framework follows the general sequence shown in the sequence diagram below. An API_USER is any component that wants to specialize a policy template into a concrete policy. The ONAP Policy Framework supplies a REST interface that exposes the API and also provides a command line tool and general purpose client that wraps the API.
...
Once the API_User is happy that the policy is completely and correctly specified, it requests PolicyDesign to generate the policy. PolicyDesign generates the policy, stores the generated policy artifact in Nexus and stores its metadata of the policy in the database.
2.
...
2.2.2 Model Driven VF (Virtual Function) Policy Design via VNF SDK Packaging
VF vendors express policies such as SLA, Licenses, hardware placement, run-time metric suggestions, etc. These details are captured within the VNF SDK and uploaded into the SDC Catalog. The SDC Distribution APIs are used to interact with SDC. For example, SLA and placement policies may be captured via TOSCA specification. License policies can be captured via TOSCA or an XACML specification. Run-time metric vendor recommendations can be captured via VES Standard specification.
...
In Step 9 above, the PolicyDesignSDCHandler must send back/publish status events to SDC such as DOWNLOAD_OK, DOWNLOAD_ERROR, DEPOLY_OK, DEPOLY_ERROR, NOTIFIED.
2.
...
2.2.3 Model Driven Policy Design via another ONAP Component's GUI
The SDC GUI supports several types of policies that can be captured during design time. DCAE micro service configuration policies can be onboarded via the DCAE-DS (DCAE Design Studio).
...
The GUI implementation in another ONAP component such as SDC or the DCAE-DS uses the API_User API to create and edit ONAP policies. Note that this puts an impact on those components.
2.
...
2.2.4 Scripted Model Driven Policy Design
Service policies such as optimization and placement policies can be captured via TOSCA models during design time. These models can be used to generate concrete policies.
...
One straightforward way of generating concrete policies from Policy metadata in TOSCA, YAML, or other such modelling languages combined with directives specified in a script file is to use a command line utility. The command line utility is an API_User. It reads the policy model from the model file, and/or the directives from a script file and uses the information from those files to drive the concrete policy generation process.
2.
...
2.3 Policy Design Process
All policies must be certified as being fit for deployment prior to run time deployment. In the case of design-time via the SDC application, it is assumed the lifecycle being implemented by SDC will suffice for any policies that are declared within the ONAP Service CSAR. For Policy Templates and raw policies, the lifecycle associated with software development process will suffice. Since models, templates and raw policies will be deployed to a Nexus repository, software development best practices can utilized and configured for various environments (eg. development, testing, production) as desired.
2.
...
3 Policy Runtime Architecture
The Policy Framework Platform components are themselves designed as micro services that are easy to configure and deploy via Docker images and K8S both supporting resiliency and scalability if required. PAPs and PDPs are deployed by the underlying ONAP management infrastructure and are designed to comply with the ONAP interfaces for deploying containers.
...
In the ONAP Policy Framework, the interfaces to the PDP are designed to be as streamlined as possible. Because the PDP is the main unit of scalability in the Policy Framework, the PF is designed to allow PDPs in a PDP group to arbitrarily appear and disappear and for policy consistency across all PDPs in a PDP group to be easily maintained. Therefore, PDPs have just two interfaces; an interface that users can use to execute policies and interface to the PAP for administration, life cycle management and monitoring. The PAP is responsible for controlling the state across the PDPs in a PDP group. The PAP interacts with Nexus and transfers policy sets to PDPs, and may cache the policy sets for PDP groups. If PDPs individually interact directly with Nexus, then a complex three-way consistency between the PDPs, PAP, and Nexus must be maintained. it is much more difficult to maintain consistency across all the PDPs in the PDP group as PDPs spontaneously appear and disappear.
2.
...
3.1 Policy Framework Services
The ONAP Policy Framework follows the architectural approach for micro services recommended by the ONAP Architecture Subcommittee.
...
There is one and only one PAP service, which handles policy deployment, administration, and monitoring for all policies in all PDPs and PDP groups in the system. There are multiple PDP services, one PDP service for each domain for which there are policies.
2.
...
3.2 The Policy Framework Information Structure
The following diagram captures the relationship between Policy Framework concepts at run time.
...
The diagram above outlines the structure of the run time topology information in the Policy Framework database. Note that the PDP_GROUP_STATE and PDP_STATE fields hold state information for life cycle management of PDP groups and PDPs. The POLICY_MAVEN_ARTIFACT field holds a reference that a PAP can use to fetch the policy artifact from Maven.
2.
...
3.3 Startup, Shutdown and Restart
This section describes the interactions between Policy Framework components themselves and with other ONAP components at startup, shutdown and restart.
2.
...
3.3.1 PAP Startup and Shutdown
The sequence diagram below shows the actions of the PAP at startup.
...
PAP shutdown is trivial. On receipt or a shutdown request, the PAP completes or aborts any ongoing operations and shuts down gracefully.
2.
...
3.3.2 PDP Startup and Shutdown
The sequence diagram below shows the actions of the PDP at startup.
...
On receipt or a shutdown request, the PDP completes or aborts any ongoing policy executions and shuts down gracefully.
2.
...
3.4 Policy Execution
Policy execution is the execution of a policy in a PDP. Policy enforcement occurs in the component that receives a policy decision.
...
| Lifecycle Mode | Behaviour |
|---|---|
| PASSIVE MODE | Policy execution is always rejected irrespective of PDP type. |
| ACTIVE MODE | Policy execution is executed in the live environment by the PDP. |
| SAFE MODE | Policy execution proceeds, but changes to domain state or context are not carried out. The PDP returns an indication that it is running in SAFE mode together with the action it would have performed if it was operating in ACTIVE mode. The PDP type and the policy templates it is running must support SAFE mode operation. |
| TEST MODE | Policy execution proceeds and changes to domain and state are carried out in a test or sandbox environment. The PDP returns an indication it is running in TEST mode together with the action it has performed on the test environment. The PDP type and the policy templates it is running must support TEST mode operation. |
2.
...
3.5 Policy Lifecycle Management
Policy lifecycle management manages the deployment and life cycle of policies in PDP groups at run time. Policy sets can be deploy at run time without restarting PDPs or stopping policy execution. PDPs preserve state for minor/patch version upgrades and rollbacks.
2.
...
3.5.1 Download Policy Set to PDP
The sequence diagram below shows how a Policy Set is loaded into a PDP.
...
Once the Policy Set is loaded, the PAP orders the PDP to enter the life cycle mode that has been specified for it (ACTIVE/SAFE/TEST). The PDP beings to execute policies in the specified mode (see section 2.2.4).
2.
...
3.5.2 Policy Rollout
A policy set steps through a number of life cycle modes when it is rolled out.
...
Finally, when the user is satisfied with policy set execution and when quality criteria have been reached, the PDP group is set into ACTIVE state and the policy set executes on the target environment. The results of target operation are reported. The PDP group can be reverted to SAFE, TEST, or even PASSIVE mode at any time if problems arise.
2.
...
3.5.3 Policy Upgrade and Rollback
There are a number of approaches for managing policy upgrade and rollback.
...
A third approach is to have two policy sets running in each PDP, an active set and a standby set. However such an approach would increase the complexity of implementation in PDPs significantly.
2.
...
3.6 Policy Monitoring
PDPs provide a periodic report of their status to the PAP. All PDPs report using a standard reporting format that is extended to provide information for specific PDP types. PDPs provide at least the information below:
| Field | Description |
|---|---|
| State | Lifecycle State (PASSIVE/TEST/SAFE/ACTIVE) |
| Timestamp | Time the report record was generated |
| InvocationCount | The number of execution invocations the PDP has processed since the last report |
| LastInvocationTime | The time taken to process the last execution invocation |
| AverageInvocationTime | The average time taken to process an invocation since the last report |
| StartTime | The start time of the PDP |
| UpTime | The length of time the PDP has been executing |
2.
...
3.7 PEP Registration and Enforcement Guidelines
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.
...