The guidance text (green) shall be removed when no longer needed or use the skeleton without guidance text which is available via the editHelp! website.

Disclaimer: This DRAFT is a working document of ETSI ISG NFV. It is provided for information only and is still under development within ETSI ISG NFV. DRAFTS may be updated, deleted, replaced, or obsoleted by other documents at any time.

ETSI and its Members accept no liability for any further use/implementation of the present DRAFT.

Do not use as reference material.Do not cite this document other than as "work in progress".

- ETSI NFV public DRAFTS are available in: http://docbox.etsi.org/ISG/NFV/Open/Drafts/- Report FEEDBACK via the NFV issue tracker: http://nfvwiki.etsi.org/index.php?title=NFV_Issue_Tracker- Approved and PUBLISHED deliverables shall be obtained via the ETSI Standards search page at:

http://www.etsi.org/standards-search

ETSI GS NVF-EVE 011 V0.0.43 (2017-06)

Network Functions Virtualisation (NFV);Software Architecture;

Specification of the Classification of Cloud Native VNF implementations

Release 3

Release 3

Reference<Workitem>

Keywords<keywords>

ETSI

650 Route des LuciolesF-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-préfecture de Grasse (06) N° 7803/88

Important notice

The present document can be downloaded from:http://www.etsi.org/standards-search

The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any

existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.

Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at

https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx

If you find errors in the present document, please send your comment to one of the following services:https://portal.etsi.org/People/CommiteeSupportStaff.aspx

Copyright Notification

No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.

The content of the PDF version shall not be modified without the written authorization of ETSI.The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute yyyy.All rights reserved.

DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.3GPPTM and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and

of the 3GPP Organizational Partners.GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.

Logos on the front page

If a logo is to be included, it should appear below the title on the right hand side of the cover page

ETSI

GROUP SPECIFICATION

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)2

Release 3

Copyrights on page 2This paragraph should be used for deliverables processed before ISG/WG approval and used in meetings.

Reproduction is only permitted for the purpose of standardization work undertaken within ETSI.The copyright and the foregoing restriction extend to reproduction in all media.

Contents (style TT)

To unlock the Table of Contents: select the Table of Contents, click simultaneously: Ctrl + Shift + F11.To update the Table of Contents: F9.To lock it: select the Table of Contents and then click simultaneously: Ctrl + F11.

Logos on the front page .......................................................................................................................................

Copyrights on page 2 ..........................................................................................................................................

Intellectual Property Rights (style H1) ................................................................................................................

Foreword (style H1) ............................................................................................................................................Multi-part documents ............................................................................................................................................................

Modal verbs terminology (style H1) ...................................................................................................................

Executive summary (style H1) ............................................................................................................................

Introduction (style H1) ........................................................................................................................................

1 Scope .........................................................................................................................................................

2 References (style H1) ................................................................................................................................2.1 Normative references (style H2) ..........................................................................................................................2.2 Informative references (style H2) ........................................................................................................................

3 Definitions, symbols and abbreviations (style H1) ...................................................................................3.1 Definitions (style H2) ..........................................................................................................................................3.2 Symbols (style H2) ..............................................................................................................................................3.3 Abbreviations (style H2) ......................................................................................................................................

4 Overview .................................................................................................................................................

5 Non-functional parameters for Cloud-native VNF Classification ..........................................................5.1 Resiliency ..........................................................................................................................................................5.1.1 Introduction ..................................................................................................................................................115.1.2 Redundancy ..................................................................................................................................................115.1.3 Fault Monitoring and Failure Detection .......................................................................................................125.2 Scaling ...............................................................................................................................................................5.2.1 Introduction ..................................................................................................................................................125.2.2 Scale-out/In ..................................................................................................................................................135.3 Cloud Native VNF Design ................................................................................................................................5.3.1 Introduction ..................................................................................................................................................135.3.2 Decomposition .............................................................................................................................................135.4 Use of Services for VNF Architecture ..............................................................................................................5.4.1 Introduction ..................................................................................................................................................145.4.2 VNF architecture requirements ....................................................................................................................145.5 Zero-touch Management ....................................................................................................................................5.5.1 Introduction ..................................................................................................................................................155.5.2 Automated instantiation and configuration ..................................................................................................155.x.3 Load-balancing .............................................................................................................................................15REQ 5.5.3.1: the information about what type of load balancing is applied or is required from the infrastructure shall be

