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.8 (2017-12)

Network Functions Virtualisation (NFV);Virtualised Network Function;

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

ETSI

GROUP SPECIFICATION

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)2

Release 3

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

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 for VNFs with high resiliency expectations............................................................................125.1.3 Redundancy for VNFs with low resiliency expectations.............................................................................125.1.4 Monitoring and Failure Detection................................................................................................................135.1.5 Healing.........................................................................................................................................................135.1.6 Requirements...............................................................................................................................................135.2 Scaling...............................................................................................................................................................5.2.2 Scale-out/In..................................................................................................................................................155.2.3 Scaling in different dimensions....................................................................................................................155.2.4 Scaling on NS level .....................................................................................................................................165.2.5 Requirements ..............................................................................................................................................165.3.2 Cloud Native VNF Composition..................................................................................................................175.3.3 Requirements...............................................................................................................................................175.4 VNF design for location independence.............................................................................................................5.4.1 Introduction..................................................................................................................................................175.4.2 Location Independence................................................................................................................................175.4.3 Requirements...............................................................................................................................................175.5 VNF state handling............................................................................................................................................5.5.1 Introduction..................................................................................................................................................185.5.2 State Management:.......................................................................................................................................185.5.3 Requirements...............................................................................................................................................18

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)3

Release 3

5.6 VNF design for open APIs................................................................................................................................5.6.1 Introduction..................................................................................................................................................185.6.2 Open APIs....................................................................................................................................................185.6.3 Requirements...............................................................................................................................................195.7 Use of Services for VNF Architecture..............................................................................................................5.7.1 Introduction..................................................................................................................................................195.7.2 Requirements...............................................................................................................................................205.8 Use of OS-containers.........................................................................................................................................5.8.1 Introduction..................................................................................................................................................205.8.2 Requirements...............................................................................................................................................205.9 Zero-touch Management....................................................................................................................................5.9.1 Introduction..................................................................................................................................................205.9.2 Automated configuration.............................................................................................................................215.9.3 Automated Resource Management..............................................................................................................215.9.4 Requirements...............................................................................................................................................215.10 Load-balancing..................................................................................................................................................5.10.1 Introduction..................................................................................................................................................225.10.2 Requirements...............................................................................................................................................225.x Parameter X.......................................................................................................................................................5.x.1 Description.........................................................................................................................................................5.x.2 Way of Measuring.............................................................................................................................................

6 Classification of Cloud-native VNF Implementations...........................................................................6.1 Introduction.......................................................................................................................................................6.2 Cloud Native VNF Characteristics and Their Classifications...........................................................................6.3 Cloud Native VNF Product Characteristic Descriptor......................................................................................6.4 Cloud Native VNF Package..............................................................................................................................6.4.1 Cloud Native VNF capacity profile.............................................................................................................256.4.2 Cloud Native VNF operational profile.........................................................................................................256.4.3 Requirements...............................................................................................................................................25

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

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

<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)...................................................................26

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

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

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

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)4

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.8 (2017-12)5

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.8 (2017-12)6

Release 3

1 ScopeThe present document specifies 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. The present document contains 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 referencesReferences 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.

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>".

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)7

Release 3

[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.

[i.4] ETSI GS NFV IFA029, Network Functions Virtualisation (NFV); Software Architecture;Report on the Enhancements of the NFV architecture towards “Cloud-native” and "PaaS", Release 3

[i.5] “Network Function Virtualization: An Introduction, Benefits, Enablers, Challenges & Call for action”, Oct 22-24, 2012, AT&T et al. available at: https://portal.etsi.org/NFV/NFV_White_Paper.pdf

[i.6] ETSI GS NFV-REL 003 V1.1.2, Network Functions Virtualisation (NFV); Reliability; Report on Models and Features for End-to-End Reliability

[i.7] ETSI GS NFV-REL 001 V1.1.1, Network Functions Virtualisation (NFV); Resiliency Requirements

[i.8] ETSI GS NFV 002 v1.1.1, Network functions virtualization (NFV); Architectural Framework”, 2013-10.

[i.9] NIST, “The NIST Definition of Cloud Computing” NIST Special Pub. 800-145 2011-10.

[i.10] ETSI GS NFV 003 v1.2.5, Network Functions Virtualisation (NFV); Terminology for Main Concepts in NFV, 2017-11.

[i.11] ETSI GS NFV-EVE 004 v1.1.1, Network Functions Virtualisation (NFV); Virtualisation Technologies; Report on the application of Different Virtualisation Technologies in the NFV Framework, 2016-03.

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.

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)8

