Network Functions VirtualizationConception, Present & Future
Rashid Mijumbi, Waterford Institute of Technology
Niels Bouten, Ghent University
Network Operations and Management Symposium (NOMS)
April 29, 2016Istanbul, Turkey
OutlinePART 1: Theory
Conception
A. Motivation, History, Concept, Anticipated benefits
B. Architecture, Business Model, Related Concepts (SDN, Cloud Computing)
C. Examples (Use Cases)
Present (State-of-the-art)
A. NFV Proofs of Concept
B. Collaborative Academic and Industrial Projects
C. (Some) Products
Future (Research Challenges)
A. Management and Orchestration, Information Modelling, NFV Performance, Energy Efficiency, Security
B. Research directions in selected NFV use cases such as Internet of Things, Information-Centric Networking
PART 2: Hands-on
Virtualized IP Multimedia Subsystem
A. Introduction to IMS and Clearwater’s virtualised IMS
B. Description of setup: Resources, Management (OpenStack).
C. Hands-on
2 of 140
Conception
PART 1.1
Motivation, History (Including NFV timeline), Concept, Anticipated benefits
Architecture, Business Model, Related Concepts (SDN, Cloud Computing)
Examples (Use Cases)
3 of 140
Global Traffic Trend
Continuously increasing user requirements: more data, rapidly changing
services: Increased CAPEX
40
60
80
100
120
140
160
180
2014 2015 2016 2017 2018 2019
Ex
ab
yte
sp
er
mo
nth
Data Source: Cisco VNI Global IP Traffic Forecast, 2014–2019. May 2015.
1 exabyte = 1 000 000 000 gigabytes
4 of 140
Proprietary Equipment
Networks with proprietary equipment, long product development cycles:
Increased OPEX
Adapted from: Network Functions Virtualization - Everything Old Is New Again. F5 White
Paper. August 20135 of 140
Declining Revenues
Increased competition amoung each other (SPs) and from OTT: No
corresponding increase in Revenue
0
5
10
15
20
25
30
35
40
45
2008 2009 2010 2011 2012 2013 2014 2015
Fixed Broadband Mobile Total
Data Source: European Telecommunications Network Operators’ Association, Annual Economic
Report. 2015. Includes Turkey, excludes Georgia, Russia, Ukraine
ARPU in Europe
6 of 140
Call for Action
A joint operator call for the Telecom and IT industry to take
action to increase service agility, network flexibility and
reduce CAPEX and OPEX
http://portal.etsi.org/NFV/NFV_White_Paper.pdf
October 2012
November 2012: Some of the operators selected the European Telecommunications Standards Institute (ETSI) to be the home of the Industry Specification Group for NFV
7 of 140
Network Functions Virtualisation (NFV)
Adapted from: Network Functions Virtualization - Everything Old Is New Again. F5 White
Paper. August 2013
Classical Network Model: Hardware Appliances
Leverage advances in virtualisation decouple network functions from dedicated
hardware to run them on standard servers, storage and switches
Virtual Router
Virtual Firewall
Virtual NAT
Virtual CDN Virtual RAN
NFV Model: Virtual Appliances
8 of 140
NFV: Anticipated Benefits
Adapted from: Network Functions Virtualization - Everything Old Is New Again. F5 White
Paper. August 2013
Architecture
Reduced number of physical network elements to manage and deploy,
Service elasticity, agility (increased time to market)
Capital Expenses (CAPEX)
Standard x86-based servers considered cheaper than routers/appliances,
Economies of scale (better resource utilization in large DCs)
Operating Expenses (OPEX)
Automated network operations: reduces management requirements, branch visits
Reduced expenses such as power due to consolidation, efficiency
Architecture CAPEX OPEX
9 of 140
Anticipated Benefits Survey
Source: sdxcentral.com ,
Reduce Capital Expenditures
13% Accelerate Time To Market
14%
Reduce Operational Expenditures
23%
Deliver Agility and Flexibility
50%
SDxCentral survey involving 79 end-user respondents, including service providers, (46%), cloud service
providers (14%), enterprise end users (14%) and a variety of others (24%) from user communities.
NFV Hardware, Software, and Services had an estimated EUR 2.1 Bn valuein 2015, forecast to grow to EUR 10.6 Bn in 2019, [50% CAGR]
IHS Infonetics NFV Hardware, Software, and Services Report, 2015. https://www.ihs.com/index.html10 of 140
NFV Timeline10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04 05 06 07 08 09 10 11 12 01 02 03 04
2012 2013 2014 2015 2016
Operator White paper: Call for Action
ETSI is chosen as “home of NFV”
1st meeting of the NFV ISG
20+ carriers and 100+ participants.
Detailed
Documents
- Use cases v2- Requirements v2- Architectural Framework v2- Terminology v2- PoC Execution and Results
~3.5 years later, over 270 individual companies including 38 of the world's major service providers.
OPNFV ARNO
OP
NF
V B
rah
ma
putr
a
https://docbox.etsi.org/ISG/NFV/Open/Other/NFV(16)000098r2_ETSI_NFV_Announcement_on_th
e_Evolution_of_Its_Release_2.docx
Publication of ETSI NFV Release 2
Documents planned for May 2016
High Level NFV
ISG Documents
- Use cases- Requirements- Architectural Framework- Terminology- PoC Framework
2nd White Paper
1st Year of NFV
3rd White Paper
2nd Year of NFV
11 of 140
Reference Architecture
VIRTUALISATION LAYER
Computing Hardware
Storage Hardware
Network Hardware
VirtualComputing
VirtualStorage
VirtualNetwork
Network Functions Virtualisation Infrastructure (NFVI)
VNF 1 VNF 2 VNF 3 VNF n…
Virtualised Infrastructure Manager (VIM)
VNF Manager(s)
NFV Orchestrator
NFV Management and Orchestration (MANO)
Virtual Network Functions (VNFs)
Infr
ast
ruct
ure
, VN
F &
Se
rvic
e D
esc
rip
tio
n
1
2
3
12 of 140
VNFs
A NF is an element within a network with well defined external interfaces and functional behavior e.g. DHCP,
firewall
VNF is an implementation of an NF that is deployed on virtual resources such as a VM
A service is an offering provided by a TSP that is composed of one or more NFs.
13 of 140
VNF Design Patterns
Internal Structure
Virtualization container
VNFC 1 VNFC 2
VNFC 4 VNFC 3
VNF with multiple components
VNFC 1
VNF with single component
VNF 1 VNF 1
VNF InstantiationVNFC 1
Non-parallelizable VNFC
VNF 1[1:1]
parallelizable VNFC(min. & max. # of instances
VNF 1
VNFC 1
[1:n]
VNFC StatesVNFC 1
Stateless VNFC
VNF 1
state
VNFC 1
Stateful VNFC
VNF 1
state
stateVNFC 1
VNFC with external state
VNF 1
14 of 140
NFVI
NFV Orchestrator
18 of 140
Reference Architecture
VIRTUALISATION LAYER
Computing Hardware
Storage Hardware
Network Hardware
VirtualComputing
VirtualStorage
VirtualNetwork
Network Functions Virtualisation Infrastructure (NFVI)
VNF 1 VNF 2 VNF 3 VNF n…VNF Orchestrator
Virtual Network Functions (VNFs)
Virtualised Infrastructure Manager (VIM)
VNF Manager(s)
NFV Management and Orchestration (MANO)
Infr
ast
ruct
ure
, VN
F &
Se
rvic
e D
esc
rip
tio
n
19 of 140
Reference Architecture
Hypervisor e.g. KVM
Standard Servers
Virtual Machines, Containers
20 of 140
NFV MANO
NFV Orchestrator
21 of 140
NFV MANO
Provides functionality required for the
provisioning of VNFs, and the related
operations, such as the configuration of the
VNFs and the infrastructure these functions
run on
Orchestration and lifecycle management of
physical and/or software resources that
support the infrastructure virtualization, and
the lifecycle management of VNFs,
Databases that are used to store the
information and data models which define
both deployment as well as lifecycle
properties of functions, services, and
resources.
22 of 140
NFV MANO
Manage/control NFVI resources in a single
domain.
NFV architecture may contain more than one
VIM, with each of them responsible for one
domain
Each VNF instance is has a VNFM.
For the management of the lifecycle of VNFs.
May be assigned the management of a single or
multiple VNF instances of the same or different
types
Combine more than one function so as to
create end-to-end services.
resource orchestration,
service orchestration
NFV Orchestrator
23 of 140
NFV MANO
Operation System Support, Business System Support
Element Management
Network Management Systems
NFV Orchestrator
24 of 140
Related Concepts: (1) Cloud Computing
Hardware
Infrastructure
Platform
Software
CPU, Storage, Bandwidth
Business Applications,
Web Services
Virtual Machines
Software Framework
Layered ResourcesMapping to NFV
Architecture
NFVI
Physical and
Virtual
Resources
VNF 1 VNF n
VNFs / Services
IaaS
Data Centres
PaaS
SaaS
Facebook, Google Apps, Twitter,
ZenDesk, Saleforce.com, Zoho
Office
Model Example
Heroku, Azure, Google AppEngine,
RedHat OpenShift, force.com
OpenStack, Azure, Amazon Web
Services (EC2, S3, DynamoDB),
GoGrid, Rackspace
Source: Rashid Mijumbi, Joan Serrat, Juan Luis Gorricho, Niels Bouten, Filip De Turck, Raouf Boutaba, “Network Function
Virtualization: State-of-the-art and Research Challenges”. IEEE Communications Surveys and Tutorials. First Quarter, 2016.
Cloud computing is “a model for enabling ubiquitous, convenient, on-demand network
access to a shared pool of configurable computing resources (e.g., networks, servers,
storage, applications, and services)
25 of 140
NFV vs Cloud Computing
NOT just transferring telecom network functions to the cloud
NFV Cloud Computing
Approach Service/Function Abstraction Computing Abstraction
Formalization ETSI NFV Industry Standard GroupDMTF Cloud Management Working
Group
Latency Expectations for low latency Some latency is acceptable
ProtocolMultiple Control Protocols (e.g OpenFlow,
SNMP)OpenFlow
Reliability Strict 5 NINES availability requirements Less strict reliability requirements
Need for high availability for VNFs
Multi-tenancy: VNFs that deploy not just for a single customer but for a large number.
Interior network features like “virtual core routing” could be associated with a large-scale network
virtualization application.
26 of 140
ETSI Use Cases
Network Functions Virtualization Infrastructure as a Service (NFVIaaS)
Virtual Network Function as a Service (VNFaaS)
Virtual Network Platform as a Service (VNPaaS)
Service Chains (VNF Forwarding Graphs)
Virtualization of Mobile Core Network and IMS
Virtualization of Mobile base station
Virtualization of CDNs
Virtualization of the Home Environment
Fixed Access Network Functions Virtualization
Clo
ud
Mo
bil
eC
DN
Acc
ess
Arc
hit
ect
ure
Ori
en
ted
Se
rvic
e O
rie
nte
d
27 of 140
Architecture Use Cases
Adapted from D.R. Lopez, “Moving along the NFV Way”, May 2014
Iaa
S
Na
aS
NFVIaaSAdministrative
Domain 1
Administrative
Domain 2
Iaa
S
Na
aS
NFVIaaS
VNFs controlled by Admin Domain 1VNF VNF
VNF
VNF
VNF
VNF
E2E service abstraction of the service provided by domain 1
VNF NFVIaaS Maps the Cloud Service
Models IaaS and NaaS to
NFV
VNFaaS Maps the Cloud Service
Model SaaS to NFV, where
a SP offers VNFs to its
customers
VNPaaS SP offers a platform to
customers on which they
can deploy their compatible
VNFs
28 of 140
Service-Oriented Use cases
Adapted from D.R. Lopez, “Moving along the NFV Way”, May 2014
Virtualization of mobile
core network and IMS
Elastic, scalable, more resilient EPC
Specially suitable for a phased approach
Virtualization of mobile
base station
Evolved Cloud-RAN
Enabler for SON
Virtualization of CDNs Better adaptability to traffic surges
New collaborative service models
Virtualization of the home
environment
L2 visibility to the home network
Smooth introduction of residential services
Fixed Access NFV Offload computational intensive optimization
Enable on-demand access services
29 of 140
Virtualised CPE
Source: Rashid Mijumbi, Joan Serrat, Juan Luis Gorricho, Niels Bouten, Filip De Turck, Raouf Boutaba, “Network Function
Virtualization: State-of-the-art and Research Challenges”. IEEE Communications Surveys and Tutorials. First Quarter, 2016.30 of 140
Virtualised EPC
Access Network
(E-UTRAN)
User Equipment
Evolved Packet Core (EPC)
eNodeB eNodeB
S-GW MME
PCRF P-GW
External Networks
Source: Rashid Mijumbi, Joan Serrat, Juan Luis Gorricho, Niels Bouten, Filip De Turck, Raouf Boutaba, “Network Function Virtualization:
State-of-the-art and Research Challenges”. IEEE Communications Surveys and Tutorials. First Quarter, 2016.
IMS
Access Network
(E-UTRAN)
User Equipment
VNFs
eNodeB eNodeB
S-GW
MME
PCRF
P-GW
External Networks
Data Centers
IMS
31 of 140
Virtualised RAN
RRH
RRH
RRH
BBU
BBU
BBU
eNodeB
eNodeB
eNodeB
Evolved Packet
Core
RRH
RRH
RRH
Centralized BBUs
Evolved
Packed Core
Front haul Front haul
Fro
nt h
au
lSource: Rashid Mijumbi, Joan Serrat, Juan-Luis Gorricho, Javier Rubio-Loyola and Steven Davy, “Server Placement and Assignment in Virtualized Radio Access
Networks”, IEEE/IFIP CNSM, International Workshop on Management of SDN and NFV Systems, Barcelona, Spain. September 201532 of 140
Use Cases Ranked
Data source: sdxcentral.com
78%
51%
41%
27%
4%0%
10%
20%
30%
40%
50%
60%
70%
80%
Virtual CPE Virtualized EPC Service Chaining asPart of Sgi/Gi-LAN
Deployment
Virtualized RAN Others
SDxCentral survey involving 79 end-user respondents, including service
providers, (46%), cloud service providers (14%), enterprise end users (14%)
and a variety of others (24%) from user communities.
33 of 140
Business Model
Brokers
Infrastructure Provider (InP)
Computing, Storage, Network Resources
UserTelecommunications Service Provider (TSP)
2
3
4
VNF Provider (VNFP)
Server Provider(SP)
1
2
Source: Rashid Mijumbi, Joan Serrat, Juan Luis Gorricho, Niels Bouten, Filip De Turck, Raouf Boutaba, “Network Function
Virtualization: State-of-the-art and Research Challenges”. IEEE Communications Surveys and Tutorials. First Quarter, 2016.34 of 140
Related Concepts: (2) SDN
Distributed Control and Middleboxes (e.g. Firewall,
Intrusion Detection, etc.) in Traditional Networks
Vs Logical Layers in a Software Defined Network
• SDN decouples the network control and forwarding functions.
• Allows network control to become directly programmable via an open interface
SDN
Controller
Infrastructure
Layer
Application
Layer
APIs
Interface e.g. OpenFlow
Load Balancing
Routing
MAC Learning
Network/Business Applications
Network Services Control
Layer
Forwarding Switches
37 of 140
NFV vs SDN
NFV SDN
Approach Service/Function Abstraction Networking Abstraction
Formalization ETSI ONF
AdvantagePromises to bring flexibility and cost
reduction
Promises to bring unified programmable
control and open interfaces
ProtocolMultiple control protocols (e.g SNMP,
NETCONF)OpenFlow is de-facto standard
Applications
runCommodity servers and switches
Commodity servers for control plane and
possibility for specialized hardware for data
plane
NFV and SDN may be highly complimentary
NFV differs from the virtualization concept as used in the SDN architecture
39 of 140
NFV vs Cloud vs SDN
Source: Rashid Mijumbi, Joan Serrat, Juan Luis Gorricho, Niels Bouten, Filip De Turck, Raouf Boutaba, “Network Function
Virtualization: State-of-the-art and Research Challenges”. IEEE Communications Surveys and Tutorials. First Quarter, 2016.40 of 140
Present (State-of-the-art)
PART 1.2
Proofs of Concept
Collaborative Industrial and Academic NFV Projects
(Some) Products
41 of 140
ETSI PoCs
42 of 140
Open source collaborative project founded and hosted by the Linux Foundation, and composed
of TSPs and vendors.
Introduced in September 2014 as an outgrowth of the ETSI NFV Industry Specification Group
(ETSI NFV ISG).
Includes participation of leading end users to validate OPNFV meets the needs of user
community
OPNFV
43 of 140
Develop an integrated and tested open source platform that can be used to build NFV
functionality, accelerating the introduction of new products and services
Contribute to and participate in relevant open source projects that will be leveraged in the
OPNFV platform; ensure consistency, performance and interoperability among open source
components
Establish an ecosystem for NFV solutions based on open standards and software to meet the
needs of end users
Promote OPNFV as the preferred platform and community for open source NFV
OPNFV Objectives
Objective is to establish a carrier-grade integrated open source reference
platform that may be used to validate multi-vendor interoperable NFV solutions.
44 of 140
OPNFV Membership
https://www.opnfv.org/about/memberslist as of April 14th 2016
20
33
3
45 of 140
Scope
VIRTUALISATION LAYER
Computing Hardware
Storage Hardware
Network Hardware
VirtualComputing
VirtualStorage
VirtualNetwork
Network Functions Virtualisation Infrastructure (NFVI)
Virtualised Infrastructure Manager (VIM)
NFV Management and Orchestration (MANO)
OPNFV Scope
46 of 140
June 4, 2015: OPNFV Arno
Initial build of the NFV Infrastructure (NFVI)
and Virtual Infrastructure Manager (VIM)
components of ETSI NFV architecture.
Baseline foundation to enable continuous
integration, automated deployment and testing
of components necessary to build an NFV
platform from upstream components such as
OpenDaylight, OpenStack, Open vSwitch,
Ceph & KVM.
Aimed at exploring NFV deployments,
developing VNF applications, or NFV
performance and use case-based testing.
[10/01/2015] Arno SR1: Designed to address known issues in the
initial release for incremental stability and improved predictability.
47 of 140
March 1, 2016: OPNFV Brahmaputra
Adapted from: OPNFV Overview Deck: Mar 1, 2016 48 of 140
OPNFV Deployment
https://www.opnfv.org/software/download
The target OPNFV deployment is an OpenStack cloud
https://www.opnfv.org/software/download
49 of 140
OPNFV Deployment: Apex
Adapted from: OPNFV Overview Deck: Mar 1, 2016
Triple-O (OpenStack On OpenStack) Deployment Architecture
Based on RDO Manager which is the RDO Project’s implementation of the OpenStack Triple-O project.
OpenStack is used to install OpenStack.
Two OpenStack installations: undercloud and overcloud.
The undercloud is used to deploy the overcloud
The undercloud is an all-in-one installation of OpenStack.
Undercloud deployed as a VM on a jumphost.
This VM is pre-built and distributed as part of the Apex RPM.
The overcloud is OPNFV.
Configuration will be passed into undercloud which uses OpenStack’s orchestration component (Heat)
to execute OPNFV deployment
OpenStack On OpenStack On OpenStack
50 of 140
ETSI-hosted project to develop an Open Source NFV MANO software stack aligned with ETSI
NFV.
ETSI OSM was announced on 22 February 2016
Aligned to ETSI NFV
To provide a regularly updated reference implementation of NFV MANO
Open Source
Apache License 2.0, using open source tools and methods
Telefonica’s OpenMANO, Canonicals’s Juju Charms and Rift.io Orchestrator
Open Community
Participation is open to members as well as non-members of ETSI as well as individual
developers
ETSI Open Source MANO (OSM)
51 of 140
OSM Architecture
VNFM
RO
SO
52 of 140
OSM vs OPNFV
VIRTUALISATION LAYER
Computing Hardware
Storage Hardware
Network Hardware
VirtualComputing
VirtualStorage
VirtualNetwork
NFVI
Virtualised Infrastructure Manager (VIM)
NFV Management and Orchestration (MANO)
OPNFV Scope
OSM ScopeSO
NFV Orchestrator
53 of 140
OSM Members: April 06, 2016
ParticipantsMembers
Within the next two months [May/June], OSM will launch Release 0, integrating and
documenting the code base from Telefonica, RIFT.io, Canonical and others.
New OSM releases are to be issued every six months
https://osm.etsi.org/ 54 of 140
Other NFV Projects
Industry
Zero-time Orchestration, Operations and Management (ZOOM)
OpenMANO, OpenNFV, Open Network Platform (ONP),
CloudNFV, CloudBand, Virtual Service Edge, etc.
Academic
Mobile Cloud Networking (MCN)
UNIFY
T-NOVA
OPEN-Orchestrator Project (OPEN-O)
55 of 140
NFV Product Example: CISCO Enterprise
56 of 140
Future (Research Challenges)
PART 1.3
Management and Orchestration, Information Modelling, NFV Performance, Energy Efficiency, Security,
Privacy and Trust,
Research directions in selected NFV use cases such as Internet of Things, Information-Centric Networking
57 of 140
MANO
Critical aspect towards ensuring the correct
operation of the NFV Infrastructure (NFVI) as well
as Virtual Network Functions (VNFs).
Provides the functionality required for the
provisioning of VNFs, and the related operations,
such as the configuration of the VNFs and the
infrastructure these functions run on.
Critical aspect towards ensuring the correct
operation of the NFVI as well as VNFs.
Provides the functionality required for the
provisioning of VNFs, and the related operations,
such as the configuration of the VNFs and the
infrastructure these functions run on.
Virtualised Infrastructure Manager (VIM)
VNF Manager(s)
VNF Orchestrator
NFV Management and Orchestration (MANO)
Infr
ast
ruct
ure
, VN
F &
Se
rvic
e D
esc
rip
tio
nNFV Orchestrator
58 of 140
MANO: State-of-the-Art
(Automated) Resource Management still missing!
Rashid Mijumbi, Joan Serrat, Juan-Luis Gorricho, Steven Latre, Marinos Charalambides and Diego Lopez,
“Management and Orchestration Challenges in Network Function Virtualization”, IEEE Communications
Magazine. January 2016.
59 of 140
Resource Management
Server Placement, Rashid Mijumbi, Joan Serrat, Juan-Luis Gorricho, Javier Rubio-Loyola and Steven Davy, “Server Placement and
Assignment in Virtualized Radio Access Networks”, IEEE/IFIP CNSM, International Workshop on Management of
SDN and NFV Systems, Barcelona, Spain. September 2015
Function Placement, Chaining and Scheduling Rashid Mijumbi, Joan Serrat, Juan Luis Gorricho, Niels Bouten, Filip De Turck, Steven Davy, “Design and evaluation
of algorithms for mapping and scheduling of virtual network functions”, IEEE Conference on Network
Softwarization (NETSOFT). April 2015.
Niels Bouten, Maxim Claeys, Rashid Mijumbi, Joan Serrat, Jeroen Famaey, Steven Latre, Filip De Turck, “Semantic
Validation of Affinity Constrained Service Function Chain Requests”, IEEE Conference on Network Softwarization
(NetSoft), Seol Korea, June 6 – 10, 2016.
Dynamic Resource Allocation
Rashid Mijumbi, Joan Serrat, Juan Luis Gorricho, “Self-managed resources in network virtualisation
environments”, IFIP/IEEE International Symposium on Integrated Network Management (IM), May 2015,
Ottawa, Canada.
60 of 140
Information Modelling NFV’s potential is based on its ability to deliver high levels of
automation and flexibility.
Resources and functions in NFV will be provided by different
entities.
Availability of well understood, open and standardized descriptors
for these multi-vendor resources, functions and services will be
key to large-scale NFV deployments.
Models should consider both initial deployment as well as
lifecycle management - reconfiguration.
As part of the MANO specification, the ETSI provided a possible
set of models that may be useful in NFV.
OVF, TOSCA, YANG and SID
Virtualised
Infrastructure
Manager (VIM)
VNF Manager(s)
VNF Orchestrator
NFV Management and
Orchestration (MANO)
Infr
ast
ruct
ure
, VN
F &
Se
rvic
e D
esc
rip
tio
n
61 of 140
Information Modelling
Rashid Mijumbi, Joan Serrat, Juan Luis Gorricho, Niels Bouten, Filip De Turck, Raouf Boutaba,
“Network Function Virtualization: State-of-the-art and Research Challenges”. IEEE
Communications Surveys and Tutorials. First Quarter, 2016.
62 of 140
ETSI Report on NFV Information Model
https://docbox.etsi.org/ISG/NFV/Open/Drafts/IFA015_NFV_Information_Model
NFV Information Model structure
COMING SOON!
Publication of ETSI NFV Release 2
Documents planned for May 2016
63 of 140
Energy Efficiency
Bell Labs’ GWATT tool is aimed at determining the possible effect, on energy
consumption, of the evolution to NFV. Based on some forecast for traffic growth, the
tool is able to show the effect of virtualizing different network functions.
http://gwatt.net/intro/1 64 of 140
Energy Efficiency (II)
Rashid Mijumbiy, Joan Serraty, Juan-Luis Gorrichoy and Javier Rubio-Loyola, “On the Energy Efficiency
Prospects of Network Function Virtualization” 65 of 140
Performance (I)
NFV means that server providers should produce
equipment without knowledge of the characteristics of
functions that could run on them in future.
In the same way, VNF providers should ensure that the
functions will be able to run on commodity servers
This raises the question of whether functions run on
industry standard servers would achieve a performance
comparable to those running on specialized hardware,
and whether these functions would be portable between
the servers.
https://www.sdxcentral.com/articles/contributed/vnf-performance-fueling-nfv-discussion-kelly-leblanc/2015/05/ 66 of 140
Performance (II)
ETSI NFV Work Item “NFV Performance & Portability Best Practises”: DGS/NFV-PER001
Current version: v0.0.7 (stable draft – 15/10/2013)
If “best practices were followed” it is not only possible to achieve high performance (up to
80 Gbps for a server) in a fully virtualized environment, but that
the performance can be predictable, consistent and in vendor-agnostic manner,
leveraging features commonly available in current state-of-the-art servers.
x10
Performance Gap
Acceptable Performance 80 Gbps per COST blade
67 of 140
Performance (III)
However, performance at high speeds is an issue even in non-virtualized NFs
Hardware acceleration will also be important for NFV.
Improves the performance of some VNFs. e.g. for some functions (e.g. DPI, Dedup and
NAT), industry standard servers may not achieve the required levels of performance.
Better performance and energy efficiency achieved by deploying a virtualized DPI on
Application Specific Instruction-set Processor (ASIP) rather than commodity servers.
While hardware acceleration may be used for such functions, such specialization is against the
concept of NFV which aims at high flexibility.
There should be defined ways of managing the trade-off between performance and flexibility.
Phased migrations to NFV where those functions that have acceptable performance are
virtualized first and allowed to run alongside un virtualized or physical ones.
Some high performance NFs that may be difficult to virtualize without degradation in performance.
Source: Rashid Mijumbi, Joan Serrat, Juan Luis Gorricho, Niels Bouten, Filip De Turck, Raouf Boutaba, “Network Function Virtualization:
State-of-the-art and Research Challenges”. IEEE Communications Surveys and Tutorials. First Quarter, 2016.68 of 140
Despite the enormous potential of cloud computing,
consumer uncertainty and concern regarding issues of
privacy, security and trust remain a major barrier to the
switch to cloud models
VNFs represent subscriber services, personally identifiable
information which may be transferred to the cloud.
Unique challenges especially as the functions will be
distributed, making it hard to know where this data is and
who has access to it.
In the case where the functions are deployed in third party
clouds, users and Telecom service providers would not have
access to the physical security system of data centers.
Even if the service providers do specify their privacy and
security requirements, it may still be hard to ensure that they
are fully respected.
Security, Privacy, Trust
NFV Security; Problem Statement. Bob Briscoe (Rapporteur). Draft Group
Specification published, Oct 2014.69 of 140
Security, Privacy, Trust
NFV Security; Problem Statement. Bob Briscoe (Rapporteur). Draft Group Specification published,
Oct 2014.
Topology Validation & Enforcement
Availability of Management Support Infrastructure
Secure Crash Performance Isolation
User/Tenant Authentication, Authorization and Accounting
Private Keys within Cloned Images
Back-Doors via Virtualized Test & Monitoring Functions Multi-Administrator Isolation
Secured Boot
Authenticated Time Service
Emphasizing its importance, ETSI constituted a security expert group to focus on this concern.
The group started by identifying potential security vulnerabilities of NFV and establishing whether
they are new problems, or just existing problems in different guises
70 of 140
The NFV SEC Working Group
NFV presents unique opportunities for addressing security problems
Exploits new capabilities:
Automation and analytics
Holistic Monitoring combined with analytics
Security and trust guidance that is unique to NFV development, architecture and
operation.
Currently no processes to take advantage of these solutions and, once in place, they
will add procedural complexity
https://portal.etsi.org/tb.aspx?tbid=799&SubTB=799
Unsolved problems: (un)lawful Interception, topology validation,
network performance isolation and multi-administrator isolation
71 of 140
Even More Challenges . . .
Challenges to Related Technologies:
- Cloud Computing
- SDN
NFV Challenges
- Interoperability and Portability
- Federation
Use case Related Challenges
- 5G
- IoT
- ICN
- Interoperability and Portability
- Federation
- Interoperability and Portability
- Federation
Use case Related Challenges
- 5G
- IoT
- ICN
72 of 140
Summary of Challenges
Challenge Current Work Opportunities for Research
Management
and
Orchestration
NV MANO Framework Specification,
Vendor specific products aligned to different NFV MANO
framework,
Multiple MANO-focused frameworks and architectures
Traffic and function monitoring, inter-operability
and interfacing, programmability and
Intelligence, distributed management, Resource
Management (placement, chaining, scaling)
NFV
Performance
Specification of “best practices" that need to followed to obtain
acceptable performance in NFV,
Some reports on deployment experiences,
Various proposals applying hardware acceleration to enhance the
performance of some VNFs such as DPI, dedup and NAT
More studies on the applicability of hardware
acceleration to some NFs, and on the resulting
trade-off between performance and flexibility
Energy
Efficiency
Measurements on the effect of transferring network and user
functions to the cloud,
Simulation of possible energy saving resulting from NFV
Still limited number of real world deployments to
give actual vales, energy efficient hardware,
energy-aware function placement chaining,
consideration of inter-data center
communications
Security,
Privacy, Trust
Definition security, trust and privacy threats in NFV,
Guidance on how security, privacy and trust may be achieved in
NFV.
Topology validation, network performance
isolation, multi-administrator isolation, data
interception
73 of 140
Virtualized IP Multimedia Subsystem
PART 2
Introduction to Clearwater IMS
Description of setup (OpenStack - TSSG Cloud)
Hands-on
75 of 140
Required Tools/Software SSH client
For example Putty
Two instances of a SIP client:
Zoiper, X-Lite, Jitsi have been tested for this tutorial
Both instances could be the same e.g. two instances of zoiper
Both could be on a computer (same computer or different ones), smartphone, or one
on computer and another on smartphone
Access to a web-browser.
Google Chrome and IE have been tested for this tutorial
76 of 140
Required Tools/Software
Zoiper:
Download Link: https://www.zoiper.com/en/voip-softphone/download/zoiper3
Support for: Android, iOS, Windows, Phone 8, Windows, Linux, Mac, Browser
Tested on: iOS, Windows 10, Ubuntu 14.04
X-Lite:
Download Link: http://www.counterpath.com/x-lite-download/
Support for: Windows, Mac
Tested on: Windows 10
Jitsi:
Download Link: https://jitsi.org/Main/Download
Support for: Windows, Mac, Linux
Tested on: Windows 10, Ubuntu 14.04
SSH Client:
For those on windows, Putty can be used
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
77 of 140
IP Multimedia Subsystem (IMS) is IMS is an architectural
framework standardized by 3GPP for delivering
multimedia services over IP
Overlay-architecture for session control in all-IP network
aimed at openness and interoperability by adopting a
separated application-layer approach based on the
Session Initiation Protocol (SIP)
Intended to aid the access of multimedia and voice
applications from wireless and wireline terminals
Introduction: IP Multimedia Subsystem
78 of 140
IMS ComponentsIncludes functionalities related to End User authentication, authorization, call control and charging
for multimedia sessions, as well as QoS enforcement at data path level through the integration with
core network platforms such as the 3GPP Evolved Packet Core (EPC)
I-CSCF S-CSCFApplication
Server
HSSSLF
P-CSCF UE
79 of 140
Clearwater - IMS in the Cloud
Clearwater is an open source implementation of IMS (the IP Multimedia Subsystem)
Deployment in the cloud to provide voice, video and messaging services to (millions of) users.
Cloud-oriented design makes it extremely well suited for deployment in an NFV environment
All components are horizontally scalable using stateless load-balancing.
Minimal long-lived state is stored on cluster nodes,
No need for complex data replication schemes.
Most long-lived state is stored in back-end service nodes using cloud-optimized storage technologies
such as Cassandra.
Interfaces between the front-end SIP components and the back-end services use RESTful web services
interfaces.
Interfaces between the various components use connection pooling with statistical recycling of connections to
ensure load is spread evenly as nodes are added and removed from each layer.
80 of 140
Clearwater Architecture
HSSTest
Provisioning
memcached
memcached
cassandracassandra
UE
P-CSCF + WebRTC
I/S-CSCF BGCF, TAS
Rf CTF
XDMS HSS Mirror
App Servers
Bono Sprout
Ralf Homer Homestead
Ellis
CDF
81 of 140
Installation Methods All-in-one (AIO) image
AMI on Amazon EC2 or OVF image on a private virtualization platform such as VMware or VirtualBox.
Easy but offers no redundancy or scalability and relatively limited performance
Automated install
Using the Chef orchestration system
Recommended install for spinning up large scale deployments since it can handle creating an arbitrary
sized deployment in a single command
Currently only supported on Amazon’s EC2 cloud and assumes that DNS is being handled by Amazon’s
Route53 and that Route53 controls the deployment’s root domain
Manual install
Using Debian packages and manually configuring every machine, firewalls and DNS entries,
Recommended method if chef is not supported on your virtualization platform or your DNS is not
provided by Amazon’s Route53.
Can be performed on any collection of machines (at least 5 are needed) running Ubuntu 14.04
Makes no assumptions about the environment in which the machines are running.
This Hands-on
http://clearwater.readthedocs.org/en/latest/Manual_Install.html 82 of 140
Manual Installation (I)Resource Requirements
Mandatory nodes: 7 machines
Each of the 6 machine takes on a separate role (Bono, Ellis, Sprout, Homer, Homestead, Ralf) in the
final deployment.
1 machine for DNS: allow each node to find the others it needs to talk to carry calls
An existing server may be used by just adding a zone and configuring records required for
Clearwater
Optional nodes: 3 machines
Cacti: monitoring and graphing
SIPp: stress testing
Jump Server: SSH access to the above machines
At least 2 publicly accessible IP addresses: 1 for Bono (hosts a restund STUN server), 1 for Ellis (GUI)
http://clearwater.readthedocs.org/en/latest/Manual_Install.html 83 of 140
Manual Installation (II)Software Requirements
All nodes initially run clean installs of Ubuntu 14.04 - 64bit server edition
1 vCPU, 2 GB RAM (equivalent to t1.small on amazon)
The firewalls of these devices must be independently configurable. A specific number of ports has to be
opened on each machine
The system requirements for each role are the same thus the allocation of roles to machines can be
arbitrary
Configure the APT software sources
Configure each machine so that APT can use the Clearwater repository server.
create /etc/apt/sources.list.d/clearwater.list with the contents:
deb http://repo.cw-ngv.com/stable binary/
http://clearwater.readthedocs.org/en/latest/Manual_Install.html 84 of 140
Manual Installation (III)
,
Installation Steps
Determine machine roles: ellis, bono, sprout, homer, homestead, ralf
Firewall configuration: http://clearwater.readthedocs.org/en/latest/Clearwater_IP_Port_Usage.html
Create the per-node configuration: local_config
Install node-specific software
Provide shared configuration: shared_cinfig
Provision telephone numbers in ellis
DNS records
http://clearwater.readthedocs.org/en/latest/Manual_Install.html
15-20 minutes
Still unstable
Pre-installed
85 of 140
ETSI Reference Architecture - Revisited
VIRTUALISATION LAYER
Computing Hardware
Storage Hardware
Network Hardware
VirtualComputing
VirtualStorage
VirtualNetwork
Network Functions Virtualisation Infrastructure (NFVI)
VNF 1 VNF 2 VNF 3 VNF n…
Virtualised Infrastructure Manager (VIM)
VNF Manager(s)
VNF Orchestrator
NFV Management and Orchestration (MANO)
Virtual Network Functions (VNFs)
Infr
ast
ruct
ure
, VN
F &
Se
rvic
e D
esc
rip
tio
n
86 of 140
Hands-on Architecture
KVM
NFVIMANO
VNFs
2x Dell PowerEdge R720
VIM
1x Dell PowerEdge R720
Virtual Machines
Virtual Machines
Virtual IP Multimedia Subsystem
Cacti
87 of 140
Hardware
3 Servers: 1x Controller (management) node, 2x Compute (Hypervisor) nodes
Dell PowerEdge R720 Servers
Each Server:
128 GB RAM, 2x 600GB Hard Drive, 32 CPU Cores, 2x 10GB NICs, 2x 1GB
NICs
https://specs.openstack.org/openstack/neutron-specs/specs/juno/neutron-ovs-dvr.html 88 of 140
VIM: OpenStack
Cloud management system
Distributed Virtual Routing (DVR)
OpenStack virtual routers are replicated across the compute nodes.
In a standard install the network traffic would have to leave the Compute
nodes via an encapsulation process and sent to the 'network node' where all
the virtual routers are and then routed out of the network node.
With DVR, if you have a floating IP on a VM, the traffic leaves the compute
node straight onto the physical network - with no encapsulation having to
take place - and no network node bottleneck.
https://specs.openstack.org/openstack/neutron-specs/specs/juno/neutron-ovs-dvr.html 89 of 140
VIM: TSSG Cloudhttps://rashidcloud.tssg.org/horizon/auth/login/
90 of 140
OpenStack: Resource Overview
Approximate Resources:
~ 250 VMs, ~ 1000 vCPUs, ~ 350 GB RAM, ~ 3 TB Storage, ~ 500 Public IPs
91 of 140
Prepared VNF Images
,
92 of 140
Planned OpenStack DeploymentExternal Network (87.44.16. and 87.44.17.)
Private Network (192.168.1.0/24)
Router
NOMS2016
VNF
Bono
VNF
Ellis
VNF
Sprout
VNF
Homer
VNF
Homestead
VNF
Ralf
Core Nodes
VNF
DNS
VNF
Cacti
VNF
SIPp
Support Nodes
VNF
Sprout-1
VNF
Homer-1
Scaling up
. . .
Instance
Jump Server
93 of 140
Creating the Jump Server
OpenStack URL:
https://rashidcloud.tssg.org/horizon/auth/login/
Login accounts
Username: nfv1, nfv2, … , nfv15
Password: noms2016
96 of 140
Create Jump Server
2 Fill in VM Details
1
Select Instances
97 of 140
Set Access and Security
2
1
Open Ports
98 of 140
Set Login Password
1
use cloud-init to assign a password [noms2016] for the user [ubuntu] to login into the instance
23
Launch Instance
4
99 of 140
External Access: Assign Floating IP
1
Assign a public IP to allow external access to VM
Allocate an IP address to the project
32
100 of 140
External Access: Assign Floating IP
1
IP Address allocated; to be used to SSH into VM
Associated IP to VM
101 of 140
Login into VM
1
VM IP Address
2
3
Trust VM identity
Username: ubuntu, password: noms2016
4
102 of 140
OpenStack Clients
Allow interaction with OpenStack using cli
Authentication: download RC File
Files already downloaded to the folder authenticate
run: source clouduserXX-rc.sh
provide password when prompted
You are authenticated!
103 of 140
Virtual IMS Deployment Jump Server has all scripts to install Clearwater
$ ls
Running the scripts ./deploy.sh
./deploy.sh makes initial deployment
./teardown.sh terminates all nodes deployed using ./deploy.sh
./stress.sh starts simulated sip calls to stress deployed system
./scaleup.sh deploys additional nodes to scale initial deployment up
./teardown_added_nodes.sh terminates all nodes deployed using ./scaleup.sh
./scaledown.sh teardown some existing nodes
104 of 140
./deploy.sh
~ 2 minutes
105 of 140
./deploy.sh
~ 3 minutes
On completion, IP addresses are printed.
These can also be checked in OpenStack
Note all of them
We will refere to them as <ellisIP>, <bonoIP>,
<nsIP> and <cactiIP> in what follows
106 of 140
./deploy.sh
~ 3 minutes
VNFs have been launched in OpenStack
107 of 140
Network Topology
108 of 140
Logging and Debugging <vnf> is one of ellis, bono, ralf, …
<domain> is nfv-tutorial.noms2016
From Jump Server, SSH into ellis <ellisIP>
sudo ssh ubuntu@<ellisIP>
All other nodes can be accessed from ellis
Check that DNS is correctly setup from ellis:
ping homer.<domain>, hs.<domain>
Clearwater <vnf>s are monitored by monit
sudo monit status
monit should automatically restart services if it goes down
To restart a component: sudo service <vnf> stop to stop the component, monit
automatically restarts it
By default each component logs to /var/log/<vnf>/
e.g. sudo nano /var/log/ellis/…
sudo clearwater-etcdctl cluster-health
sudo clearwater-etcdctl member list
http://clearwater.readthedocs.org/en/latest/Troubleshooting_and_Recovery.html 109 of 140
Making a Test Call
Ellis URL: http://<ellisIP>
In this example: Public IP for VM = 87.44.16.43
Signup as a new user
Create numbers for your client
110 of 140
Signup
signup code is noms2016
111 of 140
Number AllocationEllis will automatically allocate a new number (6505550370 in this case) and display its password
(sy6XRb3EA in this case)
Another identity can be created! Note details of second identity
1
23
Remember the password provided for each number as it will only be displayed once.
From now on, we will use <username> to refer to the SIP username (e.g. 6505550793), <password>
to refer to the password (e.g. VyZPVRKpX ), and <domain> to refer to nfv-tutorial.noms2016
112 of 140
Client Setup: Zoiper on PC
1
2
3
4
56
username
password
domain
username@domain
113 of 140
Client Setup: Zoiper on PC
username
password
domain
username@domain
username
<bonoIP>: 5060
114 of 140
Client Setup: Zoiper on PC
TCP
<bonoIP>:5060
Advanced settings
115 of 140
Client Setup: Zoiper on MAC OS X
1 2 3
4 5
username
password
domain
username@domain
Change domain from example.com to nfv-tutorial.noms2016 in all cases!
116 of 140
Client Setup: Zoiper on MAC OS X
username
password
domain
username@domain
username
<bonoIP> : 5060
117 of 140
Client Setup: Zoiper on MAC OS X
TCP
<bonoIP>: 5060
118 of 140
Client Setup: Zoiper on android
21
4
1
34
119 of 140
Client Setup: Zoiper on android
1
username
domain
password
username@domain
<bonoIP>: 5060
2 3
120 of 140
Client Setup: Zoiper on iOS
1
23
4
121 of 140
Client Setup: Zoiper on iOS
1
2
username
domain
password
username
username
username@domain
<bonoIP>: 5060
3
4
122 of 140
Client Setup: Zoiper on iOS
2
1
3
Port 5060 on <bonoIP>4
Successful Registration
123 of 140
One Client Calling the Other
124 of 140
Privacy, Call Baring and Diversion
http://clearwater.readthedocs.org/en/latest/Clearwater_Call_Barring_Support.html 125 of 140
Statistics / Monitoring
Clearwater provides a set of statistics about the performance of each
Clearwater nodes over SNMP.
Currently, this is available on Bono, Sprout, Ralf and Homestead nodes
http://clearwater.readthedocs.org/en/latest/Clearwater_SNMP_Statistics.html 126 of 140
Monitoring: Cacti
Open-source statistics and graphing solution
Supports gathering statistics via native SNMP and also via external scripts
Exposes graphs over a web interface
127 of 140
Cacti With Clearwater
Ubuntu 14.04 VM
Install Cacti: sudo apt-get install cacti cacti-spine
Accept all the configuration defaults
Finalize Installation at: <cactiIP>/cacti
Default login (admin/admin) and set a new password
Modify Configuration, add nodes to be monitored, add graphs
For Clearwater, there are instructions at:
http://clearwater.readthedocs.org/en/latest/Cacti.html
admin/noms2016
128 of 140
Cacti Graphs
129 of 140
Cacti Graphs
130 of 140
Performance Limit (./stress.sh)
Establish the upper limits of performance
and capacity for each of the four software
elements that make up a Clearwater
system.
Bulk provision subscribers (on Homer and
Homestead)
Clearwater’s SIP stress node
Runs large amounts of SIP stress
against a deployment
Runs a standard SIPp script against
your bono cluster
Bono nodes translate this into traffic for
sprout and this generates traffic on
homestead and homer
memcached
Ralf
Bonomemcached
Sprout
cassandra
Homestead
cassandra
Homer
SIPp
132 of 140
./stress.sh
Replaces Homer and
Homestead nodes with ones in
which 100,000 subscribers
have been registered
Starts 5 SIPp nodes
Updates DNS Records to
include the new nodes
memcached
Ralf
Bonomemcached
Sprout
cassandra
Homestead
cassandra
Homer
SIPpSIPpSIPpSIPpSIPp
133 of 140
Status of Deploymentsudo clearwater-etcdctl member list
/usr/share/clearwater/clearwater-cluster-manager/scripts/check_cluster_state
134 of 140
Cacti Graphs
SIPp node is started
135 of 140
Cacti Graphs
SIPp node is started
136 of 140
The core Clearwater nodes have the
ability to elastically scale;
Can grow and shrink
deployment on demand,
without disrupting calls or
losing data
Decision to scale up could be based
on resource utilisation, e.g. when
CPU utilization reaches 60%
In this hands-on, we will spin up five
new VNFs
Bono, Ralf, Sprout, Homer,
Homestead
Scaling
Bono
memcached
Ralf
BonoBono memcached
Sprout
cassandra
Homestead
cassandra
Homer
137 of 140
Scaling up: ./scaleup.sh
Spin up the new nodes:
Wait until the new nodes have fully joined the existing deployment.
sudo /usr/share/clearwater/clearwater-cluster-manager/scripts/check_cluster_state
Update DNS to contain the new nodes.
sudo clearwater-etcdctl member list
ping sprout1.nfv-tutorial.noms2016
138 of 140
References1. Niels Bouten, Maxim Claeys, Rashid Mijumbi, Joan Serrat, Jeroen Famaey, Steven Latre, Filip De Turck, “Semantic
Validation of Affinity Constrained Service Function Chain Requests”, IEEE Conference on Network Softwarization
(NetSoft), Seol Korea, June 6 – 10, 2016.
2. Rashid Mijumbi, Joan Serrat, Juan Luis Gorricho, Steven Latre, Marinos Charalambides, Diego Lopez, “Management and
Orchestration Challenges in Network Function Virtualization”. IEEE Communications Magazine. January 2016.
3. Rashid Mijumbi, Joan Serrat, Juan Luis Gorricho, Niels Bouten, Filip De Turck, Raouf Boutaba, “Network Function
Virtualization: State-of-the-art and Research Challenges”. IEEE Communications Surveys and Tutorials. First Quarter,
2016.
4. Rashid Mijumbi, Joan Serrat, Juan Luis Gorricho, Niels Bouten, Filip De Turck, Steven Davy, “Design and evaluation of
algorithms for mapping and scheduling of virtual network functions”, IEEE Conference on Network Softwarization
(NETSOFT). April 2015.
5. Rashid Mijumbi, Joan Serrat, Juan-Luis Gorricho, Javier Rubio-Loyola and Steven Davy, “Server Placement and
Assignment in Virtualized Radio Access Networks”, IEEE/IFIP CNSM, International Workshop on Management of
SDN and NFV Systems, Barcelona, Spain. September 2015
6. Niels Bouten, Jeroen Famaey, Rashid Mijumbi, Bram Naudts, Joan Serrat, Steven Latre, Filip De Turck, “Towards NFV-
based Multimedia Delivery”, IFIP/IEEE International Symposium on Integrated Network Management (IM), Ottawa,
Canada, May 2015.
139 of 140
Questionnaire
goo.gl/i7mSkk
Please be so kind to fill out the questionnaire to help us improve the tutorial
140 of 140
Top Related