Requirements Tracking Jira: REQ-42 - Getting issue details... STATUS


Overview

One of the primary advantages of a virtualized cloud infrastructure is the ability to maximize resource utilization.  In a PNF environment, resource allocation is relatively static and therefore enough capacity needs to be available for peak loads.  This leads to many inefficiencies during normal operating times.  In the software controlled environment of virtualized resources, ONAP can allocate resources to a VNF as they are needed.  Scaling is the process utilized by ONAP to change the amount of resources allocated to a VNF

Goals

Frankfurt Goals

This is the set of goals that has been committed by the PTLs for the Frankfurt Release

  1. Auto VNF configuration (Tech Mahindra)
  2. Ansible support for Scaling
  3. ConfigScaleIn Action

Future Goals

This set of goals did not make the funding list for Frankfurt.  We will attempt to do these in the G Release

  1. Scaling by multiple instances
  2. Scheduling of Manual Scaling (Not ready for Frankfurt)
  3. Homing and Capacity Check
  4. Robust healthcheck
  5. Complex post instantiation configuration
  6. Pre and Post Action signaling to VNF
  7. Manual Scale In (Manually remove instances of a VNFC)
  8. Auto Scale In (Automatically remove instances of a VNFC)
  9. Architecture approved Controller_Type Lookup
  10. Support TOSCA Based VNFs

Business Requirement

Executive Summary

Dynamic scaling gives an operator the tools it needs to maximize efficiency of the resources dedicated to the cloud. Through the Scaling Use Case, ONAP's control environment allows it to assign resources where they are most needed and reallocate them when they are needed by different VNF.  This allows the cloud environment to achieve a much higher resource utilization level than the old data centers it is replacing. 

Business Impact

Enabling dynamic resource allocation through Scale Out and Scale In will greatly increase the efficiency of the Cloud Platform.  This will be one of the key methods for meeting the cost savings that Cloud  Platforms have promised Service Providers.

Business Markets

This Use Case will be important to any provider that is trying to maximize its use of limited resources on a cloud platform

Funding/Financial Impacts

This use Case has the potential to significantly reduce CAPEX

Organizational Mgmt/Sales Strategies

There is no additional organizational management or sales strategies for this use case outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider

Participating Companies

AT&T, Ericsson, Nokia, Tech Mahindra

Scope


Presentations

VNFC Configuration in Frankfurt (Lukasz Rajewski )

Flow Diagrams

Roadmap

Scaling Use Case Team Meetings

Meeting Logistics

Weekly Scaling Meeting

Day: Tuesday

Time: UTC 1400 / China 2200 / Eastern 0900 / Pacific 0600

URL:  https://zoom.us/j/457158496

Meeting Minutes

Impacts

Project Commitments

ProjectImpactPTLCommitmentNotes
CCSDK/CDSTest Only

COMMITTED

Auto Post-Instantiation Configuration of VF_Modules
APPCComplex

COMMITTED

Ansible Support of Scaling

New ConfigScaleIn Action

SOModerate

COMMITTED

CDS Actor Selection for Scale Out Use case (TechM)
  • No labels

1 Comment

  1. One of the issues that was encountered while developing the external ETSI VNF Manager (SOL003) adapter in SO, is the disconnect between the ETSI view of a VNF and the ECOMP/ONAP view which decomposes the VNF into VFs.  How would the scaling use case be tied to the VF module construct?  Can we abstract this scaling notiion so that the resource allocation of an ETSI VNF scale operation would be driven VNF Manager "grant" request, instead of being pre-allocated?