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:
- This project will be dedicated to supporting the Control Loop implementation for the 3 use cases identified in Release 1.
- In addition, this project will be dedicated to determine how policy is captured, translated, deployed and updated when designing and on-boarding VNF's and network services in anticipation of future work.
- The project will also continue to advance the evolving architecture of the Policy Platform Framework to support more robust PDP Distribution Deployment, Policy Design GUI integration with SDC and integration with the Modeling project for future model support.
Scope:
- 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.
- Classification of Policies
- Placement
- Resource allocation
- Remediation Actions (eg. Scaling)
- Compliance Checking (eg. Security)
- SLA
- Health
- Control Loops
- Support 3 Use Cases for Control Loop Policies (Release 1)
- Residential Broadband Autohealing: Reboot/Restart, Rebuild (Future: Migrate/Evacuate)
- vFW/vDNS: ModifyConfig, Scale up
- VoLTE: Auto Scaling (Scale In/Out), Auto Healing (Reboot, Restart)
- Support 3 Use Cases for Control Loop Policies (Release 1)
- Platform Level Policies
- Governance
- 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)
- Classification of Policies
- Deliver points of interoperability within ONAP in which captured policies are translated into enforceable actions/outcomes
- Identify how translation of DSL will work
- 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)
- DCAE Analytics, Collectors and Micro services:
- Identify how policy translation works
- 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
- How Policy Decision Engines are deployed/un-deployed
- What policies are supported in the various Decision Engines
- Deliver API and flow for updating policy with the decision engines and the enforcement points
- Identify how translation of DSL will work
Architecture Alignment:
- How does this project fit into the rest of the ONAP Architecture?
- Please Include architecture diagram if possible
- 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 (github.com/att/xacml)
- Drools (drools.org)
Resources:
- 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
- Alex Vul - Intel
- Avinash S - Huawei
- Nermin Mohamed - Huawei
- Bobby Mander - AT&T
- Ralph Straubs - AT&T
- Jim Hahn - AT&T
- ding yi-ZTE
- xinyuan wang-ZTE
- Sven van der Meer [VMware], NM-Lab, Ericsson
- Liam Fallon, NM-Lab, Ericsson
- John Keeney (Ericsson EST), NM-Lab, Ericsson
- Joel Halpern, Ericsson
- Jimmy O'Meara, Ericsson
- Yusuf Mirza - IBM (ymirza@ae.ibm.com)
- Alain Lee - Huawei (ln.linan@huawei.com)
- Yuan Liu - China Mobile (liuyuanyjy@chinamobile.com)
- 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:
pdragosh@research.att.com AT&T
jh1730@att.com AT&T
rs8887@att.com AT&T
jh7358@att.com AT&T
*Link to TSC approval:
Link to approval of additional submitters: