ETSI GS NFV-REL 006 V3.1.1 (2018-02)

Network Functions Virtualisation (NFV) Release 3; Reliability; Maintaining Service Availability and Continuity Upon Software Modification

DGS/NFV-REL006

General Information

• Status: Published
• Publication Date: 12-Feb-2018
• Technical Committee: NFV REL - Reliability & Availability
• Current Stage: 12 - Completion
• Due Date: 21-Feb-2018
• Completion Date: 13-Feb-2018

Standards Content (Sample)

GROUP SPECIFICATION
Network Functions Virtualisation (NFV) Release 3;
Reliability;
Maintaining Service Availability and
Continuity Upon Software Modification
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 GS NFV-REL 006 V3.1.1 (2018-02)

Reference
DGS/NFV-REL006
Keywords
NFV, reliability, software
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 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.

© ETSI 2018.
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
3GPP and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI GS NFV-REL 006 V3.1.1 (2018-02)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 8
4 Overview . 8
5 NFV Software . 9
5.1 Types of NFV Software . 9
5.1.1 Introduction. 9
5.1.2 VNF Domain Software . 10
5.1.3 MANO Domain Software . 10
5.1.4 NFVI Software . 11
5.2 Software Modification Implications . 11
6 Software Modification Process . 12
6.1 Overview . 12
6.2 The Overall Software Modification Process. 12
6.3 Applicability for Software Types . 15
6.3.1 Network Services/VNFs . 15
6.3.1.1 VNF Software Modification Scenarios . 15
6.3.1.2 VNF Software Modification Requirements . 16
6.3.2 Management and Orchestration Software Modification Process . 17
6.3.2.1 Introduction . 17
6.3.2.2 Addition of Management and Orchestration Component - An Overview . 18
6.3.2.3 Critical Assumptions for Reliability . 18
6.3.2.4 Requirements . 19
6.3.3 NFVI Software . 19
6.3.3.1 Introduction . 19
6.3.3.2 Software Modification Precedence . 20
6.3.3.3 Coordination of NFVI Software Modifications . 20
6.3.3.4 NFVI Resource Software Modification . 21
6.3.3.5 NFVI Software Modification Requirements . 22
6.4 Exception Handling of Problems during Software Modification Process . 22
6.5 Test Process - High Level Overview . 24
6.5.1 Introduction. 24
6.5.2 Pre-deployment Testing for VNFs . 25
6.5.3 Pre-deployment Testing for NFVI Elements . 26
Annex A (informative): Analysis of VNF Software Modifications . 28
A.1 Introduction . 28
A.2 Different VNF design and deployment patterns . 28
A.3 Use Case 1: Stateless VNF upgrade . 28
A.4 Use Case 2: Stateful VNF upgrade . 29
A.4.1 Deployment option 1: Stateful VNF with active-standby redundancy . 29
A.4.2 Deployment option 2: Simultaneous operation of the old and new software version instances . 29
A.4.3 Deployment option 3: Stateful VNF with load sharing . 30
A.4.4 Deployment option 4: Stateful VNF with an internal resiliency mechanism . 31
ETSI
4 ETSI GS NFV-REL 006 V3.1.1 (2018-02)
A.5 Use Case 3: VNF software update . 32
A.6 Use Case 4: NS update with simultaneous software upgrade of multiple VNF instances . 33
A.7 Summary . 33
Annex B (informative): Potential solutions for VNF software modification . 35
B.1 Introduction . 35
B.2 Alternative Solutions for Supporting VNF Software Modification with Existing LCM Operations . 35
B.2.1 General . 35
B.2.2 Alternative Method #1 . 35
B.2.3 Alternative Method #2 . 36
B.2.3.1 General . 36
B.2.3.2 Variant A . 36
B.2.3.3 Variant B . 36
B.3 Alternative Solutions for Supporting VNF Software Modification with New LCM Operations . 37
B.3.0 Introduction . 37
B.3.1 Overview of the VNF Instantiation Operation . 38
B.3.2 VNF Software Modification Initiated from the OSS/BSS. 38
B.3.3 VNF Software Modification Initiated from the EM . 43
Annex C (informative): NFVI Software Modification Flows . 45
C.1 Exemplary Coordination of NFVI Software Modifications . 45
C.2 Illustrative Example of NFVI Resource Software Modification . 47
Annex D (informative): Authors & Contributors . 49
History . 50

