You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 85 Current »

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.
  • 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

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:

  • Names and affiliations of any other contributors
namecompanyemailtime zone
Yunlong YingZTE ying.yunlong@zte.com.cn  Nanjing,   China. UTC +8
Yuanxing   FengZTEfeng.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 ShenChina Mobileshentao@chinamobile.com Beijing, China. UTC +8
Chengli WangChina Mobilewangchengli@chinamobile.comBeijing, China. UTC +8
Xin LuHuaweiluxin7@huawei.comXiAn, China, UTC+8
Zhong QuanHuaweiquanzhong@huawei.comXiAn, China, UTC+8


  • Project Roles (include RACI chart, if applicable)

Other Information:

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: 

Collaboration:

  • Meeting: weekly friday 10:00-11:00 Beijing Time,  zoomid: 621738721
  • IRC - link TBA



  • No labels