Release 3

<defined term>: <definition>EXAMPLE: text used to clarify abstract rules by applying them literallyNOTE: This may contain additional information.

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.8 (2017-12)9

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 Virtualised Network Functions (VNF) as part of their configuration and deployment in “the Cloud”. Such VNFs are assumed to be implemented using generic cloud techniques beyond virtualization [i.1]. For example, the VNFs can 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. Cloud environment can be implemented based on hypervisor/VM or container technology. This is an indication of the “readiness” of VNFs to perform as expected in the Cloud. The objective of the present 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 help operators in their VNF selection process. To do this, it is essential that a set of non-functional parametric characterisations 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 VNFC redundancy within the VNF; this would be an indication as to the readiness by which failover from a failed VNFC instance to a standby VNFC instance can be gracefully done without intervention by the operator.

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 are 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

Editor’s Note: Either remove the bullet or add a chapter on the topic, and add bullets for the chapters we have..

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

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)10

Release 3

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.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 Introduction

One of the benefits expected from NFV is the option to repair service failures through automated reconfiguration of the service to move traffic loads to new VNFC software instances [i.5]. VNFCs are essentially components of applications deployed via cloud computing. The cloud computing paradigm [i.6] treats all applications as replaceable commodity units using the same mechanisms (e.g. create new instance and transfer load). In this paradigm, operation of the system is expected to continue despite the presence of failures. Some cloud operating environments continually exercise failover mechanisms during normal operations [i.7]. In such an environment, a Cloud Native VNF contributes to the resiliency of the network services. The high resiliency mechanisms are internal to the VNF itself; alternately the NS provides the mechanisms such that complete VNFs can be replaced quickly without negative effects on the NS’s resiliency.

The resiliency of a VNF is impacted by characteristics such as the level of separation of logic and state as well as the use of accelerators. A Cloud Native VNF is responsible for meeting its resiliency goals, taking into account the expected availability of the targeted virtualization environment. To comply with the VNF resiliency expectations, the VNF design is expected to satisfactorily overcome problem situations such as the following:

Resource outage caused by a single failure platform problem including potential failures of:

o Hypervisor or other components of the virtualisation layer

o Compute resources

o Storage (outage or inaccessibility with or without data loss)

o Connections (inter or intra VNF)

Other outage situations would include multiple failures or outage of complete NFVI POP

Significant planned downtime for NFVI PoP or parts of it as the infrastructure goes through hardware and software upgrades.

Editor’s Note: Downtime of MANO services need further study.

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)11

Release 3

A number of software resiliency characteristics are considered here to demonstrate how cloud native VNFs can achieve their resiliency expectations.

VNFs with high resiliency expectations implemented using internal mechanisms, VNFs with low resiliency expectations are covered by external mechanisms, but need to

support those mechanisms by providing certain information

NOTE: VNFs with low resiliency guarantee may still implement internal mechanisms e.g. for redundancy, but in their case e.g. a VNF internal single point of failure can be easier accepted because they can rely on external mechanisms in some situations.

NOTE2: In some cases, both internal and external mechanisms for service recovery might be in place. Typically external mechanisms will only be triggered if the VNF fails, which in this case mean the failure could not be recovered by internal mechanisms. In this respect, the description of VNFs with high or low resiliency expectations cannot really classify the cloud native VNF, but rather the implemented mechanisms for service recovery. Nevertheless, this clause uses an outside view on the VNF for the description.

NOTE3: Aspects of geographic redundancy are not covered here, since they don’t classify VNFs.

The main mechanisms and requirements are listed in the following sub-clauses.

5.1.2 Intra-VNF Redundancy

