Policy R6 Frankfurt Architecture Review

Brief Project Overview (brief as it should be known)

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.

New component capabilities for Frankfurt, i.e. the functional enhancements.

Frankfurt release targets the completion of the work started in Dublin to re-build the Policy Framework infrastructure. The new capabilities were to complete missing functionality that was previously in the legacy components, or was targeted to be part of the platform and was not able to be finished in Dublin:

• REQ-25: Policy Update NotificationsDone - When policies are deployed/undeployed (eg new version or removal), then some ONAP components need more immediate notification. Notably, DCAE microservices need to respond quickly to policy changes.

• REQ-9: Self Serve Control LoopsDone - Enhances the validation of TOSCA Policy Types and provides tools to Policy Designers.

• POLICY-1845: This epic covers the work to integrate native PDP policy supportClosed - Some support for this in the legacy components, this work greatly enhances the ability to load PDP native policies that either execute alone or in conjunction with TOSCA Policy Types. Adds in Apex Native Policy Types in addition to XACML, Drools.

• REQ-162: This epic covers the work to upgrade ONAP components from legacy Policy API to new Lifecycle APIDone - Finishing the transition to new Policy Types with the OOF team that began in Dublin. This release we are working with the SDNC team to complete their transition in Frankfurt.

• REQ-21: TOSCA Compliant PoliciesDone - Finishing the work to fully move ALL the Control Loop Policy Types into TOSCA compliance with CLAMP team.

• POLICY-2087: This epic captures the work to integrate CDS as an actor in the Policy FrameworkClosed - Started in Dublin as dark code, finishing the support for this new actor to be fully available for Control Loop Operational Policies.

New or modified interfaces

• POLICY-2025: This epic covers the work to ensure all the PDP's report statistics and that both the statistics and health checks are consolidated by the PAP.Closed - Per Integration team, one single health check requested that gives status for the whole of Policy Framework components. Added some enhancement for collection of statistics on how well the Policy components are executing.

• POLICY-2028: This epic covers the backlog for api functionality.Closed - Finished work such as added "application/yaml" as Content-Type.

• POLICY-2026: This epic covers the work to support backlog for PAP and PDP communication.Closed - Clarified PAP ↔ communication of Policy Types, Health Status, PDP Group Details, Passive vs Active modes.

If they are modified, are the backwards compatible?

Yes - all API's are backwards compatible. No real changes, only enhancements (eg adding new Content-Type) and added some convenience API's.

Interface naming (point to an example)

The Policy R6 Frankfurt Independent Versioning And Release Process Plan - has a list of our incoming and outgoing dependencies.

Consumed API from other projects

Published API - These projects use the policy libraries to build their code

Reference to the interfaces.

All API's are Documented: https://docs.onap.org/en/latest/submodules/policy/parent.git/docs/api/api.html

Legacy API: Policy API

What are the system limits?

4Gb Memory - for most of the components.

Involved use cases, architectural capabilities or functional requirements.

vFW, Scale Out, vCPE, 5G OOF

Listing of new or impacted models used by the project (for information only).

POLICY-2118: This epic covers the work to design and support TOSCA Compliant Policy Types for the operational and guard policy models.Closed - continuation of work started in Dublin

• Will be deprecating the legacy Control Loop Operational and Guard policies after this release.

POLICY-1930: This epic covers the work to re-design the code for control loops.Closed - to further support better performance during runtime of Control Loops and ability for ONAP Policy Developers to easily create and integrate their own actors into runtime Control Loops.