ETSI GR NFV-REL 012 V1.1.1 (2021-11)

Network Functions Virtualisation (NFV); Reliability; Report on availability and reliability under failure and overload conditions in NFV-MANO

DGR/NFV-REL012

General Information

• Status: Not Published
• Technical Committee: NFV REL - Reliability & Availability
• Current Stage: 12 - Completion
• Due Date: 19-Nov-2021
• Completion Date: 02-Nov-2021

Standards Content (Sample)

GROUP REPORT
Network Functions Virtualisation (NFV);
Reliability;
Report on availability and reliability under failure
and overload conditions in NFV-MANO
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 012 V1.1.1 (2021-11)

Reference
DGR/NFV-REL012
Keywords
availability, MANO, NFV, robustness

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

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

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
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2021.
All rights reserved.
ETSI
3 ETSI GR NFV-REL 012 V1.1.1 (2021-11)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Architectural overview . 8
4.1 NFV-MANO architectural considerations . 8
4.2 NFV-MANO functional entity redundancy . 10
5 Use cases . 11
5.1 Introduction . 11
5.2 NFV-MANO failures . 12
5.2.1 NFV-MANO failure detection and reporting . 12
5.2.1.1 Handling of an alarm reported by an NFV-MANO functional entity . 12
5.2.1.1.1 Introduction and goal . 12
5.2.1.1.2 Actors and roles . 12
5.2.1.1.3 Pre-conditions . 12
5.2.1.1.4 Post-conditions . 13
5.2.1.1.5 Flow description . 13
5.2.1.2 Detection of a failure of another NFV-MANO functional entity . 14
5.2.1.2.1 Introduction and goal . 14
5.2.1.2.2 Actors and roles . 14
5.2.1.2.3 Pre-conditions . 14
5.2.1.2.4 Post-conditions . 14
5.2.1.2.5 Flow description . 15
5.2.1.3 Alarm escalation . 16
5.2.1.3.1 Introduction and goal . 16
5.2.1.3.2 Actors and roles . 16
5.2.1.3.3 Pre-conditions . 16
5.2.1.3.4 Post-conditions . 17
5.2.1.3.5 Flow description . 17
5.2.2 NFV-MANO failure recovery. 17
5.2.2.1 NFV-MANO functional entity internal failover . 17
5.2.2.1.1 Introduction and goal . 17
5.2.2.1.2 Actors and roles . 18
5.2.2.1.3 Pre-conditions . 18
5.2.2.1.4 Post-conditions . 18
5.2.2.1.5 Flow description . 19
5.2.2.2 Externally managed failover of NFV-MANO functional entity redundancy units . 19
5.2.2.2.1 Introduction and goal . 19
5.2.2.2.2 Actors and roles . 20
5.2.2.2.3 Pre-conditions . 20
5.2.2.2.4 Post-conditions . 21
5.2.2.2.5 Flow description for collaborating NFV-MANO functional entity redundancy units . 21
5.2.2.2.6 Flow description for externally monitored NFV-MANO functional entity redundancy units . 21
5.2.2.3 Failover of NFV-MANO functional entities . 22
5.2.2.3.1 Introduction . 22
5.2.2.3.2 Actors and roles . 23
5.2.2.3.3 Pre-conditions . 23
ETSI
4 ETSI GR NFV-REL 012 V1.1.1 (2021-11)
5.2.2.3.4 Post-conditions . 24
5.2.2.3.5 Flow description for recovering the service of a failed NFV-MANO functional entity . 24
5.2.2.3.6 Flow description for recovering the service of a failed instance of the NFV-MANO
functional entity among many . 25
5.2.3 Failures in the interworking of NFV-MANO functional entities . 25
5.2.3.1 Correlation of failures of NFV-MANO functional entities . 25
5.2.3.1.1 Introduction and goal . 25
5.2.3.1.2 Actors and roles . 26
5.2.3.1.3 Pre-conditions . 26
5.2.3.1.4 Post-conditions . 26
5.2.3.1.5 Flow description . 26
5.2.3.2 Communication failure between NFV-MANO functional entities . 28
5.2.3.2.1 Introduction and goal . 28
5.2.3.2.2 Actors and roles . 28
5.2.3.2.3 Pre-conditions . 28
5.2.3.2.4 Post-conditions . 29
5.2.3.2.5 Flow description . 29
5.2.3.3 Notifications delivery by an NFV-MANO functional entity . 30
5.2.3.3.1 Introduction and goal . 30
5.2.3.3.2 Actors and roles . 30
5.2.3.3.3 Pre-conditions . 31
5.2.3.3.4 Post-conditions . 31
5.2.3.3.5 Flow description of a successful notification delivery . 31
5.2.3.3.6 Flow description of a timeout in delivering the notification to the NFV-MANO service user
API component . 32
5.2.3.3.7 Flow description where an error code is received by the SP API component indicating an
unsuccessful delivery . 33
5.2.4 Failures in the interworking of NFV-MANO functional entities with non-MANO functional blocks . 33
5.2.4.1 Communication with an entity of a non-NFV-MANO functional block. 33
5.2.4.1.1 Introduction and goal . 33
5.2.4.1.2 Actors and roles . 34
5.2.4.1.3 Pre-conditions . 34
5.2.4.1.4 Post-conditions . 34
5.2.4.1.5 Flow description of the case when the requestor does not receive an expected response . 35
5.2.4.1.6 Flow description of the case when the requestor receives a response late . 36
5.2.4.1.7 Flow description of the case when the request is lost . 37
5.2.5 Failures caused by human errors . 37
5.3 NFV-MANO overload . 38
5.3.1 NFV-MANO load management overview . 38
5.3.2 Handling overload . 39
5.3.2.1 Introduction and goal . 39
5.3.2.2 Actors and roles . 39
5.3.2.3 Pre-conditions . 39
5.3.2.4 Post-conditions . 40
5.3.2.5 Flow description . 40
5.3.3 Priority based request handling during overload . 41
5.3.3.1 Introduction . 41
5.3.3.2 Actors and roles . 41
5.3.3.3 Pre-conditions . 41
5.3.3.4 Post-conditions . 42
5.3.3.5 Flow description . 42
5.3.4 Congestion control . 43
5.3.4.1 Introduction and goal . 43
5.3.4.2 Actors and roles . 44
5.3.4.3 Pre-conditions . 44
5.3.4.4 Post-conditions . 44
5.3.4.5 Flow description . 44
6 Recommendations . 46
6.1 Introduction . 46
6.2 General recomendations . 46
6.3 Recommendations of functional requirements for NFV-MANO functional entities. 47
ETSI
5 ETSI GR NFV-REL 012 V1.1.1 (2021-11)
6.4 Recommendations for interfaces of NFV-MANO functional entities . 48
6.5 Recommendations for the Alarm-Aggregator . 48
6.6 Recommendations related to the MANO-Monitor . 49
Annex A: Change History . 50
History . 51

