The document outlines the conception, current state, and future challenges of Network Functions Virtualization (NFV) presented at the Network Operations and Management Symposium in 2016. It covers NFV's motivations, architecture, proofs of concept, and related concepts like Software Defined Networking (SDN) and cloud computing, highlighting its benefits in reducing operational costs and enhancing service agility. The document also discusses future research directions and use cases for NFV in various domains such as telecommunications and cloud services.

1. Network Functions Virtualization
Conception, Present & Future
Rashid Mijumbi, Waterford Institute of Technology
Niels Bouten, Ghent University
Network Operations and Management Symposium (NOMS)
April 29, 2016
Istanbul, Turkey

2. Outline
PART 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

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

4. 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
Exabytespermonth
Data Source: Cisco VNI Global IP Traffic Forecast, 2014–2019. May 2015.
1 exabyte = 1 000 000 000 gigabytes
4 of 140

5. 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 2013
5 of 140

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

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

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

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

10. 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 value
in 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.html
10 of 140

11. NFV Timeline
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 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
OPNFVBrahmaputra
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

12. Reference Architecture
VIRTUALISATION LAYER
Computing
Hardware
Storage
Hardware
Network
Hardware
Virtual
Computing
Virtual
Storage
Virtual
Network
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)
Infrastructure,VNF&ServiceDescription
1
2
3
12 of 140

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

14. 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 Instantiation VNFC 1
Non-parallelizable
VNFC
VNF 1
[1:1]
parallelizable VNFC
(min. & max. # of instances
VNF 1
VNFC 1
[1:n]
VNFC States
VNFC 1
Stateless VNFC
VNF 1
state
VNFC 1
Stateful VNFC
VNF 1
state
stateVNFC 1
VNFC with
external state
VNF 1
14 of 140

15. NFVI
NFV Orchestrator
18 of 140

16. Reference Architecture
VIRTUALISATION LAYER
Computing
Hardware
Storage
Hardware
Network
Hardware
Virtual
Computing
Virtual
Storage
Virtual
Network
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)
Infrastructure,VNF&ServiceDescription
19 of 140

17. Reference Architecture
Hypervisor e.g. KVM
Standard Servers
Virtual Machines, Containers
20 of 140

18. NFV MANO
NFV Orchestrator
21 of 140

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

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

21. NFV MANO
Operation System Support, Business System Support
Element Management
Network Management Systems
NFV Orchestrator
24 of 140

22. Related Concepts: (1) Cloud Computing
Hardware
Infrastructure
Platform
Software
CPU, Storage, Bandwidth
Business Applications,
Web Services
Virtual Machines
Software Framework
Layered Resources
Mapping 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

23. 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 Group
DMTF Cloud Management Working
Group
Latency Expectations for low latency Some latency is acceptable
Protocol
Multiple 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

24. 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
CloudMobileCDNAccess
ArchitectureOrientedServiceOriented
27 of 140

25. Architecture Use Cases
Adapted from D.R. Lopez, “Moving along the NFV Way”, May 2014
IaaS
NaaS
NFVIaaS
Administrative
Domain 1
Administrative
Domain 2
IaaS
NaaS
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

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

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

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

29. 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
Fronthaul
Source: 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
32 of 140

30. 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 as
Part 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

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

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

33. NFV vs SDN
NFV SDN
Approach Service/Function Abstraction Networking Abstraction
Formalization ETSI ONF
Advantage
Promises to bring flexibility and cost
reduction
Promises to bring unified programmable
control and open interfaces
Protocol
Multiple control protocols (e.g SNMP,
NETCONF)
OpenFlow is de-facto standard
Applications
run
Commodity 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

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

35. Present (State-of-the-art)
PART 1.2
Proofs of Concept
Collaborative Industrial and Academic NFV Projects
(Some) Products
41 of 140

36. ETSI PoCs
42 of 140

37.  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

38.  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

39. OPNFV Membership
https://www.opnfv.org/about/memberslist as of April 14th 2016
20
33
3
45 of 140

40. Scope
VIRTUALISATION LAYER
Computing
Hardware
Storage
Hardware
Network
Hardware
Virtual
Computing
Virtual
Storage
Virtual
Network
Network Functions Virtualisation Infrastructure (NFVI)
Virtualised
Infrastructure
Manager (VIM)
NFV Management and
Orchestration (MANO)
OPNFV Scope
46 of 140

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

42. March 1, 2016: OPNFV Brahmaputra
Adapted from: OPNFV Overview Deck: Mar 1, 2016 48 of 140

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

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

45.  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

46. OSM Architecture
VNFM
RO
SO
52 of 140

47. OSM vs OPNFV
VIRTUALISATION LAYER
Computing
Hardware
Storage
Hardware
Network
Hardware
Virtual
Computing
Virtual
Storage
Virtual
Network
NFVI
Virtualised
Infrastructure
Manager (VIM)
NFV Management and
Orchestration (MANO)
OPNFV Scope
OSM Scope
SO
NFV Orchestrator
53 of 140

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

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

50. NFV Product Example: CISCO Enterprise
56 of 140

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

