ETSI GS NFV-INF 007 V1.1.1 (2014-10)

Network Functions Virtualisation (NFV); Infrastructure; Methodology to describe Interfaces and Abstractions

DGS/NFV-INF007

General Information

• Status: Published
• Publication Date: 09-Oct-2014
• Technical Committee: NFV INF - Architecture of the Virtualisation Infrastructure
• Current Stage: 12 - Completion
• Due Date: 13-Oct-2014
• Completion Date: 10-Oct-2014

Standards Content (Sample)

GROUP SPECIFICATION
Network Functions Virtualisation (NFV);
Infrastructure;
Methodology to describe Interfaces and Abstractions

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 007 V1.1.1 (2014-10)

Reference
DGS/NFV-INF007
Keywords
interface, 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 2014.
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 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 007 V1.1.1 (2014-10)

Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and abbreviations . 5
3.1 Definitions . 5
3.2 Abbreviations . 6
4 Objectives . 6
4.1 Requirements . 7
4.2 Standardizing Organizations . 7
5 Architectural Principles w.r.t. Interfaces and Abstractions . 7
5.1 System Composition using Functional Blocks . 8
5.1.1 Functional Blocks as the Primary Specification Method . 8
5.1.2 Interconnection of Functional Blocks . 9
5.1.3 Recursive Structure of Functional Blocks . 9
5.1.4 General UML Diagram for Basic Functional Block Methodology . 10
5.2 Extension of Functional Block Methodology to Virtualisation . 11
5.2.1 Virtualisation: Virtual Interfaces and Container Interfaces . 12
5.2.2 Virtual Functions and Host Functions . 13
5.2.3 Recursive Virtualisation . 14
5.2.4 Configuration Lifespan, Operational Interfaces and Configuration Interfaces . 15
5.2.5 Mapping Between VFBs and HFBs . 15
5.2.6 General UML Diagram for Extended Functional Block Methodology . 16
5.3 Describing and Specifying Interfaces and Abstractions . 18
5.3.1 Functional Blocks, Components, Abstractions and Interfaces . 18
5.3.2 Specifying Organizations and Level of Detail . 18
5.4 Types of Interfaces . 18
5.5 Interface Adaptation Mechanisms . 19
5.6 Naming and Versioning . 22
5.7 Discovery of Initiators / Targets and Bootstrapping . 22
5.8 Security . 22
5.9 Performance and Availability . 23
5.10 Error and Anomaly Handling . 23
5.11 Platform Independence and Portability . 23
5.12 Level of Abstraction and Granularity of Interfaces . 24
6 Illustrative Examples . 24
Annex A (informative): Additional Potential Illustrative Examples . 27
Annex B (informative): Authors & contributors . 29
History . 30

ETSI
4 ETSI GS NFV-INF 007 V1.1.1 (2014-10)

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).
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
5 ETSI GS NFV-INF 007 V1.1.1 (2014-10)

1 Scope
The present document describes how Network Functions Virtualisation (NFV) related interfaces and abstractions are to
be derived and specified. It describes the concepts associated with these interfaces and abstractions. It covers the
specification process / methodology in general. It presents a cross-cutting framework which covers compute, hypervisor
and infrastructure network domains, also data, control and management planes.
The present document does not specify all the interfaces and abstractions as these are covered by other documents, e.g.
the NFV INF domain specific documents. Examples of interfaces and abstractions are nevertheless supplied to illustrate
the methodology.
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 development organization (SDO). Furthermore the NFV INF domain specific documents will not
provide detailed specifications either.
2 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.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
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.
Not applicable.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
unicode: unique, unified and universal encoding
zeroconf: zero configuration networking
ETSI
6 ETSI GS NFV-INF 007 V1.1.1 (2014-10)

3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3GPP 3rd Generation Partnership Project
ACL Access Control List
API Application Programming Interface
CLR Common Language Runtime
CPU Central Processing Unit
EJB Enterprise JavaBeans
ETSI European Telecommunications Standards Institute
GS Group Specification
HFB Host Functional Block
IETF Internet Engineering Task Force
ISG Industry Specification Group
IT Information Technology
ITU-T International Telecommunication Union Telecommunication Standardization Sector
JIT Just In Time
JSON JavaScript Object Notation
MANO Management and Orchestration
NFV Network Functions Virtualisation
NIC Network Interface Card
NPU Network Processing Unit
OS Operating System
OVS Open Virtual Switch
OVSDB Open Virtual Switch Database
SATA Serial Advanced Technology Attachment
SDN Software Defined Networking
SDO Standards Development Organization
SR-IOV Single Root I/O Virtualisation
SSL Secure Sockets Layer
TCP Transmission Control Protocol
UML Unified Modelling Language
UTF Unicode Transformation Format
VF Virtual Function
VFB Virtualised Functional Block
VM Virtual Machine
VNF Virtual Network Function
VNIC Virtual Network Interface Card
VT Virtualisation Technology
XML eXtensible Markup Language
4 Objectives
The three key features of the NFV approach are:
1) Separation of the software defining the network function from generic high volume hardware servers, storage
devices and network switches.
2) Independent modularity of the software and hardware components.
3) Automated orchestration which will automate remote installation and management of the virtual functions on
the generic hardware.
ETSI
7 ETSI GS NFV-INF 007 V1.1.1 (2014-10)

4.1 Requirements
The overall vision of Network Functions Virtualisation gives rise to the following overall requirements w.r.t. interfaces
and abstractions:
• Each functional block or component shall be described as an abstraction, documenting the purpose and
behaviour of the functional block or component, and as a set of interfaces to the abstraction.
• The interfaces and abstractions shall be documented at a sufficiently detailed level to permit standardizing
organizations to create specifications for these interfaces and abstractions.
• The NFV ISG is expected to liaise with standardizing organizations in order to ensure that such specifications
are sufficiently detailed to enable interoperability between platforms and devices hosting Virtualised Network
Functions that are offered by different vendors.
• The NFV ISG is expected to liaise with standardizing organizations in order to ensure that such specifications
are decoupled from vendor-specific design and implementation choices within platforms and devices hosting
Virtualised Network Functions.
4.2 Standardizing Organizations
The standardizing organizations that are responsible for creating detailed specifications of each interface and abstraction
are listed in the overview document and in domain specific documents.
Other organizations that define methodologies relevant to interfaces and abstractions include the Object Management
Group (specifically for UML) and the International Council on Systems Engineering (specifically for Systems
Engineering).
5 Architectural Principles w.r.t. Interfaces and
Abstractions
Many network systems, including those specified by 3GPP, IETF, and ITU-T, are specified using the principles of
systems engineering. Each component of the overall system is specified as a functional block and the interactions
between the functional blocks are specified as interfaces.
This clause details the basic functional block based system composition methodology and extends it to cover the
process of virtualisation.
The representation of functional blocks is part of the working methods of many industries as well as different
disciplines and perspectives within those industries. As a result, there is not a clear common representation of functional
blocks which is unambiguous across different industries, disciplines, and perspectives.
As tools that describe functional blocks are most often used by engineers for the design, development and construction
of functional blocks, quite naturally, many tools give considerable emphasis to these phases of the functional block life
cycle. For example, in the construction phase, the reuse of common design features is especially important as reuse
increases efficiency. Many tools therefore give considerable emphasis to the reuse of such features. In this case
classification of functional blocks according to common design features is of considerable value and the natural starting
point for describing functional blocks is the class. It is natural to start by representing a class of functional blocks which
can be built using the same design. The class diagram can also contain hierarchy, for example an inheritance hierarchy,
which can show increasing scope of design reuse at higher levels of the class hierarchy.
However, when describing the operation of functional blocks, the individual instances of functional blocks and the way
individual functional blocks interact with each other are important. In this case the natural starting point is not the class
but the individual instances. Classification and hierarchy of classification is much less relevant at the operations stage.
More important is the way individual functional block instances are interconnected and interact.
ETSI
8 ETSI GS NFV-INF 007 V1.1.1 (2014-10)

There are of course many other aspects to functional blocks which may be important to represent in different way. For
example the nature of what is passed between functional blocks may be important to differentiate. In all information and
network systems, it is information that is passed between the functional blocks. However, even in this narrow category,
in may be important to distinguish a continuous flow of information from discrete events. More general systems may
pass fluid (pressure and flow), electricity (voltage and current), rotation (revs and torque), money, etc.
The present document is concerned with the basic characteristics of information functional blocks. We can assume that
all the parameters passed between functional blocks are information of one form or another.
This clause considers some of the basic properties of information functional blocks. It focuses on the case where a
functional block such as a server or a network acts as a host functional block, hosting virtual functional blocks such as
virtual machines and virtual networks.
In this case, it is important to highlight the properties of functional blocks in operation and so all the discussion and
diagrams in the present document show functional block instances (and not classes of functional blocks) unless
otherwise stated.
5.1 System Composition using Functional Blocks
5.1.1 Functional Blocks as the Primary Specification Method
The great majority of specification of telecommunications systems specifies functional blocks using the methodology of
systems engineering. A functional block is the basic unit of a system and its specification can and should be precise.
A functional block, that is a single functional block instance, consists of:
• A set of input interfaces.
• State.
• A transfer function.
• A set of output interfaces.
When describing practical functional blocks, the interfaces may be described such that an input interface is paired with
an output interface. This is normally convenient when describing the interconnection between functional blocks.
When considering the functional block at its most fundamental level, the proper operation of a functional block is causal
and the flow of causality from input to output is central to the methodology. In this case is normally more convenient to
consider all input as separate from all outputs. A fundamental view of a functional block illustrated in Figure 1.

Figure 1: The fundamentals of a functional block
There a number of fundamental properties of functional blocks:
• The transfer function is fixed and defining of the functional block.
• The set of all possible values of state is fixed and is defining of the functional block.
• The set of all possible input values is fixed and is defining of the functional block.
ETSI
9 ETSI GS NFV-INF 007 V1.1.1 (2014-10)

• The set of all possible output values is fixed and is defining of the functional block.
• The transfer function is the set of mapping from a specific value of tuples of input and state to a specific value
of tuple of output and state.
• The state is the ability of the evolution of the functional block to be dependent on historic inputs and not just
on the current input.
• The process of acquiring the current input value, the current state value, calculating the transfer function
mapping, and setting the next state value and the next output value takes a finite amount of time.
• The exact amount of time may vary with each specific mapping.
A central property of functional blocks is the complete and formal separation of the static from the dynamic. Using a
more IT oriented terminology, the input, output, and internal (i.e. state) data structures and all the methods (i.e. the
transfer function) and static. They shall not change. Only the values of data within the data structures can change; these
values are the only things which are dynamic.
For standardized functional blocks, in order to ensure proper interoperability, the goal would normally be to fully define
all the static parameters of the functional block in the standard.
5.1.2 Interconnection of Functional Blocks
Having defined what a functional block is from the inside, the next fundamental property of a functional block the
ability to interconnect functional blocks. This is achieved by connecting an output interface of one functional block with
the input interface of another functional block. For this to work the following shall be true.
• The data structure of the output interface of the functional block on side of the interconnection shall be
compatible with the data structure input interface of the functional block on the other side of the
interconnection. The output set of values shall a subset of the input set of values.
This interconnection of interfaces is called an interface binding. This arrangement is illustrated in Figure 2.

Figure 2: Interconnection of functional block with interface bindings
As illustrated in Figure 2, when a number of functional blocks are interconnected all together, the interface bindings
form a topology between the functional blocks.
5.1.3 Recursive Structure of Functional Blocks
When a number of functional block are interconnected in a topology, some input interfaces and some output interfaces
remain. A fundamental property of the functional block methodology is that the entity as viewed through these
remaining input and output interfaces is also a functional block and meets all the properties of a single functional block.
ETSI
10 ETSI GS NFV-INF 007 V1.1.1 (2014-10)

This is illustrated in Figure 3.

Figure 3: Recursive property of functional blocks
This means that functional blocks have a fundamental recursive property. A larger functional block can be created by
aggregating a number of a smaller functional block and interconnecting them with a specific topology.
Another fundamental property of functional blocks which is immediately apparent from this recursive property is that
functional blocks are inherently parallel, concurrent, and asynchronous. Any sequential and synchronous properties will
arise only as a special case, normally by imposing explicit design constrains on the static properties of all the
constituent functional blocks.
5.1.4 General UML Diagram for Basic Functional Block Methodology
It is possible to summarize the basic entities of the functional block methodology using a UML class diagram. UML
class diagrams show classes, that is, sets of things which all have the same property. Most often classes in UML class
diagrams are there to define the construction of members, often called instances, of the class. In this way, members of
the class have the same properties because the class definition from the class diagram is used directly to create the
instances. However, the class can also be used to categorize things even if they were not created directly by the
specification. They can be classified in retrospect, rather by design.
The ability to classify in retrospect is important for many aspects of practical systems. Generally component functional
blocks are designed, built, and made operational at different times and often it is not possible to change existing
functional blocks when introducing new components. The UML diagrams used here show general classification, and
instances of functional block classes may be classified as instances of the classes in the diagram after they have been
designed, built, and made operational.
UML class diagrams show classes and relationships between classes. A relationship is shown between two classes. Two
completely different type of relationship are as follows.
• Generalization (also called inheritance). This relationship shows that two classifications are different
viewpoints of the same thing. The instances of the classes are the same instances. The relationship is often
referred to as an 'is a' relationship. In UML, generalization is shown by an open triangular arrowhead
• Associations. These are relationship between two separate instances which interact with each other. UML
allows three different strengths of association:
- Association. General interaction between instances.
- Aggregation. An association where the instance on one class is a component part of an instance of the
other class.
- Composition. An aggregation where the existence of the component instance depends on the existence of
the aggregate instance.
ETSI
11 ETSI GS NFV-INF 007 V1.1.1 (2014-10)

package Data[  basic functional block]
Input Interface Output Interface
Transfer State
Function
Interface
1.*
1 1 1
Functional Block
Component List
1 1.*
Binding List
Component List
Binding List
1.*
Interface Binding
Figure 4: UML class diagram of functional blocks
Figure 4 shows a UML class diagram of functional blocks (note the functional block class is called virtual function for
consistency with the following clause). The diagram specifies the three basic parts of a functional block (transfer
function, state, interfaces), the ability to bind interfaces, as well as the property of recursive composition. Note that this
use of composition is different to the UML definition.
5.2 Extension of Functional Block Methodology to Virtualisation
Functional block methodology does not anticipate or direct support virtualisation. However, the foundations of the
methodology are very general and mathematically robust. It is still possible therefore to understand virtualisation in
terms of functional blocks. This clause develops the extension of the methodology in terms which are still fully based
on the same general, mathematical principles and so still retains the formal robustness of the methodology.
In summary, the essence of virtualisation is to revisit the boundary between the static and dynamic parts of the
functional block specification. We will see that virtualisation uses a process with the following steps:
• A host function has some dynamic state which can be set to a value (configured) and held constant for a
prescribed period of time (which will be the lifetime of the virtualised function).
• This configuration allows the host to appear to operate according to the specification of the virtualised
function - this configuration of the host implements the virtualised function.
In fact, it is the case that all implementation is exactly this process. It is indeed, this mechanism of virtualisation that
allows any implementer freedom to choose and optimize their own implementation of the virtual function. Moreover,
all implementation independent specification is a specification of a virtual function.
ETSI
12 ETSI GS NFV-INF 007 V1.1.1 (2014-10)

This means that the requirement to extent the method of functional blocks to NFV has also provided a complete and
robust solution to implementation independent specification.
5.2.1 Virtualisation: Virtual Interfaces and Container Interfaces
Figure 5 shows an illustrative set of interconnected functional blocks. For the purposes of illustration, we will now
consider what happens when the second two are implemented as virtualised functions on a host function.

Figure 5: Illustrative set of interconnected functional blocks
Figure 6 shows the results of this process.

Figure 6: Implementation of two functional blocks as virtualised functions on host functions
This process has resulted in the following:
• The division of a functional block between a host functional block (HFB) and a virtualised functional block
(VFB).
• The creation of a new container interface between the HFB and the VFB it is hosting.
NOTE: The use of 'container' in this context is general and is consistent with its use over many years for the
hosting of remotely deployable executable modules such as Enterprise Java Beans (EJB). It's use should
not be confused with the use of the term for a specific Linux technology of protected execution domains
which are not full virtual machines.
• The division of the interface between the two network functions which are now virtualised between an
infrastructure interface and a virtualised interface.
• The interface to the non-virtualised functional appears to be a homogeneous interface at its end with the non-
virtualised function, however, at its virtualised end, it appears to be divided between an infrastructure interface
and a virtualised interface.
However, in carrying out this process, there are two very important distinctions from the standard functional block
description:
• The VFB is not a functional block independent of its HFB.
• The container interface is not an interface between functional blocks equivalent to other interfaces.
ETSI
13 ETSI GS NFV-INF 007 V1.1.1 (2014-10)

This arises as the VFB cannot exist autonomously in the way a functional block can. The VFB depends on the host
function for its existence, and if the host function were to be interrupted, or even disappear, then the VFB is also be
interrupted or disappear. Likewise, the container interface reflects this existence dependency between a VFB and its
host function.
The relationship between the VFB and its HFB is:
• the VFB is a configuration of the host function;
• the VFB is an abstract view of the HFB when the HFB is configured to be the VFB.
Therefore a HFB, when configured as a VFB, has the external appearance as being a functional block implementing
the VFB specification. It is the HFB that is the functional block but it appears from the outside to be the VFB.
Equivalently, the VFB is an abstract view of the HFB.
5.2.2 Virtual Functions and Host Functions
The interesting property of virtualisation is the things that are predefined. As set out above, the data structures defining
the value ranges of the inputs, outputs, and state are all predefined, as is the transfer function. These are static to the
functional block and defining of the functional block. Defining these static parameters fully specifies the functional
block. The specific values of the inputs, outputs, and state are dynamic to the functional block and are not part of its
specification.
With this background to the formal definition of a functional block, this can be developed to formally define
virtualisation. This is set out in the four steps shown in Figure 7.

Figure 7: Functional Block Virtualisation Process
The first step shows a generic functional block with inputs, outputs, state, and a transfer function.
The second step shows the state of the functional block partitioned into three distinct types of state:
• state which holds the dynamic state which is private to the host function;
• state which will be configured and then held constant and invariant during the life of the virtualised function
and which defines the virtualised function;
• state will hold the dynamic state of the virtualised function;
ETSI
14 ETSI GS NFV-INF 007 V1.1.1 (2014-10)

This second step shows the essence of virtualisation: this fixing of some of the host's state so that it is held constant for
the life of the virtualised function. The state which is available for fixing is the aspect of the container interface that
allows the virtual function to be defined.
The third step shows how this fixed state combines with this host transfer function in order to define the transfer
function of the virtualised function. This combination of the fixed state and the host transfer function allows the virtual
function to execute.
The fourth step shows how the range of values defined for the host input and output interfaces are partitioned so that
only those values which control the execution evolution of the virtual function are identified as belonging to the virtual
interfaces of the virtual function. The virtual input interface is therefore defined as a subset of the range of values of the
host function's input interface. Similarly, the virtual output interface is defined as a subset of the range of values of the
host function's output interface. The behaviour of the virtual function as perceived through the virtual interfaces, is now
exactly that of the virtual function.
With this formal definition of virtualisation, it demonstrates:
• a VFB is a configuration of its HFB;
• a VFB is an abstract view of the HFB when appropriately configured.
5.2.3 Recursive Virtualisation
Having defined the process of virtualisation, if can now be seen that the process is fully recursive. An operating virtual
function block can itself be a host functional block. This is illustrated in Figure 8.

Figure 8: Fully recursive nature of virtualisation of functional blocks
A point of which emerges from this view is when the recursion is viewed 'downwards' to look at the nature of a HFB.
We see that a HFB is itself a VFB. This is actual a statement of the observation that any functional block is itself an
implementation.
The following are consequences of the recursive nature of virtualisation:
• Implementation is a process of hosting.
• The means of achieving an implementation independent specification is to specify a virtual function.
• There is no 'bottom' to the recursion meaning that there is no 'atomic' level of implementation.
• There is normally a useful level of implementation visibility, however, this is selected based on practical
consideration.
NOTE: While it would not normally be of any practical relevance to NFV, the concept of host configuration does
include manual configuration of the spatial configuration of elements. In other words, the sitting and
installation of physical equipment together with the plugging in of physical interfaces is still a logical
configuration.
ETSI
15 ETSI GS NFV-INF 007 V1.1.1 (2014-10)

5.2.4 Configuration Lifespan, Operational Interfaces and Configuration
Interfaces
Having precisely defined the process of virtualisation, it can be seen that the existence of a VFB depends precisely on
the specific configuration of the HFB which is hosting the VFB. Given that the definition of a functional block requires
that the transfer function is static and is defining of the functional block, this means that the configuration which creates
the VFB shall not change during the lifespan of the VFB. Indeed, the lifespan of the VFB is defined by the period
during which the configuration which defines it remains unchanged.
This means that there is a profound and fundamental difference between input interfaces of the HFB which determine
the configuration state from the input interfaces which determine the dynamic state of the VFB. This distinction can
define a formal partitioning of the HFB interfaces:
• HFB configuration interfaces which allow the creation/destruction of VFBs. The data structure of these
interfaces is, by definition, a programming language.
• VFB operational interfaces which are the virtual interfaces to the VFBs.
• Host private interfaces which control aspects of the HFB which are neither part of the definition VFB or the
operational interfaces of the VFB, control aspects private to the HFB.
This partitioning of the HFB interface is illustrated in Figure 9.

Figure 9: Partitioning the interfaces of a HFB
5.2.5 Mapping Between VFBs and HFBs
The functional block methodology is fundamentally parallel and concurrent. This means that VFBs and HFBs may be
distributed with high degrees of concurrency.
This means that, when decomposed, the mapping of VFBs to HFBs may be a complex many to many relationship. In
particular:
• one HFB may host more than one VFB;
• A single VFB may be hosted across many HFBs.
This complex mapping may be viewed in two ways:
• The mapping arises from the configuration of HFBs which created the VFBs and there the mapping is simply
an observation of has is in actual operation.
• HFBs has certain properties based on their level of concurrency which will place constraints on the time
required for some specific states to evolve and this will place significant constraints on the mapping if certain
performance for the evolution of state is required.
ETSI
16 ETSI GS NFV-INF 00 007 V1.1.1 (2014-10)

The second of these is especially importantt wwhere state is required across state which will be commoon across
geographically distributed HFBs. Managingg t this constraint on the mapping between VFBs and geoggrraphically
distributed HFBs is very often a primary desiesiggn consideration for the performance and/or stability o off an end to end
VFB.
This mapping is illustrated in Figure 10.

Figururee 10: Mapping of VFBs to HFBs
5.2.6 General UML Diagrraam for Extended Functional Block MeMethodology
It is possible to extend the UML class diagraramm to include virtualisation. This is shown in Figure 11. TThe primary
extension is the inclusion of the generalizatiotion that a virtual functional block 'is a' host functional blloock. The hosting
aspects now have the configuration interfacesces and the private interfaces. The mapping of VFBs to ththeire hosting HFBs is
shown by an association.
Figure 12 further extends this to also depict tht the relationship data structures.
ETSI
17 ETSI GS NFV-INF 007 V1.1.1 (2014-10)

package Data[  VFB and HFB]
Functional Block
VFB List
Virtual Functional Block
1.* 1
<> VFB List
HFB List
HFB List
1 1.*
Host Functional Block
+load and activavte( : Host Specific Configuration )

Figure 11: UML class diagram of functional blocks including virtualisation
package Data[  mano data structures]
Configuration
State
Functional Block
Component List
1 1.*
Component List
Binding List
Binding List
Virtual Functional Block
1.*
1.* 1 Interface Binding
<> VFB List
HFB List
1 1.*
Host Specific Configuration
«use»
Host Functional Block
+load and activavte( : Host Specific Configuration )
VFB List HFB List
Figure 12: Functional blocks with relationship data structures
ETSI
18 ETSI GS NFV-INF 007 V1.1.1 (2014-10)

5.3 Describing and Specifying Interfaces and Abstractions
5.3.1 Functional Blocks, Components, Abstractions and Interfaces
As detailed in the previous clause, a significant, fundamental principle of the systems engineering approach is that the
complete system is specified by the specification of the component functional blocks and their interconnection, and all
components are always functional blocks.
The term abstraction is used to refer to the high level description of the required behaviour of a functional block or
component. For a more specific definition of the term abstraction, refer to clause 7.
5.3.2 Specifying Organizations and Level of Detail
Note that the specification of standards related to NFV is delegated to individual standardizing organizations. The
descriptions of interfaces and abstractions produced by the NFV ISG therefore need to be sufficiently detailed to clearly
document requirements for such specifications, but not detailed enough to constitute actual specifications.
The present document recommends minimum standards w.r.t. describing interfaces. (These only apply to the interfaces
that are described / specified.) NFV working groups need to at least discuss each aspect when describing interfaces in
order to make informed and deliberate decisions when deviating from the recommended minimum standards.
Note that not all interfaces and abstractions need to be specified. The focus needs to be on specifying those that affect
critical aspects of the overall system's behaviour, e.g. interoperability. Additional guidance is supplied in clause 7.
Perspectives w.r.t. Abstractions:
1) Build time
2) Run time
3) Configuration time (e.g. as viewed by MANO)
5.4 Types of Interfaces
Hardware interfaces permit access to e.g. the network (Ethernet), storage (SATA) etc. As these are manipulated and
accessed via a software interface (a "driver" 
implemented as a user mode library or a kernel mode entity), these are
represented as the software interface, and therefore not discussed separately.
Callable interfaces ("APIs") can be invoked directly by software, provided appropriate language bindings are supplied.
They may be implemented by local procedures, by stubs that invoke remote procedure calls, or by software which
invokes kernel or hypervisor facilities to implement the required behaviour.
Protocol based interfaces are specified by documenting the protocol details. The required protocol is typically specified
with reference to an underlying transport (e.g. TCP or SSL), or by referring to a standard marshalling format.
Protocol stacks can be used to supply callable interfaces for protocol based interfaces. Conversely a callable interface
can be turned into a protocol based interface by specifying a remote procedure call protocol.
As the NFV ISG merely supplies requirements that are to be conveyed to standards development organizations, the
details w.r.t. callable or protocol based interfaces should not be specified by the NFV ISG. Whether interfaces should be
callable, protocol based, or hardware based, and the required behaviour would typically be specified. In cases where
interfaces are not specified to be protocol based or callable, the semantics implied by the interface being standardized as
being callable or protocol based need to be considered.
The behaviour of interfaces and the behaviour of the associated abstractions need to be specified in sufficient detail.
...