information exposed. ....................................................................................................................................155.5.3 Automated Resource Management ..............................................................................................................155.x Parameter X .......................................................................................................................................................5.x.1 Description .........................................................................................................................................................5.x.2 Way of Measuring .............................................................................................................................................

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)3

Release 3

6 Classification of Cloud-native VNF Implementations ...........................................................................

Annex <A> (normative or informative): Title of annex (style H8) .............................................................17

Annex <B> (normative or informative): Title of annex (style H8) .............................................................17

<B.1>First clause of the annex (style H1) ........................................................................................................<B.1.1> First subdivided clause of the annex (style H2) .................................................................................................

Annex <X> (informative): Authors & contributors (style H8) ...................................................................17

Annex <Y> (informative): Bibliography (style H8) ......................................................................................17

Annex <Z> (informative): Change History (style H8) .................................................................................18

History ...............................................................................................................................................................A few examples: ..................................................................................................................................................................

Logos on the front page .......................................................................................................................................

Copyrights on page 2 ..........................................................................................................................................

Intellectual Property Rights (style H1) ................................................................................................................

Foreword (style H1) ............................................................................................................................................Multi-part documents ............................................................................................................................................................

Modal verbs terminology (style H1) ...................................................................................................................

Executive summary (style H1) ............................................................................................................................

Introduction (style H1) ........................................................................................................................................

1 Scope .........................................................................................................................................................

2 References (style H1) ................................................................................................................................2.1 Normative references (style H2) ..........................................................................................................................2.2 Informative references (style H2) ........................................................................................................................

3 Definitions, symbols and abbreviations (style H1) ...................................................................................3.1 Definitions (style H2) ..........................................................................................................................................3.2 Symbols (style H2) ..............................................................................................................................................3.3 Abbreviations (style H2) ......................................................................................................................................

4 Overview .................................................................................................................................................

5 Non-functional parameters for Cloud-native VNF Classification ..........................................................5.1 Resiliency ..........................................................................................................................................................5.1.1 Introduction ..................................................................................................................................................115.1.2 Redundancy ..................................................................................................................................................115.2 Scaling ...............................................................................................................................................................5.2.1 Introduction ..................................................................................................................................................125.2.2 Scale-out/In ..................................................................................................................................................125.3 Cloud Native VNF Design ................................................................................................................................5.3.1 Introduction ..................................................................................................................................................135.3.2 Decomposition .............................................................................................................................................135.4 Use of Services for VNF Architecture ..............................................................................................................5.4.1 Introduction ..................................................................................................................................................135.4.2 VNF architecture requirements ....................................................................................................................145.x Parameter X .......................................................................................................................................................5.x.1 Description .........................................................................................................................................................5.x.2 Way of Measuring .............................................................................................................................................

6 Classification of Cloud-native VNF Implementations ...........................................................................

Annex <A> (normative or informative): Title of annex (style H8) .............................................................16

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)4

Release 3

Annex <B> (normative or informative): Title of annex (style H8) .............................................................16

<B.1>First clause of the annex (style H1) ........................................................................................................<B.1.1> First subdivided clause of the annex (style H2) .................................................................................................

Annex <X> (informative): Authors & contributors (style H8) ...................................................................16

Annex <Y> (informative): Bibliography (style H8) ......................................................................................16

Annex <Z> (informative): Change History (style H8) .................................................................................17

History ...............................................................................................................................................................A few examples: ..................................................................................................................................................................

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)5

Release 3

<PAGE BREAK>

Intellectual Property Rights (style H1)

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (https://ipr.etsi.org).

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.

Foreword (style H1)

This unnumbered clause is mandatory and shall appear just after the IPR clause.

Replace all <parameters> with the appropriate text.

This Group Specification (GS) has been produced by ETSI Industry Specification Group <long ISGname> (<short ISGname>).

Multi-part documentsThe following block is required in the case of multi-part deliverables.

the <common element of the title> is the same for all parts;

the <part element of the title> differs from part to part; and if appropriate;

the <sub-part element of the title> differs from sub-part to sub-part.

For more details see clause 2.5 of the ETSI Drafting Rules (EDRs).

The best solution for maintaining the structure of series is to have a detailed list of all parts and subparts mentioned in one of the parts (usually it is part 1).

If you choose this solution, the following text has to be mentioned in all of the other parts and sub-parts:

The present document is part <i> of a multi-part deliverable. Full details of the entire series can be found in part [x] [Bookmark reference].

Modal verbs terminology (style H1)

This unnumbered clause is a mandatory informative element and shall appear just after the "Foreword".

In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).