In many cases resiliency is achieved on VNF level through redundancy of VNFCs, by distributed VNF architecture. By having multiple VNFC instances, it is possible to spread the VNFC instances 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 VNFC modularity also minimizes the impact of failures when an instance does fail.

In this case Cloud Native VNFs will be developed with sufficient levels of redundancy such that these VNFs perform in compliance with the resiliency requirements. It is critical that the redundancy mechanisms that are built into these VNFs are suitable to achieve the resiliency required by the service provider. VNF redundancy characteristics that need to be accurately described include the following:

Redundancy Model: Active-active, active-standby, N+M redundancy Failover Time: The mean time between the moment when a failure is detected and until the

service is available again. Single Point of Failure: all Typically VNFs can only meet high resiliency expectations by

providing redundancy for all components, links, etc. If a VNF can meet the resiliency expectations without redundancy on a certain point (e.g. because the failure probability is low enough), this single point of failure needs to be exposed.

Impact of failure: Expected number of connections/sessions/flows/subscribers/etc impacted by common failures, e.g., VNFC/VNF/links failuresNOTE: The impact of failure will vary largely depending on the failure , the load on a VNFC/VNF and the VNF instantiation level.

Details are discussed in REL003 [i.6].

ETSI

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

Release 3

5.1.3 Inter-VNF Redundancy

In these cases, resiliency is achieved on NS level through redundancy of VNFs. Like described on VNFC level above, here also it is possible to spread the VNF instances out across servers, racks, datacenters, and geographic regions. In this model, single VNFs may fail, since all services can quickly be moved to another VNF without violating resiliency expectations of the NS.

In this case Cloud Native VNFs will not implement redundancy internally by duplicating components, but support other functional blocks, e.g. partner VNFs, load balancers, management systems, … to take the necessary actions in case of failures.

These models are also discussed in REL003 [i.6].

Possible mechanisms include:

Health-check protocols e.g. between VNFs or to load balancers. The used protocols and way of decision-making for failovers need to be exposed.

Storage for state data outside the VNF if necessary: Dependency on database or redundant file systems need to be exposed.

As above, failover times and risk factor need to be accurately documented.

In this case the network service need to instantiate multiple instances of these VNFs in the appropriate locations to meet the SLA expectations.

5.1.4 Monitoring and Failure Detection

The Cloud Native VNF is responsible for accurate monitoring and detection of failures and faults affecting 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 network service for the identification of unusual conditions that might indicate failure or the potential for failure.

Monitoring and failure detection characteristics include the following: Monitoring metrics: Detailed set of metrics provided by the monitoring capability that

describes the state and health of the VNF Error logging: 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 VNF connectionso Inter VNF connections

What is the mean time to detect failures Mechanisms to support fault analysis Mechanisms for failure prediction (optional)

5.1.5 Healing

Cloud computing technology allows for several mechanisms for healing.

The redundancy mechanisms described above already provide a certain level of healing. But after a failure has occurred and the service has been recovered by performing some failover (VNFC,

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)13

Release 3

microservice or VNF level), the redundancy is lost (in case of active-standby) or reduced (in case of active-active or N+M). A second subsequent failure in that stage may lead to an outage.REL001 [i.7] describes the two stages with remediation and recovery in detail.

In case the Cloud Native VNF provides internal mechanisms for redundancy, these mechanisms should be supplemented with automated recovery actions. Typically, an automatic recovery action within the resource assigned to the VNF will be tried and the affected resource, if it cannot recover, needs to be replaced by a new resource allocated via the VIM. The resource replacement process needs to be controlled by MANO.

In case of redundancy mechanisms outside the VNF (i.e. after a failure, another VNF takes over the service), typically an automatic repair action (e.g. software recovery) will be tried and a notification is needed about success or failure of the automatic recovery. If the VNF cannot be recovered from the failure, MANO needs to terminate the VNF, free all resources and instantiate a replacement VNF.

5.1.6 Requirements

Requirement 5.1.1: VNFs shall provide the necessary redundancy mechanisms to meet their resiliency expectations.

