ETSI GS NFV-INF 001 V1.1.1 (2015-01)

Network Functions Virtualisation (NFV); Infrastructure Overview

DGS/NFV-INF001

General Information

• Status: Published
• Publication Date: 12-Jan-2015
• Technical Committee: NFV INF - Architecture of the Virtualisation Infrastructure
• Current Stage: 12 - Completion
• Due Date: 19-Jan-2015
• Completion Date: 13-Jan-2015

Standards Content (Sample)

GROUP SPECIFICATION
Network Functions Virtualisation (NFV);
Infrastructure Overview
Disclaimer
This 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-INF 001 V1.1.1 (2015-01)

Reference
DGS/NFV-INF001
Keywords
architecture, NFV
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
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
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
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.

© European Telecommunications Standards Institute 2015.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP 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.
ETSI
3 ETSI GS NFV-INF 001 V1.1.1 (2015-01)
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 . 8
3.1 Definitions . 8
3.2 Abbreviations . 11
4 Objectives of the NFV Infrastructure . 13
4.1 Standardizing Organisations Impacting the NFVI . 14
5 Structure of NFV Infrastructure Architecture Documentation . 14
6 Architectural Principles of the Network Functions Virtualisation Infrastructure (NFVI) . 16
6.1 Virtualisation and Associated Interfaces . 16
6.1.1 Describing and Specifying Network Functions When Virtualised . 16
6.1.2 NFV Interoperability Challenges . 18
6.1.3 Management and Orchestration When Network Functions are Virtualised . 19
6.1.4 Brief Formal Description and Definition of Virtualisation . 20
6.1.5 Standardizing Organisations Impacting Virtualisation and Associated Interfaces . 22
6.2 NFVI and Cloud Computing . 22
6.2.1 Essential Characteristics of Cloud Computing applied to the NFVI . 23
6.2.1.1 On-demand self-service in NFVI . 23
6.2.1.2 Broad network access in NFVI . 23
6.2.1.3 Resource pooling in NFVI . 23
6.2.1.4 Rapid elasticity in NFVI . 23
6.2.1.5 Measured service in NFVI . 24
6.2.2 Service Models impacting the NFVI . 24
6.2.2.1 SaaS. 24
6.2.2.2 PaaS. 24
6.2.2.3 IaaS . 24
6.2.3 Cloud Deployment Models impact on NFVI . 24
6.2.3.1 NFVI as a Private Cloud Infrastructure . 24
6.2.3.2 NFVI Community Clouds . 25
6.2.3.3 Public Cloud and NFVI . 25
6.2.3.4 Hybrid Cloud and NFVI . 25
6.2.4 Standardizing Organisations for Essential Characteristics of Cloud Computing applied to the NFVI . 25
6.3 Domains and Inter-Domain Interfaces . 25
6.3.1 Standardizing Organisations Impacting Domains and Inter-Domain Interfaces . 28
6.4 Multiplicity, Composition, and Decomposition . 29
6.4.1 Principles of Multiplicity . 29
6.4.2 NFVI Implications of Complete and Partial Virtualization of Network Functions . 30
6.4.2.1 Complete and Partial Virtualization . 31
6.4.2.2 Decomposition of VNFs and Relationships between VNFs . 31
6.4.2.3 1:1 VNF Implementation of a Network Element by a VNF . 31
6.4.2.4 N:1 Implementation of a Network Element by Parallel VFNCs . 32
6.4.2.5 1:N Multiplexed Implementation of Multiple Network Elements by a Single VNF . 33
6.4.2.6 Shared Virtual Network Function Component Instances . 34
6.4.2.7 Relationship of Virtual Network Functions to Orchestration . 34
6.4.2.8 Other Aspects of Virtual Network Function Decomposition . 34
6.4.3 Standardizing Organisations Impacting Multiplicity, Composition, and Decomposition . 35
6.5 Economics and Practical Interoperability . 35
ETSI
4 ETSI GS NFV-INF 001 V1.1.1 (2015-01)
6.5.1 Interoperability and Hierarchical Interfaces. 35
6.5.2 Economics and Interoperability . 36
6.5.3 Economic Analysis of Network Function Virtualization . 38
6.6 Key Quality Indicators for the NFVI . 39
6.7 Security Aspects . 39
7 Domains of the NFV Infrastructure . 40
7.1 Compute Domain . 45
7.1.1 Functional Description of the Compute Domain . 46
7.1.2 Compute Node . 46
7.1.3 Functional Description of Storage . 47
7.1.4 Scope of a Compute Node . 48
7.1.5 Standardizing Organisations Impacting the Compute Domain . 48
7.2 Hypervisor Domain . 49
7.2.1 Standardizing Organisations Impacting the Hypervisor Domain. 50
7.3 Infrastructure Network Domain . 51
7.3.1 Standardizing Organisations Impacting the Infrastructure Network Domain . 53
8 Challenges in Performance and Portability of VNFs . 53
8.1 Challenge 1: Processing performance depends on a number of factors . 54
8.2 Challenge 2: Interconnection of VNFs matter, and there are many options . 54
8.3 Challenge 3: Virtualisation may bring portability at the expense of unpredictable performance . 55
8.4 Challenge 4: The environment should be as simple to manage as possible . 56
Annex A (informative): Contacts . 57
Annex B (informative): Bibliography . 58
History . 59