"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

Executive summary (style H1)

This unnumbered clause, if present, appears after the "Modal verbs terminology" and before the "Introduction". It is an optional informative element and shall not contain requirements.

The "Executive summary" is used, if required, to summarize the ETSI deliverable. It contains enough information for the readers to become acquainted with the full document without reading it. It is usually one page or shorter.

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)6

Release 3

Introduction (style H1)

This unnumbered clause, if present, appears just before the "Scope". It is an optional informative element and shall not contain requirements.

CLAUSE NUMBERING STARTS HEREAFTER.

Automatic numbering may be used in ETSI deliverables but it is highly recommended to use sequence numbering.Check https://portal.etsi.org/Portals/0/TBpages/edithelp/Docs/EDR_Navigator.chm clauses 2.12.1.1 and 6.9.2 for help.

Editor’s Note: In this section, a high-level description is needed on how these parameters are used. To be defined whether this is part of this clause or whether clause 4 is ok for that. (currently in Clause 4)

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)7

Release 3

1 ScopeThe present document will specify a set of non-functional parameters to classify and characterize any VNF implementation including, for example, level of separation of logic and state, degree of scale-out, memory footprint, use of accelerators, and more. This specification will contain normative provisions in order to classify the VNF implementations as cloud native.

2 References (style H1)

This clause numbered 2 appears just after the "Scope". It is a required element.

The following text block applies. More details can be found in clause 2.10 of the EDRs.

2.1 Normative references (style H2)

Clause 2.1 only shall contain normative (essential) references which are cited in the document itself. These references have to be publicly available and in English.

Legal acts can never be used as normative references

References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

Referenced documents which are not found to be publicly available in the expected location might be found at https://docbox.etsi.org/Reference.

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity.

The following referenced documents are necessary for the application of the present document.

Use the EX style, enclose the number in square brackets and separate it from the title with a tab (you may use sequence fields for automatically numbering references, see clause 6.9.2: "Sequence numbering") (see example).

EXAMPLE:

[1][tab] <Standard Organization acronym> <document number>: "<Title>".

[2][tab] <Standard Organization acronym> <document number>: "<Title>".

2.2 Informative references (style H2)

Clause 2.2 shall only contain informative references, which are cited in the document itself.

References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity.

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)8

Release 3

The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.

Use the EX style, add the letter "i" (for informative) before the number (which shall be in square brackets) and separate this from the title with a tab (you may use sequence fields for automatically numbering references, see clause A.6.9.2: "Sequence numbering") (see example).

EXAMPLE:

[i.x][tab] <Standard Organization acronym> <document number>: "<Title>".

[i.1] “Network Operator Perspectives on NFV priorities for 5G”, ETSI NFV Network Operators Council White Paper, February 2017.

[i.2] ETSI GS NFV-SWA 001 V1.1.1, Virtual Network Functions Architecture, 2014-12.

[i.3] ETSI GS NFV-IFA 007 V2.1.3, Or-Vnfm reference point - Interface and Information Model Specification, 2017-04.

3 Definitions, symbols and abbreviations (style H1)

Delete from the above heading the word(s) which is/are not applicable, (see clause 2.11 of EDRs).

Definitions and abbreviations extracted from ETSI deliverables can be useful when drafting documents and can be consulted via the Terms and Definitions Interactive Database (TEDDI) (http://webapp.etsi.org/Teddi/).

3.1 Definitions (style H2)

Clause numbering depends on applicability.

A definition shall not take the form of, or contain, a requirement.

The form of a definition shall be such that it can replace the term in context. Additional information shall be given only in the form of examples or notes (see below).

The terms and definitions shall be presented in alphabetical order.

The following text block applies. More details can be found in clause 2.11.1 of the EDRs.

For the purposes of the present document, the [following] terms and definitions [given in ... and the following] apply:

Definition format Use the Normal style.

The term shall be in bold, and shall start with a lower case letter (unless it is always rendered with a leading capital) followed by a colon, one space, and the definition starting with a lower case letter and no ending full-stop.

<defined term>: <definition>

EXAMPLE: text used to clarify abstract rules by applying them literally

NOTE: This may contain additional information.

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)9