Requirement 5.1.2: Redundancy characteristics and models for a Cloud Native VNF shall be conveyed by the VNF provider to the service provider.

Requirement 5.1.3: Failover times for intra-VNF redundancy or inter-VNF redundancy shall be conveyed by the VNF provider to the service provider.

NOTE: Since the times will vary for different failure scenarios and load situations, mean times for common failures shall be documented. In case of external mechanisms it should suffice to document the times needed for a VNF to take over a certain load (e.g. number of sessions) from a failed VNF.

Requirement 5.1.4: VNFs shall document the impact of common failures, that is the expected number of impacted connections/sessions/flows/subscribers/etc.

NOTE: Common failures include but are not limited to failures of VNFC, VNF, internal and external links. The impact of failure will vary largely depending on the failure, the load and the instantiation level.

Requirement 5.1.5: VNFs shall expose any single point of failure in their architecture or that may exist caused by VNF configuration.

Requirement 5.1.6: VNFs shall be equipped with mechanisms for monitoring and failure detection to fulfill the resiliency expectations.

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

Requirement 5.1.8: The VNFs shall notify about any problems discovered related to assigned resources (e.g. failing automatic recovery actions), so MANO can trigger resource replacement if necessary.

Editor’s note: It needs to be clarified how VNF information is exposed by whom. E.g. some information the vendor will include in the VNF package.

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)14

Release 3

5.2 Scaling5.2.1 Introduction

The NIST identifies five essential characteristics of cloud computing: on-demand self-service, broad network access, resource pooling, rapid elasticity or expansion, and measured service [i.9]. One of the benefits expected from NFV is the ability for rapidly scaling services up and down [i.5] i.e. rapid elasticity or on-demand / automated deployment of new instances.

It is expected that the VNF supports scaling. There are different mechanisms for scaling. One of the mechanisms is to support scaling by adding/removing VNFC instances, in response to changed demand loads. Another mechanism is to add/remove VNF instances to an NS and share the load between those.A number of VNF characteristics may affect its ability to scale out VNFCs including VNFC deployment constraints (e.g. affinity/anti-affinity rules, use of accelerators and resource requirements).

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

- 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.

The VNF exposes in which way it supports scaling.

5.2.2 Scale-out/In

One of the benefits of cloud-native design patterns is the ease of scaling. It is expected that VNFs support scale-out/in. Scale-up/down is dependent on dynamically changing the performance of assigned resources and not described here or required from VNFs.

1) Scaling triggers:As described in [i.2], scaling can be initiated/triggered in different ways:

a. in case of Auto-scaling by the VNFM. b. in case of on-demand scaling by the VNF itselfc. by a management request

2) Scaling decision: The VNF exposes on which information the decision about scaling is based. Examples include number of connections, sessions, flows, subscribers, UEs, others.

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

4) Minimum Scale Level: Which is the minimum level for scale-in, i.e. the smallest possible VNF deployment?

5) Scale-out and scale-in performance (excluding the NFVI/VIM related performance): a.

How quickly can the VNF take new VNFC instances in service when scaling out?b. How quickly are resources released when scaling in?

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)15

Release 3

6) Granularity of scaling: Which size of scaling steps is possible, e.g. need VNFC instances be added in pairs or groups (e.g. to implement redundancy schemes or account for dependencies)?

7) Limiting Resources: What are the limiting resources when scaling infinitely, when there is no Maximum Scale Level?

The VNF exposes the scaling options, parameters and characteristics.

Editor’s note: It needs to be clarified how VNF information is exposed by whom. E.g. some information the vendor will include in the VNF package.

5.2.3 Scaling in different dimensions

Different load characteristics (e.g. number of connections, sessions, flows, subscribers, UEs, …) will affect the VNFCs differently, so in some traffic situations, only certain VNFC types need to be scaled. This implies certain requirements on the parameters described in the previous section:

Scaling triggers: The scaling trigger needs to specify which VNFCs will be scaled

Scaling decision: Depending on the type of threshold that was crossed different scaling will be triggered

Scaling level etc: There will be separate levels and granularity for the groups of VNFCs that can be scaled independently.

