Project Name:

  • Proposed name for the project: Policy Framework
  • Proposed name for the repository: 
            • policy/api - Policy CRUD and PEP enforcement client code
            • policy/common - common shared modules
            • policy/pdp - Policy Decision Engines
            • policy/pap - Policy Administration (Backend)
            • policy/gui - Policy Administration GUI (Frontend)
            • policy/docker - Policy docker image

Project description:

The Policy subsystem of ONAP maintains, distributes, and operates on the set of rules that underlie ONAP’s control, orchestration, and management functions. Policy provides a centralized environment for the creation and management of easily-updatable conditional rules. It enables users to validate policies and rules, identify and resolve overlaps and conflicts, and derive additional policies where needed. Policies can support infrastructure, products and services, operation automation, and security. Users, who can be a variety of stakeholders such as network and service designers, operations engineers, and security experts, can easily create, change, and manage policy rules from the Policy Manager in the ONAP Portal.


  • Deliver points of interoperability within ONAP for VNF and network service On-boarding to capture policy/rule expressions, VNF vendor specific policies and network service policies.
    • The following areas are identified as places where Policy is currently supported and/or potentially needed in the ONAP Platform for R1 and beyond.

      Current Seed SupportONAP Project DependenciesR1




      • Continue support for SNIRO.
      • Work to be done for Policy Driven VNF Orchestration via Alex Vul.

      Resource Allocation


      Remediation Actions (eg Scaling)

      Yes – limited



      If SO and A&AI make API changes Policy will be impacted. Otherwise we anticipate being able to deliver this functionality.

      Compliance Checking (eg. Security)






      Control Loops






      Will need to work with teams to support control loops. Will be impacted on any API changes to SO, APP-C and A&AI. Will need to develop VF-C interface.

      Platform Level Policies


      Governance for Users/Customers


    • Deliver where/how Policies are expressed
      • Policy Domain Specific Language(s) (DSL) - work with the Modeling project to define how policy expressions are captured
      • Policy Design GUI - work with SDC project to integrate the Policy Design GUI during VNF/Service design for capturing Policy Expressions
    • Deliver requirements for Policy Conflict Detection and mitigation
    • Deliver requirements for capturing vendor-embedded policy (Stretch)
  • Deliver points of interoperability within ONAP in which captured policies are translated into enforceable actions/outcomes
    • Deliver architecture flow for identify how translation of DSL will work in the following ONAP scenarios:
      • Instantiation
      • Orchestration
      • Remediation
      • Controllers
      • Control Loop (Release 1)
        • DCAE Analytics, Collectors and Micro services: 
          • Design configuration policies and required models for the 3 Use Cases
        • CLAMP
          • Design operational policies for responding to Control Loop events for the 3 Use Cases
        • Controllers
          • Design, build and integrate required code to support 3 Use Cases for needed controller(s)
    • Identify how policy translation works
      • Design architecture for a common framework for the decision engines/languages used
      • The translation tools needing development
    • Identify the Enforcement points within ONAP to support the Use Cases
      • Common API design to support enforcement
    • Deliver points of interoperability for Day2Day Operations.
      • Identify architecture, flow and API's for how operations teams can update/deploy/un-deploy Policies
    • Deliver points of interoperability to support Adaptive Policy (Stretch)
      • Reverse planning, inference rules, machine learning
    • Deliver architecture and points of interoperability for Policy Distribution. The current seed code is limited in how policies are distributed, work needs to be done. (Stretch for R1)
      • Deliver architecture flow diagram on how Policy Decision Engines are deployed/un-deployed.
      • Define requirements as to which policies are supported in the various Decision Engines.
      • Deliver Swagger/DMaap API specification for PDP engines to communicate with PAP backend for policy distribution.

Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?
    • Architecture Diagram

    • What other ONAP projects does this project depend on?
      • Modeling - provide input for Policy Expression
      • VNF SDK
      • SNIRO
      • SDC
      • ONAP Operations Manager
      • ONAP Extensibility
      • Control Loop
      • CLAMP
      • DCAE
      • Orchestration
      • Controllers
      • Basically every component in ONAP should be policy-enabled
  • How does this align with external standards/specifications?
    • APIs/Interfaces
    • Information/data models
  • Are there dependencies with other open source projects?
    • XACML (
    • Drools (

Deliverables for R1

  • PAP + Console (ONAP Portal app)
    • Policy CRUD and Deployment API
    • GUI for viewing and managing policies/PDP's
  • Policy YAML SDK
    • For building Control Loop Operational Policies
  • Drools PDP
  • Nexus Repository
    • The repository for Drools Policy Rules and support code
  • Database (MariaDB)
    • The repository for XACML Policies, templates, PDP Grouping and PDP Policy Deployment.

Offered APIs

Container/VM nameAPI nameAPI purposeprotocol usedport number or range usedTCP/UDP
Console (Portal)
UI, and interface from ONAP Portalhttp8443TCP
manages the PDP Groups and Nodeshttp9091TCP
policy publishing and PIP configuration changes and queries against Policy Enginehttp8081TCP
Nexus Repository
Nexus OSS repository for Drools model & rule artifactshttp8081TCP
MariaDB http3306TCP

Consumed APIs

Container/VM nameContainer/VM/ offering the APIAPI nameAPI purposeprotocol usedport number or range usedTCP/UDP
Drools PDPDMaaP
publish/receive eventshttp/https3904/3905RCP
BRMS GatewayDMaaP
publish configuration change events to Drools PDPhttp/https3904/3905TCP
Console (Portal)ONAP Portal/ecompuiInterface to ONAP Portal from Portal apphttps8443?TCP
Drools PDPAAI Service/aai /aai/v8/*Rest Web Service for AAIhttps8443TCP
***Drools PDPMSO Core and BPMN / MSO VMVID api handlerRequest coming from portalhttp/https8080/8443TCP


  • Primary Contact Person
    • Pamela Dragosh - AT&T
  • Names, gerrit IDs, and company affiliations of the committers
    • Pamela Dragosh - AT&T
    • Jorge Hernandez-Herrero - AT&T
  • Names and affiliations of any other contributors
NameGerrit IDCompanyEmailTimeZone
Pamela DragoshpdragoshAT&Tpdragosh@research.att.comBedminster, NJ USA, EST, UTC-4
Jorge Hernandez-HerrerojhhAT&Tjh1730@att.comUSA, CST
Alex VulavulIntelalex.vul@intel.comPacific
Avinash S
Huaweiavinash.s@huawei.comBangalore, India, UTC +5:30
Nermin Mohamed
Bobby Mander
AT&Tbobby.mander@att.comMiddletown, NJ USA, EST, UTC -4
Ralph Straubs 
AT&Trs8887@att.comUSA, CST
Jim Hahn

ding yi, China, UTC +8

xinyuan wang, China, UTC +8
Zi, China, UTC +8

Sven van der Meer

vdmeer.svenNM-Lab, Ericssonsven.van.der.meer@ericsson.comDublin, Ireland, UTC (DST: UTC+1)
Liam Fallon
NM-Lab, Ericssonliam.fallon@ericsson.comDublin, Ireland, UTC (DST: UTC+1)

John Keeney

NM-Lab, Ericssonjohn.keeney@ericsson.comDublin, Ireland, UTC (DST: UTC+1)
Joel Halpern
Jimmy O'Meara
Ericssonjimmy.o.meara@ericsson.comDublin, Ireland, UTC (DST: UTC+1)
Yusuf Mirza, UAE, UTC +4

Alain Lee


Beijing, China, UTC +8
Yuan Liu
China Mobileliuyuanyjy@chinamobile.comBeijing, China, UTC +8

Ruan HE

Orangeruan.he@orange.comParis, France, UTC+01:00
John Clara, CA UTC-7
Jingbo Liu

Beijing, China, UTC +8
Zhangxiong Zhou, China, UTC +8
Xin Miao
Huaweixin.miao@huawei.comDallas, Texas, USA, CST

  • Project Roles (include RACI chart, if applicable)

Other Information:

  • Seed code existing in ONAP
    • policy/common
    • policy/drools-pdp
    • policy/drools-applications
    • policy/engine
    • policy/docker

Use the above information to create a key project facts section on your project page

Key Project Facts

Project Name:

  • JIRA project name: Policy Framework
  • JIRA project prefix: Policy

Repo name:
Lifecycle State: incubation
Primary Contact: Pamela Dragosh
Project Lead: Pamela Dragosh
mailing list tag [policy] 
Committers: AT&T AT&T AT&T

*Link to TSC approval: 

Link to approval of additional submitters: 

  • No labels


  1. Would it also be possible to provide an updated Policy Docker Strategy since it will impact the project  ONAP Operations Manager (5/10/17) in case of the TSC will approve it? Please also add this project candidate as part of your ONAP project dependency? thank you

  2. Pam, based on the broad scope of this project, is it intended to span over several releases?

    1. Yes, definitely. We need to support the Use Cases for R1, which I believe we can do so. But also continue to evolve the platform.

  3. With regards to repository partitioning.   The repository splits will provide a cleaner structure, but I have some concerns with repositories merges, in particular the proposed policy/pdp.   I assume the proposal is to merge both the Drools PDP repos (policy/drools-pdp, policy/drools-apps) and the "XACML" PDP component present in the policy/engine package.

    If that is the case, the root of my concern is that  I don't see much affinity between the two projects at this point in time.   More specifically: (a) XACML PDP and Drools PDP have a very different technological base, with little, if any, source code commonalities, in their current state, (b)  the nature of Drools PDP (and the use of PDP term here may be debatable) is much more generic in nature, not constrained by formal standard, and potentially could be used for other purposes, not yet anticipated.  I'm of the opinion that we should keep the current drools pdp repos separated from XACML PDP one, and revisit re-unification at a later point in time as we learn more.

    1. I would like to keep the drools-applications one (or a renamed one for the same purpose) unmerged with "drools-pdp".   Some organizations are interested in the infrastructure piece with their own applications, so no need for them to inherit all the packaging if it was all put together in a single unit.

    • Basically every component in ONAP should be policy-enabled

    Why should policy framework project depend on these policy-enabled components? I think the relationship should be inverse. Policy framework will be depended on by each enabled-component, while it doesn't know that. 

    1. I agree - the Policy component should be central to all the components in ONAP. All of them interfacing with Policy.

  4. Which kind of DSL will be used, like based on Drools? What the translation mean, when and where it will be used? I am appreciated that If you can provide a simple example to help understand.

    1. We'd like to get that nailed down in this project, and drive what the DSL(s) should be. We are a little dependent on a couple of things: Modeling project. Which TOSCA will they recommend/use? We have done some work internally with TOSCA in which we derive policy nodes to help specify configuration and control loop policies. But that was for a specific type of TOSCA for DCAE templates.

      AT&T is pushing into the seed code another DSL for Control Loop called Policy YAML. We will provide documentation on how it works.

      I really believe that we should be flexible as to what DSL(s) are going to be available for capturing Policy. For example, we may want to support SUPA. An extensible framework for building translators is going to be needed. I'm hoping this project can define that architecture.

      BTW, Currently the platform supports both Drools and XACML policies. But we'd like it to be flexible enough such that if there is another Policy Engine that supports additional functionality we can pull it in easily. Initially we thought maybe Congress was a candidate for enforcing Policy, but we never got to that stage.

      1. Thanks. I think you mean we try to make both DSL and policy engine more flexible. So, there is no specific DSL and policy engine. The translated action is between captured policy expressed by DSL and policy engine. So, there are many translation jobs need to be done, if we have different DSL and engine. Please correct me, if I am wrong. 

  5. I also would like to consider the following JIRA items as part of this proposal if these are not solve earlier:

    POLICY-12 - Getting issue details... STATUS

    POLICY-5 - Getting issue details... STATUS if the following epic is approved COMMON-10 - Deploy automatically an ONAP high availability environment Open

    POLICY-8 - Getting issue details... STATUS

    POLICY-11 - Getting issue details... STATUS

    POLICY-9 - Getting issue details... STATUS

  6. If folks could update their time zones and email addresses, that would be helpful towards getting an initial meeting setup. This initial meeting would be to address any feedback/issues the TSC has with the proposal (per Mazin's email last week). Once we collect that info I will setup a doodle poll and zoom meeting for the team to meet. Thanks!

    1. Please use the following doodle poll to vote for a day/time next week for our initial meeting. Please note that we have a 15 hour time span between all the folks listed as contributors. To accommodate everyone within reasonable waking hours for all, I am suggesting times 8am EST, 9am EST for days Tues/Wed/Thurs. If you think another option is better, then please post comment and I will try to adjust.


      1. Thank you folks for participating in the Doodle poll. The result is 8am EST (UTC -4) on Wednesdays. I will work with linux foundation to setup the recurring meeting, zoom details, etc.

  7. I have a number of clarification questions, but the simplest is, why is "Classification of Policies" important? What is the use case where such a taxonomy is needed? If there is one, then I would think that things like the paradigm used (e.g., imperative vs. declarative vs. intent vs. utility function) is much more valuable, as that can be used to identify the type of compiler and/or engine required. In addition, a number of the categories in this classification seem suspect at best (e.g., what is a "control loop" policy and why could it ONLY be used in a control loop; don't all North-South policies exert governance). The 15 (warning) bullets under "Classification of Policies" seem to be identifying the purpose or use case that a policy is satisfying, as opposed to be a generic taxonomy. Please clarify

  8. Policy subsystem in the ONAP more likely works as a common service, just wonder why the policy  subsystem in the architecture diagram looks differently. 

    1. Interesting observation Bit Wei, and I agree with you. Policy is central to driving this platform, and underused in my heavily biased opinion.

  9. Team, Hi, looking for conflict resolution APIs, examples, JIRAs - if you know of anything - thanks /michael

    raised a minor C* release tracking JIRA  POLICY-659 - Getting issue details... STATUS