Release 3

3.2 Symbols (style H2)

Symbols should be ordered alphabetically. Clause numbering depends on applicability.

The following text block applies. More details can be found in clause 2.11.2 of the EDRs.

For the purposes of the present document, the [following] symbols [given in ... and the following] apply:

Symbol format Use the EW style and separate this from the definition with a tab. Use the EX style for the last term.

<1st symbol> [tab]<1st Explanation> (style EW)<2nd symbol> [tab]<2nd Explanation> (style EW)<3rd symbol> [tab]<3rd Explanation> (style EX)

3.3 Abbreviations (style H2)

Abbreviations should be ordered alphabetically. Clause numbering depends on applicability.

The following text block applies. More details can be found in clause 2.11.2 of the EDRs.

For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:

Abbreviation format Use the EW style and separate this from the definition with a tab. Use the EX style for the last term.

<1st ACRONYM> [tab]<Explanation> (style EW)<2nd ACRONYM> [tab]<Explanation> (style EW)<3rd ACRONYM> [tab]<Explanation> (style EX)

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)10

Release 3

4 OverviewEditor’s Note: some generic text on how to use the parameters and how they are defined, eventually some use cases on how the parameters are used in operator environments.

The present document focusses on the characterization of Virtual Network Functions (VNF) as part of their configuration and deployment in the “the Cloud”. Such VNFs are assumed to be implemented using generic cloud techniques beyond virtualization [i.1]. For example, the VNFs may be built with re-usable components as opposed to a unique – and potentially proprietary - block of functions.

Cloud Native VNFs are expected to function efficiently on any network Cloud, private, hybrid, or public. The VNF developer is therefore expected to carefully engineer VNFs such that they can operate independently in the desired Cloud environment. This is an indication of the “readiness” of VNFs to perform as expected in the Cloud. The objective of this document is to develop the characterization of the “Cloud Readiness” of VNFs.

From an operator perspective, it is essential to have a complete description of Cloud Native readiness of VNFs; this description will enable operators in their VNF selection process. To do this, it is essential that a set of non-functional parametric characterizations be developed that appropriately describe the Cloud Native nature of VNFs. Non-functional parameters describe the environmental behaviour of VNFs residing in the Cloud. They do not describe the actual working functions of the VNF; rather they describe how the VNF can reside independently in the Cloud without constant operator involvement. An example of a Cloud Native VNF non-functional parameter is the degree of VNF Micro-Component redundancy within the VNF; this would be an indication as to the readiness by which failover from a failed Micro-Component to a standby Micro-Component can be gracefully done without intervention by the operator.

Editor’s Note: The Term VNF Micro-Component to be defined and added to definition in clause 3 (FFS whether it is equal to VNFC and if the VNFC will address the cloud native VNFs)

The intent of the present document is to develop a minimum set of non-functional parameters by which VNFs are characterized as Cloud Native. The non-functional parameters will be classified according to the specific environmental behaviour of the VNF; examples of these behaviours include, but are not limited to the following:

Resiliency Operations Design Security Use of Accelerators Memory

Each behaviour will then provide a list of specific non-functional parameters along with specific requirements such that the Cloud Native nature of the VNF can be satisfactorily established.

5 Non-functional parameters for Cloud-native VNF Classification

From clause 4, the technical content of the deliverable shall be inserted. Each clause shall have a title which shall be placed after its number separated by a tab.

A clause can have numbered subdivisions, e.g. 5.1, 5.2, 5.1.1, 5.1.2, etc. This process of subdivisions may be continued as far as the sixth heading level (e.g. 6.5.4.3.2.1).

For numbering issues, see clause 2.12.1 of the EDRs.

Use the Heading style appropriate to its level (see clause 6.1, table 8 of the EDRs).

Separate the number of the heading and the text of the heading with a tab.

Treat clause titles as normal text (i.e. no additional capitalization), but no full stop.

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)11

Release 3

Editor’s Note: the following paragraphs contain a clause per parameter. Those parameters might include security parameters, reliability and resiliency parameters, degree of scale-out, memory footprint, use of accelerators, uonitoring capabilities, abstractions and APIs exposed, etc.

