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

Compare with Current View Page History

« Previous Version 84 Next »

Project Name:

  • Proposed name for the project: Multi VIM/Cloud for Infrastructure Providers
  • Proposed name for the repository: multicloud

Project description:

Motivation

  • ONAP needs underlying virtualized infrastructure to deploy, run, and manage network services and VNFs.
  • The service providers always look for flexibility and choice in selecting virtual and cloud infrastructure implementations, for example, on-premise private cloud, public cloud, or hybrid cloud implementations, and related network backends.
  • ONAP needs to maintain platform backward compatibility with every new release.
  • Multi-VIM/Cloud project aims to enable ONAP to deploy and run on multiple infrastructure environments, for example, OpenStack and its different distributions (e.g. vanilla OpenStack, Wind River, etc...), public and private clouds (e.g. VMware, Azure), and micro services containers, etc.
  • Multi-VIM/Cloud project will provide a Cloud Mediation Layer supporting multiple infrastructures and network backends so as to effectively prevents vendor lock-in.
  • Multi-VIM/Cloud project decouples the evolution of ONAP platform from the evolution of underlying cloud infrastructure, and minimizes the impact on the deployed ONAP while upgrading the underlying cloud infrastructures independently.

Scope:

The scope of Multi-VIM/Cloud project is a plugable and extensible framework that

  1. provides a Cloud Mediation Layer which includes the following functional modules
    1. Provider Registry to register infrastructure site/location/region and their attributes and capabilities in A&AI
    2. Infra Resource to manage resource request (compute, storage and memory) from SO, DCAE, or other ONAP components, so as to get VM created and VNF instantiated at the right infrastructure
    3. SDN Overlay to configure overlay network via local SDN controllers for the corresponding cloud infrastructure
    4. VNF Resource LCM to perform VM lifecycle management as requested by VNFM (APP-C or VNF-C)
    5. FCAPS to report infrastructure resource metrics (utilization, availability, health, performance) to DCAE Collectors for Close Loop Remediation
  2. provides a common northbound interface (NBI) / Multi-Cloud APIs of the functional modules to be consumed by SO, SDN-C, APP-C, VF-C, DCAE etc.
  3. provides a common abstraction model
  4. provides the ability to
    1. handle differences in models
    2. generate or extend NBI based on the functional model of underlying infrastructure
    3. implement adapters for different providers.

Across the project, the implementation of any differentiated functionalities will be done in a way where ONAP users can decide if to use or not to use those functionalities.

Multi-VIM/Cloud project will align with the Common Controller Framework to enable reuse by different ONAP elements.

Deliverables of Release One:

Note: this section is for brainstorming and informational purpose, and subject to change during release planning stage

In R1, we target to support

  • Minimal
    • Implementation of the adapters for VMware, OpenStack (Wind River), and Microsoft Azure.
    • Demo use case within a single site, supported by any single cloud provider.
    • For vVoLTE or vCPE, enable single cloud provider across multi-site
  • Stretch goal
    • For vVoLTE or vCPE, enable mix of different cloud providers across multi-site

Architecture Alignment:

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

The proposed Multi VIM/Cloud layer will be added into the infrastructure controller. It has dependencies with SO, DCAE, A&AI, APP-C/VNF-C, Modeling, and will act as the single access point to be called by these components for accessing the cloud and virtual infrastructure. Furthermore, it will align with SDN-C component for both intra DC connectivity as well as inter-DC connectivity. Thus it is also the single access point for SDN-C to work with other local SDN Controllers. Applications/VNFs can be homed to the different cloud providers through the standard ONAP methods. For automated homing (SNIRO), different cloud providers can register attributes that differentiate their cloud platforms (e.g., reliability, latency, other capabilities) in A&AI and application placement policies/constraints can request for these specific properties (e.g., reliability > 0.999).



  • What other ONAP projects does this project depend on?

Common Services, AAI, Modeling, SDC, SO, APP-C/VNF-C, DCAE, SDN-C

  • How does this align with external standards/specifications?
    • Support existed functions
    • Information/data models by ONAP modeling project
    • Compliant with ETSI NFV architecture framework
      • VIM, NFVI, Nf-Vi, Vi-Vnfm, and Or-Vi
  • Are there dependencies with other open source projects?

    • Cassandra, OpenStack java sdk, AWS Java sdk, Azure and Bare metal.

Resources:

Other Information:

  • link to seed code (if applicable)

OPEN-O

ECOMP

Use the above information to create a key project facts section on your project page

Key Project Facts

Project Name:

  • JIRA project name: multicloud
  • JIRA project prefix: multicloud

Repo name:

  • org.onap.multicloud/framework
  • org.onap.multicloud/openstack
  • org.onap.multicloud/vmware
  • org.onap.multicloud/azure

IRC: http://webchat.freenode.net/?channels=onap-multicloud

Lifecycle State: incubation
Primary Contact: Danny Lin, VMware
Project Lead: To Be Elected
mailing list tag: multicloud

Committers:

Contributors

*Link to TSC approval: 
Link to approval of additional submitters:


Save

in selecting virtual and cloud infrastructure implementations

  • No labels