ETSI
5 ETSI GS NFV-INF 001 V1.1.1 (2015-01)
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 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 (http://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.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Network Functions
Virtualisation (NFV).
The present document gives an overview to the series of documents covering the NFV Infrastructure.
Infrastructure Architecture Document Document #
Overview GS NFV INF 001
Architecture of the Infrastructure Compute Domain GS NFV INF 003
Domains
Hypervisor Domain GS NFV INF 004
Infrastructure Network Domain GS NFV INF 005
Architectural Methodology Interfaces and Abstraction GS NFV INF 007
Service Quality Metrics GS NFV INF 010

Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "may not", "need", "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-INF 001 V1.1.1 (2015-01)
1 Scope
The present document presents an overview of the architecture of the NFV Infrastructure (NFVI) which supports
deployment and execution of Virtualised Network Functions (VNFs).
As well as presenting a general overview description of the NFV Infrastructure, the present document sets the NFV
infrastructure and all the documents which describe it in the context of all the documents of the NFV. It also describes
how the documents which describe the NFV infrastructure relate to each other.
The present document does not provide any detailed specification but makes reference to specifications developed by
other bodies and to potential specifications, which, in the opinion of the NFV ISG could be usefully developed by an
appropriate Standards Developing Organisation (SDO).
The overall objectives of the ISG NFV were set out in the white paper [i.1] that led to the founding of the ISG and
updated in the white paper update [i.2].
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
reference 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 ETSI GS NFV 001 (V1.1.1) (10-2013): "Network Functions Virtualisation (NFV); Use
Cases".
[2] ETSI ETSI GS NFV 002 (V1.1.1) (10-2013): "Network Functions Virtualisation (NFV);
Architectural Framework".
[3] ETSI ETSI GS NFV 003 (V1.1.1) (10-2013): "Network Functions Virtualisation (NFV);
Terminology for Main Concepts in NFV".
[4] ETSI ETSI GS NFV 004 (V1.1.1) (10-2013): "Network Functions Virtualisation (NFV);
Virtualisation Requirements".
[5] ETSI GS NFV-PER 002 (V1.1.1) (10-2013): "Network Functions Virtualisation (NFV); Proofs of
Concepts; Framework".
[6] ETSI GS NFV-SEC 001 (V1.1.1) (10-2014): "Network Functions Virtualisation (NFV); NFV
Security; Problem Statement".
ETSI
7 ETSI GS NFV-INF 001 V1.1.1 (2015-01)
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
reference 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] NFV Whitepaper: "Network Function Virtualization", issue 1, (2012).
NOTE: Available at http://portal.etsi.org/NFV/NFV_White_Paper.pdf.
[i.2] NFV Whitepaper: "Network Function Virtualization - Update White Paper", issue 2, (2013).
NOTE: Available at http://portal.etsi.org/NFV/NFV_White_Paper2.pdf.
[i.3] IEEE Cloud Computing 2009: "The Method and Tool of Cost Analysis for Cloud Computing",
Ying Li, Tiancheng Liu, Jie Qiu, Fengchun Wang.
[i.4] IEEE System Science (HICSS) (2012): "Costing of Cloud Computing Services: A Total Cost of
Ownership Approach", B. Martens, M. Walterbusch, F. Teuteberg.
[i.5] TR174 Enterprise-Grade IaaS Requirements Rev1.3.
NOTE: Available at http://www.tmforum.org/TechnicalReports/EnterpriseGradeExternal/50445/article.html.
[i.6] The Open Virtualization Format (OVF) Specification, Version 2.0, 2012, Distributed Management
Task Force.
NOTE: Available at http://dmtf.org/sites/default/files/standards/documents/DSP0243_2.0.0.pdf.
[i.7] Master Usage Model: Compute Infrastructure as a Service, Rev 1, (2012), Open Data Center
Alliance.
NOTE: Available at
http://www.opendatacenteralliance.org/docs/ODCA_Compute_IaaS_MasterUM_v1.0_Nov2012.pdf.
[i.8] Usage Model: Guide to Interoperability Across Clouds, 2012, Open Data Center Alliance.
NOTE: Available at
http://www.opendatacenteralliance.org/docs/ODCA_Interop_Across_Clouds_Guide_Rev1.0.pdf.
[i.9] USAGE: Input/Output (IO) Controls , Rev 1.1., 2012, Open Data Center Alliance.
NOTE: Available at http://www.opendatacenteralliance.org/docs/IO_Controls_Rev_1.1_b.pdf.
[i.10] NIST SP-800-145 (September 2011): "The NIST Definition of Cloud Computing," Peter Mell and
Timothy Grance, US National Institute of Standards and Technology.
NOTE: Available at http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf.
[i.11] Recommendation ITU-T Q.1741: "GSM evolved UMTS core network".
[i.12] ETSI GS NFV-INF 003: "Network Functions Virtualisation (NFV); Infrastructure; Compute
Domain".
[i.13] ETSI GS NFV-INF 004: "Network Functions Virtualisation (NFV); Infrastructure; Hypervisor
Domain".
[i.14] ETSI GS NFV-INF 005: "Network Functions Virtualisation (NFV); Infrastructure; Infrastructure
Network Domain".
ETSI
8 ETSI GS NFV-INF 001 V1.1.1 (2015-01)
[i.15] ETSI GS NFV-INF 007: "Network Functions Virtualisation (NFV); Infrastructure; Methodology
to describe Interfaces and Abstractions".
[i.16] A. Capiluppi, K-J.Stol, C. Boldyreff, "Software reuse in Open Source: A Case Study", Int"l J. of
Open Source Software and Processes, Vol 3. Iss. 3, (2011).
[i.17] NIST SP-800-146: "Cloud Computing Synopsis and Recommendations".
TM
[i.18] IEEE 802.1Q : "Virtual LANs".
TM
[i.19] IEEE 802.1ad : "Support on Provider Bridges".
[i.20] ISO/IEC JTC1 SC 38: "Distributed application platforms and services (DAPS)".
NOTE: Available at
http://www.iso.org/iso/home/standards_development/list_of_iso_technical_committees/jtc1_home/jtc1_s
c38_home.htm.
[i.21] Recommendation ITU-T SG13: "Future networks including cloud computing, mobile and next-
generation networks".
NOTE: Available at http://www.itu.int/en/ITU-T/studygroups/2013-2016/13/Pages/default.aspx.
[i.22] Recommendation ITU-T SG15: "Networks, Technologies and Infrastructures for Transport,
Access and Home".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
container interface: environment within a HFB which is configured in or to realize a VFB
NOTE 1: This includes the configurability and/or programming language of the environment. The container
interface is not an interface between functional blocks.
NOTE 2: Container interface should not be confused with 'containers' as used in the context of Unix type operating
systems as an alternative to full virtual machines.
NOTE 3: The relation between a container interface as defined in the present document and a virtualization
container as defined in the ETSI GS NFV 003 [3] is for further study.
domain: specific part of a larger entity which is useful to separate out based on given criteria
NOTE: Domains can be defined for many different purposes and the features which distinguish domains may
differ in different contexts.
EXAMPLE: The compute domain, hypervisor domain, and infrastructure network domain may not be
administrative domains.
functional block: basis element of a system
NOTE: A Functional Block has interfaces (both input interfaces, output interfaces), can hold state, and evolves its
state and output parameters according to a unchanging transfer function.
Host Functional Block (HFB): functional block which can be configured and/or programmed
NOTE: When suitable configured and/or programmed, a Host Function Block behaves as if it were one or more
functional blocks with a more specific definition. A Host Functional Block is said to host one or more
Virtual Functional Blocks.
ETSI
9 ETSI GS NFV-INF 001 V1.1.1 (2015-01)
hypervisor: piece of software which partitions the underlying physical resources and creates Virtual Machines, and
isolates the VMs from each other
NOTE: The Hypervisor is a piece of software running either directly on top of the hardware (bare metal
hypervisor) or running on top of a hosting operating system (hosted hypervisor). The abstraction of
resources comprises all those entities inside a computer/server which are accessible, like processor,
memory/storage, NICs. The hypervisor enables the portability of VMs to different Hardware.
infrastructure interface: interface between two HFBs
NOTE: An Infrastructure Interface can transport a virtualised interface without placing any dependency on the
particular type of virtualised interface.
Network Element (NE): discrete telecommunications entity, which can be managed over a specific interface, e.g. the
RNC (from Recommendation ITU-T Q.1741 [i.11])
Network Function (NF): Functional Block (FB) within a network infrastructure which has well-defined external
interfaces and well-defined functional behaviour
NOTE: In practical terms, a Network Function is today often a network node or physical appliance.
Network Functions Virtualisation Infrastructure (NFVI): totality of all hardware and software components which
build up the environment in which VNFs are deployed
NOTE: The NFV-Infrastructure can span across several locations, e.g. places where data centres are operated.
The network providing connectivity between these locations is regarded to be part of the NFV-
Infrastructure. NFV-Infrastructure and VNF are the top-level conceptual entities in the scope of Network
Function Virtualization. All other components are sub-entities of these 2 main entities.
NFVI-Node: physical device deployed and managed as a single entity providing the NFVI functions required to
support the execution environment for VNFs
NFVI-PoP: single geographic location where a number of NFVI-Nodes are sited
portability: ability to transfer data from one system to another without being required to recreate or re-enter data
descriptions or to modify significantly the application being transported
Virtual Functional Block (VFB): functional block, defined in a logical, implementation independent way, which is
implemented by configuring a host functional block
NOTE: Programming is a form of configuration.
Virtual Machine (VM): virtualized computation environment which behaves very much like a physical
computer/server
NOTE: A VM has all its ingredients (processor, memory/storage, interfaces/ports) of a physical computer/server
and is generated by a Hypervisor, which partitions the underlying physical resources and allocates them
to VMs. Virtual Machines are capable of hosting a VNF Component (VNFC).
virtualized interface: interface, defined in a logical and abstract way, between two VFBs
virtual network: topological component used to affect forwarding of specific characteristic information
NOTE 1: The virtual network is bounded by its set of permissible network interfaces.
NOTE 2: In the NFVI architecture, a virtual network forwards information among the network interfaces of VM
instances and physical network interfaces, providing the necessary connectivity and ensures secure
isolation of traffic from different virtual networks.
Virtualised Network Function (VNF): implementation of an NF that can be deployed on a Network Functions
Virtualisation Infrastructure (NFVI)
NOTE: A VNF is a VFB which provides exactly the same functional behaviour and interfaces as the equivalent
Network Function.
ETSI
10 ETSI GS NFV-INF 001 V1.1.1 (2015-01)
Virtualised Network Function Component (VNFC): internal component of a VNF providing a VNF
Provider-defined sub-set of that VNF's functionality, with the main characteristic that a single instance of this
component maps 1:1 against a single VM Container Interface
NOTE: A VNFC which has been instantiated and deployed in a VM is called a VNFC Instance. A VNFC which
is part of the resource pool is called a VNFC Resource, and a reserved VNFC is called a Reserved VNFC
Resource. A more general VNF may be a functional composition of a number of VNFCs.
The following definitions relate to the specific domains of the NFVI, the compute domain, the hypervisor domain, and
the infrastructure network domain. Further definitions relating to each domain are contained in each respective domain
architecture document.
accelerator: co-processor or other specialized hardware entity deployed to offload processing, or otherwise improve
performance of software running on a main processor
Central Processing Unit (CPU): device in the compute node which provides the primary container interface
NOTE: The CPU instruction set is the primary runtime and execution language of the compute node. A
programme of CPU instructions loaded into memory and executing is the primary way by which a
compute node acts as a HFB and hosts VFBs. A specific VFB is defined by the specific programme for
that VFB running on the specific CPU.
compute domain: general area for focus which includes servers and storage
NOTE: The compute domain has its own architecture documentation within the Infrastructure architecture.
compute Nnde: single identifiable, addressable, and manageable element within an NFVI-Node that provides
computing resource using compute, storage, and networking functions
NOTE: A Compute Node is normally programmable and can run a hypervisor which supports VM instances.
Stand-alone acceleration devices are also compute nodes.
execution cycle: step in the evolution of state within a compute node
NOTE: Strictly, this can be defined abstractly, in practical terms, this will relate directly to a CPU clock cycle.
gateway node: single identifiable, addressable, and manageable element within an NFVI-Node that implements
gateway functions
hypervisor domain: general area for focus which includes hypervisors
infrastructure connectivity service: connectivity service provided by the infrastructure network domain
NOTE: The Infrastructure Connectivity Services abstract the details of topology, switching equipment, and
protocol/encapsulations of the infrastructure network domain. In practice relevant examples of
Infrastructure Connectivity Service as likely to include E-Line and E-LAN services as defined by
Metro-Ethernet Forum (MEF).
infrastructure network domain: general area for focus which includes all networking which interconnects
compute/storage infrastructure and pre-exists the realisation of VNFs
Network Interface Controller (NIC): device in a compute node which provides a physical interface with the
infrastructure network
network node: single identifiable, addressable, and manageable element within an NFVI-Node that provides
networking (switching/routing) resource using compute, storage, and network forwarding functions
NOTE: This is a node in the NFV Infrastructure network and if the context is not clear should be called an
Infrastructure Network Node.
offload: delegating processing (e.g. classification, forwarding, load balancing, cryptography, transcoding) to a different
processor or other specialized hardware entity
state: set of all parameters held within a functional block
NOTE: For a compute node, in practice, this is the memory (volatile and non-volatile).
ETSI
11 ETSI GS NFV-INF 001 V1.1.1 (2015-01)
storage: non-volatile storage with in the compute domain
NOTE: In practice, this is likely to be implemented as spinning disks or as solid-state disks.
storage node: single identifiable, addressable, and manageable element within an NFVI-Node that provides storage
resource using compute, storage, and networking functions
vCPU: virtualised CPU created for a VM by a hypervisor
NOTE: In practice, a vCPU may be a time sharing of a real CPU and/or in the case of multi-core CPUs, it may be
an allocation of one or more cores to a VM. It is also possible that the hypervisor may emulate a CPU
instruction set such that the vCPU instruction set is different to the native CPU instruction set (emulation
will significantly impact performance).
vNIC: virtualised NIC created for a VM by a hypervisor
vStorage: virtualised non-volatile storage allocated to a VM
vSwitch: Ethernet switch implemented in the hypervisor domain which interconnects vNICs of VMs with each other
and with the NIC of the compute node
NOTE: The vSwitch may be combined with the hypervisor as a single software package or provided as a
standalone piece of software running on top of or aside the hypervisor.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
rd
3GPP 3 Generation Partnership Project
ACL Access Control List
API Application Programming Interface
ASIC Application Specific Integrated Circuit
ATIS Alliance for Telecommunications Industry Solutions
BIOS Basic Input Output System
BSS Business Support System
CDN Content Distribution Network
COTS Commercial Off The Self
CPU Central Processor Unit
CSA [TBC by EG SEC]
CSCF Call Session Control Function
DMA Direct Memory Access
DMTF Distributed Management Task Force
DNS Domain Name System
DPDK Data Plane Development Kit
DPI Deep Packet Inspection
DRAM Dynamic Random Access Memory
E-LAN Ethernet Local Area Network
E-Line Ethernet Line
EPC Evolved Packet Core
ETSI European Telecommunications Standards Institute
FB Functional Block
FIFO First In First Out
GW Gateway
HFB Host Functional Block
HSS Home Subscriber Server
HW Hardware
IaaS Infrastructure as a Service
I-CSCF Interrogating Call Session Control Function
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IMS IP Multimedia Subsystem
INCOSE International Council on Systems Engineering
ISG Industry Specification Group
ETSI
12 ETSI GS NFV-INF 001 V1.1.1 (2015-01)
ISO International Standard Organisation
IT Information Technology
ITU-T International Telecommunications Union - Telecommunications
KLR Kernel Level Rootkits
KQI Key Quality Indicators
KVM Kernel-Based Virtual Machine
LAN Local Area Network
MAC Media Access Control
MANO Management and Orchestration
MEF Metro Ethernet Forum
MME Mobility Management Entity
NAPI Network Application Programming Interface
NE Network Element
NF Network Function
NFV Network Functions Virtualisation
NFVI Network Functions Virtualisation Infrastructure
NFVI-Node Network Functions Virtualisation Infrastructure Node
NFVI-PoP Network Functions Virtualisation Infrastructure Point of Presence
NFVO Network Functions Virtualisation Orchestration
NIC Network Interface Card
NIST National Institute for Standards and Technology
NSI North American Association of State and Provincial Lotteries Standards Initiative
NVF Network Functions Virtualisation
OAM Operations, Administration, and Maintenance
OASIS Organization for the Advancement of Structured Information Standards
OCP Open Computing Project
ODCA Open Data Centre Alliance
OMG Object Management Group
ONF Open Networking Foundation
OS Operating System
OSS Operational Support System
PaaS Platform as a Service
PCEF Policy and Charging Enforcement Function
PCIe Peripheral Component Interconnect - Express
PCRF Policy and Charging Rule Function
P-CSCF Proxy Call Session Control Function
P-GW Proxy Gateway
PSTN Public Switched Telephone Network
RAM Random Access Memory
SaaS Software as a Service
SAN Storage Area Network
S-CSCF Serving Call Session Control Function
SDN Software-Defined Networking
SDN-C Software Defined Networking - Controller
SDO Standards Developing Organisation
S-GW Serving Gateway
SLA Service Level Agreement
SNIA Storage Networking Industry Association
SR-IOV Single Root Input Output Virtualisation
SSD Solid State Disk
SSH Secure Shell
SSO Standards Setting Organisation
SW Software
SWA SoftWare Architecture
TCP Transport Control Protocol
TLS Transport Layer Security
TMF TM Forum
UML Unified Modelling Language
vCPU Virtual Central Processor Unit
VFB Virtual Functional Block
VFND Virtualised Network Function Descriptor
VIM Virtual Infrastructure Manager
ETSI
13 ETSI GS NFV-INF 001 V1.1.1 (2015-01)
VLAN Virtual Local Area Network
VM Virtual Machine
VN Virtual Network
VNF Virtualised Network Function
VNFC Virtualised Network Function Component
VNFD Virtualised Network Function Descriptor
vNIC Virtual Network Interface Card
XML eXtensible Markup Language
4 Objectives of the NFV Infrastructure
The objectives of the Network Function Virtualisation Infrastructure emerge from consideration of the overall
objectives for NFV and the role that the NFVI has in supporting the NFV ecosystem. The NFV Use Cases document [1]
identifies 9 fields of application or use cases for NFV. The NFVI is the totality of the hardware and software
components which build up the environment in which VNFs are deployed [3]. The NFVI is deployed as a distributed set
of NFVI-nodes in various locations to support the locality and latency requirements of the different use cases and the
NFVI provide the physical platform on which the diverse set of VNFs are executed; enabling the flexible deployment of
network functions envisaged by the NFV Architectural Framework [2].
From a functional perspective, the NFVI provide the technology platform with a common execution environment for
the NFV use cases as illustrated in figure 1. The NFVI provide the infrastructure that support one or more of these use
cases simultaneously and is dynamically reconfigurable between these use cases through the installation of different
VNFs.
Figure 1: NFVI as the execution environment for NFV Use cases
ETSI
14 ETSI GS NFV-INF 001 V1.1.1 (2015-01)
The introductory NFV Whitepaper [i.1] envisaged an NFV ecosystem offering integration services as well as
maintenance and third party support. The 2013 White paper update [i.2] reiterated the need for encouraging the
development of an open NFV ecosystem with industry capabilities for the integration of solutions from different
technology providers; where this open and innovative NFV ecosystem supported the porting of VNFs between nodes of
the NFVI. The PoC Framework [5] was developed to further encourage this open global NFV ecosystem through the
integration of components from different technology providers. The NFVI is the technology platform enabling the open
innovation expected in the NFV ecosystem.
The NFV Architectural Framework [2] provides some initial description of the NFVI in clause 7.2.4 of that
specification. The NFV Requirements Specification [4] identifies a number of requirements for an NFVI to fulfil the
role of supporting the execution environment for VNFs. These requirements span areas such as security, Operations and
Maintenance and Service Models.
4.1 Standardizing Organisations Impacting the NFVI
The ETSI NFV ISG is not intended to be a Standards Development Organization (SDO) (see [i.1], page 13); rather the
documentation produced by the ISG, including this specification, should reference the work of existing SDOs and
identify gaps where additional standardization efforts by those SDOs may be required to further enable the NFV
ecosystem.
There are many standards organisations which already have or are progressing standards which are relevant to the NFVI
and these are referenced at the end of each clause of the present document. At the general level, NIST is responsible for
developing terminology for cloud computing applications and infrastructure. Cloud computing is an enabling
technology for network function virtualization. The relationship between cloud computing and NFV is discussed further
in clause 6.2.
The 2013 Operator whitepaper update [i.2] also identifies the relevance of open source approaches as complementary to
formal standardization efforts in the development of reference implementations as a substrate for open innovation in the
NFV ecosystem. Open source developer communities and user communities can be helpful in the further development
of the NFV ecosystem, (e.g. open source communities can provide a mechanism for increased software reuse [i.16]; and
software reuse may increase the efficiency in the NFV ecosystem, as well as enabling more rapid development and
deployment of new services which would support the increased service velocity objective of NFV. Open Source
Communities do exist in support of projects relevant to the NFVI (e.g. the XEN and KVM hypervisors). The NFVI may
include open source software components, but the role and collaboration mechanisms of open source communities in
the NFV ecosystem are beyond the scope of the present document.
5 Structure of NFV Infrastructure Architecture
Documentation
The overall architectural framework for NFV is set out in the "Architectural Framework" document [2]. Figure 4 of that
document provides the NFV reference architectural framework and shows for the NFV Infrastructure (NFVI)
interactions with other parts of the NFV architecture, notably the Virtual Network Function (VNF) architecture (defined
by the SWA Working Group), and the Management and Orchestration architecture (defined by the MANO Working
Group) and well as with existing networks and systems.
NOTE 1: The Architectural Framework [2] is one of four documents covering the overall scope of ISG NFV. The
others documents cover Use Cases [1], Terminology [3], and Requirements [4].
The architecture of the NFV Infrastructure (NFVI) is further separated into three domains, namely the compute domain
(including storage), the hypervisor domain, and the infrastructure network domain. These domains are largely distinct
both at a functional and practical level (see note). The general positioning of these domains within the NFV reference
architectural framework is shown in figure 2.
NOTE 2: Examples of overlap functionality are a virtual Ethernet switch (vSwitch) and an embedded Ethernet
switch in a NIC. These are discussed in more detail in clause 6.
ETSI
15 ETSI GS NFV-INF 001 V1.1.1 (2015-01)

Figure 2: NFV reference architectural framework and identification of NFVI domains
The documentation of the NFVI Architecture is structured as follows:
• Overview Documents. These documents give the overview and set out the feature for the Network Functions
Virtualisation Infrastructure (NFVI):
- Overview of the Architecture of the NFVI (the present document).
- Use Cases of the NFVI.
• Domain Documents. These documents define the architecture of the three domains of the NFVI:
- Compute Domain Architecture.
- Hypervisor Domain Architecture.
- Infrastructure Network Architecture.
• Methodology Documents. These documents set out principles for the specification, construction, and
exploitation of the NFVI:
- Interfaces and Abstraction. The present document set out some of the foundations of virtualisation. In
particular, it describes the way interfaces are specified, the way practical interfaces use an abstract view
of a function, and the way in which a VNF is always a abstract view of a network function.
- Portability and Replicability. The present document set out the way in which the portability of VNFs
between different implementation of NFVI may be assured. In addition, the document set out more
generally the way one implementation of a component either of a VNF or of the NFVI may be replicated
and replaced with another implementation. The present document provides the framework by which
economic analysis including business case analysis can be carried out.
The primary specification of the NFVI is therefore contained in the three domain architecture documents. The
methodology documents contain important information about how the NFVI can be used in order to achieve the benefits
set out in the white paper.
ETSI
16 ETSI GS NFV-INF 001 V1.1.1 (2015-01)
This NFVI Architecture Overview is structured as follows:
• Clause 6 sets out a number of important architectural principles on which the NFVI architecture is based. It
covers a number of underlying foundations which are relied on in developing the more specific architecture of
the NFVI including:
- virtualisation and functional block methodology (clause 6.1)
...