5.1 Resiliency5.1.1 IntroductionThe Cloud Native VNF is responsible for meeting its resiliency goals and must factor in expected availability of the targeted virtualization environment. To comply with the VNF SLA expectations, the VNF design is expected to satisfactorily overcome problem situations such as the following:

Continued working of the VNF in case of a single failure platform problem including potential failures of:

o Hypervisor

o Server

o Datacenter outages

Significant planned downtime for the Network Cloud as the infrastructure goes through hardware and software upgrades.

Rapidly respond to the changing conditions of the underlying infrastructure.

A number of software resiliency characteristics are considered here to increase the resiliency of Cloud Native VNFs. As VNFs are deployed into the Network Cloud, resiliency must be designed into the VNF software to provide high availability versus relying on the Network Cloud to achieve that end. These characteristics are listed in the following sub-clauses.

5.1.2 RedundancyVNF resiliency can typically be met through redundancy that can be supported by distributed systems architectures. By having more instances of small “micro components”, it is possible to spread the instance out across servers, racks, datacenters, and geographic regions. This level of redundancy can mitigate most failure scenarios and has the potential to provide a service with acceptable availability. Careful consideration of component modularity also minimizes the impact of failures when an instance does fail.

The expectation is that Cloud Native VNFs will be developed with sufficient levels of redundancy such that these VNFs perform in compliance with an operator’s resiliency requirements. From an operator’s perspective, it is critical that the redundancy mechanisms that are built into these VNFs are accurately characterized to assist the operator’s VNF procurement process. VNF redundancy characteristics that need to be accurately described include the following:

Redundancy Model: Active-active, active-standby, N+M redundancy, on-demand redundancy, other. The level of redundancy needs to be specified.

Mode of Recovery: Given appropriate levels of redundancy, is the failover recovery automatic or is manual intervention required.

Performance metrics related to redundancy model:o Time to boot and instantiate standby/on-demand instance (Note the boot time is measured once the

underlying resource is initiated/available)o Expected utilization level of supporting resources (compute/network/storage) for instantiation and at

maximum traffic loads. Note that the allowed maximum traffic load is determined by the VNF software vendor.

Failover Time: The time, once the supporting resources are available, to recover from: o Failure internal to the VNF (e.g., internal memory failure, message queueing failure)o Failure external to the VNF (e.g., VM failure, disk failure). Note that recovery times for this case will

be derived from the VNF vendor’s testing process under a representative range of use cases. Single Point of Failure: If the VNF design includes a single point of failure, then this information should be

made available

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)12

Release 3

Risk Factor: Expected number of impacted connections/sessions/flows/subscribers during any VNF/VNFC failure

Requirement 5.1.2.1: Redundancy characteristics for a Cloud Native VNF shall be accurately stated by the VNF developer to network operators.

Requirement 5.1.2.2: VNFs shall meet their stated resiliency goals, as far as physically possible, and not rely on the Network Cloud

Note: restoring the designed capacity may require interaction with the Network Cloud.

5.1.3 Fault Monitoring and Failure DetectionThe Cloud Native VNF is responsible for accurate monitoring and detection of failures and faults in the VNF and its components. Specifically, the Cloud Native VNF is expected to be equipped with appropriate mechanisms to monitor and support the general operational health of the VNF. This is critical for supporting the implementation of many resiliency patterns essential to the maintenance of the system for the identification of unusual conditions that might indicate failure or the potential for failure. This would contribute to improve Mean Time to Identify (MTTI), Mean Time to Repair (MTTR), and post-incident diagnostics.

Fault Monitoring and Failure Detection characteristics include the following:

Fault Monitoring Metrics: Detailed set of metrics provided by the Fault Monitoring capability that describes the state and health of the VNF

Fault Logging Configuration: Does the logging mechanism capture critical events at an appropriate level of detail

Failure Detection Scheme: The ability to detect appropriate levels of failures at:o VNF/VNFC levelo Intra VNFC connectionso Inter VNF connections

What is the Mean Time to Identify (MTTI) failures

Requirement 5.1.3.1: VNFs shall be equipped with appropriate levels of Fault Monitoring and Failure Detection mechanisms.

Requirement 5.1.3.2: Fault Monitoring and Failure Detection characteristics for a Cloud Native VNF shall be accurately conveyed by the VNF developer to network operators.

