ETSI GS NFV-IFA 002 V2.1.1 (2016-03)

ETSI GS NFV-IFA 002 V2.1.1 (2016-03)
GROUP SPECIFICATION
Network Functions Virtualisation (NFV);
Acceleration Technologies;
VNF Interfaces 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.

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

If you find errors in the present document, please send your comment to one of the following services:

No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying

The content of the PDF version shall not be modified without the written authorization of ETSI.

DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.

3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and

GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.

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 ........................................................................................................................................ 6

3 Definitions and abbreviations ................................................................................................................... 7

3.1 Definitions .......................................................................................................................................................... 7

3.2 Abbreviations ..................................................................................................................................................... 8

4 Overview .................................................................................................................................................. 9

4.1 Problem Statement ............................................................................................................................................. 9

4.1.1 VNF Acceleration goals ................................................................................................................................ 9

4.1.2 Network related acceleration ...................................................................................................................... 11

4.1.3 Storage related acceleration ........................................................................................................................ 11

4.1.4 Algorithmic acceleration ............................................................................................................................. 11

4.2 Software architecture ........................................................................................................................................ 12

4.2.1 Overview .................................................................................................................................................... 12

4.2.2 Acceleration model ..................................................................................................................................... 12

4.2.2.1 General .................................................................................................................................................. 12

4.2.2.2 VNF aspects .......................................................................................................................................... 13

4.2.2.3 Virtualisation Layer aspects .................................................................................................................. 14

4.2.2.4 Intra-VNF acceleration .......................................................................................................................... 15

5 Abstract Interface functional requirements ............................................................................................ 17

5.1 Overview .......................................................................................................................................................... 17

5.2 Common Acceleration Virtualisation interface requirements .......................................................................... 18

5.3 EPD Driver requirements ................................................................................................................................. 18

5.4 Cryptography functional group ........................................................................................................................ 19

5.4.1 Overall requirements................................................................................................................................... 19

5.4.2 Operations requirements ............................................................................................................................. 19

5.4.3 Crypto interface requirements..................................................................................................................... 20

5.4.4 Crypto driver requirements ......................................................................................................................... 20

5.4.5 Management and monitoring requirements ................................................................................................ 20

5.5 IPSec offloading functional group .................................................................................................................... 20

5.5.1 Overview .................................................................................................................................................... 20

5.5.2 IPSec offloading interface requirements ..................................................................................................... 21

5.5.3 Operations requirements ............................................................................................................................. 21

5.5.4 Management and monitoring requirements ................................................................................................ 21

5.6 TCP offloading functional group ...................................................................................................................... 21

5.6.1 TCP offloading interface requirements ....................................................................................................... 21

5.6.2 TCP offloading type requirements .............................................................................................................. 22

5.7 Storage functional group .................................................................................................................................. 22

5.7.1 NVMe Over Fabric ..................................................................................................................................... 22

5.7.1.1 Overview ............................................................................................................................................... 22

5.7.1.2 Interface requirements ........................................................................................................................... 22

5.8 Re-programmable computing functional group ................................................................................................ 22

5.8.1 Re-programmabe interface requirements .................................................................................................... 22

5.8.2 Operations requirements ............................................................................................................................. 22

5.8.3 Management and monitoring requirements ................................................................................................ 23

5.9 Dynamic Optimization of Packet Flow Routing Functional Group ................................................................. 23

5.9.1 DOPFR interface requirements ................................................................................................................... 23

5.9.2 Management and monitoring requirements ................................................................................................ 23

5.10 NAT offloading functional group ..................................................................................................................... 23

5.10.1 Overview .................................................................................................................................................... 23

5.10.2 Overall requirements................................................................................................................................... 23

5.10.3 NAT offloading interface requirements ...................................................................................................... 24

5.10.4 NAT offloading Operations requirements .................................................................................................. 24

5.10.5 Management and monitoring requirements ................................................................................................ 24

5.11 VXLAN offloading functional group ............................................................................................................... 24

5.11.1 Overview .................................................................................................................................................... 24

5.11.2 Overall requirements................................................................................................................................... 24

