...
- 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.
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.
The following areas are identified as places where Policy is currently supported and/or potentially needed in the ONAP Platform for R1 and beyond.
Classification of PoliciesCurrent Seed Support ONAP Project Dependencies R1 Placement
Yes
SNIRO
- Continue support for SNIRO.
- Work to be done for Policy Driven VNF Orchestration via Alex Vul.
Resource Allocation
No
- Placement Resource allocation
- Residential Broadband Autohealing: Reboot/Restart, Rebuild (Future: Migrate/Evacuate)
- vFW/vDNS: ModifyConfig, Scale up VoLTE: Auto Scaling (Scale In/Out), Auto Healing (Reboot, Restart)
.Remediation Actions (eg
Support 3 Use Cases for Control Loop Policies (Release 1)Scaling)
Yes – limited
SO
A&AI
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)
No
SLA
No
Health
No
Control Loops
Yes
APP-C
SO
VF-C
A&AI
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
No
Governance
Customersfor Users/Customers
No
- 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)
- Identify 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)
- DCAE Analytics, Collectors and Micro services:
- Identify how policy translation works
- A 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
- How Policy Decision Engines are deployed/un-deployed.
- What Define requirements as to which policies are supported in the various Decision Engines.
- Deliver API and flow for updating policy with the decision engines and the enforcement pointsSwagger/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?Please Include architecture diagram if possible
- 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
- What other ONAP projects does this project depend on?
- 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)
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
- XACML PDP
- 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 name | API name | API purpose | protocol used | port number or range used | TCP/UDP |
---|---|---|---|---|---|
Console (Portal) | UI, and interface from ONAP Portal | http | 8443 | TCP | |
PAP | manages the PDP Groups and Nodes | http | 9091 | TCP | |
PDP | policy publishing and PIP configuration changes and queries against Policy Engine | http | 8081 | TCP | |
Nexus Repository | Nexus OSS repository for Drools model & rule artifacts | http | 8081 | TCP | |
Database | MariaDB | http | 3306 | TCP |
Consumed APIs
Container/VM name | Container/VM/ offering the API | API name | API purpose | protocol used | port number or range used | TCP/UDP |
---|---|---|---|---|---|---|
Drools PDP | DMaaP | publish/receive events | http/https | 3904/3905 | RCP | |
BRMS Gateway | DMaaP | publish configuration change events to Drools PDP | http/https | 3904/3905 | TCP | |
Console (Portal) | ONAP Portal | /ecompui | Interface to ONAP Portal from Portal app | https | 8443? | TCP |
Drools PDP | AAI Service/aai | /aai/v8/* | Rest Web Service for AAI | https | 8443 | TCP |
***Drools PDP | MSO Core and BPMN / MSO VM | VID api handler | Request coming from portal | http/https | 8080/8443 | TCP |
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, NM-Lab, Ericsson
- Liam Fallon, NM-Lab, Ericsson
- John Keeney, 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)
- Ruan HE - Orange (ruan.he@orange.com)
Name | Gerrit ID | Company | TimeZone | |
---|---|---|---|---|
Pamela Dragosh | pdragosh | AT&T | pdragosh@research.att.com | Bedminster, NJ USA, EST, UTC-4 |
Jorge Hernandez-Herrero | jhh | AT&T | jh1730@att.com | USA, CST |
Alex Vul | avul | Intel | alex.vul@intel.com | Pacific |
Avinash S | Huawei | avinash.s@huawei.com | Bangalore, India, UTC +5:30 | |
Nermin Mohamed | Huawei | nermin.mohamed@huawei.com | ||
Bobby Mander | AT&T | bobby.mander@att.com | Middletown, NJ USA, EST, UTC -4 | |
Ralph Straubs | AT&T | rs8887@att.com | USA, CST | |
Jim Hahn | AT&T | jrh3@att.com | ||
ding yi | ZTE | ding.yi5@zte.com.cn | Beijing, China, UTC +8 | |
xinyuan wang | Xinyuan | ZTE | wang.xinyuan1@zte.com.cn | Beijing, China, UTC +8 |
Zi Li | Nancylizi | ZTE | li.zi30@zte.com.cn | Beijing, China, UTC +8 |
Sven van der Meer | vdmeer.sven | NM-Lab, Ericsson | sven.van.der.meer@ericsson.com | Dublin, Ireland, UTC (DST: UTC+1) Dublin, |
Liam Fallon | NM-Lab, Ericsson | liam.fallon@ericsson.com | Dublin, Ireland, UTC (DST: UTC+1) | |
John Keeney | NM-Lab, Ericsson | john.keeney@ericsson.com | Dublin, Ireland, UTC (DST: UTC+1) | |
Joel Halpern | Ericsson | joel.Halpern@ericsson.com | ||
Jimmy O'Meara | Ericsson | jimmy.o.meara@ericsson.com | Dublin, Ireland, UTC (DST: UTC+1) | |
Yusuf Mirza | IBM | ymirza@ae.ibm.com | Dubai, UAE, UTC +4 | |
Alain Lee | Huawei | linan@huawei | Beijing, China, UTC +8 | |
Yuan Liu | China Mobile | liuyuanyjy@chinamobileliuyuanyjy@chinamobile.com | Beijing, China, UTC +8 | |
Ruan HE | Orange | ruan.he@orange.com | Paris, France, UTC+01:00 | |
John Strassner | strazzie123 | Huawei | john.sc.strassner@Huawei.com | Santa Clara, CA UTC-7 |
Jingbo Liu | BOCO | Beijing, China, UTC +8 | ||
Zhangxiong Zhou | BOCO | zhouzhangxiong@boco.com.cn | Beijing, China, UTC +8 | |
Xin Miao | Huawei | xin.miao@huawei.com | Dallas, Texas, USA, CST |
- Project Roles (include RACI chart, if applicable)
...
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@attbm116p@att.com AT&T
*Link to TSC approval:
...