ONAP R3+ Cloud Infrastructure Modeling

Owned by Bin Hu
Last updated: May 21, 2018 by Ramki Krishnan
2 min read

Goal

ONAP has to be able to create and manage the life cycle of VNFs and services with operations automation in the context of multiple clouds, for example:

  • Clouds with OpenStack etc. as service managers

  • Clouds like Microsoft Azure, Amazon Web Services, Google Compute Platform etc.

  • Public clouds where information about the underlying infrastructure and operations on them are limited.

  • ONAP operator-owned clouds where much more information and operations on the cloud infrastructure are potentially available.

Ideally, the data model is cloud-agnostic. The impact to ONAP of introducing a new cloud type (or upgraded version of a cloud type) is to be minimized. To meet this objective, the architecture calls for all the specific-to-a-particular cloud knowledge to be localized, and for the rest of ONAP to use a cloud-agnostic model. The various cloud-specific template objects, attributes and APIs that are relevant to ONAP should be readily mapped into this data model.

The data model should be structured to help and not hinder, to the extent possible for a data model, the architectural desired separation of concerns between ONAP and the clouds.

Challenge

That a useful-to-ONAP cloud-agnostic abstraction is possible can only be demonstrated by creating it. That being said, the key word here is "useful". This data model is NOT intended to address every feature, capability, resource type and operation in every cloud. The focus is on "What does ONAP need?", and to specify the concepts needed for the ONAP view of a cloud infrastructure.

In particular, at a minimum:

  1. The data model must provide a representation of the cloud resources identified in the VNF Descriptor model.

  2. The data model must provide a representation of the information that the Service Orchestrator sends towards the cloud.

  3. The data model must represent the information needed for the ONAP Optimization Framework.

  4. The data model must enable mapping of relevant data of the specific cloud resources created by ONAP into the A&AI inventory.

  5. The data model must facilitate the consumption of cloud-specific telemetry.

  6. The data model must support distributed edge cloud DCs.

Scope

  1. The initial scope is for virtual machine based workloads, but work on containers must also start.

  2. OpenStack private and public clouds, and Azure as a public cloud are the minimum that the initial model must handle.

  3. It is assumed, for the initial model, that VNFs use only the set of similar cloud resources listed here.

Principles

  1. Generic: provides a description of any cloud

  2. Simple: clear definition with examples

  3. Adequate to address immediate use cases (e.g., Edge Automation)

  4. Extensible – not intended to be final, complete, comprehensive

  5. Standards-compliant (with proposed extensions to standard where necessary)

Methodology

  1. The data model should be illustrated by examples, that tend to show that model expresses what it needs to.

    1. For example, demonstrate the mappings from the data needed by the APIs to the cloud infrastructure data model.

  2. Align with ETSI NFV IFA 015 as much as is reasonable. Originality in data modeling is not a virtue.

  3. Creating and maintaining modeled data is expensive. Only what is necessary should be modeled.

Proposals

  1. Cloud Infrastructure Aggregate Representation Classes