5.11.3 VXLAN offloading interface requirements ................................................................................................ 24

5.11.4 VXLAN offloading operations requirements.............................................................................................. 25

5.11.5 Management and monitoring requirements ................................................................................................ 25

5.12 Media functional group .................................................................................................................................... 25

5.12.1 Overview .................................................................................................................................................... 25

5.12.2 Media overall requirements ........................................................................................................................ 25

5.12.3 Media operations requirements ................................................................................................................... 25

5.12.4 Media interface requirements ..................................................................................................................... 26

5.12.5 Management and monitoring requirements ................................................................................................ 26

Annex A (informative): Authors & contributors ................................................................................. 27

Annex B (informative): Bibliography ................................................................................................... 28

Annex C (informative): Change History .............................................................................................. 29

History .............................................................................................................................................................. 30

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

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

This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Network Functions

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

"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

The present document specifies requirements for a set of abstract interfaces enabling a VNF to leverage acceleration

services from the infrastructure, regardless of their implementation. The present document also provides an acceleration

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 documents which are not found to be publicly available in the expected location might be found at

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee

The following referenced documents are necessary for the application of the present document.

[1] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for main concepts in

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

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee

The following referenced documents are not necessary for the application of the present document but they assist the

[i.1] ETSI GS NFV-INF 003: "Network Functions Virtualisation (NFV); Infrastructure; Compute

[i.2] ETSI GS NFV-SWA 001: "Network Functions Virtualisation (NFV); Virtual Network Functions

[i.3] ETSI GS NFV-IFA 003: "Network Functions Virtualisation (NFV); Acceleration Technologies;

[i.4] ETSI GS NFV-IFA 004: "Network Functions Virtualisation (NFV); Acceleration Technologies;

[i.6] ETSI GS NFV-INF 005: "Network Functions Virtualisation (NFV);Infrastructure; Network

[i.7] ETSI GS NFV-IFA 001: "Network Functions Virtualisation (NFV); Acceleration Technologies;

For the purposes of the present document, the terms and definitions given in ETSI GS NFV 003 [1] and the following

abstract interface: computer specification and modelling construct. It defines an information model and a way to

NOTE: Computing objects and APIs can be developed for a programming language to implement it.

Application Programming Interface (API): computer programming language construct, composed of a set of

functions, methods, objects, structures and constant definitions used to implement an abstract interface

NOTE: This construct is called an abstract interface language binding. There might be multiple bindings to a

single abstract interface, one for each computer language (C, C++, Java™, Ruby, PHP, etc.).

dispatching: deterministic method of distributing packets amongst packet queues to be handled by the network stack,

NOTE: This dispatching can be done by an operating system or a software library such as DPDK or ODP. The

criteria for dispatching can be as simple as round robin or as complex as packet hashing on combination

of IP address, TCP ports, taking into account tunnelling. The number of processor threads handling the

extensible para-virtualised device: para-virtualised device that can execute code and use resources provided by the

NOTE: The benefit of the extensibility is to avoid crossing virtualisation boundary whenever it is possible. The

Execution Environment (EE): set of resources and control mechanisms on which application are running

NOTE 2: An Execution Environment may be virtualised on top of a hypervisor or not.

NOTE 3: Execution Environments may share or not resources such as processor between applications running on

language binding: API definition for an abstract interface on a particular programming language

library: collection of implementations of behaviour, written in terms of a language that has a well-defined interface by

NOTE: This means that as long as a higher level program uses a library to make system calls, it does not need to

be re-written to implement those system calls over and over again. In addition, the behaviour is provided

for reuse by multiple independent programs. A program invokes the library-provided behaviour via a

mechanism of the language. For example, in a simple imperative language such as C, the behaviour in a

library is invoked by using C's normal function-call. What distinguishes the call as being to a library,

versus being to another function in the same program, is the way that the code is organized in the system.

load balancing: dynamic application level traffic distribution function, that distributes traffic amongst VNFC instances