ETSI
5 ETSI GS NFV-REL 006 V3.1.1 (2018-02)
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 Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Network Functions
Virtualisation (NFV).
Modal verbs terminology
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.
ETSI
6 ETSI GS NFV-REL 006 V3.1.1 (2018-02)
1 Scope
The present document specifies requirements for the purpose of Software Modifications, such that NFV service
availability and continuity is maintained. All types of software related to Network Function Virtualisation (NFV) - e.g.
Virtual Network Functions (VNF), Management and Orchestration (MANO) and Network Function Virtualisation
Infrastructure (NFVI) as well as required controlling and supporting functionality will be addressed. Where applicable,
external specifications may be referenced to avoid duplication of work. The present document contains normative
provisions.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI GS NFV 002 (V1.2.1): "Network Functions Virtualisation (NFV); Architectural
Framework".
[2] ETSI GS NFV-MAN 001 (V1.1.1): "Network Functions Virtualisation (NFV); Management and
Orchestration".
[3] ETSI GS NFV-SWA 001 (V1.1.1): "Network Functions Virtualisation (NFV); Virtual Network
Functions Architecture".
[4] ETSI GS NFV-IFA 011 (V2.1.1): "Network Functions Virtualisation (NFV); Management and
Orchestration; VNF Packaging Specification".
[5] ETSI GS NFV-IFA 013 (V2.1.1): "Network Functions Virtualisation (NFV); Management and
Orchestration; Os-Ma-Nfvo reference point - Interface and Information Model Specification".
[6] ETSI GS NFV-IFA 007 (V2.1.1): "Network Functions Virtualisation (NFV); Management and
Orchestration; Or-Vnfm reference point - Interface and Information Model Specification".
[7] ETSI GS NFV-IFA 005 (V2.1.1): "Network Functions Virtualisation (NFV); Management and
Orchestration; Or-Vi reference point - Interface and Information Model Specification".
[8] ETSI GS NFV-IFA 008 (V2.1.1): "Network Functions Virtualisation (NFV); Management and
Orchestration; Ve-Vnfm reference point - Interface and Information Model Specification".
[9] ETSI GS NFV-SOL 004 (V2.3.1): "Network Functions Virtualisation (NFV) Release 2; Protocols
and Data Models; VNF Package specification".
[10] ETSI GS NFV-SOL 005 (V2.4.1): "Network Functions Virtualisation (NFV) Release 2; Protocols
and Data Models; RESTful protocols specification for the Os-Ma-nfvo Reference Point".
[11] ETSI GS NFV-SOL 003 (V2.3.1): "Network Functions Virtualisation (NFV) Release 2; Protocols
and Data Models; RESTful protocols specification for the Or-Vnfm Reference Point".
ETSI
7 ETSI GS NFV-REL 006 V3.1.1 (2018-02)
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] CRN website: "The 10 Biggest Cloud Outages Of 2013".
NOTE: Available at http://www.crn.com/slide-shows/cloud/240165024/the-10-biggest-cloud-outages-of-
2013.htm.
[i.2] ETSI GR NFV-REL 007 (V1.1.1): "Network Functions Virtualisation (NFV); Reliability; Report
on the resilience of NFV-MANO critical capabilities".
[i.3] ETSI GR NFV-IFA 021 (V0.11.0): "Network Functions Virtualisation (NFV) Release 3;
Management and Orchestration; Report on management of NFV-MANO and automated
deployment of EM and other OSS functions".
[i.4] ETSI GS NFV-TST 001 (V1.1.1): "Network Functions Virtualisation (NFV); Pre-deployment
Testing; Report on Validation of NFV Environments and Services".
[i.5] ETSI GS NFV 001 (V1.1.1): "Network Functions Virtualisation (NFV); Use Cases".
[i.6] Iulian Meamtiu and Tudor Dumistras: "Cloud Software Upgrades: Challenges and Opportunities",
IEEE conferenceInternational Workshop on the Maintenance and Evolution of Service-Oriented
and Cloud-Based Systems (MESOCA), 2011.
NOTE: Available at https://www.umiacs.umd.edu/~tdumitra/papers/MESOCA-2011.pdf.
[i.7] ETSI GS NFV-IFA 018: "Network Functions Virtualisation (NFV); Acceleration Technologies;
Network Acceleration Interface Specification".
[i.8] ETSI GS NFV-REL 003 (V1.1.2): "Network Functions Virtualisation (NFV); Reliability; Report
on Models and Features for End-to-End Reliability".
[i.9] ETSI GR NFV-TST 006 (V0.0.8): "Network Functions Virtualisation (NFV); Testing; Report on
NFV CICD and Devops".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
software rollback: software modification process that reverts the system from the newly deployed software version to
the previously deployed software version
software update: software modification process for bug fixes or enhancements without adding, modifying or removing
functionality, interfaces or protocols
software upgrade: software modification process aimed at adding, modifying or removing functionality, interfaces or
protocols
ETSI
8 ETSI GS NFV-REL 006 V3.1.1 (2018-02)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
BSS Business Support System
CompHost Compute Host
DF Deployment Flavor
DUT Devices Under Test
EM Element Manager
EMS Element Management System
EPC Evolved Packet Core
FUT Functions Under Test
IE Information Element
IMS IP Multimedia System
KPI Key Performance Indicator
LCM Life Cycle Management
MANO Management and Orchestration
NAT Network Address Translation
NFV TST ETSI NFV Test Working Group
NFV Network Function Virtualisation
NFVI NFV Infrastructure
NFVO NFV orchestrator
NS Network Service
NSD Network Service Descriptor
O&M Operation and Maintenance
OS Operating System
OSS Operations Support System
PNF Physical Network Function
SDN Software defined Network
SUT System Under Test
VIM Virtualised Infrastructure Manager
VNF Virtual Network Function
VNFC VNF Component
VNFD VNF Descriptor
VNFFG VNF Forwarding Graph
VNFM VNF Manager
VPN Virtual Private Network
VR Virtualised Resource
4 Overview
The intent of the present document is to specify requirements for the purpose of Software Modifications, such that
service availability and continuity in an NFV environment are maintained. All types of software related to NFV (e.g.
VNFs, MANO and NFVI) are considered for the software modification process; in addition, required controlling and
supporting functionality is addressed. Where applicable, external specifications may be referenced to avoid duplication
of work.
It should be noted that supporting work on the test processes for Software Modification is addressed by the ETSI NFV
Test Working Group (NFV TST). As appropriate, references to the TST work and/or brief descriptions of the developed
test processes are provided. An overview of the overall document framework is as follows.
Software related to NFV may be of different types. Clause 5.1 refers to the three working domains identified for NFV in
previous work [1] and associates specific software types to these domains. The purpose for delineating these individual
software types is to align specific processes or methods that may apply to the modification of each type of software as
well as the corresponding requirements to support such processes. The software types are as follows:
• Clause 5.1.2 - VNFs that support the full range of Network Services and Applications: note that components
comprising a VNF are referred to as VNF Components (VNFC). Thus modifications may be done for
individual VNFCs or VNFs. VNF Descriptors and Attributes are included as appropriate.
• Clause 5.1.3 - MANO Software: Software components that provide MANO functionality.
ETSI
9 ETSI GS NFV-REL 006 V3.1.1 (2018-02)
• Clause 5.1.4 - NFVI Software: Software components that support NFV Infrastructure.
Software Updates and Upgrades have been defined for VNFs as follows [3]:
• A VNF update does not introduce new functionality and/or new interfaces.
• A VNF upgrade might introduce new functionality and/or new interfaces.
Detailed definitions for these terms indicating precise intent for these actions are provided in clause 3.1. Note that they
apply to VNFs, NFVI, and MANO software components.
Software modification implications are presented in clause 5.2.
The methods by which modifications are instituted are as follows:
• "NetOps" or Network Operations - This method involves significant manual involvement throughout the
modification process followed by substantial levels of testing by the Network Operator. Typically, this method
could be instituted when major changes in software are involved with careful management of resource
utilization. Additionally, it is expected that major changes will not be very frequent; this may allow for a
carefully planned modification and testing process.
• "DevOps" or Development Operations - This method is fully automated end-to-end. The magnitude of changes
is expected to be small for each new version and allows for automated testing throughout the process delivery
cycle. It is also expected that such changes could be fairly frequent (e.g. multiple changes on a daily basis).
The DevOps method is out of scope for the present document.
Clause 6 is structured as follows
• Clause 6.1: This clause provides an overview and introduces the phases of the software modification process.
• Clause 6.2: This clause describes the overall software modification process.
• Clause 6.3: Software Modification Requirements. This clause provides detailed normative requirements for
modification of VNFs, MANO components, and NFVI components.
• Clause 6.4: Rollback of Software Modifications. This clause provides requirements on how to deal with
problem situations associated with the software modification process.
• Clause 6.5: Test Process Implications. The test processes developed in the ETSI NFV TST Working Group are
referenced and briefly described as applicable.
Additional information that is relevant for the software modification process is provided in informative annexes A, B
and C.
5 NFV Software
5.1 Types of NFV Software
5.1.1 Introduction
The types of NFV Software that are in scope for the software modification process are described in ETSI
GS NFV 002 [1], clause 5.2 as follows:
"Network Functions Virtualisation" envisages the implementation of NFs as software-only entities that run over the
NFV Infrastructure (NFVI). Figure 1 illustrates the high-level NFV framework. As such, three main working
domains are identified in NFV:
• Virtualised Network Function, as the software implementation of a network function which is capable of
running over the NFVI.
• NFV Infrastructure (NFVI), including the diversity of physical resources and how these can be virtualised.
NFVI supports the execution of the VNFs.
ETSI
10 ETSI GS NFV-REL 006 V3.1.1 (2018-02)
• NFV Management and Orchestration, which covers the orchestration and lifecycle management of physical
and/or software resources that support the infrastructure virtualisation, and the lifecycle management of VNFs.
NFV Management and Orchestration focuses on all virtualisation-specific management tasks necessary in the
NFV framework.
Figure 1 from clause 5.2 of ETSI GS NFV 002 [1] depicts the three working domains; this is shown below. The VNF
domain is supported by the NFVI domain and both of these domains are managed by the MANO domain.

