ETSI GS NFV-IFA 010 V2.7.1 (2019-09)
Network Functions Virtualisation (NFV) Release 2; Management and Orchestration; Functional requirements specification
Network Functions Virtualisation (NFV) Release 2; Management and Orchestration; Functional requirements specification
RGS/NFV-IFA010ed271
General Information
Standards Content (Sample)
GROUP SPECIFICATION
Network Functions Virtualisation (NFV) Release 2;
Management and Orchestration;
Functional requirements specification
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-IFA 010 V2.7.1 (2019-09)
Reference
RGS/NFV-IFA010ed271
Keywords
functional, management, MANO, NFV,
orchestration, requirements, virtualisation
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 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.
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.
ETSI
3 ETSI GS NFV-IFA 010 V2.7.1 (2019-09)
Contents
Intellectual Property Rights . 7
Foreword . 7
Modal verbs terminology . 7
1 Scope . 8
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 8
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 9
3.3 Abbreviations . 9
4 General Description . 10
4.1 Introduction . 10
4.2 Overview . 10
5 General functional requirements . 11
5.1 General functional requirements for virtualised resource management . 11
5.2 General functional requirements for multi-tenancy . 12
6 Functional requirements for NFVO . 14
6.1 Functional requirements for virtualised resource management . 14
6.1.1 Functional requirements for general virtualised resource management . 14
6.1.2 Functional requirements for VNF-related resource management in indirect mode . 14
6.1.3 Functional requirements for VNF-related resource management in direct mode . 14
6.1.4 Functional requirements for NS-related resource management performed by the NFVO . 15
6.1.5 Functional requirements for resource reservation management. 15
6.1.6 Functional requirements for virtualised resource capacity management . 16
6.1.7 Functional requirements for virtualised resource performance management . 16
6.1.8 Functional requirements for virtualised resource fault management . 17
6.1.9 Functional requirements for virtualised resource information management . 17
6.1.10 Functional requirements for Network Forwarding Path (NFP) management . 17
6.1.11 Functional requirements for quota management . 18
6.1.12 Functional requirements related to permitted allowance management . 18
6.2 Functional requirements for VNF lifecycle ma nage me nt . 19
6.2.1 Functional requirements for VNF lifecycle management . 19
6.2.2 Functional requirements for VNF instantiation . 19
6.2.3 Functional requirements for VNF scaling . 19
6.2.4 Functional requirements for VNF termination . 20
6.2.5 Void . 20
6.2.6 Void . 20
6.2.7 Functional requirements for change of the external VNF connectivity . 20
6.3 Functional requirements for NS lifecycle management . 20
6.3.1 Functional requirements for NS lifecycle management . 20
6.3.2 Functional requirements for NS instantiation . 21
6.3.3 Functional requirements for NS scaling . 21
6.3.4 Functional requirements for NS updating . 21
6.3.5 Functional requirements for NS termination. 22
6.4 Functional requirements for VNF configuration management . 22
6.5 Functional requirements for VNF information management. 22
6.5.1 Functional requirements for VNF Package management . 22
6.5.2 Functional requirements for VNF instance information management . 22
6.6 Functional requirements for NS information management . 23
6.6.1 Functional requirements for NSD management . 23
6.6.2 Functional requirements for NS instance information management . 23
6.6.3 Functional requirements for PNF Descriptor (PNFD) archive management . 23
ETSI
4 ETSI GS NFV-IFA 010 V2.7.1 (2019-09)
6.7 Functional requirements for NS performance management . 24
6.8 Functional requirements for VNF fault management . 24
6.8.1 Functional requirements for virtualisation-related fault management . 24
6.9 Functional requirements for NS fault management . 24
6.10 Functional requirements for infrastructure resource management . 25
6.11 Functional requirements for security consideration . 25
6.12 Functional requirements for software image management . 25
6.13 Functional requirements for NFV acceleration management . 25
6.14 Functional requirements for multi-tenancy . 26
7 Functional requirements for VNFM . 26
7.1 Functional requirements for virtualised resource management . 26
7.1.1 Functional requirements for virtualised resource management . 26
7.1.2 Functional requirements for VNF-related resource management in indirect mode . 27
7.1.3 Functional requirements for VNF-related resource management in direct mode . 27
7.1.4 Functional requirements for resource reservation management. 28
7.1.5 Functional requirements for virtualised resource performance management . 28
7.1.6 Functional requirements for virtualised resource fault management . 28
7.1.7 Functional requirements for virtualised resource information management . 28
7.1.8 Functional requirements for quota management . 29
7.1.9 Functional requirements related to permitted allowance management . 29
7.2 Functional requirements for VNF lifecycle ma nage me nt . 29
7.2.1 Functional requirements for VNF lifecycle management . 29
7.2.2 Functional requirements for VNF instantiation . 30
7.2.3 Functional requirements for VNF scaling . 30
7.2.4 Functional requirements for VNF termination . 31
7.2.5 Void . 31
7.2.6 Functional requirements for change of the external VNF connectivity . 31
7.3 Functional requirements for VNF configuration management . 31
7.4 Functional requirements for VNF information management. 32
7.4.1 Functional requirements for VNF Package management . 32
7.4.2 Functional requirements for VNF instance information management . 32
7.5 Functional requirements for VNF performance management . 32
7.6 Functional requirements for VNF fault management . 33
7.6.1 Functional requirements for virtualised resource-related VNF fault management . 33
7.6.2 Functional requirements for virtualisation-related fault management . 33
7.7 Functional requirements for security consideration . 33
7.8 Functional requirements for software image management . 34
7.9 Functional requirements for NFV acceleration management . 34
7.10 Functional requirements for multi-tenancy . 34
7.11 Functional requirements for VNF indicator management . 34
8 Functional requirements for VIM . 35
8.1 General considerations . 35
8.2 Functional requirements for virtualised resource management . 35
8.2.1 Functional requirements for virtualised resource management . 35
8.2.2 Functional requirements for resource reservation management. 36
8.2.3 Functional requirements for virtualised resource capacity management . 36
8.2.4 Functional requirements for virtualised resource performance management . 36
8.2.5 Functional requirements for virtualised resource fault management . 37
8.2.6 Functional requirements for virtualised resource information management . 37
8.2.7 Functional requirements for virtualised resource configuration management . 37
8.2.8 Functional requirements for NFP management . 38
8.2.9 Functional requirements for quota management . 38
8.3 Functional requirements for infrastructure resource management . 38
8.3.1 Functional requirements for infrastructure resource performance management . 38
8.3.2 Functional requirements for infrastructure resource fault management. 39
8.4 Functional requirements for security consideration . 39
8.5 Functional requirements for software image management . 39
8.6 Functional requirements for NFV acceleration management . 39
8.7 Functional requirements for multi-tenancy . 40
9 Architectural level Requirements . 40
ETSI
5 ETSI GS NFV-IFA 010 V2.7.1 (2019-09)
9.1 General guidelines for NFV management and orchestration interface design . 40
9.2 General requirements to NFV management and orchestration interface design . 40
9.3 General requirements for NFV management and orchestration services . 41
9.4 General requirements for multi-tenancy . 41
Annex A (informative): Resource management additional information . 42
A.1 Quota based resource management . 42
A.1.1 Overview . 42
A.1.2 Summary of key aspects . 42
A.1.3 Allocation of consumer identifiers . 43
A.1.4 Setting of quotas . 43
A.1.5 NFVO awareness of NFVI resource consumption . 43
A.1.6 NFVI resource acquisition . 43
A.1.7 Resource contention mitigation . 44
A.1.8 Data centre resource utilization efficiency . 44
A.1.9 Resource management evolution and interoperability. 44
A.1.10 Co-existence of resource quota enforcement and resource management with reservation . 44
A.2 Management of resource reservations . 44
A.2.1 Introduction . 44
A.2.2 Use cases . 44
A.2.2.1 Use case for securing resources for several tenants . 44
A.2.2.2 Use case for securing resources with detailed capabilities . 45
A.2.2.3 Use case for securing resources during NS instantiation . 45
A.2.2.4 Use case for securing resources during NS scaling . 45
A.2.2.5 Use case for securing resources related to a scheduled event . 45
A.2.3 Summary of key aspects . 45
A.2.4 Resource reservation management by NFVO . 46
A.2.5 Resource reservation handling by the VNFM . 47
A.2.6 Resource reservation contention mitigation . 47
A.2.7 Co-existence of reservation with quota . 47
A.2.8 Resource reservation types . 47
A.3 Management of permitted allowance . 48
A.3.1 Introduction . 48
A.3.2 Summary of key aspects . 48
A.3.3 Setting of permitted allowance . 48
A.3.4 Permitted allowance management by NFVO . 49
A.3.5 Permitted allowance awareness by the VN FM . 49
A.3.6 Permitted allowance contention mitigation . 49
A.3.7 Co-existence of permitted allowance and resource quota enforcement . 49
A.3.8 Co-existence of permitted allowance and resource management with reservation . 49
Annex B (informative): Virtualised resources capacity management . 50
B.1 Introduction . 50
B.2 Virtualised resources capacity information management by the VIM . 50
B.2.1 Functionality . 50
B.3 Virtualised resources capacity management by the NFVO . 50
B.3.1 Functionality . 50
Annex C (informative): VNF management . 52
C.1 Introduction . 52
C.2 Use cases . 52
C.2.1 Use case for stopping a VNF instance . 52
C.2.1.1 Introduction. 52
C.2.1.2 Steps. 52
C.2.2 Use case for starting a VNF instance. 53
C.2.2.1 Introduction. 53
C.2.2.2 Steps. 53
ETSI
6 ETSI GS NFV-IFA 010 V2.7.1 (2019-09)
Annex D (informative): Authors & contributors . 54
Annex E (informative): Change History . 56
History . 57
ETSI
7 ETSI GS NFV-IFA 010 V2.7.1 (2019-09)
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
8 ETSI GS NFV-IFA 010 V2.7.1 (2019-09)
1 Scope
The present document specifies functional requirements for NFV management and orchestration, and general guidelines
and requirements for NFV management and orchestration interface design.
The scope of the present document does not cover the functional requirements on interfaces.
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
http://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-IFA 011: "Network Functions Virtualisation (NFV) Release 2; Management and
Orchestration; VNF Descriptor and Packaging Specification".
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 GS NFV 002: "Network Functions Virtualisation (NFV); Architectural Framework".
[i.2] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for main concepts in
NFV".
[i.3] ETSI GS NFV 004: "Network Functions Virtualisation (NFV); Virtualisation Requirements".
[i.4] ETSI GS NFV-MAN 001: "Network Functions Virtualisation (NFV); Management and
Orchestration".
[i.5] ETSI GS NFV-SWA 001: "Network Functions Virtualisation (NFV); Virtual Network Functions
Architecture".
[i.6] ETSI GS NFV-REL 001: "Network Functions Virtualisation (NFV); Resiliency requirements".
[i.7] ETSI GS NFV-INF 001: "Network Functions Virtualisation (NFV); Infrastructure Overview".
ETSI
9 ETSI GS NFV-IFA 010 V2.7.1 (2019-09)
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.2] and the following apply:
NOTE: A term defined in the present document takes precedence over the definition of the same term, if any, in
ETSI GS NFV 003 [i.2].
composite network service: network service containing at least one network service
NS healing: procedure that includes all virtualisation related corrective actions to repair a faulty Network Service (NS)
instance including components/functionalities which make up the instance, and have been associated with this fault
situation
NOTE 1: In a virtualised environment network service healing focuses only on the virtualised
components/functionalities. In case of a NS consisting of virtualised and non-virtualised parts a procedure
able to handle both parts is needed. This will be done in connection with components/functionalities that
are located outside the virtualised environment.
NOTE 2: "Virtualisation related corrective actions" refers to action(s) toward virtualised resource(s) and associated
NS instance.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS NFV 003 [i.2] and the following apply:
BSS Business Support System
CP Connection Point
DF Deployment Flavour
EM (Network) Element Manager
FB Functional Block
FPGA Field Programmable Gate Array
IP Internet Protocol
LCM LifeCycle Management
NFP Network Forwarding Path
NSD Network Service Descriptor
NUMA Non Uniform Memory Access
OS Operating System
OSS Operation Support System
PCIe Peripheral Component Interface express
PM Performance Management
PNFD Physical Network Function Descriptor
SAP Service Access Point
URI Uniform Resource Identifier
VL Virtual Link
WIM WAN Infrastructure Manager
ETSI
10 ETSI GS NFV-IFA 010 V2.7.1 (2019-09)
4 General Description
4.1 Introduction
Network Functions Virtualisation (NFV) adds new capabilities to communications networks and requires a new set of
management and orchestration functions to be added to the current model of operations, administration, maintenance
and provisioning. The NFV Management and Orchestration (NFV-MANO) architectural framework has the role to
manage the infrastructure and orchestrate the resources needed by the Network Services (NSs) and Virtualised Network
Functions (VNFs).
In order to guide the development of the specification of the interfaces exposed between the NFV-MANO Functional
Blocks (FBs), it is important to have a clear and consolidated set of functional requirements to be addressed by the
NFV-MANO. The present document is providing functional requirements on NFV MANO e.g. VNF lifecycle
management (LCM), NS LCM, virtualised resource management, etc.
The functional requirements specified in the present document are mainly derived from functional requirements
identified in ETSI GS NFV 002 [i.1], ETSI GS NFV 003 [i.2], ETSI GS NFV 004 [i.3], ETSI GS NFV-MAN 001 [i.4],
ETSI GS NFV-SWA 001 [i.5], ETSI GS NFV-REL 001 [i.6] and ETSI GS NFV-INF 001 [i.7] or derived from concepts
defined in these documents.
4.2 Overview
In order to provide systematic functional requirements, the present document arranges the functional requirements by
categorizing the requirements according to key operational functions of NFV-MANO, which are documented in ETSI
GS NFV-MAN 001 [i.4].
Key operational function categories which are used to organize the requirements on NFV Orchestrator (NFVO), VNF
Manager (VNFM) and Virtualised Infrastructure Manager (VIM) in the present document are listed below:
• Virtualised resource management.
• VNF LCM.
• NS LCM.
• VNF information management.
• NS information management.
• NFV performance management.
• NFV fault management.
• Security considerations.
• Software image management.
• NFV acceleration management.
• Multi-tenancy.
NOTE: This categorization groups related functional requirements together. Actual interface requirements
derived from the functional requirements may be grouped differently, and/or individual interface
requirements may be placed into a group that is different from the category of the related functional
requirement.
ETSI
11 ETSI GS NFV-IFA 010 V2.7.1 (2019-09)
5 General functional requirements
5.1 General functional requirements for virtualised resource
management
The NFV-MANO architecture shall provide support to permit service providers to partially or fully virtualise the
Network Functions (NFs) needed to create, deploy and operate the services they provide. In case of partial
virtualisation, performance, management and operations of the non-virtualised NFs shall not be impacted.
The NFV-MANO architecture shall be able to support a NS composed of Physical Network Functions (PNFs) and
VNFs implemented across multivendor environments.
The NFV-MANO architecture shall be able to manage NFV Infrastructure (NFVI) resources, in order to provide NSs
and related VNFs and PNFs with the resources needed. Management of resources for PNFs shall be restricted to
provisioning connectivity, e.g. necessary when a NS instance includes a PNF that needs to connect to a VNF.
The NFV-MANO architecture shall enable the NFVO and the VNFM to manage the virtualised resources needed for
LCM of the VNFs. The NFV-MANO architecture shall enable deployments and implementations where:
• the NFVO is the only FB to manage the virtualised resources needed for the LCM of the VNF (VNF-related
Resource Management in indirect mode);
• the VNFM is the only FB to manage the virtualised resources needed for the LCM of the VNF (VNF-related
Resource Management in direct mode);
• the NFVO and the VNFM, both, manage the virtualised resources needed for the LCM of the VNF.
NOTE: This is a decision per VNFM whether it is the NFVO or the VNFM that manages the virtualised
resources.
It is a deployment and implementation decision whether one option or both are deployed and implemented. All VNFs
managed by one VNFM shall use the same option for virtualised resource management. The detailed requirements on
the NFVO and the VNFM for each case are depicted in clauses 6.1 and 7.1.
In addition to managing the VNF-related virtualised resources as explained above, the NFV-MANO architecture shall
enable the NFVO to manage the virtualised resources (i.e. network resources) that are needed for LCM of the NS(s).
Additionally, the NFV-MANO shall enable different models, per resource type, to facilitate availability of resources
and to avoid resource contention. It shall be possible for the network operator, on a per NS basis, tenant basis or VNF
basis, to select one of the following resource commitment models, or a combination of them:
• Reservation model, where resources are committed, but not allocated, to a particular consumer or consumer
type. A reservation can have one of the following types (see details in clause A.2.8):
1) reserving a set of resources considering particular virtualised resource configurations, i.e. reserving a
number of virtualised containers, virtual networks, network ports and/or storage volumes;
2) reserving virtualised resource capacity without considering particular resource configurations,
i.e. reserving virtualised resource capacity of compute, storage and network resource types.
• Quota/Allowance based model, where the number of resources to be consumed by a particular consumer is
limited to a defined amount or a percentage of resources; in this model, resources are committed upon demand
from the consumer when a VNF or a NS is instantiated or scaled out, as long as those are within the limits
established by the quota/allowance for that consumer or consumer type.
• On demand, where resources are committed when a VNF or a NS is instantiated or scaled out, as long as there
are available resources for consumption.
The permitted allowance concept should be distinguished from the quota concept:
• Quota: enforced by the VIM. Quotas are usually used to prevent excessive resource consumption in the VIM
by a given consumer.
ETSI
12 ETSI GS NFV-IFA 010 V2.7.1 (2019-09)
• Permitted allowance: maintained at NFVO level. Permitted allowances might vary in granularity (VNFM,
VNF, group of VNFs, NS, etc.) and are used to control resource consumption by VNFMs in relation to the
granularity associated with the permitted allowance.
The detailed requirements on the affected FBs are depicted in clauses 6.1, 7.1 and 8.2.
5.2 General functional requirements for multi-tenancy
Multi-tenancy can be applied to all infrastructure and service resources which can be consumed from an NFV system
and managed by NFV-MANO.
NOTE: The term "resource" as used in the present clause goes beyond the definition of NFV-resource as
specified in the NFV Terminology document (ETSI GS NFV 003 [i.2]).
Figure 5.2-1 shows the entities relevant to multi-tenancy for any kind of resources.
Figure 5.2-1: Entities relevant to multi-tenancy
Each FB may act as multiple tenants on the FBs from which it uses service or infrastructure resources. A service
resource e.g. a VNF can be composed from multiple virtual resources from different tenants. Figure 5.2-2 shows an
example how a VNFM may use tenants on the VIM.
EXAMPLE: The VNF (Resource Group a) is composed out of virtual resources from Resource Group c. The
virtual resources in Resource Group c are assigned to Tenant C. Thus the VNFM has to identify as
Tenant C to modify the virtual resources for VNF (Resource Group a). The VNF (Resource
Group b) uses virtual resources assigned to Tenant D (Resource Group d) and Tenant E. Therefore
the VNFM has to identify as Tenant D or Tenant E or both to modify the virtual resources for
VNF (Resource Group b).
ETSI
13 ETSI GS NFV-IFA 010 V2.7.1 (2019-09)
Figure 5.2-2: Example of how a VNFM may use tenants on a VIM
Since multi-tenancy exists for all kinds of service and infrastructure resources which can be used from an NFV-MANO
service, tenants can be grouped based in the resources they use:
• A tenant to which virtual resources are assigned is referred to as an infrastructure tenant (Tenant C, D, E).
• A tenant to which VNFs are assigned is referred to as a VNF tenant (Tenant A, B).
• A tenant to which NSs are assigned is referred to as a NS tenant.
A resource group has different meaning for different resources which are being used:
• A resource group can be a "service resource group" containing VNFs, PNFs or NSs instances.
• A resource group can be an "infrastructure resource group" containing a set of virtual resources under the
control of a VIM and belonging to a tenant.
ETSI
14 ETSI GS NFV-IFA 010 V2.7.1 (2019-09)
6 Functional requirements for NFVO
6.1 Functional requirements for virtualised resource
management
6.1.1 Functional requirements for general virtualised resource
management
Table 6.1.1-1: Functional requirements for general virtualised resource management
Numbering Functional requirements description
Nfvo.Gvrm.001 The NFVO shall support orchestration of actions related to virtualised resources managed
by one or more VIMs.
Nfvo.Gvrm.002 The NFVO shall support the capability to mitigate conflicts in resource allocation in case of
conflicting resource requests.
Nfvo.Gvrm.003 The NFVO shall support the capability to provide deployment-specific configuration
information for virtualised resources related to NS.
6.1.2 Functional requirements for VNF-related resource management in
indirect mode
Table 6.1.2-1: Functional requirements for VNF-related resource management in indirect mode
Numbering Functional requirements description
Nfvo.VnfRmpbNfvo.001 When VNF-related Resource Management in indirect mode is applicable, the NFVO shall
support the capability to request to the VIM the management of virtualised
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...