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 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, 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 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 PAP component will be enhanced to support Dmaap notifications to 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 Dmaap Notification of Policy Update

Impacts

ProjectImpactNotes
PolicyLow

Notifications will require small effort to model the payload and work to publish to Dmaap updates.

DCAEMediumNeed DCAE-PolicyHandler updated to support new DMaaP interface to resync and update policy for MS in consul  

Project Commitments

ProjectPTLCommitmentNotes
DCAE

COMMITTED


Policy

COMMITTED


  • No labels