offload: delegate processing (e.g. classification, forwarding, dispatching, load balancing, cryptography, and

Real Time Application (RTA): application whose execution can be guaranteed to be accomplished under a specific

NOTE: For instance within a bounded delay, for a certain bandwidth. It assumes execution on a Real Time

Real Time Execution Environment (RTEE): Execution Environment that offer applications with provisions to meet

Real Time Operating System (RTOS): Real Time Execution Environment in the form of an Operating System

NOTE: An RTOS has an advanced algorithm for scheduling. Scheduler flexibility enables a wider,

computer-system orchestration of process priorities, but a real-time OS is more frequently dedicated to a

narrow set of applications. Key factors in a real-time OS are minimal interrupt latency and minimal thread

switching latency; a real-time OS is valued more for how quickly or how predictably it can respond than

software framework: abstraction in which software providing generic functionality can be selectively changed by

NOTE 1: A software framework is a universal, reusable software environment that provides particular functionality

as part of a larger software platform to facilitate development of software applications, products and

solutions. Software frameworks may include support programs, compilers, code libraries, tool sets, and

application programming interfaces (APIs) that bring together all the different components to enable

NOTE 2: Frameworks contain key distinguishing features that separate them from normal libraries:

Inversion of control: In a framework, unlike in libraries or normal user applications, the overall

Default behaviour: A framework has a default behaviour. This default behaviour is some useful

Extensibility: A framework can be extended by the user usually by selective overriding or

Non-modifiable framework code: The framework code, in general, is not supposed to be modified,

while accepting user-implemented extensions. In other words, users can extend the framework, but

For the purposes of the present document, the abbreviations given in ETSI GS NFV 003 [1] and the following apply.

• to identify common design patterns that enable an executable VNFC to leverage, at runtime, accelerators to

• to describe how a VNF Provider might leverage those accelerators in an implementation independent way; and

• to define methods in which all aspects of the VNF (VNFC, VNFD, etc.) could be made independent from

• VNFs might have constraints to perform their function within certain power consumption boundaries, CPU

Use of accelerators can help meet the constraints but can have an influence on deployment flexibility. VNF acceleration

implementations will range from inflexible software that is tightly-coupled to specific software and hardware in the

VNF and NFVI (see pass-through model as shown in figure 4.1.1-1), to highly flexible loosely-coupled software that

uses common abstractions and interfaces (see abstracted model as shown in figure 4.1.1-2). Further it is understood that

virtualisation and acceleration technologies will evolve. Pass-through deployments are expected to exist, and the present

document does not intend to preclude any specific acceleration architectures from NFV deployments. However, the

It is desirable that the use of accelerators be implementation independent. There is a slight difference between

"implementation independent executable VNFC" and "implementation independent VNF":

• An implementation independent executable VNFC is a software that can leverage a known set of accelerator

implementations both in hardware and in software. The part of the VNFD that applies to this VNFC contains

information elements that allow the NFV management and orchestration to find a compute node with the

requested characteristics or hardware. Should a new hardware become available on the market, a VNF

Provider willing to make use of it to accelerate a VNFC has to update it's the VNFC image and the VNFD, the

operator has to on-board the new VNF package and redeploy it to make use of the new hardware. This was

• An implementation independent VNF is a VNF that makes no assumption whatsoever on the underlying

NFVI. Its VNFD does not contain any accelerator specific information elements. Should a new hardware

become available on the market, the operator will update its NFVI to allow the VNF to make use of the new

hardware. An implementation independent VNF is thus based on implementation independent VNF software

that makes use of a functional abstraction of an accelerator supported by an adaptation layer in the NFVI. This

model is close to the abstracted model defined in ETSI GS NFV-INF 003 [i.1], clause 7.2.2.

NOTE 1: An implementation independent executable VNFC allows for VNF deployment in both hypervisor based

and non-hypervisor based environments. The latter configuration is outside the scope of the present

Live migration of such hardware independent accelerated VNF may be possible if any associated acceleration state

NOTE 2: Live migration from a compute node with accelerator to a compute node without accelerator or with a

different accelerator is allowed (in particular to cope with emergency response situations).

A further refinement of the aforementioned goals is to make sure that VNFs can leverage those accelerators regardless