ETSI GR NFV-REL 010 V3.1.1 (2019-06)

Network Functions Virtualisation (NFV) Release 3; Reliability; Report on NFV Resiliency for the Support of Network Slicing

DGR/NFV-REL010

General Information

• Status: Published
• Publication Date: 23-Jun-2019
• Technical Committee: NFV REL - Reliability & Availability
• Current Stage: 12 - Completion
• Due Date: 21-Jun-2019
• Completion Date: 24-Jun-2019

Standards Content (Sample)

GROUP REPORT
Network Functions Virtualisation (NFV) Release 3;
Reliability;
Report on NFV Resiliency for the Support of Network Slicing
Disclaimer
The present document has been produced and approved by the Network Functions Virtualisation (NFV) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR NFV-REL 010 V3.1.1 (2019-06)

Reference
DGR/NFV-REL010
Keywords
network, NFV, resiliency, slicing

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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.

© ETSI 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI GR NFV-REL 010 V3.1.1 (2019-06)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Introduction . 4
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 NFV for supporting network slicing . 8
4.1 Network slicing for providing diverse SLA . 8
4.2 Mapping of NFV and network slicing concepts . 9
4.3 Network services and 3GPP network functions . 10
5 NFV resiliency concerns for network slice design . 12
5.1 General considerations . 12
5.2 NFV NS resiliency for supporting network slices . 13
5.3 Designing network service for certain availability . 14
5.3.1 Overall considerations . 14
5.3.2 Availability of redundant entities . 15
5.3.2.1 Consideration of VNF-internal redundancy . 15
5.3.2.2 Availability estimation for the 1+1 and 1:1 redundancy models . 16
5.3.2.3 Availability estimation for the N+M and N:M redundancy models . 17
5.3.2.4 Availability estimation for single- and dual-homed link redundancy . 18
5.3.3 Analysis of service resiliency configuration examples . 20
5.3.4 Summary of availability design considerations . 21
6 NFV resiliency for composite network service operations . 23
6.1 Scaling and migration . 23
6.1.1 Scaling . 23
6.1.2 Migration . 25
6.2 Restoration . 26
6.3 Resource reallocation . 28
7 NFV software modification and their impacts on network slice resiliency . 32
7.1 Introduction . 32
7.2 VNF software . 33
7.3 NFVI resource software . 33
8 Recommendations . 35
8.1 Design time recommendations . 35
8.2 Run time recommendations . 36
8.3 Software modification recommendations . 37
8.3.1 VNF software . 37
8.3.2 NFVI resource software . 37
Annex A: Authors & contributors . 38
History . 39