52. 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)
Infrastructure,VNF&ServiceDescription
NFV Orchestrator
58 of 140

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

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

55. 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)
Infrastructure,VNF&ServiceDescription
61 of 140

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

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

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

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

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

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

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

63.  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

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

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

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

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

68. Virtualized IP Multimedia Subsystem
PART 2
Introduction to Clearwater IMS
Description of setup (OpenStack - TSSG Cloud)
Hands-on
75 of 140

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

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

71.  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

72. IMS Components
Includes 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-CSCF
Application
Server
HSSSLF
P-CSCF UE
79 of 140

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

74. Clearwater Architecture
HSS
Test
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

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

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

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

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

79. ETSI Reference Architecture - Revisited
VIRTUALISATION LAYER
Computing
Hardware
Storage
Hardware
Network
Hardware
Virtual
Computing
Virtual
Storage
Virtual
Network
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)
Infrastructure,VNF&ServiceDescription
86 of 140

80. Hands-on Architecture
KVM
NFVI
MANO
VNFs
2x Dell PowerEdge R720
VIM
1x Dell PowerEdge R720
Virtual
Machines
Virtual
Machines
Virtual IP Multimedia Subsystem
Cacti
87 of 140

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

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

83. VIM: TSSG Cloud
https://rashidcloud.tssg.org/horizon/auth/login/
90 of 140

84. OpenStack: Resource Overview
Approximate Resources:
~ 250 VMs, ~ 1000 vCPUs, ~ 350 GB RAM, ~ 3 TB Storage, ~ 500 Public IPs
91 of 140

85. Prepared VNF Images
,
92 of 140

86. Planned OpenStack Deployment
External 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

87. Creating the Jump Server
 OpenStack URL:
 https://rashidcloud.tssg.org/horizon/auth/login/
 Login accounts
 Username: nfv1, nfv2, … , nfv15
 Password: noms2016
96 of 140

88. Create Jump Server
2 Fill in VM Details
1
Select Instances
97 of 140

89. Set Access and Security
2
1
Open Ports
98 of 140

90. Set Login Password
1
use cloud-init to
assign a password
[noms2016] for the
user [ubuntu] to
login into the
instance
2
3
Launch Instance
4
99 of 140

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

92. External Access: Assign Floating IP
1
IP Address allocated; to be used to SSH into VM
Associated IP to VM
101 of 140

93. Login into VM
1
VM IP Address
2
3
Trust VM identity
Username: ubuntu, password: noms2016
4
102 of 140

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

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

96. ./deploy.sh
~ 2 minutes
105 of 140

97. ./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

98. ./deploy.sh
~ 3 minutes
VNFs have been launched in OpenStack
107 of 140

99. Network Topology
108 of 140

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

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

102. Signup
signup code is noms2016
111 of 140

103. Number Allocation
Ellis 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
2
3
 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

104. Client Setup: Zoiper on PC
1
2
3
4
5
6
username
password
domain
username@domain
113 of 140

105. Client Setup: Zoiper on PC
username
password
domain
username@domain
username
<bonoIP>: 5060
114 of 140

106. Client Setup: Zoiper on PC
TCP
<bonoIP>:5060
Advanced
settings
115 of 140

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

108. Client Setup: Zoiper on MAC OS X
username
password
domain
username@domain
username
<bonoIP> : 5060
117 of 140

109. Client Setup: Zoiper on MAC OS X
TCP
<bonoIP>: 5060
118 of 140

110. Client Setup: Zoiper on android
2
1
4
1
3
4
119 of 140

111. Client Setup: Zoiper on android
1
username
domain
password
username@domain
<bonoIP>: 5060
2 3
120 of 140

112. Client Setup: Zoiper on iOS
1
2
3
4
121 of 140

113. Client Setup: Zoiper on iOS
1
2
username
domain
password
username
username
username@domain
<bonoIP>: 5060
3
4
122 of 140

114. Client Setup: Zoiper on iOS
2
1
3
Port 5060 on
<bonoIP>4
Successful
Registration
123 of 140

115. One Client Calling the Other
124 of 140

116. Privacy, Call Baring and Diversion
http://clearwater.readthedocs.org/en/latest/Clearwater_Call_Barring_Support.html 125 of 140

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

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

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

120. Cacti Graphs
129 of 140

121. Cacti Graphs
130 of 140

122. 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
Bono
memcached
Sprout
cassandra
Homestead
cassandra
Homer
SIPp
132 of 140

123. ./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
Bono
memcached
Sprout
cassandra
Homestead
cassandra
Homer
SIPpSIPpSIPpSIPpSIPp
133 of 140

124. Status of Deployment
sudo clearwater-etcdctl member list
/usr/share/clearwater/clearwater-cluster-manager/scripts/check_cluster_state
134 of 140

125. Cacti Graphs
SIPp node is started
135 of 140

126. Cacti Graphs
SIPp node is started
136 of 140

127.  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
Bono
Bono memcached
Sprout
cassandra
Homestead
cassandra
Homer
137 of 140

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

129. References
1. 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

130. Questionnaire
goo.gl/i7mSkk
Please be so kind to fill out the questionnaire to help us
improve the tutorial
140 of 140