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. For the detailed requirements are described in the respective use cases,
1) A single Cloud Region needs to be able to manage multiple 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
Document Jira
Jira - MULTICLOUD-153Getting issue details... STATUS
Document Contributors
VMware: Ramki Krishnan, Sumit Verdi, Giridhar Jayavelu, Chris Dent, Former user (Deleted)
AT&T: Shankaranarayanan Puzhavakath Narayanan, Sastry Isukapalli
Intel: Maryam Tahhan, Srinivasa Addepalli
Wind River: Gil Hellmann, Bin Yang
Document Reviewers
Huawei: Zhipeng Huang
AT&T: Arun Gupta, alok411
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.