You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Status: DRAFT

Policy Framework:

1. High Level Component Definition and Architectural Relationships 

2. API Definitions

2a. Exposed APIs

Interface NameDefinitionCapabilitiesVersionStatusPayload Model(s)
POE-1Policy Type DesignAllows applications to create, update, delete, and query PolicyType entities so that they become available for use in ONAP by applications such as CLAMP.1.0.0production

tosca.policies.root

TOSCA

POE-2Policy DesignAllows applications (such as CLAMP and Integration) to create, update, delete, and query Policy entities.1.0.0production

tosca.policies.root

TOSCA

POE-3Policy AdministrationSupport CRUD of PDP groups and subgroups and to support the deployment and life cycles of PolicyImpl entities (TOSCA Policy and PolicyTypeImpl entities) on PDP sub groups and PDPs.1.0.0productionEmbedded
POE-4Data IngressListen on a DMaaP topic. 
production

Messages of interest are described in the policy logic

DMaaP

POE-5Decision QueryPolicy decisions are required by ONAP components to support the policy-driven ONAP architecture. Policy Decisions are implemented using the XACML PDP. The calling application must provide attributes in order for the XACML PDP to return a correct decision.NAproductionDefined by policy

2b. Consumed APIs

API KeyAPI NameDescription
AAI-XTopologyEnrich ingress data with topology information
SO-XService OrchestratorTrigger orchestration actions (policy driven)
Controller-XController APItrigger control actions (policy driven)
TT-XTrouble Ticketingtrigger open loop ticketing system
OtherOther ActionsTrigger any interface defined in a policy


3. Component Description

Please see the TOSCA Policy Primer page for an introduction to TOSCA policy concepts. See the Policy Design and API flow page for a description of the component interactions.

TOSCA defines a PolicyType, the definition of a type of policy that can be applied to a service. It also defines a Policy, the definition of an instance of a PolicyType. In the Policy Framework, we must handle and manage these TOSCA definitions and tie them to real implementations of policies that can run on PDPs.

Each TOSCA PolicyType must have a corresponding PolicyTypeImpl in the Policy Framework. The TOSCA PolicyType definition can be used to create a TOSCA Policydefinition, either directly by the Policy Framework, by CLAMP, or by some other system. Once the Policy artifact exists, it can be used together with the PolicyTypeImpl artifact to create a PolicyImpl artifact. A PolicyImpl artifact is an executable policy implementation that can run on a PDP.

The TOSCA PolicyType artifact defines the external characteristics of the policy; defining its properties, the types of entities it acts on, and its triggers.  A PolicyTypeImpl artifact is an XACML, Drools, or APEX implementation of that policy definition. PolicyType and PolicyTypeImpl artifacts may be preloaded, may be loaded manually, or may be created using the Lifecycle API. Alternatively, PolicyType definitions may be loaded over the Lifecycle API for preloaded PolicyTypeImpl artifacts. A TOSCA PolicyType artifact can be used by clients (such as CLAMP or CLI tools) to create, parse, serialize, and/or deserialize an actual Policy.

The TOSCA Policy artifact is used internally by the Policy Framework, or is input by CLAMP or other systems. This artifact specifies the values of the properties for the policy and specifies the specific entities the policy acts on. Policy Design uses the TOSCA Policy artifact and the PolicyTypeImpl artifact to create an executable PolicyImpl artifact. 

4. Known System Limitations

https://docs.onap.org/en/dublin/submodules/policy/parent.git/docs/release-notes.html

5. System Deployment Architecture

https://docs.onap.org/en/dublin/submodules/policy/parent.git/docs/installation/docker.html#

6. New Release Capabilities

Support for Control Loop
CCVPN support
5G OOF PCI suport
Scale out support
Security hardening
ONAP maturity Performance (S3P)
ONAP maturity Securtiy (S3P)
CLC Coordination directives
Code refactoring

7. References

  1. Casablanca architecture description https://onap.readthedocs.io/en/casablanca/submodules/policy/engine.git/docs/platform/architecture.html
  2. Policy Design and API Flow for Model Driven Control Loop

  • No labels