Project Name:
- Proposed name for the project: VF-C
- Proposed name for the repository: vfc
Project description:
As part of the integration between OpenECOMP and OPEN-O, this proposed project VF-C leverages ETSI NFV MANO architecture and information model as a reference, and implements full life cycle management and FCAPS of VNF and NS.
- support NS and VNF lifecycle management based on the ONAP tosca and yang data model and workflow
- support integration with multi VNFMs via drivers, which include vendors VNFM and generic VNFM
- support integration with multi VNFs via generic VNFM, which does not provide VNFM function
- support integration with multi VIMS via Multi-VIM, which include the opensource and commercial VIMs
- support microservice architecture and model driven resource orchestration and management
Scope:
The project scope provides the full intended scope of the VF-C; not just what is intended for the first release.
- Describe the functionality proposed.
- NFV-O Component,
- compliant with ETSI NFV MANO architecture and information model,
- providing resource orchestration and full life cycle management and FCAPS for NS,
- providing standard south bound interface to VNFMs,
- providing north bound interface to SO, to take part in fulfilling the orchestraion and operation of end2end service,
- providing interface and work with DCAE and Policy for Close Loop Automation.
- VNFM Component,
- compliant with ETSI NFV MANO architecture and information model
- providing full life cycle management and FCAPS for VNFs which do not require a vendor VNFM,
- providing interface and work with NFV-O component, to take part in fulfiiling the LCM and FCAPS management of NS,
- providing interface and work with DCAE and Policy for Close Loop Automation.
- NFV-O Component,
- Specify any interface/API specification proposed,
- Provide interfaces to Policy
- Provide interfaces to SO
- Provide interfaces to Portal/VID
- Provide interfaces to Vendor VNFM
- Use vendor VNFM interfaces
- Use Multi-VIM interfaces
- Use A&AI interfaces
- Use SDC interfaces
- Identity a list of features and functionality will be developed.
- features
- compliant with ETSI NFV MANO architecture and information model
- providing standard south bound interface to VNFMs
- take part in end2end service orchestration by working with SO
- take part in close loop automation by working with DCAE and Policy
- functionalities
- resource orchestration and full life cycle management and FCAPS for NS
- full life cycle management and FCAPS for VNFs
- Identify what is in or out of scope. During the development phase, it helps reduce discussion.
- end2end service orchestration is out of scope for VF-C
Identify the usecase in the Release 1
- (obselete)Use Case: VoLTE (vIMS + vEPC)
- VNF onboarding
- Network service deployment automation
- Network service termination automation
- Framework for integration with vendor provided VNFM
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?
- Projects depend on: SDC, A&AI,DCAE,Common Service, Modeling and Multi-Vim
- Interfaces provided to: Policy, SO,VID, portal
Note: VF-C will be align to the ONAP modeling project defined data model(TOSCA/Yang) and information model.
Now the VF-C seed code doesn’t depend on the common controller framework project.We will collaborate with common controller framework to identify the potential denpendency in the future.
- How does this align with external standards/specifications?
VF-C takes the following specifications as a reference.- APIs/Interfaces: ETSI NFV IFA 007, ETSI NFV IFA 008, ETSI NFV SOL 005 – additional API may be required
- Information/data models: ETSI NFV IFA 015, ETSI NFV SOL 001, ETSI NFV SOL 004 – additional API may be required
- Are there dependencies with other open source projects?
- WSO2: BPMN workflow engine.
- ARIA: TOSCA Parser.
Resources:
- Primary Contact Person
Lingli Deng (denglingli@chinamobile.com) Names, gerrit IDs, and company affiliations of the committers
Name Gerrit ID Company Email Time Zone Lingli Deng
lingli China Mobile
Beijing, China. UTC +8
Maopeng Zhang
maopengzhang ZTE
Nanjing, China. UTC +8
Kanagaraj Manickam
mkr1481 Huawei
India. UTC +5:30
Jinhua Fu
fujinhua ZTE
Nanjing, China. UTC +8
Yan Yang
yangyan China Mobile
Beijing, China. UTC +8
Victor Gao
g310497 Huawei
XiAn, China, UTC+8
Anatoly Andrianov
caa028 Nokia
Chicago, USA, UTC -6
Nagesha Subramanya
hsnagesh Nokia
India. UTC +5:30
Xinhui Li xinhuili VMware lxinhui@vmware.com Beijing, China. UTC + 8 Guirong Wang Wang_Guirong Boco wangguirong@boco.com.cn Beijing, China. UTC +8 Xiaodong Ning ningxiaodong2017 Boco ningxiaodong2017@boco.com.cn Beijing, China. UTC +8 Yog Vashishth yogvashishth Jio Yog.Vashishth@ril.com India GMT+05:30 Adityakar Jha adityakar.jha Jio Adityakar.Jha@ril.com India GMT+05:30 Hu Dong donghu1102 raisecom donghu@raisecom.com Beijing, China. UTC +8 Yannan Han hanyanan raisecom hanyanan@raisecom.com Beijing, China. UTC +8
- Names and affiliations of any other contributors
name | company | time zone | |
---|---|---|---|
Yunlong Ying | ZTE | ying.yunlong@zte.com.cn | Nanjing, China. UTC +8 |
Yuanxing Feng | ZTE | feng.yuanxing@zte.com.cn | Nanjing, China. UTC +8 |
Shitao Li | Huawei | lishitao@huawei.com | Nanjing, China. UTC+8 |
Guangmin Liu | Huawei | liuguangmin@huawei.com | Shenzhen, China. UTC +8 |
Yang Xu | Huawei | yang.xu3@huawei.com | New Jersey, USA UTC -5 |
Hui Deng | Huawei | denghui12@huawei.com | Beijing, China. UTC +8 |
Tao Shen | China Mobile | shentao@chinamobile.com | Beijing, China. UTC +8 |
Chengli Wang | China Mobile | wangchengli@chinamobile.com | Beijing, China. UTC +8 |
Xin Lu | Huawei | luxin7@huawei.com | XiAn, China, UTC+8 |
Zhong Quan | Huawei | quanzhong@huawei.com | XiAn, China, UTC+8 |
Yaoye Zhang | Huawei | zhangyaoye@huawei.com | Nanjing, China. UTC+8 |
- Project Roles (include RACI chart, if applicable)
Other Information:
- link to seed code (if applicable)
git clone https://gerrit.open-o.org/r/nfvo
git clone https://gerrit.open-o.org/r/gvnfm-vnflcm
git clone https://gerrit.open-o.org/r/gvnfm-vnfmgr
git clone https://gerrit.open-o.org/r/gvnfm-vnfres - link to documents of seed code
https://wiki.open-o.org/display/NFVO
https://wiki.open-o.org/display/GVNFM - Vendor Neutral
- if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?
- Meets Board policy (including IPR)
Use the above information to create a key project facts section on your project page
Key Project Facts
Project Name:
- JIRA project name: Virtual Function Controller
- JIRA project prefix: vfc-
Repo name:
- vfc/nfvo
- vfc/gvnfm
Lifecycle State: incubation
Primary Contact: Lingli Deng(CMCC)
Project Lead: Lingli Deng(CMCC)
mailing list tag [vfc]
Committers:
Please refer to the table above.
*Link to TSC approval:
Link to approval of additional submitters:
14 Comments
Dhananjay Pavgi
With VF-C; presumably SDN-C in existing ONAP will be obsolete. Please confirm.
Daniel Rose
neither VF-C and SDNC/APP-C are going away at the moment. There is a lot of work going on around that but just wanted to make sure you know where it stands now.
Lingli Deng
Second Daniel. Neither VF-C or SDNC/APP-C are going away. VF-C is not meant to obsolete SDN-C or APP-C at the moment.
Ranny Haiby
Reading the CLAMP project proposal, it seems there is a dependency between VF-C and CLAMP, in addition to the other projects listed above
Lingli Deng
Thanks. Added.
Ranny Haiby
Request #1 - Please explicitly state that the VNFM portion of VF-C is optional and the VF-C can interface with external VNFMs
Request #2 - Please explicitly state that the VF-C (and VNFM) interface to the VIM can be used for direct resource creation and management. This means that there is no need to work in an "indirect mode" where the VF-C (or VNFM) requests resource grant from a resource orchestrator before creating resources on the VIM. This indirect mode is not fully defined by ETSI and is rarely used in the industry.
xinhuili
For the VIM side, we suppose to expose LCM, health, and clustering service API on behalf of VNFM and VF-C.
Lingli Deng
Thanks for the suggestions.
For Request #1, there is interface with vendor VNFMs, which is meant for external VNFMs.
For Request #2, I suppose it would be dependent on what operator wants in deployment, direct mode or indirect mode, but doubt having both options (if vendor support both) would be preferred. Hence hesitate to be too restrictive in scope definition.
Yan Yang
I have created a doodle poll for VF-C project weekly meeting and I am suggesting times 9pm CST, 10pm CST for days Mon/FRI.
Please respond with your choice.
https://doodle.com/poll/ukfsehpxkymz3ib6
Maybe the options are inconvenience for you,hope you can take into consideration that our members come from India/America/Asia,it is so difficult to accommodate everyone within reasonable waking hours.
I will end the poll at 24:00 on next Wednesday, May 31th. Hope to give me your feedback before the timeline.
Manoj Nair
WSO2 Workflow engine is indicated as a dependency. Will there be two workflow engines in ONAP in this case.? I guess SO uses Camunda workflow engine. As per the above text , VF-C will host a separate WSO2 WF Engine as a micro service ?
maopeng zhang
In the openo, the WSO2 is a micro service. In the MSO of ECOMP, it is included in the MSO service and not a micro service. If the Workflow engine can be micro service standalone and shared with the project in the future, in my mind it is great.
Vlademir Brusse
In case of making Configuration Management (CM) changes to VNF via VF-C/EMS, can you clarify how is this done ? What is the interface ?
Regarding to Onboarding process: is it the same regardless if using APPC or VF-C ?
Thanks.
Yan Yang
In fact,VF-C hasn't implemented automated configuration management in R1. VF-C plans to add this feature in future release.
Can you explain the Onboarding process you mentioned? If you mean VNF initialization, It is a little different, you can see the work flow in Use Case: VoLTE(approved)
mudassar rana
I want to attach my own svnfm driver . And as part of that , i have few queries :
1> I was going through ZTE driver code and found out that svnfm api's are getting invoked using views.py under swagger. How does vfc-nfvo-driver-vnfm-svnfm get invoked. Is there any changes has to be done on vfc-nfvo to call for ZTE driver To summarise the doubt , how does VFC NFVO component knows which vendor VNFM driver to be invoked ?? Can you help me with the file
2> How the BPMN flow is handled w.r.t SVNFM driver . Can you name out the bpmn file w.r.t this
3> why there are two different approach being used for SVNFM ( Huawei & ZTE ). Is there any doc w.r.t Huawei SVNFM . what is this activator file under Huawei , used for ??