ETSI
6 ETSI GR NFV-REL 012 V1.1.1 (2021-11)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 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.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Network Functions
Virtualisation (NFV).
This study assumes a fault management model as defined by 3GPP TS 32.111-1 [i.3], which in turn is based on
Recommendation ITU-T X.733 [i.4].
This is done in consistency with ETSI GS NFV-IFA 031 [i.6].
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.

ETSI
7 ETSI GR NFV-REL 012 V1.1.1 (2021-11)
1 Scope
The present document reports on impacts of NFV-MANO failures and overload conditions, including human errors, on
the availability and reliability of NFV-MANO. A set of use cases will be described and analysed which include
interactions between NFV-MANO functional entities under such conditions and other functional blocks (VNF, EM,
OSS, .). Also situations are analysed, where availability is achieved by a system of collaborating NFV-MANO
functional entities possibly provided by different vendors. As a result, recommendations for the requirements of an
available and reliable NFV-MANO system will be derived.
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] ETSI GR NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV".
[i.2] ETSI GS NFV-REL 001: "Network Functions Virtualisation (NFV); Resiliency Requirements".
[i.3] 3GPP TS 32.111-1 (V16.0.0): "Telecommunication management; Fault Management; Part 1:
3G fault management requirements".
[i.4] Recommendation ITU-T X.733: "Systems Management: Alarm reporting function".
[i.5] ETSI GR NFV-REL 011: "Network Functions Virtualisation (NFV) Release 4; Management and
Orchestration; Report on NFV-MANO Software Modification".
[i.6] ETSI GS NFV-IFA 031 (V3.4.1): "Network Functions Virtualisation (NFV) Release 3;
Management and Orchestration; Requirements and interfaces specification for management of
NFV-MANO".
[i.7] ETSI GS NFV-IFA 008 (V3.4.1): "Network Functions Virtualisation (NFV) Release 3;
Management and Orchestration; Ve-Vnfm reference point - Interface and Information Model
Specification".
[i.8] IETF RFC 7230: "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing".
ETSI
8 ETSI GR NFV-REL 012 V1.1.1 (2021-11)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GR NFV 003 [i.1] and the following apply:
alarm: information about a specific condition requiring attention
NOTE: An alarm does or does not represent an error.
alarm notification: message used to report an alarm
error: discrepancy between a computed, observed, or measured value or condition and a true, specified, or theoretically
correct value or condition
NOTE 1: Error is a consequence of a fault.
NOTE 2: See ETSI GS NFV-REL 001 [i.2].
failure: deviation of the service from fulfilling its functionality
NOTE: See ETSI GS NFV-REL 001 [i.2].
fault: adjudged or hypothesized cause of an error
NOTE: See ETSI GS NFV-REL 001 [i.2].
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the terms given in ETSI GR NFV 003 [i.1] and the following apply:
DDoS Distributed Denial of Service
FE Functional Entity
RU Resource Unit
RUI Resource Unit Instance
SU Service User
4 Architectural overview
4.1 NFV-MANO architectural considerations
The internal architecture of an NFV-MANO functional entity is not visible to the external world and it can follow
different architectural paradigms.
ETSI
9 ETSI GR NFV-REL 012 V1.1.1 (2021-11)

Figure 4.1-1: Example of the internal architecture of an NFV-MANO functional entity
and the users of its services
One of the popular paradigms is the microservice based architecture according to which an NFV-MANO functional
entity could be built as a set of different microservices. For example, an NFV-MANO functional entity can include a
microservice implementing the Life Cycle Management (LCM) operations, another for Fault Management (FM) and yet
another handling the HTTP API communication needs of the microservices as shown in figure 4.1-1. These different
microservices are supported by different sets of components of the NFV-MANO functional entity to provide the
NFV-MANO services in accordance with the ETSI GS NFV-IFA 031 [i.6]. An example of the Service Provider (SP)
NFV-MANO functional entity could be a VNFM.
The same architectural considerations apply to the users of the NFV-MANO services provided by the NFV-MANO
functional entity. Examples of the NFV-MANO Service User (SU) could be a VNF or the NFVO.
NOTE: The SP NFV-MANO functional entity is not aware of the internal structure of the NFV-MANO SU and
vice versa. These details are shown and discussed for the purpose of the use case analysis.
When it comes to the reliability of the communication between these two categories of entities, i.e. the SP NFV-MANO
functional entity and the NFV-MANO SU, two kinds of communication segments need to be considered. On the one
hand, between the entities on the external portion of the communication path, HTTP is used as the communication
protocol as defined in the ETSI NFV-SOL specifications. On the other hand, the means of internal communication -
among the components of each of the entities - is left to the implementer (e.g. vendor) of each of these entities.
In addition, in the ETSI NFV specifications, two communication patterns are considered. The two-way communication
pattern is implemented through the exchange of a request followed by a response. While in the one-way communication
pattern (also referred as fire-and-forget), a message is sent without the need for follow-up.
This means that, in case of two-way communication, for example, when an LCM user component of the SU sends a
request to an LCM component of the SP, the request passes through the SU-internal, the external and again on the
SP-internal portions of the communication path between these components. The same applies in reverse order to the
response. If the communication fails on any portion of this communication path, it can be detected by the SU LCM user
component as it would not receive the response sent by the SP; and therefore, it can take actions as needed or sees
appropriate.
In case of one-way communication, the sender, for example, an FM component of the SP, does not expect any response
to the notification it sends. Nevertheless, the delivery of this notification to all intended receivers, i.e. FM user
components of the SUs, is important to ensure that they can take any necessary actions. However, the sender of such
communication - the FM component of the SP - has no way to detect if the notification was not delivered. Therefore, it
is typically expected that the underlying communication mechanism guarantees the delivery to the receiving end(s) -
FM user components of the SUs.
To this end, the HTTP protocol mandated for the external portion of the communication path does not cover the internal
portions of the path, hence it cannot detect any loss occurring on the internal portions of the communication path.
ETSI
10 ETSI GR NFV-REL 012 V1.1.1 (2021-11)
With respect to the HTTP portion of the communication path itself, according to IETF RFC 7230 [i.8]:
"HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since
different applications of the protocol require different error handling strategies."
Also, HTTP allows for the chaining of connections through intermediaries, in which case the end-to-end delivery
through this chain cannot always be guaranteed without appropriate error handling mechanism.
In clauses 5.2.3 and 5.2.4, different message loss scenarios and their mitigation are investigated through different use
cases.
4.2 NFV-MANO functional entity redundancy
The internal architecture of an NFV-MANO functional entity is exposed only to the extent of enabling a network
operator to manage the redundancy of the deployment of the NFV-MANO functional entity. For this purpose, the ETSI
GR NFV-REL 011 [i.5] report has proposed a refinement to the concepts defined in the ETSI GS NFV-IFA 031 [i.6]
specification. Accordingly, an NFV-MANO functional entity consists of one or more NFV-MANO functional entity
Redundancy Unit(s)(RU). Each RU can be deployed redundantly according to a redundancy model. This redundancy
model is one of the vendor defined redundancy models. An NFV-MANO functional entity redundancy unit might be
further decomposed into NFV-MANO functional entity components. However, these NFV-MANO functional entity
components are generally hidden from the network operator. If desired and available, the network operator can choose a
redundancy model that deploys multiple RU instances.
To clarify these concepts that are essential for the understanding of use cases described in clause 5.2.2, figure 4.2-1
provides an example of the internal architecture of a deployed NFV-MANO functional entity.

Figure 4.2-1: Example of the internal architecture of an NFV-MANO functional entity
The NFV-MANO functional entity in this example has three NFV-MANO functional entity redundancy units:
• The LifeCycle Mgmt redundancy unit (LifeCycle Mgmt RU) is deployed with two active and a standby
Redundancy Unit Instances (RUIs). This is a selectable redundancy model for this redundancy unit specified
by the vendor. The redundancy unit is further decomposed into components for handling the instantiation (Inst.
comp), the scaling (Scale comp) and other services the LifeCycle Mgmt redundancy unit provides, which are
not exposed. The components of the active and standby instances of the redundancy unit collaborate with each
other to provide these services seamlessly in case of failures of components or an entire redundancy unit
instance.
ETSI
11 ETSI GR NFV-REL 012 V1.1.1 (2021-11)
• The Fault Mgmt redundancy unit (Fault Mgmt RU) is deployed with one active and one standby instances.
Again, this is one of the selectable redundancy models for this redundancy unit and accordingly the active and
standby instances collaborate with each other. In the example, this redundancy unit consists of at least two
components not visible for the network operator: one for handling the subscriptions (Subscr comp) and another
for generating the notifications (Notify comp).
• The API Redundancy Unit (API RU) is deployed with three active instances. The redundancy unit is
composed of the sender (Send comp) and the receiver (Rcvr comp) components. These RU instances do not
collaborate with each other, meaning that if one of them fails the other RU instances will not have any
information about the messages sent and received by the failed RU instance. But they will handle any new
incoming and outgoing messages. The service thus remains available, but its continuity might not be
guaranteed.
An NFV-MANO functional entity might include an internal availability management, which is capable of deploying the
appropriate number of redundancy unit instances according to the redundancy model selected for instantiation. It would
also monitor these instances and perform healing actions as they might become necessary. Note, however, that the
internal availability management cannot detect and heal failures impacting the entire NFV-MANO functional entity.
This requires an external manager.
It is also possible that there is no internal availability management, but, due to their need for collaboration, for example,
the redundancy units or their components can detect that their instances have been deployed redundantly by an external
manager. In this case, the redundancy units are able to report if there is any problem with their redundant peer. But
since the life cycle of the redundancy unit instances is managed externally, the task of healing a failed redundancy unit
instance also remains with this external manager. In addition, the external manager would need to monitor the health of
the NFV-MANO functional entity redundancy unit instances if they cannot report each other's failure - for example
because they are deployed all active without any need for collaboration other than sharing the load. Such external
monitoring and management are also necessary to detect and heal a failure impacting the entire NFV-MANO functional
entity.
Finally, it is possible that an entire NFV-MANO functional entity is deployed redundantly. In this case, the
NFV-MANO functional entity instances are not aware of each other by default and the external manager should not
only manage the life cycle of the NFV-MANO functional entity instances, but also facilitate their collaboration. This
collaboration might be very limited and typically would be implemented by external means, e.g. via external
database/file.
To achieve higher reliability and availability, the options above can be combined. That is, the internal and external
availability/life cycle managers can be used in combination with each other, each responsible for a particular scope of
management. For example, the internal availability manager would handle the internal failures of components and
redundancy units of the NFV-MANO functional entity. While the external life cycle manager monitors the
NFV-MANO functional entity as a whole and performs healing actions at the NFV-MANO functional entity level.
For certain NFV-MANO functional entities, geo-redundant deployment might be necessary. This could be achieved
either by redundant deployment of the entire NFV-MANO functional entity or its redundancy units. The main
difference is that when the NFV-MANO functional entity redundancy unit(s) is/are deployed redundantly, they still act
together as a single NFV-MANO functional entity instance, as they all represent the same identity. When the entire
NFV-MANO functional entity is deployed redundantly, each instance will have its own identity and the collaboration of
these different instances does not go beyond any applicable interface specifications (e.g. Or-Or).
5 Use cases
5.1 Introduction
Clause 5 describes use cases for NFV-MANO failure and overload conditions. Two functions are introduced for the
purpose to describe the use cases, the Alarm-Aggregator and the MANO-Monitor functions. The task of the
Alarm-Aggregator function is to maintain an aggregated list of alarm conditions that exist in the NFV system, while the
MANO-Monitor function is responsible to take actions towards resolving the root cause of an alarm.
The use cases do not make any assumption what entity or entities can play such roles. The roles could be fulfilled by an
administrator or OSS, or they could be new functionalities offered by NFV-MANO.
ETSI
12 ETSI GR NFV-REL 012 V1.1.1 (2021-11)
5.2 NFV-MANO failures
5.2.1 NFV-MANO failure detection and reporting
5.2.1.1 Handling of an alarm reported by an NFV-MANO functional entity
5.2.1.1.1 Introduction and goal
An NFV-MANO functional entity may detect an internal error that prevents it from providing a service as specified. If
this error cannot be recovered internally, it is a failure. This failure situation should be reported to other interested
parties by sending an alarm notification. The NFV-MANO functional entity will track the state of this alarm by adding
it to its own active alarm list.
When receiving an alarm notification, the Alarm-Aggregator will inform the registered entities to enable them to take
precautions to mitigate the impact of the failure of the faulty NFV-MANO functional entity.
The MANO-Monitor will acknowledge the alarm notification and take over the responsibility to resolve the root cause
of the alarm. The MANO-Monitor will maintain a list of active alarms that it has acknowledged. After resolving the
root cause, the normal operation resumes.
NOTE: It cannot always be assumed, that an NFV-MANO functional entity is able to detect, that it cannot
provide service as specified and report this. The NFV-MANO functional entity may not even be
operational anymore. The use case of the detection ofa potential failure by an external entity is described
in clause 5.2.1.2.
5.2.1.1.2 Actors and roles
Table 5.2.1.1.2-1 describes the use case actors and roles.
Table 5.2.1.1.2-1: Handling of an alarm reported by an NFV-MANO functional entity actors and roles
# Role Description
1 Faulty NFV-MANO The entity that detects a failure on itself.
functional entity
2 Registered entity Entity that has registered with the Alarm-Aggregator to be informed in case of an alarm.
3 MANO-Monitor Entity responsible to resolve the root cause of the alarm.
4 Alarm-Aggregator Entity responsible for maintaining an aggregated list of alarm conditions in the NFV
system. For this purpose, it has registered with the NFV-MANO functional entities to
receive alarm notifications. The Alarm-Aggregator will forward notifications to registered
entities.
5.2.1.1.3 Pre-conditions
Table 5.2.1.1.3-1 describes the use case pre-conditions.
Table 5.2.1.1.3-1: Handling of an alarm reported by an NFV-MANO functional entity pre-conditions
# Pre-condition Additional description
1 All NFV-MANO functional entities, the Alarm-Aggregator This includes the NFV-MANO functional entity that
and the MANO-Monitor are running correctly will become faulty.
2 The Alarm-Aggregator has registered with all the
NFV-MANO functional entities to receive alarm
notifications
3 The MANO-Monitor has registered with the Alarm-
Aggregator to receive alarm notifications
4 All NFV-MANO functional entities have registered with
the Alarm-Aggregator to be informed about alarms they
are interested in
ETSI
13 ETSI GR NFV-REL 012 V1.1.1 (2021-11)
5.2.1.1.4 Post-conditions
Table 5.2.1.1.4-1 describes the use case post-conditions.
Table 5.2.1.1.4-1: Handling of an alarm reported by an NFV-MANO functional entity post-conditions
# Post-condition Additional description
1 All NFV-MANO functional entities, the Alarm-Aggregator This includes the NFV-MANO functional entity that
and the MANO-Monitor are running correctly was faulty.

5.2.1.1.5 Flow description
Table 5.2.1.1.5-1 describes the use case flow.
Table 5.2.1.1.5-1: Handling of an alarm reported by an NFV-MANO functional entity flow description
# Actor/Role Action/Description
Begins when Faulty NFV-MANO The faulty NFV-MANO functional entity detects an internal error. This error
functional entity prevents it from providing a service as specified, thus it is a failure. It cannot
recover from this failure on its own. It creates an entry in its active alarm list.
Step 1 Faulty NFV-MANO The faulty NFV-MANO functional entity sends an alarm notification to the
functional entity -> Alarm-Aggregator.
Alarm-Aggregator
Step 2 Alarm-Aggregator -> The Alarm-Aggregator creates an entry in its global list of active alarms and
Registered entities sends the alarm notification to the registered entities. This includes the
MANO-Monitor.
Step 3 MANO-Monitor-> The MANO-Monitor acknowledges to the faulty NFV-MANO functional entity
Faulty NFV-MANO that it has received the alarm notification and the responsibility to recover from
functional entity the failure is taken over. The faulty NFV-MANO functional entity can stop
trying to recover from the failure locally and it does not need to s
...