NFV aims to virtualize network functions that were traditionally run on dedicated hardware appliances. This allows the functions to run on commercial off-the-shelf servers and switches in data centers. NFV promises to reduce costs, increase flexibility and speed up innovation cycles compared to proprietary hardware appliances. A key enabler is virtualization technology which allows multiple virtual machines to run in isolation on shared server hardware through the use of hypervisors.

1. 1 © Nokia 2018
Network Function
Virtualisation
Public
A tutorial
• Paresh Khatri
• Feb 27, 2018

2. 2 © Nokia 2018
1. Introduction
2. Virtualisation for network engineers: a primer
3. ETSI NFV ISG Framework:
a. NFVI
b. MANO
c. VNFs
4. Performance
5. Open source
6. State of industry
Public
Agenda

3. 3 © Nokia 2018
introduction
Public

4. 4 © Nokia 2018 Public
Specialization versus generalization
… repeating cycle of technology evolution
Specialization Generalization
• Ability to finely
tune and optimize
for high
performance
• High efficiency
• Limited to specific
functions
• Limited flexibility
• Higher cost due to
reduced economies
of scale
• Flexibility – ability
to perform
multiple, diverse
functions
• Lower cost due to
economies of scale
• Not overly efficient
at any one
particular task
• Lower efficiency
and performance
… NFV is the latest phase in this cycle

5. 5 © Nokia 2018 Public
The evolution of the humble router
1969
Interface
Message
Processor (IMP)
• Router for the first
TCP/IP network –
ARPANET
• Ruggedized Honeywell
DDP-516 minicomputer
• Special-purpose
interfaces and software
1981
Multi-protocol
routers
• Stanford/MIT
researchers
• IP/AppleTalk/DECnet/
Xerox protocols
• General-purpose
mini-computers
Late 1990s
Internet-scale
routers
• Very-high throughput
based on specialised
forwarding ASICs
• Optimized for IP
Early 2000s
Multi-service
routers
• Continued hardware
evolution
• Programmable
network processors
• Optimized for multi-
services over IP
Basic packet
processing in
software
Addition of QoS,
access control,
control plane
protocols
Optimization of
hardware for line-
rate performance
Programmable
hardware, massive
parallel
processing, L4-7
services

6. 6 © Nokia 2018
When faced with new or different
problems, “we” have…
Public
Solving network-layer problems
developed new protocols
optimised with new hardware

7. 7 © Nokia 2018
So what’s the problem, really ?
Anatomy of a telco application (ATCA)
System Control & Management Cards
® Specialised OAM middleware
I/O and load distribution
® Specialised application middleware
Application Function A
® More cards for more capacity
Application Function B
® More (different) cards for more capacity
Specialised blades with dedicated processors
® Many different/specialised OS’s
Standard components in specialised configuration => ‘box scaling rules’
ATCA = Advanced Telecommunications Computing Architecture
Public

8. 8 © Nokia 2018
The world before NFV
Pre-NFV
• Specialized network software running on
purpose-built hardware (ASICs, NPUs)
• Different devices generally required for
different functions
• Each function is independently
dimensioned, scaled and deployed.
• Lifecycles dictated primarily by hardware
evolution
Public

9. 9 © Nokia 2018 Public
A call to action…
• Seminal white paper written by
representatives of 13 major carriers
• Published at the “SDN and OpenFlow
World Congress”, Darmstadt-Germany in
October 2012
… and thus, NFV was
born
http://portal.etsi.org/NFV/NFV_White_Paper.pdf