The VNF exposes which VNFCs or groups of VNFCs can be scaled independently including the necessary dependency on traffic characteristics.

Editor’s note: This needs more study.

5.2.4 Scaling on NS level

Also in case of scaling of the NS by adding/removing VNF instances, the VNF needs to provide scaling support:

Scaling decision: The VNF needs to provide load monitoring, for the decision when additional VNF instances are needed or can be stopped.

Scaling level etc: The number of VNF instances sharing the load in a NS is not limited by the VNF implementation.

5.2.5 Requirements

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

Requirement 5.2.2: The VNF shall convey which scaling triggers (Auto-scaling/On-demand/Mgmt-request) it supports

Requirement 5.2.3: The VNF shall convey the types of conditions that trigger scaling.

Requirement 5.2.4: The VNF shall convey which traffic/load information the VNF provides to support a scaling decision outside the VNF instance.

Requirement 5.2.5: The VNF shall convey which groups of VNFCs can be scaled independently, including their relation to traffic/load characteristics.

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)16

Release 3

Requirement 5.2.6: The VNF shall convey the maximum and minimum scaling level, that is maximum and minimum number of VNFCs for each group that can be scaled independently.

Requirement 5.2.7: The VNF shall convey the minimum and maximum size of a scaling step, e.g. number of VNFCs.

Requirement 5.2.8: The VNF shall convey the scaling performance, that is the time needed between two scaling requests, the time needed for smallest scale-out, the time needed to free resources for smallest scale-in.

Requirement 5.2.9: The VNF shall convey the limiting resource when scaling infinitely

Editor’s Note: Scaling under different deployment flavours is FFS.Editor’s Note: It needs to be clarified whether this information will be included in the VNF package.

5.3 Composition5.3.1 Introduction

A key design principle for virtualizing services is the composition of the Cloud Native VNF from modular VNFCs. Composition of virtualized network functions using NFV granular functions [i.2] enables instantiating and deploying only the essential VNFC functions as needed for the service, thereby making service delivery more nimble. It provides flexibility with deploying VNFs as needed for the service. It enables grouping functions in a common cloud datacenter to minimize inter-component latency.

5.3.2 Cloud Native VNF Composition

A VNF can 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 Chapter 4 and Annex B of [i.2]. When designing the components of the VNF it is important to create VNFCs with single capabilities and independence as described below.

Individual VNFCs are assumed to each provide a single capability with a clearly defined scope and functionality. If there are optional features in the VNF it could be preferred to provide them by a separated VNFC. Also redundancy and independent scalability need to be considered.

VNFCs should be designed for independence. Dependencies of VNFCs on each other should be kept to a minimum. The goal is that VNFCs can be independently deployed, configured, upgraded, scaled, monitored, etc.

5.3.3 Requirements

Requirement 5.3.1: Composition characteristics for a Cloud Native VNF shall include details on individual VNFCs and dependencies between VNFCs. These characteristics shall be conveyed by the VNF provider to network operators.

Requirement 5.3.2: The VNFCs comprising the Cloud Native VNF shall perform a single capability.

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)17

Release 3

Requirement 5.3.3: The Cloud Native VNF shall be described in terms of deployment, configuration, scaling, and monitoring.

5.4 VNF design for location independence5.4.1 Introduction

In a Cloud Native VNF, it is expected that VNFC functionality is independent of the resource location. This provides MANO with the capability to allocate the resources in a flexible way as resources are available.In other words, Cloud Native VNFs can be instantiated in any location that meets the performance, latency or regulatory requirements of the network service.

5.4.2 Location Independence

Editor’s Note: More aspects like hardware acceleration, affinity/anti-affinity e.g. for redundancy, location dependency caused by the functionality (e.g. caching of content delivery) need to be discussed here.

5.4.3 Requirements

Editor’s Note: to be added.

5.5 VNF state handling5.5.1 Introduction

In most cloud environments it is preferred to have stateless applications, since the benefits of cloud computing can much easier be achieved. However the nature of telco services leads to VNF’s need of keeping states, reflecting e.g. the current network usage.It is critical for a cloud native design, how the VNF manages the state information that is necessary for its operation.

