Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

  1. A plugable and extensible framework that
    1. provides a Mediation Layer which includes
      1. A common northbound interface (NBI) / Multi-Cloud APIs
      2. A common abstraction model
      3. The ability to handle differences in models
    2. The ability to generate or extend generates or extends NBI based on the functional model of underlying infrastructure
    3. allows Infrastructure Controller to register, discover and choose one or more VIM(s) to use
    4. allows global SDN Controller to choose and work with multiple local SDN Controller backends
    5. enables multiple local SDN Controller backends to interoperate collaboratively and simultaneously
    6. implements adapters for different providers.
  2. Close loop remediation — Monitoring API collection for multi-cloud resource metrics (utilization, availability, health, performance), potential integration with DCAE collectors
  3. SDC VNF template customization and/or optimization to establish close match to the underline capabilities of the infrastructure provider(s)
  4. Should align with the Common Controller Framework to enable reuse by different ONAP elements.

...

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 VIM cloud provider.
    • For vVoLTE or vCPE, enable single VIM cloud provider across multi-site site
  • Stretch goal
    • Implementation of the adapters for VMware VIO, OpenStack (Wind River), and Microsoft Azure.
    • For vVoLTE or vCPE, enable mix of different VIM cloud providers across multi-site

...

            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, 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
      • This project aligns with ETSI NFV VIM and NFViVIM, NFVI, Nf-Vi, Vi-Vnfm, and Or-Vi


  • Are there dependencies with other open source projects?
    • OpenStack

Resources:

...