Figure 1: High Level NFV Framework as shown in clause 5.2 of ETSI GS NFV 002 [1]
The software in scope for the present document relates to these three domains.
5.1.2 VNF Domain Software
There are two types of VNF domain software:
1) Individual VNFs: Virtualised network functions that perform a given network task. Examples of individual
VNFs include:
a) Network Address Translation (NAT)
b) Firewall
c) Load Balancer
2) Network Services: An end-to-end Network Service is defined in ETSI GS NFV 002 [1] as a Forwarding Graph
(FG) of the necessary Network Functions that support the desired service. This FG of Network Functions can
include a combination of Physical Network Functions (PNF) as well as VNFs. From the perspective of the
present document, only the portion of the FG that contains VNFs is in scope. Examples of services include the
following:
a) Mobile Voice/Data
b) Internet Access
c) Virtual Private Network (VPN)
5.1.3 MANO Domain Software
MANO domain software support the three MANO Functional Blocks in ETSI GS NFV-MAN 001[2]:
1) VNF Manager (VNFM).
ETSI
11 ETSI GS NFV-REL 006 V3.1.1 (2018-02)
2) Virtualised Infrastructure Manager (VIM).
3) NFV Orchestrator (NFVO).
It is assumed that the software for these Functional Blocks will need to be modified in their entirety; at the moment
there is no breakdown available for splitting these blocks into smaller components.
5.1.4 NFVI Software
NFVI Software comprises the set of software that support all VNFs and Network Services. Examples of NFVI Software
include:
• Operating System (OS),
• Hypervisor,
• Network Controller Software.
It is assumed that each of these software systems will need to be modified in their entirety unless individual software
vendors create the software as a package of components.
5.2 Software Modification Implications
Network services do need to provide a defined level of availability. It is expected that service availability and service
continuity will be maintained while modifying the software of any part of the NFV system. In DevOps environments in
ETSI GR NFV-TST 006 [i.9], updates without functional changes may occur frequently and are deployed
automatically. Therefore, the NFV system is expected to guarantee service continuity during software modifications at
any time.
Especially when functional changes are introduced, the question of compatibility arises, e.g. data structure
compatibility, internal and external interface compatibility, software functional compatibility, etc. In case of any
incompatibility, the software modification needs to be carried out via upgrade procedures and different categories of
incompatibilities need to be considered:
• Incompatibilities may arise among the entities to be modified for the duration of the software modification
process, e.g. data structure incompatibility, internal interface incompatibility.
• As a result of software changes, incompatibilities may also occur between the modified entities and the rest of
the system or the users of the modified entities, e.g. external interface incompatibility, software functional
incompatibility.
The first category creates a reliability threat and needs to be considered in the solution design and resolved during the
software modification process. The latter category cannot be resolved purely by the software modification process and
the impact would become unavoidable for the environment and the users after the modifications if it was not considered
in the software design. In order to avoid the outage from the latter category, the modified software needs to be
backward compatible in external interfaces and software functions.
Incompatibilities may occur due to changes in the data structure, in the interfaces, their combinations, or even without
interface and/or data structure changes due to behavioural changes. These changes need to be clearly indicated so that
they can be taken into account in the design, planning and scheduling of the software modification process.
Even if data structures are changed in an incompatible manner, it is expected that the service continuity during the
modification process will not be affected. This cannot be handled as an update. Instead an upgrade procedure has to be
used to accomplish the software modification. It needs to be clearly indicated, if during the upgrade the reliability of
network services is reduced. If so, then this upgrade can be scheduled at a proper time when the impact of reduced
availability is (more) acceptable.
In addition, the software modification (e.g. upgrade) mechanism is expected to be implemented in such a way that the
mechanism itself does not reduce the reliability of the running services.
ETSI
12 ETSI GS NFV-REL 006 V3.1.1 (2018-02)
6 Software Modification Process
6.1 Overview
The software modification process which is part of the overall Life Cycle Management process needs to consider the
following tasks: downloading the new software to the network operator's domain, pre-deployment testing of the
software in the network operator's lab environment, on-boarding the new software into the NFV system, preparing the
deployment plans and any other prerequisite necessary for the software modification, deploying the new software, and
the application of post-deployment field testing and follow up actions. These tasks can be grouped into two main
phases:
• Software modification preparation phase: This phase includes:
- the initial software download which is an interaction between the software vendor and the network
operator for the purpose of software delivery to the network operator's domain;
- testing the new software version in the network operator's lab environment;
- on-boarding the new software into NFV system;
- preparing the deployment plans and any other prerequisite necessary to carry out the software
modification.
• Software deployment phase: This phase deploys the new software in the live NFV system. This means the
instantiation of entities with the new software version to replace entities of the old software version. The
switch over process may migrate the services to the new software instances gradually to ensure service
continuity and/or to allow for post-deployment field testing and verification. To complete the software
modification process follow up actions may be required as well as handling any failures that may occur in the
process.
Further details on the overall software modification process are given in clause 6.2 while clause 6.3 elaborates on the
software deployment phase for the different types of NFV software:
• Clause 6.3.1 - VNF software
• Clause 6.3.2 - Software related to NFV management and orchestration
• Clause 6.3.3 - NFVI software
Clause 6.4 discusses the considerations for handling failures during the software modification process and clause 6.5
provides a high-level overview of the pre-deployment testing process.
6.2 The Overall Software Modification Process
A high-level overview of the software modification process between the Software Vendor and Network Operator is as
follows:
1) Software Vendor:
a) New Software Version is complete.
b) Vendor performs software version control testing that certifies accuracy and performance of the
modified version.
c) Vendor signals to Network Operator(s) about impending software update/upgrade delivery.
ETSI
13 ETSI GS NFV-REL 006 V3.1.1 (2018-02)
2) Network Operator:
a) Receives information of impending delivery of modified software:
Type of Software includes:
- VNF Software.
- NFVI Software.
- Management and Orchestration Software.
Criticality of Modification:
- Urgent: Critical bug fix; may require accelerated/instantaneous testing process followed by
possible migration of existing traffic flows from old version to new version.
- Normal: Can follow scheduled testing process with minimized level of migration of existing
traffic flows.
b) Network Operator and Software Vendor engage in software download processes.
Secure delivery of software from Software Vendor to Network Operator with following
dependencies:
- Protocol(s) used for download process.
- Security of download (e.g. image authenticity).
Network Operator informs Software Vendor of receipt of software.
c) Network Operator tests integration and performance of the new software in Lab.
Type of testing:
- Urgent.
- Normal.
Testing Phase:
- Integration testing.
- Test performance metrics.
- Result of test:- certified or failed.
Network Operator informs Software Vendor if pre-deployment testing failed otherwise proceeds to
onboard the new software.
d) On boarding the new software.
For VNF software the VNF package which includes its VNFD is on-boarded into NFV MANO
system according to the related NFV specifications using the standard VNF package management
operations.
For MANO software if it is implemented as a VNF and delivered as VNF package, the on boarding
is the same as for VNF software. Otherwise, the on-boarding procedure is MANO system or
functional block specific.
For NFVI software, the new software is on-boarded by the NFVI software management system
which is not in the scope of NFV specification currently.
ETSI
14 ETSI GS NFV-REL 006 V3.1.1 (2018-02)
e) Planning of software deployment and verification of all prerequisites.
Verifying the availability of resources, their configuration at the target deployment location(s)
based on the following information:
- Physical locations of the existing version of the software.
- Available server capacity at physical locations in a global view (new version may or may not
be installed at the location of existing software).
- Processor capabilities at available servers (e.g. modified software may require same type of
processor as existing software.
Scheduling the software modification.
Preparation of the software deployment plan, which includes:
- The polices and strategies for the execution of the software modification.
- Post-deployment testing and monitoring procedures to verify in-situ deployed instances of
the new software.
- The strategies for handling exception conditions, which may arise during the execution of the
software modification or if post-deployment test procedure fails.
Backup the necessary data and configurations of the currently running software.
3) Network Operator.
a) Deploys the new software according to the deployment plan prepared for the software modification:
Software modification operations are initiated and post-deployment test and monitoring procedures
are applied. The software modification operations depend on the type of the delivered software and
they are discussed in the subsequent clauses.
Service migration might follow different strategies, e.g. gradual migration during which the old and
new software might provide services simultaneously.
Post-deployment test and monitoring results on deployed instances might be evaluated periodically.
If successful, the deployment of the new software continues until complete deployment at which
point the old version is deactivated or removed as appropriate.
In case of an exception during software deployment, if any post-deployment test procedure fails, or
the monitored results are not satisfactory the modified software is removed from service according
to the exception handling plans and old software continues to be used. More discussion will be in
clause 6.4.
b) After the new software is deployed into the field, the Network Operator may monitor the software
performance for some time (e.g. capacity in different traffic load) before the product certification results
are submitted to the Software Vendor.
4) Software Vendor - Follow Up Action.
a) Product certification is issued - Success:
The contracted performance requirements are fulfilled.
No immediate action is required.
Test results are examined for potential improvement of the software.
b) Product certification is not issued - Failure:
The contracted performance requirements are not fulfilled.
Rollback is initiated due to the final performance results of the monitored software.
ETSI
15 ETSI GS NFV-REL 006 V3.1.1 (2018-02)
Test results are examined to determine cause of software fault/malfunction.
Errors/bugs are fixed in the software.
c) Process cycle is repeated from Step 1.
6.3 Applicability for Software Types
6.3.1 Network Services/VNFs
6.3.1.1 VNF Software Modification Scenarios
It is expected that the download process between the software vendor and the network operator will be carried out by
the network operator's Operations Support System/Element Management System (OSS/EMS). When the network
operator has approved the new VNF software package for operating in NFV networks (after lab testing), on-boarding
VNF packages into the network can be done via the management systems directly or via the operator's NFV
Management and Orchestration System such as MANO. For the latter case, VNF packaging principles and a set of VNF
Package management operations have been specified as follows:
• Principles of new software packages prior to release [4] and [9]:
- The VNF Package contents, including the VNF descriptor, VNF binaries, configuration, scripts and
software images, as well as manifest file, checksum, etc. as appropriate constitutes a single delivery unit
from a distribution perspective.
- Any changes to the constituency of this unit shall be considered as a change to the whole which shall be
versioned, tracked and inventoried.
• On-boarding a VNF package to NFVO via the interface between OSS/BSS and NFVO [5] and [10].
• Adding images of a VNF package to the image repository managed by the VIM via the interface between
NFVO and VIM [7].
• Subscription to and notification of on-boarding a VNF package, and fetching of VNF package/VNF package
artefacts by VNFM via the interface between NFVO and VNFM [6] and [11].
A representative set of software modification scenarios are considered to ensure that service availability and continuity
expectations are satisfactorily met:
1) Software Modification Via Network Operator's Management System: This scenario involves the
onboarding of the new VNF packages directly by the OSS/BSS systems of the network operator and the
initiation of the VNF software modification by the OSS/BSS or EM systems. The EM is the only VNF-aware
sub-system capable of handling any VNF-specific coordination and management that may be required during
the VNF software modification to ensure service availability and continuity.
2) Software Modification for Different VNF Types: As defined in clause 4, VNFs can be modified via
software updates (minor changes) or as software upgrades (major changes). In case of software update, the
VNF software modification operation is performed on an existing instance. However software upgrades often
require the instantiation of new instances depending on the applicable method of upgrade.
3) VNFC Software Modification: Even though every new software package contains the complete VNF, the
actual changes may involve only a subset of the VNFCs. Rather than update or upgrade the entire VNF
instance by instantiating a new VNF instance with the new software version, it may be more efficient to
modify only the affected VNFC instances. VNFC upgrades and updates become increasingly necessary due to
the following reasons:
a) As the market demand for new service introduction intensifies and agile development processes become
more common (e.g. DevOps), there is a demand for frequent changes to the VNF software. Such rapid
changes may best be accomplished by modifying individual VNFCs in a VNF.
b) Research results [i.6] show that the release interval of cloud services is as short as one week or less.
ETSI
16 ETSI GS NFV-REL 006 V3.1.1 (2018-02)
c) Per [i.1], three of the 10 biggest cloud outages of 2013 and 2014 were caused by software upgrade related
operations. It is important to enable upgrades of the smallest component of a VNF, which is the VNFC.
This minimizes the following:
risk of outages,
negative service impacts,
required resources for upgrade,
duration of t
...