5.5.2 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 stateo Separation of logic and state

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)18

Release 3

5.5.3 Requirements

Requirement 5.5.1: Cloud Native VNF shall include sufficient levels of state management for facilitating traffic movement between VNFCs as well as sufficient levels of redundant storage for state data.

Requirement 5.5.2: Cloud Native VNFC shall separate logic and state for fast restart of an VNFC instance and for easy scale-out of VNFC instances.

Editor’s note: these requirements need to be revised in the light of the coming description details.

5.6 VNF design for open APIsEditor’s note: It needs further discussion whether this clause is necessary.

5.6.1 Introduction

Editor’s note: tbd.

5.6.2 Open APIs

API Usage: 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.6.3 Requirements

Requirement 5.6.1: API’s associated with the Cloud Native VNF shall conform to industry standards.

5.7 Use of Services for VNF Architecture5.7.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

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)19

Release 3

Independent deployment and management (from other services) Fast deployment times by using technologies like OS-containers. 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.

Possible use of microservices provided by a PaaS (Platform-as-a-Service) implementation, e.g. VNF Common Services or VNF Dedicated Services as defined in IFA029 [i.4]

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.

Container technology is one lightweight and high performance OS-level virtualisation technology, which is expected as execution environment to support atomic units in a Cloud Native VNF. See more details on usage of containers in clause 5.x.

5.7.2 Requirements

Requirement 5.7.1: A VNF shall be natively developed using a microservices oriented architecture.

Requirement 5.7.2: The microservices in a VNF shall be deployable and testable independently of other units in the VNF

Requirement 5.7.3: Each microservice in a VNF shall be managed independently of other units in the VNF, i.e. initiated, terminated, scaled out/in, upgraded, updated and healed

Requirement 5.7.4: The microservices in a VNF shall communicate via lightweight APIs

Requirement 5.7.5: A VNF may be composed of a combination of VNF Dedicated Service and VNF Common Service as definitions given in ETSI GS NFV IFA029 [i.4].

5.8 Use of OS-containers5.8.1 IntroductionIn cloud native environments, OS-containers is a preferred technology for VNFCs, whole VNFs or also subunits of a VNFC. See EVE004 [i.11] Microservices would ideally run in OS-containers.Some VNFs can be provided as single container images and that way be very easily and fast deployed. In other cases the VNF can be structured as a group of containers via its VNFCs, where the VNF may use a container infrastructure service (see IFA029 [i.4]) or manage the containers itself.

Editor’s Note: More content to be provided.

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)20

Release 3

5.8.2 Requirements

Requirement 5.8.1: The microservices of a VNF should be capable to run in a OS-container.

Editor’s Note: The container definition is FFS (check also EVE004).

5.9 Zero-touch Management5.9.1 Introduction

The ultimate goal of cloud-native designs is zero-touch management , e.g,, the application (VNF) should be automatically configured or self-configured where possible. 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 healing please refer to clause 5.1.5 on resiliency.

5.9.2 Automated configuration

When a new instance of a VNF or VNFC is instantiated, it needs a certain degree of configuration. There are several ways to do that. Two of the major options are:

1) The VNF/VNFCis configured from the outside by a management entity like an EM/MANO component.

2) The VNF/VNFC fetches the required configuration from a configuration store and has internal provisions to do all other types of configuration itself.Hybrid approaches mixing 1) and 2) are possible as well.

5.9.3 Automated Resource Management

Resource 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.5.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 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.

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)21

Release 3

REQ 5.5.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.

Editor’s note: This needs further study.

5.9.4 Requirements

Requirement 5.9.1: the information about what type of configuration approach is used in an VNF shall be exposed.Requirement 5.9.2: In case of a fetch approach from a configuration store, the exposed VNF information shall indicate what type of configuration store including the access method to the configuration store is required.

5.10 Load-balancing5.10.1 Introduction

Cloud Native VNFs typically are working in a highly distributed and scaled system. So there will be load balancer systems established distributing the traffic between VNFs or between components (VNFCs, microservices) inside a VNF instance.Typically load balancers need to be adjusted during LCM operations, failure handling/healing (see clause 5.1), scaling operations (see clause 5.2) etc.

