Project Name:
- Proposed name for the project: Policy Driven VNF Orchestration
- 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:
Some VNF products have been optimized to take advantage of hardware platform specific capabilities, such as NUMA or CPU pinning in order to maximize their performance and throughput. During VNF development, hardware platform requirements for such VNFs are defined in the "VNF descriptor" (i.e. VNF model) and stored in the VNF package (CSAR) as part of the CSAR metadata. When an "optimized" VNF is on-boarded and subsequently instantiated as part of a network service instance, it has to be deployed on specific compute resources that exhibit required hardware platform capabilities. Furthermore, some VNFs are implemented in a way that allows them to operate both in optimized and non-optimized manner, depending on resource availability, entitlements and licensing. Once instantiated, VNFs may require scaling or other remediation actions in order to maintain service levels. Additional VNF resources may need to be added or removed and existing resources may need to be "re-sized" or entirely replaced, depending on operating events and conditions.
This project will provide Policy Framework extensions to enable use of policy based constraints during instantiation, operation and remediation of VNFs. Given its cross-cutting nature and dependencies on other ONAP projects (see below), we are treating this project as a sub-project within the Policy Framework.
Scope:
This project is limited in scope to changes and additions within the Policy Framework. Project deliverables will include:
- A mechanism to handle ingestion of VNF vendor supplied operational policies specified in the VNF Model, and their federation with Operator-specified policies
- Policy DSL support for specification of VNF centric policy constraints for:
- Handling of VNF resource inventory/optimization
- Homing and placement of VNF components
- Allocation of VNF compute, storage and network resources
- Handling of VNF remediation actions, including VNF scaling
- This project will implement programmatic and declarative interfaces required to support:
- Management of VNF related policies, including creation, modification and deletion
- Ability to override/modify policies supplied as part of the VNF package metadata
Architecture Alignment:
- How does this project fit into the rest of the ONAP Architecture?
NOTE - Functional components in RED DOTTED LINES denote project scope and dependencies
- What other ONAP projects does this project depend on
Project | Dependency |
---|---|
Policy Framework | Closed loop policy specifications |
Multi-VIM | Discovery of available VIM level compute resource capabilities |
A&AI | Persistence of VIM supplied compute resource hardware platform capabilities. Interfaces for access to persisted data. |
SO | Enforcement of VNF instantiation policies |
APP-C | Enforcement of VNF operation and remediation policies |
VF-C | Enforcement of VNF instantiation, operation and remediation policies |
DCAE/Holmes | Collection of data relevant to health and state of compute resource hardware platform level capabilities |
SNIRO | Enforcement of VNF resource optimization policies |
SDC | Extraction and persistence of VNF vendor supplied hardware platform requirements |
- How does this align with external standards/specifications?
- ETSI NFV IFA11
- ETSI NFV SOL01
- ETSI NFV SOL04
- How does this align with external standards/specifications?
- XACML (github.com/att/xacml)
- Drools (drools.org)
Resources:
- Primary Contact Person
- Alex Vul - Intel
- 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
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 Brian Hedstrom ARM Ankit Patel AT&T ankit@research.att.com Bedminster, 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
ZTE wang.xinyuan1@zte.com.cn Beijing, China, UTC +8 - Project Roles (include RACI chart, if applicable)
- Primary Contact Person
Other Information:
- link to seed code (if applicable)
- N/A
- Vendor Neutral
- Yes
- Meets Board policy (including IPR)
- Yes
- link to seed code (if applicable)
Use the above information to create a key project facts section on your project page
Key Project Facts
Project Name:
- JIRA project name: Policy Driven VNF Orchestration
- JIRA project prefix: policy-vnf
Repo name:
Lifecycle State: incubation
Primary Contact: Alex Vul, Pamela Dragosh
Project Lead: Alex Vul, Pamela Dragosh
mailing list tag [policy-vnf]
Committers:
pdragosh@research.att.com AT&T
jh1730@att.com AT&T
*Link to TSC approval:
Link to approval of additional submitters:
6 Comments
Catherine Lefevre
Alex, Pam - I believe that this project should also consider CLAMP (CLAMP Project Proposal (5/11/17) as a dependent project if CLAMP is approved by TSC.
Alexander Vul
Catherine,
My hunch is that the implementation might be a combination of policy extensions, CLAMP and resource optimization. I have an end-to-end storyboard diagram that backs this use case. Perhaps we can meet and discuss the desired outcomes and figure out where things go from there. At this point, I simply wanted to surface the use case and the need. We can implement it in whatever way is appropriate...
Cheers,
Alex
maopeng zhang
Alex, should the project depandency add the VF-C?
Alexander Vul
Maopeng, you are right. We need to figure out how this would work for generic VNF managers and VNF specific managers...
Yuan Liu
Alex,
I just quick review the proposal. I found it is focus on the constraints of resource allocation and placement. Can we just call the interface of VIM to do the resource allocation with the constraints parsed by O?
If use the policy-driven solution, what is the interactive process among ONAP Components? Would you mind have an example to show how it works, like provide a flow diagram.
Thanks.
Gildas Lanilis
NOTE: During TSC Meeting on June 22, it was decided that this project will actually be a functionality within the Policy Framework project - No need to review/approve this as a separate project. Meeting minutes (section 3 bullet r)