10. 10 © Nokia 2018
• White paper 2 (http://portal.etsi.org/NFV/NFV_White_Paper2.pdf):
- Published October 15-17, 2013 at the “SDN and OpenFlow World Congress”, Frankfurt-Germany.
- Provided an update on the work of the ETSINFV ISG and a summary of the documents produced
thus far
- Highlighted need for standardisation of interfaces (reference points) between various elements of
the reference architecture
• White paper 3 (http://portal.etsi.org/NFV/NFV_White_Paper3.pdf):
- October 14-17, 2014 at the “SDN & OpenFlow World Congress”, Dusseldorf-Germany.
Public
Follow-up white papers
http://portal.etsi.org/NFV/NFV_White_Paper.pdf

11. 11 © Nokia 2018
• Large numbers of diverse, proprietary
hardware appliances.
• Increasing costs of energy, capital
investment challenges difficulties in
finding skillsets to support ever more
complex network architectures
Public
Challenges articulated by operators
• New network services require newer
varieties of hardware with the
resultant requirement for space and
power
• Relatively small lifetime of hardware-
based appliances (getting shorter all
the time) necessitating an endless
cycle of procure-design-integrate-
deploy hardware
Roll-out of new services is slow

12. 12 © Nokia 2018
disaggregation
/dɪsˈaɡrɪɡeɪʃ(ə)n/
noun
past tense: disaggregated; past participle: disaggregated
separate (something) into its component parts.
usage: "a method for disaggregation of large conglomerates"
Public
Disaggregation
Definition
In a networking context:
Disaggregation is the process of decomposing the elements of an
integrated system into discrete, individual components so that they may be
individually sourced to provide an optimal mix of software and hardware

13. 13 © Nokia 2018 Public
NFV disaggregation
The basic model
• Consolidation of different types of
network equipment onto industry-
standard high-volume servers, storage
and switches.
Vertically Integrated System
NFV
Network
Function
Purpose-
built
Hardware
Virtual
Network
Function
COTS
Hardware
Basic Premise (Simplified)

14. 14 © Nokia 2018
NFV vs SDN
SDN
Monolithic switches/routers
Virtual
Appliance
Virtual
Appliance
Virtual
Appliance
Virtual
Appliance
Virtual
Appliance
Virtual
Appliance
Virtual
Appliance
Virtual
Appliance
Standard high volume servers, storage, switches
Orchestrated,
automatic &
remote lifecycle
management
SDN Controller
Network
Mgmt
Programmability, separate control plane, centralized view
NFV
Physical appliances
Public

15. 15 © Nokia 2018 Public
SDN disaggregation
The basic model
Net-
work
Apps
Net-
work
Apps
Net-
work
Apps
VERTICALLY INTEGRATED
SYSTEM
SDN
Network
Apps
Forwarding
Hardware
Northbound
Interfaces
Southbound
Interfaces
FORWARDING PLANE ELEMENTS
CONTROL PLANE ELEMENTS
APPLICATION PLANE ELEMENTS
Network
Apps
Network
Apps
Network Operating
SystemNetwork Operating
System
Forwarding Hardware
Lightweight
OS
Forwarding
Hardware
Lightweight
OS
Forwarding
Hardware
Lightweight
OS

16. 16 © Nokia 2018
NFV: challenging the status quo
Public
Why NFV?
NFV
Key premises:
• Decouple hardware from software
• Use COTS hardware
SERVICE VELOCITY
Reduce time-to-market
of new services
OPENNESS
Reduce vendor lock-in
MULTI-TENANCY
Greater efficiency of network
usage
OPERATIONAL EFFICIENCY
Homogeneity of physical
elements, elasticity
Optimize network resources,
Reduce opex,
Open ecosystem
IMPROVED
NETWORK ECONOMICS

17. 17 © Nokia 2018
Enablers
Public
Cloud Computing
• Hardware virtualisation via
hypervisors
• Virtual (software-based)
Ethernet switches
• Multi-core CPUs
• Smart Ethernet NICs
• Poll-mode drivers
• Compute management
systems for lifecycle
management of VMs
• Open APIs for management
COTS Hardware
• Economies of scale of
compute platforms
• Competitive market for
server components, avoiding
vendor lock-in
• Improving performance over
time

18. 18 © Nokia 2018
• Development of virtualized applications that are portable between different hypervisors,
hardware etc.
• Inter-working in a mixed virtual-physical environment
• Evolution of OSS/BSS systems to support virtualised systems
• Management and orchestration of virtual appliances
• Achieving acceptable performance and resilience compared to hardware-based functions
• Support of multi-vendor environments
Public
Perceived challenges
Significant challenges would have to be surmounted

19. 19 © Nokia 2018
• A new operator-led Industry Specification Group (ISG) was set up under ETSI to support
NFV development
• While ETSI is an SDO, the objective of the ISG was not to produce standards but to
identify requirements and develop architectures. It would reference the work of other
SDOs as required.
• Produced the following (release 1 documents):
- NFV Use Cases document
- NFV Requirements document
- NFV Architectural Framework document
- NFV Terminology document
- NFV Proof-of-concept framework
Public
Consequences
Formation of ETSI NFV ISG

20. 20 © Nokia 2018
Original 2-year term of the ISG expired in early 2015.
• Extended for an additional 2 years with the objective of:
- Completion of the definition of key interface specifications to allow inter-operable implementations
of NFV components:
• Orchestrator <-> VIM
• Orchestrator <-> VNF
• VNFM <-> VNF
• VNF <-> NFVI
- Study of how NFV infrastructures will interact with legacy OSS/BSS systems
• How OSS/BSS systems need to evolve to support NFV
• OSS/BSS <-> Orchestrator interface
• OSS/BSS <-> Element manager interface
Public
ETSI NFV ISG
Phase 2

21. 21 © Nokia 2018
• Elaborated on requirements, information models and interface specifications for key
interfaces identified in the reference architectures
• Produced the following Release 2 documents in early 2015:
- NFVI:
• NFV Infrastructure Overview
• NFV Compute Domain
• NFV Hypervisor Domain
• NFV Infrastructure Network Domain
- Management and Orchestration document
• Detailed functionality of NFVO, VNFM and VIM
• Phase 3:
- Third 2-year period of work ongoing with a view to producing Release 3 documents
Public
ETSI NFV ISG
Release 2

22. 22 © Nokia 2018
virtualisation for
network engineers:
a primer
Public

23. 23 © Nokia 2018
• Motivation:
- Better use of hardware resources: significant waste of compute resources when using bare-metal
server.
- Requirement to be able to pool hardware resources and get better efficiency.
- Reduce power and space requirements via consolidation
- Ability to ship applications as a package that can run anywhere
• Requirements:
- Isolation between different applications sharing server hardware
- Isolation (or allocation) of resources to different applications sharing the hardware platform
- No significant loss of performance
Public
Server virtualisation

24. 24 © Nokia 2018
• Emulation
- Make one system behave like or imitate a different one; software mimicking hardware
- Take an entire system and make it run on a platform it was not designed for (includes totally
different CPU architectures) (Example: play your Sega Megadrive games on your PC)
- Huge performance impact
- Very useful for ensuring the continuation of required legacy hardware/software and for migrations
Public
Virtualisation Overview
Types of Virtualisation (1)
VM
HWHW
VMM
VM
Real driver XReal driver X
Real driver Y
Emulated HW

25. 25 © Nokia 2018
• (Full) Virtualisation
- Known as many things (HVM, Accelerated Virtualisation, Hardware Assisted Virtualisation, Native
Virtualisation)…essentially emulation, but with support of virtualization in hardware
- Hypervisor: software that allows hosting of multiple “virtual machines” on a single guest machine by
turning physical resources into logical resources which can be supplied/requested to/from guests e.g KVM
- Guest operating system is unaware that it is operating in a virtualized environment and therefore, requires
no modification to operate in the virtualised environment; Guests use unmodified drivers to connect to the
virtualised resources
Public
Virtualisation Overview
Types of Virtualisation (2)
- Host and Guest architectures must be the same
architecture (e.g. x86_64)
- Calls to hardware need to be intercepted by the
hypervisor
- Hardware support for virtualization is required e.g.
Intel VT-x
VM
Real
driver
HW
VM
Real
driver
HW
VM
Real
driver
HW
VMM
HW
VM
Real
driver
(As seen by VM) (As seen by VMM)

26. 26 © Nokia 2018
• Para-Virtualisation (PV)
- The code of an operating system is modified in order to allow that operating system to run as a
guest; most OS’s today ship with para-virtualization interfaces
- Rather than calls directly being made by the guest to hardware, which are then intercepted by the
hypervisor (or Virtual Machine Monitor, VMM) and converted, the calls are instead made from the
guest directly to the VMM
Public
Virtualisation Overview
Types of Virtualisation (3)
- The guest is aware that it is running in a virtualized system.
- Can provide better performance than full (software-based)
virtualization
- The VMM is aware of the requirements on the guest(s) and
can manage resources accordingly
- For high I/O where the guest knows that it is virtualised
(most situations these days) para-virtualisation
(VirtIO drivers on KVM, VMware Tools on VMware ) can be used
Driver itf
VM
modified driver
HWHW
VMMReal driver
VM
modified driver
Driver itf

27. 27 © Nokia 2018
• Hybrid Virtualisation
- Combination of para-virtualisation for some hardware functions (e.g. virtio for I/O) and full
virtualisation for others.
- Can provide better performance without requiring full para-virtualization
- Can provide the best of both worlds
- Example: KVM uses hardware virtualization extensions but also supports para-virtualisation driver
for network devices (via virtio) etc.
Public
Virtualisation Overview
Types of Virtualisation (4)

28. 28 © Nokia 2018
• Also know as a Virtual Machine Monitor (VMM)
• Software that allows hosting of multiple “virtual machines” on a single guest machine by
turning physical resources into logical resources which can be supplied/requested to/from
guests
• Interfaces with the physical host hardware allowing it to be presented to multiple
virtualised guests
• Marshals the sharing of resources between guests (access to CPU, GPU, memory and
other hardware)
Public
Virtualisation Overview
Hypervisors

29. 29 © Nokia 2018
Type 1: Native Hypervisor
Virtualisation Overview
Hypervisors (1)
Hardware
Native Hypervisor
Virtual
Hardware
Virtual
Hardware
Virtual
Hardware
Spare
Guest
Operating
System
(VNF)
Guest
Operating
System
(VNF)
Guest
Operating
System
(VNF)
Public
Type 1: Native/Bare-Metal Hypervisors
Examples: VMware ESXi, Microsoft Hyper-V,
Citrix XEN
The host operating system is the Hypervisor
software. Hypervisor has direct access to all
hardware and features of the underlying
machine.

30. 30 © Nokia 2018
Hardware
Conventional (Host) Operating System
Virtual
Hardware
Virtual
Hardware
Virtual
Hardware
Hosted Hypervisor
Apps on
Host
Operating
System
Guest
Operating
System
(VNF)
Guest
Operating
System
(VNF)
Guest
Operating
System
(VNF)
Virtualisation Overview
Hypervisors (2)
Public
Type 2: Hosted Hypervisors
Examples: VMware Workstation, Parallels, Oracle
Virtual Box
Relies on the underlying host operating system
for access to the hardware. If the underlying
host O/S develops an issue the guests can fail.
More resource overhead than Type-1
hypervisors
[Linux KVM is actually a kernel module that converts the
operating system to a type-1 hypervisor so can be said to
exhibit characteristics of both type-1 and type-2
hypervisors]
Type 2: Hosted Hypervisor

31. 31 © Nokia 2018
Virtualisation Overview
Common Hypervisors
Public

32. 32 © Nokia 2018
• VM-based virtualisation operates at a
hardware-level i.e. it attempts to
provide a distinct, virtual hardware
environment for each VM.
• Containers are a new approach that
provides separate operating
environments for each application via a
single, shared kernel i.e. OS-
virtualisation instead of machine
virtualisation
• Uses Linux kernel features cgroups and
namespaces, which provide an isolated
execution environment with its own PID
space, network device, filesystems, CPU,
RAM etc.
Public
Containers
Containers
Hardware
Host operating system kernel
Container 1 Container 2 Container 3 Container 4
App App App App
Container engine
Bins/
Libraries
Bins/
Libraries
Bins/
Libraries
Bins/
Libraries

33. 33 © Nokia 2018
• Advantages over VMs:
- No duplication of operating system resources
- VMs have higher overheads (each VM is a complete machine)
- Smaller and light-weight
- Higher scale
- Faster loading times
• Challenges:
- Isolation and sharing concerns need to be resolved; VMs provide much better isolation as
each VM operates in a separate, virtual hardware context.
- All containers on a single hardware server must use the same operating system and kernel
• Outlook:
- Use cases exist for both VM and container applications; hard to see containers completely
replacing VMs in the near future
Public
Containers
Comparing and contrasting with VMs

34. 34 © Nokia 2018
• LXC
• Docker(Uses LXC)
• OpenVz
• Parallels Virtuozzo
• Solaris Containers
• HP-UX containers
Public
Containers
Implementations

35. 35 © Nokia 2018
Leverage: Agility & Cost Effectiveness EXTEND
Real-time and 5 9s
Distributed Architecture
Unrestricted Networking
Optimized Operations
Security
IT Best Practices
Open Source SW Commodity HW
Cloud Technology
Data Centre
Technology
What makes NFV different from public cloud?
Public

36. 36 © Nokia 2018
etsi nfv reference
architecture
Public

37. 37 © Nokia 2018 Public
NFV disaggregation
The basic model
NFV
Vertically Integrated System
Network
Function
Purpose-
built
Hardware
Virtual
Network
Function
COTS
Hardware
Basic Premise (Simplified)
`VNF
Virtual Network Functions (VNFs)
VNF VNF
NFV Infrastructure (NFVI)
Virtual
Compute
Virtual
Storage
Virtual
Network
Virtualization Layer
Storage
Hardware
Network
Hardware
Compute
Hardware
NFVManagement&
Orchestration(MANO)
ETSI High-level NFV Framework

38. 38 © Nokia 2018
High-level ETSI NFV Framework
ETSI GS NFV 002
Public
NFV
Management
and
Orchestration
(MANO)
Virtual Network Functions (VNFs)
VNF VNF VNF VNF VNF
NFV Infrastructure (NFVI)
Virtualisation Layer
Virtual
Compute
Virtual
Network
Virtual
Storage
Hardware Resources
Compute NetworkStorage
Source: ETSI GS NFV 002
Underlying
physical
resources
Virtualised
resources
Virtualised
instances of
network
functions
All tasks
required for
management
of the VNF
lifecycle
Hypervisor,
containers etc

39. 39 © Nokia 2018
• In charge of orchestration and
management of NFV infrastructure,
software resources and realizing
network services.
• Network Service lifecycle
management.
Responsible for VNF lifecycle
management (e.g. instantiation,
update, query, scaling, termination)NS
Catalog
VNF
Catalog
NFV
Instances
NFVI
Resources
OSS/BSS
EM VNF Manager
(VNFM)
Virtualized
Infrastructure
Manager (VIM)
NFV Orchestrator (NFVO)
VNF
NFV Infrastructure
(NFVI)
Execution reference points Other reference points Main NFV reference points
NFV MANO
Or-ViNf-Vi
Vi-Vnfm
Ve-Vnfm-em
Ve-Vnfm-vnf
Or-Vnfm
Vn-Nf
Os-Ma-
nfvo
ETSI NFV E2E Architecture
ETSI GS NFV-MAN 001
Controls and manages the
interaction with the virtualized
infrastructure (compute, network
and storage resources)
All hardware and software
components which build up the
environment in which VNFs are
deployed, managed and executed
Public

40. 40 © Nokia 2018
etsi nfv reference
architecture
nfvi
Public

41. 41 © Nokia 2018
• All of the hardware and software components
which provide the environment in which VNFs are
deployed
• Provides virtual resources required to run VNFs;
includes COTS hardware, accelerator components
and a software layer which virtualizes and
abstracts the underlying hardware.
• Multi-tenant environment
Public
NFVI
Framework

42. 42 © Nokia 2018
NFVI
Public
Framework
Virtualised
Infrastructure
Manager (VIM)
May include
SDN controller
for network
virtualisation
Virtual Network Functions (VNFs)
VNF VNF VNF VNF VNF
Vn-Nf
Nf-Vi
NFV Infrastructure (NFVI)
Virtualisation Layer
Virtual
Compute
Virtual
Network
Virtual
Storage
Hardware Resources
Compute NetworkStorage
Underlying
physical
resources
Virtualised
resources
Hypervisor,
containers etc

43. 43 © Nokia 2018
• Hardware resources - compute:
- VNF requirements still dictate server
specifications
• Key challenge as a one-size-fits-all-VNFs policy
could result in over-engineered servers, with
impact on TCO and large amounts of unused
capacity
- Typically rack servers but blade servers also
popular
- Dominated by Intel (Intel has >90% market
share in servers)
• Intel Xeon E5-2600 processors offering good price
vs performance characteristics
Public
NFVI
Hardware resources
NFV Infrastructure (NFVI)
Virtualisation Layer
Virtual
Compute
Virtual
Network
Virtual
Storage
Hardware Resources
Compute NetworkStorage

44. 44 © Nokia 2018
• Hardware resources - storage:
- Particularly important for storage-intensive VNFs
such as caching, analystics
- Direct Attached Storage (DAS)
• Attached directly to the server
- Network Attached Storage (NAS)
• Provides network access to file-level data storage
- Storage Area Network (SAN)
• Provides network access to block-level data storage
- Software-Defined Storage (SDS)
• Akin to SDN for networks
• Separates management and control software from
underlying storage hardware (industry-standard
storage-optimized servers)
Public
NFVI
Hardware resources
NFV Infrastructure (NFVI)
Virtualisation Layer
Virtual
Compute
Virtual
Network
Virtual
Storage
Hardware Resources
Compute NetworkStorage

45. 45 © Nokia 2018
• Hardware resources - network:
- Traditional, proprietary L2 or L3 switches
- Open, industry-standard, switches:
• bare-metal switches
• white-box switches
• brite-box switches (brite = branded white-box, a
Gartner-coined term)
Public
NFVI
Hardware resources
NFV Infrastructure (NFVI)
Virtualisation Layer
Virtual
Compute
Virtual
Network
Virtual
Storage
Hardware Resources
Compute NetworkStorage

46. 46 © Nokia 2018 Public
NFVI
Virtualisation layer
• Hypervisor sits on top of the hardware resources
and provides a mechanism to share them across
virtual machines (VMs)
• Abstracts and logically partitions physical resources
- Emulates a physical machine for each VM
- Provides isolation between VMs
- Emulates NIC cards for each VM
• Major deployments based on KVM and Vmware
vSphere
- Others include Oracle XEN and Microsoft Hyper-V
• Emphasis has been on virtual machines but
containers are now being looked at as a future
option
NFV Infrastructure (NFVI)
Virtualisation Layer
Virtual
Compute
Virtual
Network
Virtual
Storage
Hardware Resources
Compute NetworkStorage

47. 47 © Nokia 2018
• Virtualised CPU (vCPU): virtualised CPU created for a VM by a hypervisor
• Virtualised NIC (vNIC): virtualised NIC created for a VM by a hypervisor
• Virtualised Switch (vSwitch): Ethernet switch implemented by the hypervisor that
interconnects vNICs of VMs with each other and with the NIC of the compute node
Public
NFVI
Terminology
Source: ETSI GS NFV 003 V1.3.1

48. 48 © Nokia 2018
• Virtual resources - compute:
- Created by the hypervisor
- APIs to support VM lifecycle actions: create,
start, stop, pause, shutdown, migrate, delete,
manage etc.
Public
NFVI
Virtual resources - compute
NFV Infrastructure (NFVI)
Virtualisation Layer
Virtual
Compute
Virtual
Network
Virtual
Storage
Hardware Resources
Compute NetworkStorage

49. 49 © Nokia 2018
• Virtual resources - network:
- Software switch or router on the hypervisor
- Functions:
• Allows communication between VMs
• Tunneling for overlay services
• ACLs
• Distributed routing
- Switching solutions:
• OpenVSwitch (OVS)
• FD.io (“fido”)
• vSphere Distributed Switch (VDS)
- Data-plane acceleration technologies:
• DPDK
• OpenDataPlane (ODP)
Public
NFVI
Virtual resources - network
NFV Infrastructure (NFVI)
Virtualisation Layer
Virtual
Compute
Virtual
Network
Virtual
Storage
Hardware Resources
Compute NetworkStorage

50. 50 © Nokia 2018
• Hardware:
- Specialised I/O processors
- Smart NICs: ability to offload functions such as ACL, tunnel encapsulation/decapsulation, switching,
encryption and acceleration from the CPU
• Virtualisation layer:
- Maturation of container technology (use of Operating System virtualization instead of virtual
machine virtualization.
- Concerns around isolation need to be addressed
Public
NFVI
What’s next ?

51. 51 © Nokia 2018
VIM
Public
Framework
Virtualised Infrastructure
Manager (VIM)
Or-Vi
NFV
Infrastructure
(NFVI)
Orchestrator VNFM
Nf-Vi
Vi-Vnfm
• VIM
- Manages the NFV Infrastructure (NFVI),
performance and fault management
- Maintains inventory of hardware and software
resources
- Maintains inventory of allocation of virtual
resources to physical resources
- Manages lifecycle of virtual resources
- Interacts with MANO layer

52. 52 © Nokia 2018
• Two dominant solutions today:
- OpenStack
- Vmware vCloud Director (vCD)
• New solution focus areas:
- Seamless integration with MANO and automation solutions
- Management of containers and bare metal in addition to VMs
• Emerging solutions:
- OpenVIM: part of OpenMANO, lightweight VIM
- Kubernetes: container orchestration project that came out of Google, now under the Linux
Foundation
Public
VIMs

53. 53 © Nokia 2018
etsi nfv reference
architecture
vnfs
Public

54. 54 © Nokia 2018
VNFs
Public
NFV
Management
and
Orchestration
(MANO)
Virtual Network Functions (VNFs)
VNF VNF VNF VNF VNF
NFV Infrastructure (NFVI)
Virtualisation Layer
Virtual
Compute
Virtual
Network
Virtual
Storage
Hardware Resources
Compute NetworkStorage
Source: ETSI GS NFV 002
software implementation of
a network function which is
capable of running over the
NFVI. Corresponds to the
software component of
today’s network devices,
delivered as pure software
that is hardware-
independent (or at least
capable of running on
industry-standard servers)
Physical Network Function (PNF): physical
version of a network function i.e. a network
function designed to run on purpose-built
hardware

55. 55 © Nokia 2018
• Network Function (NF): functional block within a network infrastructure that has well-
defined external interfaces and well-defined functional behavior; network node or
physical appliance today e.g. BNG, firewall, IDS, IPS
• Physical Network Function (PNF): implementation of a NF via a tightly coupled software
and hardware system
• Virtualised Network Function (VNF): implementation of an NF that can be deployed on a
Network Function Virtualisation Infrastructure (NFVI)
Public
VNFs
Terminology
Source: ETSI GS NFV 003 V1.3.1

56. 56 © Nokia 2018
• Virtualised Network Function Component (VNFC): internal component of a VNF providing a
VNF Provider a 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 Virtualisation
Container
• Virtualised Network Function Descriptor (VNFD): configuration template that describes a
VNF in terms of its deployment and operational behaviour, and is used in the process of
VNF on-boarding and managing the lifecycle of a VNF instance
Public
VNFs
Terminology
Source: ETSI GS NFV 003 V1.3.1

57. 57 © Nokia 2018
VM
• Functional behaviour and state of a NF are largely independent of whether the NF is
virtualised or not. The functional behaviour and the external operational interfaces of a
Physical Network Function (PNF) and a VNF are expected to be the same.
• A VNF can be composed of multiple internal components. For example, one VNF can be
deployed over multiple VMs, where each VM hosts a single component of the VNF.
However, in other cases, the whole VNF can be deployed in a single VM as well.
Public
VNFs
Decomposition
VNFC 1
VNF 1 VM
VNFC 2b
VNF 2
VM
VNFC 2a
VM
VNFC 2c
Simple VNF Composite VNF

58. 58 © Nokia 2018
• Tends to be focussed more on L4-L7 functions today.
• Top NFV use cases today are CPE virtualisation and mobile core virtualisation.
Public
VNFs
Key functions
vCPE
Move fast
evolving
functions
into the
cloud
vEPC
Easy
deployment
of customer
specific
mobile
services
vDNS,vFW
Virtualizatio
n of simple
network
appliances
vIMS
Rapid
deployment
of new
communicat
ions
services

59. 59 © Nokia 2018
• A simple porting of a network function from a proprietary hardware element to a
virtualised version capable of running on industry-standard servers is not sufficient:
- Unless network functions are optimised for the hardware on which they are intended to run, they
will not deliver a level of performance that makes the transition economically viable; low-level code
needs to be re-written to be able to enhance performance, particularly for data-plane-intensive
functions
- To truly achieve the benefits of virtualisation, monolithic applications may need to be
disaggregated into their constituent components, leading to an architecture that is more cloud-
native
- New horizontal scaling mechanisms need to be introduced, something that is not readily realised in
today’s hardware-based systems
Public
VNFs
Porting

60. 60 © Nokia 2018
VNFs
VNF Descriptor
Template
Node
template
Relationship
template
Group
Inputs
Outputs
node_templates:
rra:
type: tosca.nodes.Compute
properties:
num_cpus: 2
mem_size: 2048
image_name:
{ get_input: ImageName }
keypair_name:
{ get_input: keypair_input }
(De-facto) standards:
• OpenStack HOT
• OASIS TOSCA
VNF Descriptor (VNFD): A template
describing the application specifics
and topology
Public

61. 61 © Nokia 2018
• A lot VNFs today are not truly cloud-optimised, being simple ports of PNFs (“NFV
washing”). This is a necessary step, however, for the industry to start gaining experience
with virtualisation without waiting for full, cloud-native functions.
• Achieving high performance (for data-plane functions) remains a challenge. VNFs are
shipping with vendor-specified minimum requirements for hardware.
• The ability to use common hardware for all VNFs is not there yet. Extensive inter-
operability testing is still required between VNFs and the underlying NFVI.
• Licensing for VNFs is not as straightforward as the hardware-equivalent; VNFs have
different characteristics and performance, can scale in and out and are a lot more
dynamic. How do you price this ?
• Managing VNFs (via the MANO infrastructure) is vastly different to managing network
hardware. Newer skills will be required for operators.
Public
VNFs
Challenges

62. 62 © Nokia 2018
etsi nfv reference
architecture
mano
Public

63. 63 © Nokia 2018
• Purpose of the MANO
function is to:
- Manage and
orchestrate VNFs
- Manage and
orchestrate NFV
infrastructure
…in order to allow NFV
Network Services (chain
of VNFs and/or PNFs) to
be created, maintained
and destroyed
MANO
NS
Catalog
VNF
Catalog
NFV
Instances
NFVI
Resources
OSS/BSS
EM VNF Manager
(VNFM)
Virtualized
Infrastructure
Manager (VIM)
NFV Orchestrator (NFVO)
VNF
NFV Infrastructure
(NFVI)
Execution reference points Other reference points Main NFV reference points
Or-ViNf-Vi
Vi-Vnfm
Ve-Vnfm-em
Ve-Vnfm-vnf
Or-Vnfm
Vn-Nf
Os-Ma-
nfvo
Public

64. 64 © Nokia 2018
• Lifecycle management: set of functions required to manage the instantiation,
maintenance and termination of a VNF or NS
• Scaling out/in: ability to scale by add/remove resource instances (e.g. VM)
• Scaling up/down: ability to scale by changing allocated resource, e.g. increase/decrease
memory, CPU capacity or storage size
• Virtualisation Deployment Unit (VDU): construct that can be used in an information
model, supporting the description of the deployment and operational behaviour of a
subset of a VNF, or the entire VNF if it was not componentized in subsets NOTE: In the
presence of a hypervisor, the main characteristic of a VDU is that a single VNF or VNF
subset instance created based on the construct can be mapped to a single VM. A VNF may
be modelled using one or multiple such constructs, as applicable.
Public
VNFM
Terminology
Source: ETSI GS NFV 003 V1.3.1

65. 65 © Nokia 2018
• VNFM:
- performs orchestration and management
(i.e. Lifecycle management) functions of
VNFs
- responsible for maintaining of resources
required for the operation of the VNF, not
the function of the VNF
- invoked by the NFVO
- interacts with the Element Manager (EM) and
the VNF for provisioning, configuration, and
fault and alarm management
- May manage one or more instances or even
types of VNFs; the reality today is that VPF-
specific VNFMs are required for a lot of VNFs
MANO
VFNM
NS
Catalog
VNF
Catalog
NFV
Instances
NFVI
Resources
VNF Manager
(VNFM)
Virtualized
Infrastructure
Manager (VIM)
NFV Orchestrator (NFVO)
Or-Vi
Vi-Vnfm
Or-Vnfm
Public

66. 66 © Nokia 2018
• VNF life cycle management
functions:
- onboard a VNF
- instantiate a VNF
- scale a VNF
- update a VNF
- terminate a VNF
Public
MANO
VNF Life Cycle Management (LCM)
ONBOARD
1
DEPLOY
2
MONITOR3
SCALE
4
HEAL
5
UPDATE 6
TERMINATE 7
Life of a VNF

67. 67 © Nokia 2018
• NFVO:
- Two key functions:
• orchestration functions of NFVI resources across
multiple VIMs
• lifecycle management of network services.
- Has to ensure that there are sufficient
compute, storage and network resources to
provision a network service
- interacts with the OSS/BSS for provisioning,
configuration, capacity management, and
policy-based management
- Constructs and end-to-end service between
one or more VNFs by communicating with
VNFMs and VIMs
MANO
NFVO
NS
Catalog
VNF
Catalog
NFV
Instances
NFVI
Resources
VNF Manager
(VNFM)
Virtualized
Infrastructure
Manager (VIM)
NFV Orchestrator (NFVO)
Or-Vi
Vi-Vnfm
Or-Vnfm
Public

68. 68 © Nokia 2018
• Network Service: composition of Network Function(s) and/or Network Service(s), defined
by its functional and behavioural specification
• Network Service Descriptor: template that describes the deployment of a Network Service
including service topology (constituent VNFs and the relationships between them, Virtual
Links, VNF Forwarding Graphs) as well as Network Service characteristics such as SLAs and
any other artefacts necessary for the Network Service on-boarding and lifecycle
management of its instances
• Network Service Orchestration: subset of NFV Orchestrator functions that are responsible
for Network Service lifecycle management
Public
NFVO
Terminology (1)
Source: ETSI GS NFV 003 V1.3.1

69. 69 © Nokia 2018
• NF set: collection of NFs with unspecified connectivity between them
• Network Forwarding Path (NFP): ordered list of connection points forming a chain of NFs,
along with policies associated to the list
• NF forwarding graph: graph of logical links connecting NF nodes for the purpose of
describing traffic flow between these network functions
• Virtual Link: set of connection points along with the connectivity relationship between
them and any associated target performance metrics (e.g. bandwidth, latency, QoS).
NOTE: The Virtual Link can interconnect two or more entities (VNF components, VNFs, or
PNFs) and it is supported by a Virtual Network (VN) of the NFVI.
• VNF Forwarding Graph (VNF FG): NF forwarding graph where at least one node is a VNF
Public
NFVO
Terminology (2)
Source: ETSI GS NFV 003 V1.3.1

70. 70 © Nokia 2018
• An end-to-end network service (e.g.
mobile voice/data, Internet access,
a virtual private network) can be
described by an NF Forwarding
Graph of interconnected Network
Functions (NFs) and end points.
• A network service can be viewed
architecturally as a forwarding
graph of Network Functions (NFs)
interconnected by supporting
network infrastructure
Public
NFVO
Network Service
Source: ETSI GS NFV 002 V1.2.1

71. 71 © Nokia 2018
NFVO
Public
Network Service with a nested forwarding graph
Source: ETSI GS NFV 002 V1.2.1

72. 72 © Nokia 2018
• Most current network services are defined by statically combining network functions in a
way that can be expressed using an NF Forwarding Graph or NF Set construct. A major
change brought by NFV is that virtualisation enables additional dynamic methods rather
than just static ones to construct and manage the network function graphs or sets
combining these network functions. A major focus of NFV is to enable and exploit the
dynamic construction and management of network function graphs or sets.
• VNF Forwarding Graph: covers the case where network connectivity between VNFs is
specified, e.g. a chain of VNFs on the path to a web server tier (e.g. firewall, NAT, load
balancer)
• VNF Set covers the case where the connectivity between VNFs is not specified, e.g. a Web
server pool, independent virtualised residential gateways
Public
NFVO
Forwarding Graphs

73. 73 © Nokia 2018
• Functions responsible for coordinating the lifecycle of VNFs that jointly realise a Network
Service. Include:
- on-boarding a Network Service
- management of resources used by the Network Service
- managing dependencies between different VNFs composing the Network Service
- managing the forwarding graphs between the VNFs.
Public
NFVO
Network Service Orchestration

74. 74 © Nokia 2018
• Described by a set of descriptors:
- VNF Descriptors (VNFD)
- Network Service Descriptors (NSD)
- VNF Forwarding Graph Descriptors (VNFFGD)
- Virtual Link Descriptors (VLD).
• Descriptors are essentially deployment templates that describe the resource and
operational requirements for each of the above components
Public
NFVO
Information Models

75. 75 © Nokia 2018
VNF C
VNF A
VNF B
PNF A
PNF B
VL Virtual Link: Logical connection between one or more VNFs [VLAN/VxLAN/subnet]
CP Connection Point: Interface on a VNF/PNF which connects to the VL [vPort/vNIC/pNIC]
VNFFG VNF Forwarding Graph: Defines traffic flows between VNFs within the NS
NFP Network Forwarding Paths: Ordered list of CPs that form chains of VNFs with associated policies
CP
VL
CP
CPCP
CP CP
CP
VL
VL
Network service
VL
CP
VL
CP
CP
NFVO
Network Service Descriptor example

76. 76 © Nokia 2018
MANO
Public
Industry Players
ETSI
Driving NFV specifications
TMForum
Next-gen OSS/BSS with
virtualisation
MEF
Reference architectures for
Lifecycle Service Orchestration
(LSO)
Linux Foundation
Hosting large number of open-
source NFV projects

77. 77 © Nokia 2018
• Huge number of open-source initiatives to tackle this space:
- ONAP (from a merging of Open-O and AT&T’s ECOMP [OpenECOMP])
- OSM
- Tacker
- OpenLSO
- OpenBaton
- Tacker
• Many different approachs:
- Some provide NFVO with a generic VNFM and VIM
- Some provide an extensible plugin architecture for supporting different VNFMs and VIMs
Public
MANO
Implementations

78. 78 © Nokia 2018
• Large number of solutions , (overlapping) open-source and proprietary, are being
developed
• Elements outside of the NFV framework being identified as gaps
• Increased importance of assurance capabilities being recognised
• MANO ecosystem seen as immature and requiring considerable work
• For operators to be able to exploit NFV capabilities, they have to be able to integrate their
current OSS and BSS systems with their new NFV orchestration systems. This is an area
of work that is still in its infancy.
Public
MANO
Current market state

79. 79 © Nokia 2018
• Lifecycle management of Network Services (NS)
• Integration of OSS/BSS systems
• Inter-operation in hybrid PNF/VNF environments
• Certification for better portability of VNFs
• Comprehensive assurance mechanisms
Public
MANO
Evolution – Focus Areas

80. 80 © Nokia 2018
use cases
Public

81. 81 © Nokia 2018
• Currently architected using purpose-built
hardware for different functions such as PDN-
GE, S-GW, HSS, MME etc
• Opportunity to further decompose these
functions
• Allow independent scaling of each (sub-)
function.
• Already being deployed by a number of mobile
operators worldwide
• 5G mobile core likely to be exclusively based on
virtualised deployment
Public
Use cases
Virtualisation of EPC
Source: ETSI GS NFV 001

82. 82 © Nokia 2018
• Currently designed for peak-hour
requirements. May be vastly unused during
off-peak times
• No mechanism to cost-effectively and
dynamically provide additional capacity to
handle unforeseen demand
• Virtualisation allows CDN capacity to be
dynamically scaled on demand
• vCDN caches can be instantiated closer to
users to reduce bandwidth requirement
through the network
Public
Use cases
Virtualisation of CDNs
Source: ETSI GS NFV 001

83. 83 © Nokia 2018
Use cases
Public
Virtualisation of the home environment
Source: ETSI GS NFV 001
From… To…

84. 84 © Nokia 2018
performance
Public

85. 85 © Nokia 2018
• Would an industry standard server be capable of supporting realistic network workloads ?
• How can we provide provide predictable behaviour for new network functions ?
• How can we achieve 99.999% service availability using server hardware with 99.9%
availability ?
• Ideally:
- Hardware vendors would be agnostic to the VNFs that would end up running on their servers
- VNF vendors would be able to provide a guarantee of predictable performance subject to minimal
hardware requirements without explicit knowledge of actual hardware system they will run on i.e.
VNF performance is predictable, consistent and vendor-agnostic
Public
Performance
Challenges and expectations as identified during inception of NFV

86. 86 © Nokia 2018
• Measures of performance:
- Packet processing rates (bps, pps)
- Processing latency
- Jitter
• Key difference between network services and traditional cloud-computing workloads is
that they are more I/O-intensive.
• Performance and scalability are important since the implementation of a VNF may have a
per-instance capacity that is less than that of a corresponding physical network function
on dedicated hardware. Therefore, methods are needed to split the workload across
many distributed/clustered VNF instances.
Public
Performance

87. 87 © Nokia 2018
• Two key approaches to improving performance:
- CPU enhancements and acceleration technologies:
• SR-IOV
• DPDK
• PCI-passthrough
• Huge page support
• CPU pinning
- Hardware offload
• Smart NICs with offloads for virtual switching, encryption, compression etc.
• Co-processors
• Intel QuickAssist Technology (QAT): hardware-based acceleration services for encryption and compression
Public
Performance
Achieving higher performance

88. 88 © Nokia 2018
open source
Public

89. 89 © Nokia 2018
• Number of operator-initiated open-source projects that were subsequently put into the
public domain:
- Open Source MANO (OSM): project initiated by Telefonica as OpenMANO, now hosted under ETSI
- ONAP: result of merging of AT&T’s ECOMP and Open-O
• Open Compute Platform (OCP)
- Founded by Facebook, Intel and Rackspace
- Applies open-source principals to hardware
• Linux Foundation hosts the following NFV-related projects:
- ONAP, OPNFV, ODL, FD.io, OVS, CORD, DPDK and many more
• OpenStack Foundation
• Telecom Infra Project (TIP): founded by Facebook
Public
Open source projects

90. 90 © Nokia 2018
• Launched in September 2014 under the Linux Foundation
• Objective is to create an open reference platform for NFV consisting of open hardware
and software interfaces based on open source projects such as OpenDaylight, OpenStack
etc.
• Focused on system-level integration, deployment and testing to create a reference
implementation rather than direct software development
Public
OPNFV

91. 91 © Nokia 2018
• CORD = Central Office Re-architected as a Datacenter (CORD)
• Founded by ON.Lab
• Focusses on how traditional telco exchange architectures can be translated to a cloud
environment
Public
CORD

92. 92 © Nokia 2018
• ONAP: result of merging of AT&T’s ECOMP and Open-O
• Open-O:
- Joint effort between China Mobile, China Telecom and a number of vendors
• ECOMP:
- Developed by AT&T together with Amdocs
Public
ONAP

93. 93 © Nokia 2018
state of industry
Public
Source: SDxCentral 2017 NFV Report Series Part I
Foundations of NFV: NFV Infrastructure and VIM

94. 94 © Nokia 2018
• In the 5 years since the inception of the ETSI NFV ISG, significant investment has been
made in:
- industry-standard commercial off-the-shelf (COTS) hardware
- hypervisors and Virtualized Infastructure Managers (VIMs)
- Virtual Network Functions (VNFs)
- management and orchestration (MANO)
Public
Progress

95. 95 © Nokia 2018
• A lot VNFs today are not truly cloud-optimised, being simple ports of PNFs (“NFV
washing”). This is a necessary step, however, for the industry to start gaining experience
with virtualisation without waiting for full, cloud-native functions.
• Achieving high performance (for data-plane functions) remains a challenge. VNFs are
shipping with vendor-specified minimum requirements for hardware.
• The ability to use common hardware for all VNFs is not there yet. Extensive inter-
operability testing is still required between VNFs and the underlying NFVI.
• Licensing for VNFs is not as straightforward as the hardware-equivalent; VNFs have
different characteristics and performance, can scale in and out and are a lot more
dynamic. How do you price this ?
• Managing VNFs (via the MANO infrastructure) is vastly different to managing network
hardware. Newer skills will be required for operators.
Public
VNFs
Current market state

96. 96 © Nokia 2018
• Large number of solutions , (overlapping) open-source and proprietary, are being
developed
• Elements outside of the NFV framework being identified as gaps
• Increased importance of assurance capabilities being recognised
• MANO ecosystem seen as immature and requiring considerable work
• For operators to be able to exploit NFV capabilities, they have to be able to integrate their
current OSS and BSS systems with their new NFV orchestration systems. This is an area
of work that is still in its infancy.
Public
MANO
Current market state

97. 97 © Nokia 2018
• For operators to be able to exploit NFV capabilities, they have to be able to link their
current OSS and BSS systems to their new NFV orchestration systems. This is a big hurdle
today:
- OSS/BSS systems are complex and not geared for virtualization.
- Operators are deeply invested in these systems so a straight replacement is neither practical nor
economically viable.
- The systems tend to be highly customized, often developed by their IT teams over many years;
there is no one-size-fits-all making integration even more complex.
- Even prior to the advent of NFV, OSS integration was a costly and complex exercise; NFV has the
capability to simplify future integration but the OSS systems need to ”catch up” with the virtualized
world first.
- The MEF LSO framework is helping to bridge the gap between legacy OSS and BSS systems and
NFV.
Public
OSS/BSS integration

98. 98 © Nokia 2018
bibliography/references
Public

99. 99 © Nokia 2018
• NFV whitepapers:
- http://portal.etsi.org/NFV/NFV_White_Paper.pdf
- http://portal.etsi.org/NFV/NFV_White_Paper2.pdf
- http://portal.etsi.org/NFV/NFV_White_Paper3.pdf
• ETSI ISG specifications: http://www.etsi.org
• Insights on current state of NFV industry have been quoted from:
- SDxCentral 2017 NFV Report Series Part I Foundations of NFV: NFV Infrastructure and VIM
- SDxCentral 2017 NFV Report Series Part 2: Orchestrating NFV - MANO and Service Assurance
- SDxCentral 2017 NFV Report Series Part 3: Powering NFV - Virtual Network Functions (VNFs)
Public
Acknowledgements