Different types of load balancing are described in ETSI GS NFV-SWA 001 [i.2] in clause 5.1.4.Editor’s note: Reference to be provided.

Load balancing needs to be managed on multiple levels/domains: VNF-internal Load Balancer VNF-external Load Balancer End-to-End Load Balancing Infrastructure Network Load Balancer

5.10.2 Requirements

Requirement 5.10.1: The information about the type of load balancing shall be conveyed.

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

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)22

Release 3

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.

6.1 IntroductionClause 5 described a representative set of functionalities and associated requirements that a Cloud Native VNF is expected to provide. Based on these functionalities, the classifications of the Cloud Native VNF characteristics are provided in Clause 6.2. These classifications are critical for network operators as they need to make informed decisions on the acquisition of Cloud Native VNFs and subsequent integration into their networks. The result is a “packaging” of the Cloud Native VNFs that contains these classifications as part of their Life Cycle Management. The VNF Packaging is described in Clause 6.3.

6.2 Cloud Native VNF Characteristics and Their ClassificationsThe Cloud Native VNF requirements developed in Clause 5 generate a set of characteristics that are summarized in this clause along with their classifications.

VNF Classification Characteristics Requirement NotesResiliency - Redundancy

Redundancy Model 5.1.2.1Mode of Recovery 5.1.2.1Performance Metrics 5.1.2.1, 5.1.2.2Failover Time 5.1.2.1, 5.1.2.2Single Point of Failure 5.1.2.1Risk Factor 5.1.2.1

Resiliency – Fault Monitoring and Failure Detection

Fault Monitoring Metrics 5.1.3.1, 5.1.3.2Fault Logging Configuration 5.1.3.1, 5.1.3.2Failure Detection Scheme 5.1.3.1, 5.1.3.2Mean Time to Identify (MTTI) Failure

5.1.3.1, 5.1.3.2

Scaling – In/Out Scaling Triggers 5.xScaling Influencing Factor 5.x

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)23

Release 3

Maximum Scale Level 5.xScaling Frequency 5.xGranularity of Scaling 5.xLimiting Resources 5.xMinimal Resource 5.xScale-In Resource Free-Up 5.x

Design - Decomposition

Composition of VNFIndependence of VNFCState ManagementAPI Usage

VNF Architecture – Use of Services

VNF Atomic Unit 5.4.2.1VNF Atomic Unit Deployment and Testing

5.4.2.2

VNF Atomic Unit Independence

5.4.2.3

VNF Automation 5.4.2.4VNF Communication – Use of Lightweight API’s

5.4.2.5

Zero-Touch Management – Automated Instantiation and Configuration

VNF Configuration Method 5.5.2.1VNF Configuration Fetching Scheme

5.5.2.2

Hybrid Approach 5.5.2.1

Zero-Touch Management – Load Balancing

Internal Load Balancer 5.5.3.1External Load Balancer 5.5.3.1End-to-End Load Balancer 5.5.3.1Infrastructure Network Load Balancer

5.5.3.1

Zero-Touch Management – Automated Resource Management

Detailed Management and Control

5.5.3.2

Increase in Underlying Resources

5.5.3.2

Table 1 – Cloud Native VNF Characteristics and Their Classifications

Editor’s Note: is there a requirements this being machine readableEditor’s Note: Add information on how the descriptor is expected to be used

6.3 Cloud Native VNF Product Characteristic Descriptor A Cloud Platform enables the migration of key software applications to Cloud Infrastructure. Cloud Native VNFs permit these applications to exhibit the necessary behaviours of elasticity, scalability, and self-service. The VNF requirements and characteristics developed in this document serve as a blueprint by which operators can determine how best to select them for their networks. This blueprint can be part of a VNF Package [i.10] or separate to the VNF Package.

Usage of the Cloud Native VNF Product Characteristic Descriptor is as follows:

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)24

Release 3

1. The Cloud native VNF product characteristic descriptor is used by an operator to decide on what VNF to deploy, when the decision is based on non-functional parameters.

