Contents

Goal

To support latency-sensitive, high-bandwidth network functions and applications driven by 5G, Edge Computing, VoLTE use cases from a Cloud Infrastructure perspective, there are several requirements to be met. While the detailed requirements are described in the respective use cases, the key business requirements are summarized in the next section for convenience. 

***The goal of this wiki page is to drive the realization of various requirements in relevant ONAP components.***

A preliminary list of various ONAP components for realizing these requirements is in a following section.

Business Requirements Summary

To support latency-sensitive, high-bandwidth network functions and applications driven by 5G, Edge Computing, VoLTE use cases the requirements from a Cloud Infrastructure perspective are summarized below.  The detailed requirements are described in the respective use cases.

1) A single Cloud Region needs to be able to manage one or more distributed (typically Edge) physical DCs

2) Standardized representation of Multi-vendor Cloud Object Hierarchy

  • Aggregate objects (Cloud Region, Tenants, DCI Overlay etc.) 
  • Atomic objects (VMs, Containers etc.) 
  • Resource (CPU, Memory, Network etc.) allocation statistics and resource utilization metrics

3) Standardized representation of Multi-vendor Cloud Analytics

  • Events (E.g. VM Power On/Off), 
  • Alerts (E.g. Cloud Region CPU Usage exceeds threshold) and 
  • Faults (E.g. Loss of Redundancy from a Host NIC perspective) 
  • Policies for correlating between various Events, Alerts, Faults 

4) Near-real-time Streaming Data Management

  • Resource (CPU, Memory, Network etc.) Utilization Metrics 
  • Analytics (Events/Alerts/Faults)

5) Inter-Cloud (typically Edge) Workload (especially Data Plane) Placement/Scheduling/Change Management decisions to leverage metrics and analytics information at an aggregate object level 

ONAP Components (Preliminary List)

A&AI

DCAE

Multi VIM/Cloud

OOF

Policy

SDN-C

Current Progress

Multi-Cloud Object Hierarchy & Capability Information Model Document (Focus on Summarized Requirement 2)

Multi-Cloud Object Hierarchy & Capability Information Model

Jira  MULTICLOUD-153 - Getting issue details... STATUS

Document Contributors 

VMware: ramki krishnanSumit Verdi, Giridhar Jayavelu, Chris Dent, xinhuili

AT&T: Shankaranarayanan Puzhavakath NarayananSastry Isukapalli

Intel: Maryam Tahhan, Srinivasa Addepalli

Wind River: Gil HellmannBin Yang

Document Reviewers

Huawei: Zhipeng Huang

AT&T: Arun GuptaAlok Gupta

VMware: Richard Boswell

Planned Next Steps on Document

  • Update to Modelling Sub Committee

Document Highlights

Objectives

The specification aims to define and standardize an information model which can drive cloud agnostic abstraction across various cloud provider platforms. The specification includes definitions of information objects and their relationships as they represent an individual infrastructure resource and aggregations classes.

Representations can be modelled for reservation, allocation and utilization for all infrastructure resources.

Three core representations are envisioned:

  • Infrastructure Class - Representation for a NFVI resource, its information model, relationships, hierarchies, and aggregations.

  • Cloud Capability Class - Representation for cloud profiles and capabilities including technology, architecture, hardware, configurations, and so on.

  • Application Class - Representation for various workloads and their compositions to deliver end-to-end services such as vEPC, vIMS, vCPE, etc. This is out of scope for this specification.


Business Context

In the current solution landscape, Multi-vendor Cloud (OpenStack-based, VMware VIO, Microsoft Azure etc.) management involves a Cloud-specific Service Provider Design time (on-boarding, infrastructure policy authoring etc.), Deployment time (workload management etc.), Operational time (data management etc.).

This specification aims to address the above challenge by standardizing the information model for various cloud objects (aggregates and atomic) and cloud capabilities. With this approach, service providers can benefit from on-boarding clouds once, then flexibly distribute and life-cycle manage workload across different cloud variants (Internal IT, NFV, Public Clouds).

The information model is consumed by various actors in the operational landscape to carry out lifecycle management and operational functions. As such the information model for the infrastructure class is split into an aggregate and atomic entities to meet the objective of the various actors. The finer granularity telemetry information is typically used by monitoring and analytical systems for decisioning and closed-loop optimizations. Inventory management systems could also be interested in such granularities. Aggregate entities in contrast are are more suitable for actors such as workload placement functions to make dynamic decisions, capacity planning, service orchestration, for example.

In addition to individual infrastructure level telemetry, the infrastructure cloud platform presents aggregate view as a provider of resources including available, used, and step-size; allocations assigned including reservations, limits, and share; and utilization to represent current resource consumptions.

  • No labels

2 Comments

  1. One question or comment w.r.t. "1) A single Cloud Region needs to be able to manage multiple distributed (typically Edge) physical DCs"

    If the "Cloud Region" refer to the the cloud region in AAI, that is not necessary to be true.  IMHO, it is reasonable and true that "A single VIM needs to be able to manage multiple distributed (typically Edge) physical DCs", but there could be multiple "Cloud Region"s on-boarded into ONAP AAI that each "Cloud Region" represents a single Distributed physical DC. This complies with existing representations of physical DCs(VIM/Cloud instance) as well.

  2. I have modified the wording as "one or more distributed (typically Edge) physical DCs" to avoid this confusion.