VF-C: Virtual Function Controller (5/16/17)

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

•  

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

• Open

  

• 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

• Names and affiliations of any other contributors

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

Collaboration:

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

• IRC - link TBA