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

Compare with Current View Page History

Version 1 Next »

Project Name:

  • Proposed name for the project: Multi-vim
  • Proposed name for the repository: 
    • Multi-vim-framework
    • Multi-vim-vmware-plugin
    • Multi-vim-azure-plugin
    • Multi-vim-openstack-plugin

Project description:

  • In ONAP, SO, APPC/VNF-C, DCAE, need to access to virtual and cloud infrastructure. SDC also requires knowledge of the infrastructure to onboard VNF images and VNF template. And finally, SDN-C could benefit from the capability of a local SDN to create VNF connectivity within the cloud. An abstraction layer with ONAP is necessary to consolidate all these infrastructure capabilities.
  • Service providers also look for flexibility and choice in terms of multiple clouds to meet their business requirements. ONAP needs to support different infrastructure environment including OpenStack (different versioned), VMware, Azure, micro-services, and containers.

Scope:

1: A framework for registration, resource, capacity, and homing

2: A plugin for different cloud providers. In R1, we expect  OpenStack?Wind River?, VMware VIO, and Azure.

3: DCAE close loop remediation

  • Monitoring API collection for multi-cloud resource metrics (utilization, availability, health, performance)? potential extending DCAE collectors

4: Deliverables:

  • Minimal
    • Demo vFirewall in an environment with any single cloud provider, within a single site
    • For VoLTE and vCPE (or whatever is the minimal release requirement), enable single cloud provider across multi-site 
  • Stretch goal
    • Enable multiple cloud provider across multi-site

5: SDN-C

           * SDN-C Delegation to local SDN controller

           * SDN Controller can establish cross DC connectivity, including support public cloud SDN federation

Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?

            The proposed infrastructure mediation layer will work as the single access point to be called by different components. Where, authentication federation should be provided to different adaptors/plugins, together with infrastructure management and operation API (e.g., LCM), and expose monitoring/alerts/events for DCAE or any consumer

  • How does this align with external standards/specifications?
    • Support existed functions
    • Information/data models
    • Compliant with ETSI NFV arhitecture framework
  • Are there dependencies with other open source projects?

Resources:

  • Primary Contact Person: Bin Yang, Xinhui Li,
  • Initial Committers:
    • Andrew Philip, Microsoft
    • Bin Yang, Wind River
    • Xinhui Li, VMware
    • Anbing Zhang, CMCC

Contributors

    • Isaku Yanahata, Intel
    • Matti Hiltunen, AT&T
    • Ethan, VMware

Other Information:

  • link to seed code (if applicable)
  • 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:
  • JIRA project prefix:

Repo name:
Lifecycle State:
Primary Contact:
Project Lead:
mailing list tag [Should match Jira Project Prefix] 
*Link to TSC approval: 
Link to approval of additional submitters: 

    • Andrew Philip, Microsoft
    • Bin Yang, Wind River
    • Xinhui Li, VMware
    • Anbing Zhang, CMCC

 

  • No labels