5.2 Scaling5.2.1 IntroductionScaling is expected at the VNFC level within a VNF; the scaling mechanism needs to support independent horizontal scaling, by adding/removing VNFC instances, in response to demand loads on that VNFC. The VNF design should be such that its components can scale independently of each other.

[i.3] has defined terminology (Clause 7.2). Also, [i.2] defines different VNF Scaling Models (Clause 5).

- Auto scaling: The VNFM triggers scaling according to the rules in the VNFD.- On-demand scaling: VNF Instance or its EM monitor the states of the VNF Instance's constituent VNFC

Instances and trigger a scaling operation through explicit request to the VNF Manager to add or remove VNFC instances (scale out or scale in, respectively) or increase or decrease resources of one or more VNFC instances (scale up or scale down, respectively).

- Scaling based on a management request: manually or through an OSS

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)13

Release 3

5.2.2 Scale-out/InOne of the benefits of cloud-native design patterns is the ease of scaling a VNF. There are one or several parameters influencing scaling.

1) Scaling triggers: Based on the different scaling triggers defined in [i.2], is the VNF scaling itself (on-demand scaling) or is the expectation that MANO takes care of scaling (auto-scaling using for example NFVO-VNFM: ScaleVnfRequest), or is no scaling possible. There might be a difference between scaling detection and scaling execution.

2) Scaling influencing factor: Based on what is the VNF scaling-out and –in. Or what is the influencing factor a VNF would scale, examples include connections, sessions, flows, subscribers, UEs, others.

3) Maximum ScaleLevel: Is there a maximum scaling level, where scale-out is limited or is the VNF only bound by resource availability.

4) Scale-out and scale-in frequency: How many scaling steps per time is the VNF able to scale-out or scale-in5) Granularity of scaling: In what scaling unit is the scaling steo calculated if any. For examples per what number

of scaling units, a new VNFC instance is instantiated/shutdown. 6) Limiting Resources: What are the limiting resources when scaling infinitely, when there is no maximum

scaleLevel.7) Minimal resource/smallest possible resource for running the VNFC on the minimum scaleLevel8) Scale-In Resource free-up: How quickly are resources given back to the system when scaling-in.

Requirement 5.x: Scale-out characteristics for a Cloud Native VNF shall be accurately conveyed by the VNF developer to network operators.

Editor’s Note: The expectation is that cloud-native VNFs are only scaling in and out (but not up or down), therefore for the moment no further text on Scale-Up and Down is provided.

Editor’s Note: Scaling under different deployment flavours is FFS.

5.3 Cloud Native VNF Design5.3.1 IntroductionThe design of a “Cloud Ready” VNF is critical because the VNF is expected to be agnostic of the resource location in order to leverage capacity where it exists in the Network Cloud. In other words, Cloud Native VNFs can be instantiated in any location that meets the performance and latency requirements of the service.

A key design principle for virtualizing services is the decomposition of the Cloud Native VNF. Decomposition of network functions using NFV concepts into granular functions [i.2] enables instantiating and customizing only essential functions as needed for the service, thereby making service delivery more nimble. It provides flexibility of sizing and also provides flexibility with packaging and deploying VNFs as needed for the service. It enables grouping functions in a common cloud datacenter to minimize inter-component latency.

5.3.2 DecompositionA VNF may be a large construct and therefore when designing it, it is important to think about the components from which it will be composed. A good overview of the architecture of a VNF is provided in [i.2] - see Chapter 4 as well as some good examples of how to compose a VNF in its Annex B. When laying out the components of the VNF it is important to keep in mind the following principles: Single Capability, Independence, State and the APIs. The characteristics associated with these principles are as follows:

Composition of VNF: Individual VNFCs that comprise the VNF and are assumed to each provide a single capability.

Independence of VNFC: Is the VNFC a standalone executable process? Can the VNFC be independently deployed, configured, upgraded, scaled, and monitored, (Editor’s Note: This needs further discussion)

State Management: o Level of state required to facilitate the movement of traffic from one instance of a VNFC to another. o Level of redundancy for storage of required state

API Usage:

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)14

Release 3

o How “open” are the API’s - Conformance of API’s to accepted industry standards (e.g. 3GPP, BBF specifications)

o Ability of API’s to enable access to key functionalityo Underlying Data Model: Is the model open and extensible?o Ability to support versioning of VNFC with preservation of backward compatibility

