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
Scope:
...
- 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,
- interface Provide interfaces to DCAE and Policy
- interface to A&AI
- interface Provide interfaces to SO
- interface Provide interfaces to Portal/VID
- interface Provide interfaces to Vendor VNFM
- Use vendor VNFM interfaces
- Use interface to 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, CLAMPDCAE, DCAE, Common Service, Modeling and Multi-Vim
- Interfaces provided to: Policy, SO, Common Service, Modeling, and Multi-VimVID, 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
Shitao LiName Gerrit ID Company Email Time Zone Lingli Deng
lingli China Mobile
Beijing, China. UTC +8
Maopeng Zhang
maopengzhang lishitao@huaweiHuawei
Maopeng ZhangZTE
Nanjing, China. UTC +8
zhangKanagaraj Manickam
mkr1481 Huawei
India. UTC +5:30
Jinhua Fu
fujinhua ZTE
maopeng1@zteNanjing, China. UTC +8
Yan Yang
yangyan China Mobile
Beijing, China. UTC +8
Victor Gao
Kanagaraj Manickam
kanagaraj.manickam@huaweiHuawei
g310497 Huawei
XiAn, China, UTC+8
Anatoly Andrianov
caa028 Nokia
Chicago, USA, UTC -6
Nagesha Subramanya
hsnagesh Nokia
India. UTC +5:30
Shen Tao
shentao@chinamobile.comChina Mobile
Xinhui Li xinhuili VMware lxinhui@vmware.com Beijing, China. UTC + 8 Guirong Wang Wang_Guirong Boco wangguirong@boco.com.cn Beijing, China. UTC +8 Jinhua Fu
fu.jinhua@zteZTE
NanjingXiaodong Ning ningxiaodong2017 Boco ningxiaodong2017@boco.com.cn Beijing, China. UTC +8 Chengli Wang
wangchengli@chinamobileChina Mobile
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 Guangmin Liu
liuguangmin@huaweiHuawei
ShenzhenYannan 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 |
...
Yan Yang
...
China Mobile
Shitao Li | Huawei | lishitao@huawei |
...
...
Nanjing, China. UTC+8 |
...
Guangmin Liu |
...
Huawei |
...
...
...
Shenzhen, China. UTC +8 |
...
Yang Xu |
...
Huawei |
...
...
...
Chicago, U.S. CST
...
Nagesha Subramanya
...
Nokia
...
...
Bangalore, India. IST
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 |
...
...
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 [Should match Jira Project Prefixvfc]
Committers:
Please refer to the table above.
foo@bar.com baz@qux.com *Link to TSC approval:
Link to approval of additional submitters: