Draft ETSI GSNFV-REL008V0.0.1(2016-04)
Network Functions Virtualisation (NFV);
Reliability;
Report on Error Handling – Detection, Correlation, Notification
Disclaimer
This document has been produced and approved by the Open Radio equipment Interface (ORI) 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.
GROUP SPECIFICATION
Disclaimer
This document has been produced and approved by the <long techbody> (<short techbody)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.
Draft ETSI GS NFV-REL008 V0.0.1 (2016-04)
1
Reference
Workitem
Keywords
keywords
ETSI
650 Route des Lucioles
F-06921 Sophia AntipolisCedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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
Individual copies of the present document can be downloaded from:
The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the 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
If you find errors in the present document, please send your comment to one of the following services:
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute yyyy.
All rights reserved.
DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
3GPPTM and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
Contents
Contents
Intellectual Property Rights
Foreword
Introduction
1Scope
2References
2.1Normative references
2.2Informative references
3Definitions, symbols and abbreviations
3.1Definitions
3.2Symbols
3.3Abbreviations
4Metrics
4.1Detection
4.2Notification
5Use Cases
5.1Message Flow
5.2Correlation
6Error Detection
6.1Requirements
6.2Methods
7 Correlation
7.1Layers
7.2Event floods
7.3Geographical Correlation
8 Notification
8.1Notification requests
8.2Mechanisms
8.3Information Elements
History
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSISR000314: "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 (
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 ETSISR000314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group Network Functions Virtualisation (NFV).
Introduction
1Scope
The current document provides a report on how to detect and notify errors occuring in NFV entities. The scope of the WI is focused on the hardware, software and resource related failures. It discusses mechanisms how to correlate errors that have been detected at different layers in the NFV reference architecture model but are caused by the same fault. It will be investigated how to generate notifications that allow controlling mechanisms to take decisions and actions to maintain the defined reliability, availability and other applicable SLA performance requirements. The report also focuses on identifying appropriate metrics for detection and notification. This report will use industry standard fault management terminology, conceptual and operational models, such as ITU-T X.7xx, TM Forum eTOM or ITIL. Extensions to existing NFV specifications will be recommended where necessary.
2References
2.1Normative references
2.2Informative references
[i.1]ETSI GS NFV 003: "Terminology for Main Concepts in NFV".
[i.2]ETSI GS NFV-REL 001: "Resiliency Requirements".
3Definitions, symbols and abbreviations
3.1Definitions
Editor’s note: No private definition for Error Handling expected. Definitions should come from referenced documents.
3.2Symbols
3.3Abbreviations
4Metrics
Editor’s note: This clause discusses about metrics to be used for error detection
4.1Detection
4.2Notification
5Use Cases
5.1Message Flow
5.2Correlation
6Error Detection
6.1Requirements
Editor’s note: This clause discusses about parameters for error detection like detection rates and delays
6.2Methods
Editor’s note: This clause discusses about available techniques to detect errors in virtualized environments
7Correlation
7.1Layers
Editor’s note: This clause evaluatesthe requirements to correlate events occurring in different components
7.2Event floods
Editor’s note: This clause discusses about how to reduce events to avoit floods on higher layers
7.3Geographical Correlation
Editor’s note: This clause elaborates the requirements to include geographical dependencies into correlation decisions
8Notification
8.1Notification requests
Editor’s note: This clause describes the types of notifications required (push, pull)
8.2Mechanisms
Editor’s note: This clause describes the required characteristic of the notifications (e.g. reliability, delay)
8.3Information Elements
Editor’s note: This clause describes the type of information that should to be sent by notifications (severity,..)
Annex <A>:
Error/Fault Classes
History
This clause shall be the last one in the documentand list the main phases (all additional information will be removed at the publication stage).
Document history<Version> / <Date> / <Milestone>
V0.0.1 / April 2016 / Skeleton
ETSI