5.4 Use of Services for VNF Architecture5.4.1 IntroductionOne of the properties of the cloud-native systems is to be microservices oriented to adopt an architecture designed for cloud infrastructure.

The term microservices lacks a common view across the industry, it has been used to describe a way to develop an application as a set of collaborating but independently deployable modules with the smallest size possible.

Although this described concept of microservices present serious drawbacks in developing complex systems for instance regarding the size of the units, the number and the transactions between them, some common beneficial characteristics have been identified when developing services/applications as a set of independent modules:

Automated deployment Independent deployment and management (from other services) Enable elasticity, i.e. to be able to scale, in or out, independently of other services in the same

application. Reduce side effects across collaborating services, e.g. scaling only portions of an application that need the

additional capacity, and being able to update/upgrade portions of the application without impacting users Improve fault isolation: larger applications can remain largely unaffected by the failure of a single module.

Considering the state of the art, the next clauses specify the requirements for VNFs using a service approach, as to take advantage of the beneficial characteristics of using services for building applications whilst limiting the drawbacks that can arise for telecom applications.Additional requirements on the virtualisation requirements of VNF services can be found in clause x.x

5.4.2 VNF architecture requirements[5.4.2.1] A VNF shall be natively developed entirely as composition of atomic units

[5.4.2.2] The atomic units in a VNF shall be deployable and testable independently of other units in the VNF

[5.4.2.3] Each atomic unit in a VNF shall be managed independently of other units in the VNF, i.e. initiated, terminated, scaled out/in, upgraded, updated and healed

[5.4.2.4] The VNF shall enable full automation by interacting with NFVO and VNFM, including recovery of its components, self detecting the triggering events

[5.4.2.5] The atomic units in a VNF shall communicate via lightweight APIs reachable over IP

Editor’s Note: Whether an atomic unit is a VNFC or not is FFS.

Editor’s Note: Whether the NFVO needs to be aware of the composition of the VNF is FFS.

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)15

Release 3

5.5 Zero-touch Management5.5.1 IntroductionThe ultimate goal of cloud-native designs is zero-touch management of functionality. There are several approaches to do that and several components in NFV might be affected through that. This includes the zero-touch installation/configuration and instantiation, self-healing, self-optimizing features including automated resource management.

For self-healing please refer to clause XXX on resiliency.

5.5.2 Automated instantiation and configurationIn order to automatically instantiate a new instance of a NFV Micro-Service it needs a certain degree of configuration. There are several ways to do that. Two of the major options are

1) The VNF/VNFC/ NFV Micro-Service is configured from the outside by a management entity like an EMS/MANO component.

2) The VNF/VNFC/ NFV Micro-Service fetches the required configuration from a configuration store in the environment and has internal provisions internally to do all other types of configuration themselves.

3) Hybrid approaches mixing 1) and 2) are possible as well.

REQ 5.5.2.1: the information about what type of configuration approach is used in an VNF shall be exposed.

REQ 5.5.2.2: In case of a fetch approach from a configuration store in the environment, the VNF information shall expose what type of configuration store including the access method to the configuration store is required in the infrastructure.

5.x.3 Load-balancingThe most common way of automated resource management for cloud-native VNFs is load-balancing between the various instances of VNFCs or NFV Micro Services. [i.x] in clause 5.1.4 is describing different types of load balancing. There is naturally an interplay between automated resource management and scaling (see clause XXX for scaling).

NOTE: Here we only address load balancing as a mean to resource management (it can similarly used as mean to do a certain way of failure handling).

1)  VNF-internal Load Balancer2)  VNF-external Load Balancer3)  End-to-End Load Balancing4) Infrastructure Network Load Balancer

REQ 5.5.3.1: the information about what type of load balancing is applied or is required from the infrastructure shall be information exposed.

5.5.3 Automated Resource ManagementResource Management on the virtualization layer can be done through

1) detailed management and control of resources assigned to VNFs and eventually in the future to VNFCs/NFV Micro-Services or

2) by a resource management relying on increasing the underlying resources early enough to basically have always enough resource available for consumption by the VNFs/VNFCs/Micro Components. The underlying resources can be on-premises physical or virtual or off-premises physical or virtual resources.

REQ 5.3.3.2: the information about the expected resource management model shall be exposed.

