Page Status: Copied from R6 - Mar, 22, 2020
Component Status: Pending PTL Updates and ArchCom Review
Last Reviewed:
Certified by:
1. High Level Component Definition and Architectural Relationships
| Drawio | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
2. API Definitions
2a. Exposed APIs
| Interface Name | Definition | Capabilities | Version | Status | Payload Model(s) | API Spec (Swagger) |
|---|---|---|---|---|---|---|
| POE-1 | Policy Type Design | Allows 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.0 | production | tosca.policies.root | |
| POE-2 | Policy Design | Allows applications (such as CLAMP and Integration) to create, update, delete, and query Policy entities. | 1.0.0 | production | tosca.policies.root | |
| POE-3 | Policy Administration | Support 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.0 | production | Embedded | |
| POE-4 | Data Ingress | Listen on a DMaaP topic. | production | Messages of interest are described in the policy logic DMaaP | ||
| POE-5 | Decision Query | Policy decisions are required by ONAP components to support the policy-driven ONAP architecture. Policy Decisions are implemented using the XACML and Apex PDPs. The calling application (which may be another policy – e.g. invocation of a guard policy from PDP-D) must provide attributes in order for the PDP to return a correct decision. | NA | production | Defined by policy |
2b. Consumed APIs
| Interface Name | Consumed by | Description | API Spec (Swagger) |
|---|---|---|---|
| AAF | Policy Framework | Authentication and authorization | |
| DMaaP | Policy Framework Policies | Policy framework uses DMaaP for SDC subscriptions and internal communication. Policies use DMaaP as a transport for contextual information from various sources | |
| SDC | Policy Framework | Notification of CSAR; Retrieval of CSAR | |
| AAI | Policies | Enrich ingress data with topology information | |
| SO | Policies | Trigger orchestration actions (policy driven) | |
| Policies | Trigger control actions (policy driven) | ||
| Other | Policies | Trigger any interface defined in a policy, for example, trouble ticketing |
3. Component Description
The ONAP Policy Framework is a comprehensive policy design, deployment, and execution environment. The Policy Framework is the decision making component in an ONAP system. It allows you to specify, deploy, and execute the governance of the features and functions in your ONAP system, be they closed loop, orchestration, or more traditional open loop use case implementations. The Policy Framework is the component that is the source of truth for all policy decisions
...
Policy Enforcement is in general not handled by the Policy Framework. Enforcement is handled by either the originator of a decision query (PDP-D does enforce guard policy decisions made in the XACML PDP), or by a reaction to a policy output (trigger).
4. Known System Limitations
https://docs.onap.org/projects/onap-policy-parent/en/latest/release-notes.html
5. System Deployment Architecture
https://docs.onap.org/projects/onap-policy-parent/en/latest/installation/installation.html
6. New Release Capabilities
Support for Control Loop
CCVPN support
5G OOF PCI support
E2E Network Slicing support
Scale out support
Security hardening
ONAP maturity Performance (S3P)
ONAP maturity Securtiy (S3P)
CLC Coordination directives
Code refactoring
7. References
- Frankfurt architecture description https://docs.onap.org/projects/onap-policy-parent/en/latest/architecture/architecture.html
Policy Framework API's - https://docs.onap.org/projects/onap-policy-parent/en/latest/offeredapis.html