2. The descriptor can be used in a VNF market place for a standardized description of the VNF products non-functional characteristics and as such can be checked/searched for automatically.

Requirement 6.3.1: Cloud Native VNF characteristics developed in this document (VNF PCD) shall be included in the VNF Package relating all software elements, configuration information and transition profiles (VNF traffic load limits necessary to trigger scaling up or down) which enable the VNF functionality.

6.4 Cloud Native VNF Package

6.4.1 Cloud Native VNF capacity profile

Since the cloud infrastructure needs some information for planning capacity and eventually for scheduling the various VNFCs a capacity profile is envisioned to be part of the VNF Package. The VNF capacity profile instructs the cloud infrastructure on determining demand (expected input traffic load) and the (scaling operation) instructions it executes at specific demand (trigger) levels. The cloud-native VNF capacity profile includes identification of the input traffic interface and the load metric (packets/ transaction/ sec etc.) and example trigger policies on some standard infrastructure configuration. The capacity profile is given in terms of the overall VNF and in terms of the VNFCs that compose each VNF. See clause 5.x on resource management and clause 5.y on scaling for a variety of capacity oriented parameters.

6.4.2 Cloud Native VNF operational profile

The operational profile includes parameter for operation task like the initial provisioning, recovery parameters, and re-location oriented parameters.

6.4.3 Requirements

Requirement 6.4.1: A cloud-native VNF capacity profile shall be part of the VNF Package and shall contain demand in terms of expected traffic load, the scaling operation at specific demand thresholds.

Requirement 6.4.2: A cloud-native VNF operational profile shall be part of the VNF package to support initial provisioning, elastic re-provisioning, relocation re-provisioning and recovery provisioning. The runtime parameters reconfigurable in those operations shall be identified in the Cloud Native VNF operational profile on a per NFV microservice basis

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)25

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:Marcus Brunner, SwisscomOther contributors:Percy Tarapore, AT&TSusana Sabater, VodafoneCecilia Corbi, Telecom ItaliaLei Zhu, HuaweiAijuan Feng, HuaweiUlrich Kleber, Huawei

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.8 (2017-12)26

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

Sept 14, 2017 0.0.5

Fixed paragraph numbering for some paragraphs, Addition of NFVEVE(17)000234r1_EVE011___Initial_Draft_Text_for_Clause_6.docx, Addition of NFVEVE(17)000227r1 and the according reference [i.4]Addition of NFVEVE(17)000179r2

Nov 30, 2017 0.0.6

Addition of NFVEVE(17)000275_EVE011_Services_on-demand_deploymentPlenary NFV#20 Approved Title ChangeGS EVE011Network Functions Virtualisation (NFV) Release 3;Software ArchitectureVirtualised Network Function;Specification of the Classification of Cloud Native VNF implementations

Dec 15, 2017 0.0.7

Implementation of contributions:NFVEVE(17)000312r4_EVE011_Clause_5_2_ImprovementsNFVEVE(17)000313r2_EVE011_Clause_5_1_ImprovementsNFVEVE(17)000314r2_EVE011_Clause_5_3_ImprovementsNFVEVE(17)000316r2_EVE011_Clause_5_4_ImprovementsNFVEVE(17)000320r2_EVE011_Clause_5_5_ImprovementsNFVEVE(17)000321r2_EVE011_Add_Self_Healing_to_Clause_5_1NFVEVE(17)000322r1_EVE011_Clause_6_3_Cloud_Native_VNF_Product_Characteristic_DeNFVEVE(17)000327r2_EVE011_Changes_to_Clauses_1-4editor action: fixing the reference i.11

Dec 22, 2017 0.0.8

Implementation of contributionsNFVEVE(17)000333_EVE011_Clause_5_1_Introduction_merged_proposalsNFVEVE(17)000334_EVE011_Further_improvements_Clause_5_1

Removed reference i.12 (same docuemtn references twice (updated the reference in the text)

ETSI

ETSI GS NVF-EVE 011 V0.0.8 (2017-12)27

Release 3

<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>

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.8 (2017-12)28