ETSI
4 ETSI GR NFV-REL 010 V3.1.1 (2019-06)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Network Functions
Virtualisation (NFV).
Modal verbs terminology
In the present document "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.
Introduction
The present document studies diverse NFV resiliency facets for supporting network slicing. Following a reminder of the
way slicing can be conducted with respect to the NFV framework, several aspects of slicing oriented NFV design are
described, including the design of network services for network slices with availability targets. In support of network
slicing, the following network service operations are discussed:
• scaling, i.e. the dynamic provisioning or deprovisioning of resources granted to VNFs;
• migration, i.e. the move of virtualised resources from one set of physical resources to another;
• restoration following failures if resources are available;
• resource reallocation, i.e. restoration if the desired resources are insufficient.
Modification of VNF software and NFVI resource software and their impact on network slice resiliency are examined.
Recommendations regarding the support of network slicing are finally provided covering:
1) design time;
2) run time;
3) VNF and /NFVI software modification.
ETSI
5 ETSI GR NFV-REL 010 V3.1.1 (2019-06)
It is noteworthy that NFV-MANO resiliency is considered in ETSI GR NFV-REL 007 [i.11], i.e. it is not discussed in
the present document.
ETSI
6 ETSI GR NFV-REL 010 V3.1.1 (2019-06)
1 Scope
The present document reports on the guiding principles of NFV resiliency assurance for the support of network slicing
based on an NFV infrastructure. In order to achieve this objective, it covers all resiliency related operational facets
supporting network slicing. This includes design, scaling, migration, software modification, resource reallocation in
time of scarcity, and restoration following a failure (including failure containment). The present document finally
provides recommendations for building NFV based dependable network slicing.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative 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.
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.
[i.1] Recommendation ITU-R M.2083-0 (2015): "IMT Vision - Framework and overall objectives of
the future development of IMT for 2020 and beyond".
[i.2] ETSI TS 128 530 (V15.0.0) (2018): "5G; Management and orchestration; Concepts, use cases and
requirements (3GPP TS 28.530 version 15.0.0 Release 15)".
[i.3] ETSI GR NFV-EVE 012: "Network Functions Virtualisation (NFV) Release 3; Evolution and
Ecosystem; Report on Network Slicing Support with ETSI NFV Architecture Framework".
[i.4] 3GPP TR 28.801 (V15.1.0) (2018): "Study on management and orchestration of network slicing
for next generation network (Release 15)".
[i.5] ETSI TS 123 501 (V15.5.0) (2019): "5G; System architecture for the 5G system (3GPP TS 23.501
version 15.5.0 Release 15)".
[i.6] 3GPP TS 22.261 (V15.2.0) (2017): "Service requirements for next generation new services and
markets".
[i.7] ETSI GS NFV-REL 001: "Network Functions Virtualisation (NFV); Resiliency Requirements".
[i.8] ETSI GS NFV-REL 003: "Network Functions Virtualisation (NFV); Reliability; Report on Models
and Features for End-to-End Reliability".
[i.9] Network Functions Virtualisation (NFV) - Network Operator Perspectives on NFV priorities for
5G, February 21st, 2017.
NOTE: Available at http://portal.etsi.org/NFV/NFV_White_Paper_5G.pdf.
[i.10] ETSI GS NFV-REL 006: "Network Functions Virtualisation (NFV) Release 3; Reliability;
Maintaining Service Availability and Continuity Upon Software Modification".
[i.11] ETSI GR NFV-REL 007: "Network Functions Virtualisation (NFV); Reliability; Report on the
resilience of NFV-MANO critical capabilities".
ETSI
7 ETSI GR NFV-REL 010 V3.1.1 (2019-06)
[i.12] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS NFV 003 [i.12] and the following apply:
dedicated network service: nested network service which is only part of a single composite network service
N+M: Pool of N+M active resources allowing the failure of M (typically M ≤ N) resources without impacting the
availability of the service capacity of N resources
shared network service: nested network service which is shared by two (or more) composite network services
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS NFV 003 [i.12] and the following apply:
(R)AN (Radio) Access Network
rd
3GPP 3 Generation Partnership Project
th
5G 5 Generation
AF Application Function
AMF Access and Mobility Management Function
AN Access Network
API Application Programming Interface
AUSF Authentication Server Function
CN Core Network
CS Communication Service
CSMF Communication Service Management Function
DC Data Center
DN Data Network
eMBB enhanced Mobile Broadband
IMT International Mobile Telecommunications
IoT Internet of Things
ITU-R International Telcommunication Union - Radiocommunication Sector
MIMO Multiple Inputs, Multiple Outputs
mMTC massive Machine Type Communications
NOMA Non Orthogonal Multiple Access
NSMF Network Slice Management Function
NSS Network Slice Subnet
NSSF Network Slice Selection Function
NSSMF Network Slice Subnet Management Function
OSS Operations Support System
PCF Policy Control Function
RM Redundancy Model
SDN Software Defined Networking
SMF Session Management Function
UDM Unified Data Management
UE User Equipment
UPF User Plane Function
uRLLC ultra Reliable and Low Latency Communications
ETSI
8 ETSI GR NFV-REL 010 V3.1.1 (2019-06)
4 NFV for supporting network slicing
4.1 Network slicing for providing diverse SLA
Although network slicing is not a new feature in the context of 5G systems, its applicability comes to fruition in the
context of the new capabilities enabled by 5G. The 5G technologies can be viewed as disruptive technologies allowing
to go beyond mass market mobile communications which can/will unify extremely diverse applications and use cases
within a single framework. As an enabler for all types of usage in a digital society, e.g. energy, health, media and
entertainment, factories of the future, automotive, these technologies do not focus exclusively on bandwidth increase, as
the previous mobile generations. Instead they are being developed and offered as a universal technology: 5G is
presented as a polymorphous approach capable of handling, from its conception, a variety of needs.
IMT 2020, defined by ITU-R, has listed some usage scenarios covering these needs [i.1]:
• enhanced Mobile Broadband (eMBB), i.e. improved performance and increased user experience, both outdoor
(wide area coverage) and indoor (hotspot) - both scenarios have different requirements, i.e. seamless coverage
and medium to high mobility for the former, high traffic capacity and high user data rate for the latter;
• ultra Reliable and Low Latency Communications (uRLLC), i.e. stringent requirements for capabilities such as
throughput, latency, reliability and availability - the scenarios include critical needs for wireless control of
industrial manufacturing or production processes, remote medical surgery, distribution automation in a smart
grid, transportation safety, etc.;
• massive Machine Type Communications (mMTC), i.e. low volume of data not sensitive to latency transmitted
by a very large number of connected devices - this scenario tackles the exponential increase of low cost and
long battery life objects for IoT.
To address such diverse market segments, the multiservice 5G network will leverage new technologies at the air
interface, e.g. MIMO (Multiple Inputs, Multiple Outputs), NOMA (Non Orthogonal Multiple Access), and new
networking architectures relying on recent paradigms such as NFV (Network Functions Virtualisation) and SDN
(Software Defined Networking). An expectation for the 5G system is to be able to provide optimized support for a
variety of different services with diverse reliability and availability requirements, different traffic loads, and different
end user communities through the use of network slicing. Network slicing uses virtualisation rather than provisioning
dedicated physical networks for each type of usage, e.g. current Long Range network for IoT.
Indeed, the technical requirements for the wide variety of usage scenarios targeted cannot be met simultaneously.
Instead usage classes are defined, each of which is being fulfilled by a network slice. Based on a common physical
infrastructure providing virtualised resources, all slices may comprise one or more subnet slices that cover various
components of the end-to-end network, such as the Access Network (AN) part and the Core Network (CN) part, and are
optimized to fulfill the requirements of the network functions needed to support those use cases.
The current 3GPP vision [i.2] relates each Communication Service (CS), e.g. usage scenario, to a particular network
slice spanning over both the access network and the core network (Figure 4.1). Each slice is made of network slice
subnets composed of network functions (not shown in the figure) which in the present document are assumed to share
the same infrastructure.
, CS , CS ) designed to use three network slices. Each
The illustrative figure shows three communication services (CS1 2 3
of these network slices is composed of dedicated network slice subnets, and/or shared network slice subnets. For
instance, network slice 1 is formed by one dedicated core network slice subnet (NSS_CN ) and one dedicated access
network slice subnet (NSS_AN ). In contrast, network slice 3 is formed by two dedicated network slice subnets
(NSS_CN , NSS_AN ) and one network slice subnet shared with network slice 2 (NSS_AN ).
3 3 2
ETSI
9 ETSI GR NFV-REL 010 V3.1.1 (2019-06)

Figure 4.1: Customized slices for communication services
4.2 Mapping of NFV and network slicing concepts
Network slices and network slice subnets contain 3GPP network functions. If any of these functions is virtualised, the
NFV approach can be utilized. For such cases, the 3GPP slicing concepts were mapped to the NFV concepts in ETSI
GR NFV-EVE 012 [i.3]. A network slice or a network slice subnet can contain other network slice subnets, and their
resources view can be realized via the network service concept in NFV, which also supports a nested network service
hierarchy. Figure 4.2 (extracted from [i.3]) shows the proposed touchpoints between network slices and network
services. This representation shows the relation between network slices, or network slice subnets, and the network
services from a resource-centric standpoint.

Figure 4.2: Network slicing and its counterpart in NFV [i.3]
Although 3GPP SA5 currently favours, in the context of network slicing, a service-based approach to the management
of 3GPP 5G Core systems ETSI TS 128 530 [i.2], i.e. dealing with REST API services instead of management
functional blocks, their previous report 3GPP TR 28.801 [i.4] has defined three management functions:
• Communication Service Management Function (CSMF) used to translate the communication service
requirements to network slice requirements;
ETSI
10 ETSI GR NFV-REL 010 V3.1.1 (2019-06)
• Network Slice Management Function (NSMF) managing/orchestrating network slices, and deriving network
slice subnet requirements from the network slices requirements;
• Network Slice Subnet Management Function (NSSMF) managing/orchestrating network slice subnets.
These management functions can interact with the NFV architecture as shown in Figure 4.3 via the Os-Ma-Nfvo
interface.
Figure 4.3: Network slice management in an NFV framework [i.3]
4.3 Network services and 3GPP network functions
As shown in Figure 4.2, 3GPP network functions are the constituents of network slices or network slice subnets. These
network slices or network slice subnets can in turn be mapped to network services from a resource management
viewpoint. These network services can be made of VNF(s) and can contain PNF(s), together with the Virtual Links
between them, or can be made of nested network service(s) in addition to the VNF(s)/PNF(s) and the Virtual Links for
the connectivity between them.
The 3GPP reference architecture for a 5G core system consists of different 3GPP network functions interacting with
each other through various reference points N [i.5]:
i
• Application Function (AF);
• Access and Mobility Management Function (AMF);
• Authentication Server Function (AUSF);
• Network Slice Selection Function (NSSF);
• Policy Control Function (PCF);
• Session Management Function (SMF);
• Unified Data Management (UDM);
• User Plane Function (UPF);
• etc.
As an example, Figure 4.4 shows the non-roaming 5G system architecture using the reference point representation.
ETSI
11 ETSI GR NFV-REL 010 V3.1.1 (2019-06)
NSSF AUSF N13 UDM
N22 N12 N8 N10
AMF N11 SMF N7 PCF N5 AF
N14 N15
N4
N1 N2
UE (R)AN N3 UPF N6
DN
N9
Figure 4.4: (Non-roaming) 5G system architecture [i.5]
A 5G system can be exposed and managed by using different network slice (or slice subnet) instances, for which the
resources can be managed via NFV network service instances (see clause 4.2). While many models can be used to
support the deployment of 3GPP network functions that are part of a network slice or a network slice subnet, two of the
more complex deployment cases are selected below for analysis from a resiliency perspective:
• a 3GPP network function deployed as a network service instance, which is shared by different slice (slice
subnet) instances. As the NFV-MANO is not aware of how the consumer (e.g. NSMF, NSSMF, OSS) is using
the NS instances, then NFV-MANO does not know if a NS instance is shared or not between either network
slice instances nor by different tenants;
• a 3GPP network function deployed as a network service instance dedicated to a given slice (subnet) instance.
It is noteworthy that a group of 3GPP network functions may be deployed as one VNF. In this case, the VNF resiliency
and availability aspects apply, so it not further analysed in the present document.
The choice between these options is outside of the scope of NFV. NFV-MANO is not aware of the network slice
instances, of network slice subnet instances, nor of the 3GPP network function instances that may be using a network
service as part of their deployment. However, the information on whether a network service is shared or not has an
impact on how NFV-MANO handles resiliency for the network service (e.g. see clause 6.1.1).
Figure 4.5 shows the example of a composite network service 1 (corresponding to a network slice or network slice
subnet) instance with its dedicated network service NS instance and sharing the network service NS instance with a
1 3
network service 2 (corresponding to another network slice or network slice subnet) instance. The latter also includes a
instance.
dedicated network service NS2
It is noteworthy to mention that the concept of shared network service instance is only visible to NFV-MANO in a
nesting configuration. The analysis of the reliability and resiliency aspects in this study focuses then on the scenarios
where nested NS instances are shared between composite NSs.
The NFV-MANO is only aware of the network service instances and their constituents, i.e. NS , NS and NS , i.e. it is
1 2 3
not aware of the network slices (or network slice subnets) using these resources.
NOTE: A top-level composite NS instance can also be shared by multiple network slices (or network slice
subnets). However, this is not visible to NFV-MANO.
ETSI
12 ETSI GR NFV-REL 010 V3.1.1 (2019-06)

Figure 4.5: Composite network service instances with nested shared
and dedicated network service instances
5 NFV resiliency concerns for network slice design
5.1 General considerations
The shared network service NS instance in Figure 4.5 is a single logical entity of the whole 5G system architecture
considered here, and might consist of VNFs/PNFs, virtual links and nested network services. Some constraints are thus
imposed on the deployment, operation and maintenance of this network service instance. The first constraint is about
resiliency. It is critical that the shared network service instance has the resiliency level needed to support each network
slice (subnet) instance which uses it. Note that for the dedicated network services NS and NS instances, their need for
1 2
reliability and availability strongly depends on the usage scenario sketched in clause 4.1. The second constraint is
related to isolation. It needs to be ensured that the performance provided by NS instance for each network slice
satisfies the requirements and does not have negative impact in two different situations:
• the overload of one network slice instance should not impact the performance of the other network slice
instance;
• the failure of one network slice instance should not cause operation anomalies in the other network slice
instance.
If these cannot be guaranteed, then the network service instance should not be shared, but rather different network
service instances (even using same NSD) should be created for each network slice.
NOTE 1: Failure isolation will be discussed in the clause 6.
As an example, Ultra Reliable and Low Latency Communications (uRLLC) requirements for this matter are obviously
more stringent than for those expected for the massive Machine Type Communications (mMTC) scenario.
Actually, the availability values needed by different communication services of uRLLC range between 99,9 % and
99,9999 % according to 3GPP [i.6], i.e. beyond the traditional five 9 s commonly known as carrier grade. In order to
reach such objectives, the supporting network services have to be designed and deployed appropriately, guidelines for
which will be outlined in the following clauses.
The service availability of a network slice is realized by resiliency of its NSs (e.g. use of redundant network functions),
the internal resiliency mechanisms of its network functions (VNFs/PNFs) and the related infrastructure resiliency. The
different requirements of reliability and availability for uRLLC [i.5] imply that appropriate resiliency rules, e.g.
anti-affinity placement for redundant network functions, resiliency class determining resource selection and handling
policies, can be specified for the corresponding network services of uRLLC slices, which then can be deployed and
maintained by the NFV-MANO. Accordingly, the service provider might deploy one (or several) network slice(s) to
support uRLLC services.
NOTE 2: The availability figures have to be understood as applied to the whole 5G system from an end-to-end
standpoint, e.g. from the UE "input" to the UPF "output" in Figure 4.4.
ETSI
13 ETSI GR NFV-REL 010 V3.1.1 (2019-06)
5.2 NFV NS resiliency for supporting network slices
As discussed in clause 4.3, the design of a network slice instance might consist of, for example, shared and dedicated
network service instances. The availability/reliability requirements of network slice instances impose, on the one hand
side, resiliency expectations on the virtualised resources supporting the slice instances; and on the other hand, the
application of appropriate operational rules. Thus, appropriate anti-affinity, scaling policy configuration, reliability of
virtualised resources, etc., have to be considered during the deployment of the network service instances supporting the
creation and operation of network slice instances.
NOTE 1: The present document only considers VNFs resiliency. If the network slice instances comprise PNFs, the
availability/reliability requirements for these PNFs have to be apprehended, according to the related slice
use case, as in a legacy context, e.g. request for "five 9 s" availability.
Accordingly, to meet the availability/reliability requirements of a network slice instance, the supporting network service
instances, made of virtualised/physical network functions (VNFs/PNFs), have to be designed and deployed with the
following considerations:
• creating the proper NS design, e.g. NS deployment flavor by choosing VNFs deployment flavours and
defining VL flavours to set up such NS and VNFs;
• specifying the appropriate reliability class of resources (for compute, storage, networking) for the related
VNFs;
• assign and apply the appropriate policies.
Combinations of these features could be abstracted into resiliency classes targeting given availability/reliability
requirements. For example, an availability expectation of five "9 s" and higher could be represented by resiliency class
"high", an availability expectation of four "9 s" and up to five "9 s" by resiliency class "medium", an availability
expectation below four "9 s" by resiliency class "low".
To minimize the probability of VNFs failure, a protection scheme has to be considered to face unavoidable errors. For
this purpose, depending on the VNFs internal architecture, the selection of VNF deployment flavours needs to be
consistent with the resiliency class requirements expressed for the associated network services. Table 5.1 shows some
potential redundancy options for VNFs deployment. Such choices have to be communicated to the network services
designer by the VNF vendors, e.g. through the VNF documentation. It is noteworthy to mention that, based on the
requirements of the service provider, some redundancy options can be considered as shown in Table 5.1.
Table 5.1: Redundancy options
Level Type Localization
• VNFC: intra-VNF redundancy • 1+1 Active-Active • Local (on-site) redundancy
(i.e. built into the application • 1:1 Active-Standby (with anti-affinity rules)
logic)
• N+M Pool/Cluster • Geo (off-site) redundancy
• VNF: intra-NS redundancy
As for the related virtual links, the redundancy techniques include link aggregation, redundant single-homed or dual-
homed connections, virtual networks providing alternative paths, etc.
NOTE 2: As for redundancy, diversity is another means for building resiliency [i.8], but it might not be reasonable,
mainly for costs constraints, to apply this approach even to the highest resiliency class related VNFs.
Actually, the use of redundant VNFs from different vendors in a NS is an attractive perspective, but may
raise interoperability issues. The application of diversity to the virtualisation layer, e.g. using two
different types of hypervisors, one for active VNFs and the other for standby VNFs in the 1:1 redundancy
type, makes the operations not easy to manage.
As the VNFs resiliency partly depends on the underlying NFVI reliability, equipment of highest reliability would need
to be allocated to the VNFs involved in the creation of network service instances of the highest resiliency class. In
conjunction with the slice management function(s), at deployment, the NFV-MANO thus needs to provision the
pertinent infrastructure means for realizing them.
To illustrate the options presented above for the creation of network service instances of different resiliency, Table 5.2
shows an example of network service configuration for both VNFs architecture and resources allocated to them.
ETSI
14 ETSI GR NFV-REL 010 V3.1.1 (2019-06)
Table 5.2: Examples of network service resiliency configuration
Network Network service VNFs redundancy Link
Storage Compute
service redundancy
Level Type Technique
resource resource
resiliency
reliability reliability
class
High High High VNF and 1+1 Local + Geo Redundant
VNFC redundancy dual-homed
Medium Medium Medium VNF and 1+1 Local + Geo Redundant
VNFC redundancy single-homed
Low Regular Regular VNFC N+M Local Link
redundancy aggregation
If the first composite network service instance (NS I) has to be highly resilient, while the second composite network
service instance (NS I) resiliency is medium, an application of this example to the two composite network services
shown in Figure 4.5 could be the following (Table 5.3).
Table 5.3: Examples of composite network service resiliency configuration
Shared or
Composite Composite NS Shared or dedicated
dedicated NS Characteristics
network service resiliency class network service
resiliency class
NS1 High
NSI High
NS3 High
see Table 5.2
NS3 High
NS2I Medium
NS Medium
5.3 Designing network service for certain availability
5.3.1 Overall considerations
Since a network slice instance is deployed in the NFV environment as a concatenation of one or more Network
Service (NS) instances [i.9], it can be said that the network slice instance availability depends on the availability of
these NS instances, any of which may be a nested instance. Note that if two NS instances are redundant and backing up
each other they can be considered as nested NS instance.
Accordingly, the network slice instance is available when all of the NS instances are available, which can be formulated
as the product of the availability of the individual NS instances ().

= ∗ ∗… ∗ (1)
Since typically an NS instance availability is less than 100 % or <1, the multiplication in equation (1) implies that

at minimum the availability of each NS instance needs to be greater than the target availability of the network slice
> .
instance, i.e.
Each of the NS instances themselves are compositions of VNF instances and nested NS instances. Unfolding the nested
NS instances, the NS instance becomes a concatenation of VNFs, some or all of which might be deployed with
redundant instances, in which case a Redundancy Model (RM) applies.
The VNF instances resulting from the unfolding of the NS instances can be re-grouped into new NS instances in such a
way that it does not change the graph interconnecting the VNF instances, and each new NS instance contains only
instances of a single VNF. E.g. if two instances of the same VNF are in sequence then they will form two NSs each
with one VNF instance. If two instances of a VNF are redundant and are in parallel then they form a single NS with the
two VNF instances related through a RM. Thus, these new simple NS instances consist of possibly redundant instances
of a particular VNF. It can be said that the availability of such an NS instance depends on the availability of the one or
more VNF instances (each with the availability of ) and the availability of the NFVI () on which they are

deployed.
Considering the NFVI and the VNF instances independent, the NS instance availability () is:

= × () (2)
ETSI
15 ETSI GR NFV-REL 010 V3.1.1 (2019-06)
For the calculations, the NFVI can be considered as a whole, or as different subsets of components hosting different
VNF instances. An example of the latter case is, when the NFVI hosting an NS is distributed over different locations
and deployed with heterogeneous resources.
Assumption: For simplicity in equation (2) the NFVI is considered as a whole.
The RM function depends on the redundancy model used with the VNF instances, but in general it can be stated that
≥ . That is, using some redundancy improves the availability of the individual VNF instances,

i.e. > , while using no redundancy =.

Considering equations (1) and (2), to achieve a given availability for a network slice instance (), it can be said that

the availability of all NSs composing the network slice instance has to be greater than the targeted availability for the
network slice instance. That is, > , where indicates the availability of the ith NS of the network slice

instance. Therefore, the conditions > > and >> need to be fulfilled,

indicates the availability of the NFVI on which the ith NS is built and is the availability of the VNF
where
composing it.
In Table 5.2, three different configurations were proposed to achieve different resiliency levels represented by NS
resiliency classes. Each row proposed a selection of NFVI components and redundancy models of the VNFs and VLs to
achieve a given NS resiliency class. However, the above considerations suggest that this approach may not be suitable,
and it is necessary to know the absolute availability value a VNF can provide under ideal conditions. That is, when the
availability is influenced only by the VNF implementation itself without external assistance and without external
hindering, i.e. the interest is in the availability, the VNF can provide on its own without the help of an admin or external
availability management.
With respect to Table 5.2, let consider only two different resiliency classes and define resiliency class "high" with an
availability of equal to or greater than 99,999 % and "low" if the availability is below this. This means that if this
classification is applied individually to the different NFVI resources represented in the columns and if the availability of
each of them is equal to 99,999 % (or A = 0,99999), then they are each considered of the category "high" as the first
row of the table shows. If these different resources are used to compose an NS, then the availability of the resources
needs to be multiplied to calculate the availability of the composed NS. Since all the composing resources have an
availability A = 0,99999 any multiplication will result in an availability lower than A = 0,99999 (e.g. 0,99999 ×
0,99999 = 0,9999800001), which according to the definition falls into the "low" category. The more such resources are
needed for the NS the more the overall availability falls below expected by the "high" category.
Considering the redundancy models as discussed with respect to equation (2), they can improve the availability of the
individual VNF instances which is discussed next. This discussion is based on the considerations in ETSI
GS NFV-REL 003 [i.8].
5.3.2 Availability of redundant entities
5.3.2.1 Consideration of VNF-internal redundancy
For the NFV-MANO, the VNF is a black box with respect to its internal redundancy. The NFV-MANO does not
manage nor is aware of the redundancy applied to the VNFC instances. Instead the NFV-MANO instantiates a VNF
according to the instantiation level of the deployment flavour (DF) selected and for scaling it follows the scale levels
associated with the DF.
The scale levels dictate the number of VNFC instances the NFV-MANO should instantiate for each VNFC. Since
redundancy is reflected in the number of VNFC instances, it is safe to assume that scale levels of a DF of a VNF reflect
the redundancy model used within the VNF for each VNFC. Note that different VNFCs may utilize different
redundancy models within the same VNF and may be scaled differently. It is also possible that a given VNFC is used
with different redundancy models in different DFs of the same VNF and accordingly it may be scaled differently in
different DFs. That is, the scale levels associated with a DF take into consideration both the workload related
performance and the needs of the redundancy model used for each of the VNFCs used in the DF.
ETSI
16 ETSI GR NFV-REL 010 V3.1.1 (2019-06)
Therefore, it is better to know the absolute availability a VNF DF provides than the redundancy model(s) used by that
DF for the different VNFCs. In this respect however, it is expected that the different scale levels of a DF and any
applicable scaling policy in the VNFD are provided in such a way that the availability indicated for the DF, for
example, in the VNF documentation is guaranteed at each scale level of the DF assuming ideal conditions. That is, the
absolute availabil
...