Overview

The new Policy Framework architecture developed and released in Dublin did not have time to build support for PEP (Policy Enforcement Point) Applications to register for receive Policy Update Notifications when a new or updated Policy is deployed from the PAP (Policy Administration Point) to any of the PDP engines. For some PDP engines, registration update notifications is irrelevant since they are the enforcement of their policy types. Notably, the Drools and Apex PDP engines enforce policies and are automatically updated when a new or updated policy is pushed to it. However, the XACML PDP engine hosts the Policy Decision API for many clients in ONAP to retrieve at runtime the a Policy decision for enforcement.

Some ONAP clients, such as the DCAE Policy Handler, require a more immediate notification in order to retrieve the latest policy for enforcement during runtime. That is, changing thresholds, etc. for DCAE uS should happen fairly quickly as those components are constantly enforcing policy while retrieving events/alarms/etc. Other ONAP clients, such as OOF, do not require the immediate notification as they only call policy in response to an event initiated on their end.

Requiring clients to continuously poll the Decision API for the latest policy(s) is a sub-optimal solution especially when policy changes do not occur very frequently. But when a policy change does occur, if the desired goal is for a more timely notification to occur for performance considerations then building a simple infrastructure for doing so is what this functional requirement is for.

Problem Statement

The previous implementation of policy update notifications in the legacy policy components, utilized a websocket between Policy and DCAE. This has been determined as less than ideal implementation and the preference would be to utilize ONAP components such as Dmaap and a simple RESTful PEP Registration API to better manage the communication. In addition, using websockets in a geographically distributed ONAP would not scale very well.

Since polling of Dmaap is necessary for its use regardless, the goal is to create a simple notification via Dmaap for policy updates to minimize overhead on the systems. The XACML PDP engine will be scaled accordingly to support Decision calls being made in response to client PEPs getting the update notifications.

Proposed notification structure - R6 Dmaap Notification of Policy Update

Business Requirements

1) Policy Framework will add support for a PEP Registration RESTful API for PEP clients to optionally use for notification of updates for specific Policy Types being deployed to PDP Engines.2) Policy Framework PAP component will be enhanced to support Dmaap notifications when a new policy or an updated Policy (eg different version) is deployed for any registered PEP clients.

3) (Stretch) - ONAP PEP Clients (notably the DCAE uS) should be updated to utilize the PEP Registration RESTful API to register for notifications

4) (Stretch) - ONAP PEP Clients should be enhanced to query the XACML PDP Decision API when an updated notification is receivedto a well-known topic for the following conditions:

• A brand new policy is deployed
• An updated policy is deployed (eg new version)
• A policy is undeployed

2) ONAP PEP Clients should be enhanced to listen to the well-known Dmaap topic for Policy Update notifications, scan the payload for any desired Policy Type(s), and then make subsequent Decision API REST calls to get the latest Policy Decision.

Participating Companies

AT&T

Goals

Restore and enhance the Policy update notification functionality in the new Policy Framework Architecture.

Contributions

R5 El Alto proposal for policy flows between the new PDP and DCAE component

R6 PEP Registration API and Dmaap Notification of Policy Update

Impacts

Project Commitments