Versions Compared

Key

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

Description

• General

-This function requirement is to support auto and manual scaling. 

-This function requirement is not limited to VoLTE VNFs (MME, SGW, CSCF, TAS), it aims to be supported by both VF-C and APP-C VNFs and Services.

• Auto Scaling
-VNF auto scaling is based on policies. The input of the policy can be either application aspect events/conditions (e.g. subscriber capabilities ,call loss rate) or non-application aspect events/conditions (e.g. CPU usage).
-The ONAP platform should be able to perform scaling of any VNF that supports scaling, in all flavors/levels supported by the VNF

• Manual Scaling

-Auto-scaling can trigger the scaling operation based on the real-time state of a VNF instance. But it cannot cover all operators’ requirements of scaling. For example, on holidays or in large activities, auto-scaling cannot provide an immediate response to the huge growth of traffic.

-Manual scaling provide the capability of VNF scale in/out triggered by operators based on predicted demand.

-The ONAP platform should be able to perform scaling of any VNF that supports scaling, in all flavors/levels supported by the VNF.NF

capabilitie

General Flows

Step 1-5 are trigger procedures: Step 1-5 are auto-scaling trigger procedures;  5a is manual scaling trigger procedures.

Step 6-7 are scaling execute procedures which is independent from trigger procedures. Step 7 is for VF-C scaling and 7a is for APP-C scaling.


VNF Capabilities

•Any dependencies on specific VNF capabilities
-VNF should support scaling in different flavors/levels
-VNF/EMS should support the monitoring of the metrics which are used by auto-scaling policies


•VNFs that we would use to test the use cases
-Any VNFs
-VNFs in VoLTE usecase: MME, SAE-GW, CSCF, TAS


Companies willing to support

-China Mobile, AT&T, ZTE, Huawei


Summary of ONAP platform impacts

VNFs/Services under either VF-C or APP-C have different detailed flows and requirements for each ONAP component.

The table summaries all the requirements for both VF-C and APP-C VNFs/Services, and also a overlap analysis provided.

Summary of ONAP platform impacts

Functional Req

Component

Used for

Impact

Auto and Manual Scaling

UUI

VF-C (Only for manual scaling)

Support trigger manual scaling for a dedicate VNF instance.

VID

APP-C (Only for manual scaling)

Support trigger manual scaling for a dedicate VNF instance.

SO

both

Support scaling recipe, forward scaling demand to VF-C and/or APP-C depends on which VNF is selected.

VF-C

VF-C

Support scaling API, and execute VNF scaling procedures.

APP-C

APP-C


POLICY

both

Definition of auto scaling policy, collect policy related data from DCAE, receive alert from DCAE, trigger auto scaling which the event/condition fulfilled.

DCAE

both

Collect resource data from Multi-Cloud, collect application data from VF-C/VNF/EMS/APP-C. Support TCA.

CLAMP

both

Design and manage control loops.

AAI

both

Provide real-time views of Resources, services and their relationship.

Multi-Cloud

both

Support deploy VNF on infrastructure environment. Already supported.

OOF

both


SDNC

both


SDC

both

Support design and accept VNF packages and policies.

VNF Req

both

Create and maintain VNF requirements targeted to VNF providers.


Overlap Analysis

Image Added


S3P impacts

•Manual Scale Out and Auto Scale Out are automated processes that will help bypass many manual operations steps for scaling VNFs.  Therefore this cannot be treated as most ONAP components are treated from a S3P point of view.
•Scalability – Manual and Auto Scale Out will be a major step in allowing VNFs to easily scale and use only the resources that are required for the current demand.  Scale out use cases should also be exercised in parallel to determine how many scale out operations can be done simultaneously.
•Stability – As part of initial tests, both scale out use cases will need to be aggressively exercised in varied conditions to ensure the processes work and are resilient to failure.
•Security – New instances of the VNF(C) should be tested from a security point of view to ensure there are no vulnerabilities.
•Performance – the scale out use cases will need to be measured to determine the length of time it takes to do a single scale out operation.  This will likely vary greatly amongst different VNF types and therefore conducting the tests across multiple VNFs would result in better measurements.  There might also be significant differences based on process changes.  Experimentation might be the best way to determine the most efficient process to use for scale out.


References

•ETSI GS NFV-MAN 001 —— “B.4 VNF instance scaling flows” describes flows of scaling. The scaling use case is grouped in 3 categories, auto-scaling, on-demand scaling and scaling based on management request.
-Auto-scaling and on-demand scaling refer to the scaling triggered by VNFM/EMS/VNF automatically, related to R46.
-Scaling based on management request refers to the scaling triggered by some senders (OSS/BSS/operators) manually, related to R47.
-http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf

•ETSI IFA 005, 006, 007 define the stage 2 specifications of Or-Vnfm, Or-Vi, Vnfm-Vi interfaces;

•ETSI SOL 003 defines the stage 3 specifications of Or-Vnfm interface;
-http://www.etsi.org/standards, http://www.etsi.org/deliver

•Openstack defines the VIM NBI APIs;
-https://developer.openstack.org/api-guide/quick-start/

•OASIS TOSCA defines the VNF Descriptor in TOSCA Format

•VoLTE use case support EPA HPA capabilities