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, Wind River
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
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 HPA capabilities