For the separation of infrastructure resource management and VNF resource management, the two are logically decomposed and are handled in separate management components or through an infrastructure planning process. Since

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)16

Release 3

NFV infrastructure resource are bound by available physical or virtual reserved resources it is important to understand the growth rate of resource usage in the various resource categories. Therefore, VNF information about the growth rate and based on what unit is an important information for the management and planning process of the physical resource deployments.

REQ 5.3.3.3: the physical resource growth for a VNF shall be given as static information like a growth functions of different input parameters, or a dynamic prediction of future resource requirements exposed by the VNF.

5.x Parameter XEditor’s Note: this is an example structure for a parameter definition. The further development of the documents will show the parameters required.

5.x.1 DescriptionEditor’s Note: a description of the parameter itself

5.x.2 Way of MeasuringEditor’s Note: the section on Way of Measuring is very dependent on the parameter itself and contains a way of measuring quantitative of qualitative the particular parameter.

6 Classification of Cloud-native VNF ImplementationsEditor’s Note: this clause will specify the classification of VNF Implementations to be cloud-native.

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)17

Release 3

Annex <A> (normative or informative):Title of annex (style H8)

<Text>.

<PAGE BREAK>

Annex <B> (normative or informative):Title of annex (style H8)

<B.1> First clause of the annex (style H1)

<B.1.1>First subdivided clause of the annex (style H2)

<Text>.

<PAGE BREAK>

Annex <X> (informative):Authors & contributors (style H8)

The annex entitled "Authors & contributors" is optional. When present it describes the list of persons and companies that contributed to the elaboration of the present Group Specification.

The following people have contributed to this specification:

Rapporteur:Title, Firstname, Lastname, company

Other contributors:Title, Firstname, Lastname, company

Co-Signing Companies: SWISSCOM, TELEFONICA S.A., TELECOM ITALIA S.p.A., VODAFONE Group Plc, Deutsche Telekom AG, CableLabs, Amdocs Software Systems Ltd, ZTE Corporation, AT&T GNS Belgium SPRL, Canonical Group Limited, Huawei

<PAGE BREAK>

Annex <Y> (informative):Bibliography (style H8)

This optional informative clause shall start on a new page and be the last annex of an ETSI deliverable or the last but one if followed by the "Change history/Change request history" annex, if any. The Bibliography shall not contain requirements.

The Bibliography identifies additional reading material not mentioned within the document. Those publications might or might not be publicly available (no check is made by the ETSI Secretariat).

The Bibliography shall include list of standards, books, articles, or other sources on a particular subject which are not referenced in the document.

The Bibliography shall not include references mentioned in the deliverable.

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)18

Release 3

Use Heading 8 style for the "Bibliography" annex, see clause 2.13 for examples.

For the listed material use the Normal style or bulleted lists (e.g. B1+), do not use numbered references.

<Publication>: "<Title>".

OR

<Publication>: "<Title>".

<PAGE BREAK>

Annex <Z> (informative):Change History (style H8)

The informative clause shall start on a new page and be the last annex before the "History" clause. It is an optional, informative element and shall not contain requirements.

If it is desired to keep a detailed record of the changes implemented in a new version it is recommended that this is done by inserting a "Change history/Change request" annex, see clause 2.15.

It shall be presented as a table. Apply the normal style format for tables (see clause 5.2.2 of the EDRs).

Date Version Information about changesMarch 2017 0.0.1 Skeleton

May 2017 0.0.2 Addition of contributions NFVEVE(17)000090r3, NFVEVE(17)000103r4, FVEVE(17)000119r1

June 6, 2017 0.0.3 Addition of contribution NFVEVE(17)000123r2June 15, 2017 0.0.4 Addition of contribution NFVEVE(17)000111 and NFVEVE(17)000115r2

<PAGE BREAK>

HistoryThis unnumbered clause shall start on a new page and be the last clause of an ETSI deliverable. It is a required informative element and shall not contain requirements.

The "History" identifies the major milestones in the life of an ETSI deliverable through the means of a table. The history box shall be provided by the ETSI Secretariat (all additional information will be removed at the publication stage).

Document history

<Version> <Date> <Milestone>

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)19

Release 3

A few examples:

Document history

V0.0.1 March 2017 Early Draft

Latest changes made on 2016-05-20

ETSI

ETSI GS NVF-EVE 011 V0.0.4 (2017-06)20