You are on page 1of 116

Republic of Yemen

Ministry of High Education


University of Modern Sciences
Deanship of Graduate Studies
Program: Information Technology

An Efficient Approach
For Mobile Core Services Placement On
Network Function Virtualization
A thesis submitted in partial fulfillment of the requirements for Master

Degree in Information Technology.

By
Basheer Ameen Raddwan

Supervisor
Prof. Dr. Khalil Al-Wagih

January 2019
Republic of Yemen
Ministry of High Education
University of Modern Sciences
Deanship of Graduate Studies
Program: Information Technology

An Efficient Approach
For Mobile Core Services Placement On
Network Function Virtualization
A thesis submitted in partial fulfillment of the requirements for Master

Degree in Information Technology.

By
Basheer Ameen Raddwan

Supervisor
Prof. Dr. Khalil Al-Wagih

January 2019
Acknowledgment

In the first place I am thankful to God almighty praise be to him for fulfilling this
humble effort for the sake of his satisfaction.

Then I am thankful to my supervisor Prof. Khalil Al-Wagih for his highly appre-
ciated mentoring, guiding, and vital motivation. And to the dean of the Deanship
of Graduate Studies and the head of Department of Information Technology and all
the staff of University of Modern Sciences.

Also, I am thankful to who support me with advice or by providing reference docu-


ments; namely, Dr. Ibrahim Al-Baltah, Sana’a University. Dr. Waddah Al-Ashwal,
University of Adelaide, Australia.

Also, I am thankful to Yemen Mobile Co. represented by Eng. Amer Haza’a ex-
ecutive manager and Eng. Ali Aziz, core network manager, for supporting this
work.

Finally, a worm thanks to my family.

iii
List of abbreviations

Abbriviation Meaning
3GPP Third Generation Partner ship Project
ARPU Average Revenue Per User
BLP Binary Linear Programming
CAPEX Capital Expense
CDN Content Delivery Network
COTS Commercial off-the-shelf
DcPSM Decomposition Path Selection Mapping
DSBM Decompostion Selection Back-track Mapping
E2E End-to-End
EM Element Management
EMS Element Management System
EPC Evolved Packet Core
ETSI European Telecommunications Standards Insti-
tute
ETSI-MANO ETSI Management and Orchestration framework
EvoVNFP Evolvable VNF Placement
FCAPS Fault Management, Configuration Management,
Accounting Management, Performance Manage-
ment, and Security Management
GA Genetic Algorithms
IETF Internet Engineering Task Force
ILP Integer Linear Programming
ISG Industry Standard Group

iv
IT Information Technology
LP Linear Program
LXC Linux Container
LXD Linux Container guest (Docker like containers)
M2M Machine to Machine
MANO Management and Orchestration
MILP Mixed Integer Linear Programming
MIP Mixed Integer Programming
MVG Modularly Varying Goals
NF Network Function
NFV Network Function Virtualization
NFVO NFV Orchestrator
NFV-RA Network Function Virtualization Resource
Allocation problem
NS Network Service
OPEX Operational Expense
PoC Proof of Concept
PoP Present of Position
QoS Quality of Service
RL Reenforcement Learning
RO Resource Orchestrator
SDN Software Defined Networking
SFC Service Function Chaining
SFC-RA Service Function Chaining Resource Allocation
problem
( similar to NFV-RA)
SG Service Graph
SO Service Orchestrator
VIM Virtualized Infrastructure Manager
VM Virtual Machine
VM-PP Virtual Machine Placement problem
VNF Virtual Network Function

v
VNF-FG VNF Forwarding Graph
VNF-FGE VNF Forwarding Graph Embedding
VNF-P Virtual Network Function Placement problem
VNFc Virtual Network Function component
VNFM VNF Manager

vi
List of Figures

Figure 1.1 Top level design of virtualized Telecom 4G, 5G, and 5G-IoT
networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Figure 1.2 ETSI NFV Architectural Framework . . . . . . . . . . . . . . . 5
Figure 1.3 NFVI node components . . . . . . . . . . . . . . . . . . . . . . 8
Figure 1.4 Service decomposition example . . . . . . . . . . . . . . . . . . 10
Figure 1.5 Path types result from service decomposition . . . . . . . . . . . 11

Figure 2.1 Example of service decomposition types . . . . . . . . . . . . . . 25

Figure 3.1 Top level design of virtualized Telecom 4G, 5G, and 5G-IoT
networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 3.2 Path identificaition and candidate paths grouping . . . . . . . . 40
Figure 3.3 Clustering Factor (CF) as proposed by Sahhaf . . . . . . . . . . 41

Figure 4.1 Experiment framework design . . . . . . . . . . . . . . . . . . . 49


Figure 4.2 Service request counters . . . . . . . . . . . . . . . . . . . . . . 61
Figure 4.3 Execution time . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Figure 4.4 Request Execution time . . . . . . . . . . . . . . . . . . . . . . 64
Figure 4.5 Acceptance ratio . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 4.6 Request Acceptance ratio . . . . . . . . . . . . . . . . . . . . . 67
Figure 4.7 Average cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 4.8 Request embedding cost . . . . . . . . . . . . . . . . . . . . . . 69
Figure 4.9 Average cost to average revenue . . . . . . . . . . . . . . . . . . 70
Figure 4.10Request embedding cost revenue . . . . . . . . . . . . . . . . . . 71

Figure A.1Five paths small scenario . . . . . . . . . . . . . . . . . . . . . . 91


Figure A.2Five paths large scenario . . . . . . . . . . . . . . . . . . . . . . 92
Figure A.3Ten paths small scenario . . . . . . . . . . . . . . . . . . . . . . 93

vii
Figure A.4Ten paths large scenario . . . . . . . . . . . . . . . . . . . . . . 94
Figure A.5Twenty paths small scenario . . . . . . . . . . . . . . . . . . . . 95
Figure A.6Twenty paths large scenario . . . . . . . . . . . . . . . . . . . . 96

viii
List of Tables

Table 2.1 Litrature review summary of VNE and VNF-P . . . . . . . . . . 26


Table 2.2 Litrature review summary . . . . . . . . . . . . . . . . . . . . . 27

Table 3.1 Physical Network Model . . . . . . . . . . . . . . . . . . . . . . 30


Table 3.2 Service Request Model . . . . . . . . . . . . . . . . . . . . . . . 33

Table 4.1 Environment Setup: Simulation Parameters . . . . . . . . . . . 50


Table 4.2 Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . 51
Table 4.3 Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . 52
Table 4.4 List of compared schemes . . . . . . . . . . . . . . . . . . . . . 56
Table 4.5 Expriment scenarios . . . . . . . . . . . . . . . . . . . . . . . . 57
Table 4.6 List of synthetic physical network . . . . . . . . . . . . . . . . . 58
Table 4.7 Impact of increasing physical edges . . . . . . . . . . . . . . . . 63

ix
Contents

Resolution of Discussion and Judge Committee Number 2 for the


Year 2018-2019 to Accept the Thesis i

Resolution of Discussion and Judge Committee to Correction and


Amendments ii

Acknowledgment iii

List of abbreviations iv

List of figures vii

List of tables ix

Table of contents x

Abstract xiv

1 Introduction 1
1.1 Virtualizing Telecom Network Services . . . . . . . . . . . . . . . . . 1
1.2 ETSI NFV Architectural Framework . . . . . . . . . . . . . . . . . . 3
1.2.1 NFV Management and Orchestration . . . . . . . . . . . . . . 5
1.2.2 Network Function Virtualization Infrastructure (NFVI) . . . . 7
1.3 Network Function Decomposition . . . . . . . . . . . . . . . . . . . . 9
1.4 The Use Case of the Study . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6 Research Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.7 The Significance of the Study . . . . . . . . . . . . . . . . . . . . . . 13
1.8 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 13

x
1.9 Scope of the Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.10 Benchmark Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.11 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.12 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Literature Review and Related Work 16


2.1 Network Function Placement in Literature . . . . . . . . . . . . . . . 16
2.1.1 Virtual Network Embedding . . . . . . . . . . . . . . . . . . . 16
2.1.2 Virtual Network Function Placement . . . . . . . . . . . . . . 17
2.1.3 NFV Resource Allocation . . . . . . . . . . . . . . . . . . . . 17
2.1.4 VNF Placement and Routing (VNF-PR) . . . . . . . . . . . . 18
2.2 Placement Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Proposed Strategies to Solve the Placement Problems . . . . . . . . . 19
2.3.1 Integer Linear Programming . . . . . . . . . . . . . . . . . . . 20
2.3.2 Reinforcement Learning . . . . . . . . . . . . . . . . . . . . . 20
2.3.3 Multi-Stage Network Service Embedding . . . . . . . . . . . . 20
2.3.4 VNF Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.5 Evolvable Approach . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.6 Placement on Top of Linux Containers . . . . . . . . . . . . . 22
2.4 Complexity of Placement Problem . . . . . . . . . . . . . . . . . . . 23
2.5 Placement with Service Decomposition Support . . . . . . . . . . . . 24
2.6 Efficiency Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 The Proposed Approach 28


3.1 Network Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.1 Physical Network . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1.2 Path Identification . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.3 Service Requests . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Problem Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.1 Problem Variables . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2.2 Objective Function . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.3 Constraints of the Problem . . . . . . . . . . . . . . . . . . . 36
3.3 Exact Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

xi
3.4 Catalogue of Physical Paths . . . . . . . . . . . . . . . . . . . . . . . 39
3.5 Heuristic Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5.1 Decomposition Selection Algorithm . . . . . . . . . . . . . . . 40
3.5.2 Service Mapping Algorithm . . . . . . . . . . . . . . . . . . . 42
3.5.3 Path Mapping Algorithm . . . . . . . . . . . . . . . . . . . . 43
3.5.4 Check Node Validation Algorithm . . . . . . . . . . . . . . . . 45
3.5.5 Check Links Validation Algorithm . . . . . . . . . . . . . . . 46

4 Experiment and Performance Evaluation 48


4.1 Experiments Design Framework . . . . . . . . . . . . . . . . . . . . . 48
4.2 Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1 Generating Service Requests . . . . . . . . . . . . . . . . . . . 50
4.2.2 NFV Physical Network Infrastructure . . . . . . . . . . . . . 51
4.2.3 Synthetic Physical Networks . . . . . . . . . . . . . . . . . . . 52
4.2.4 Hardware and Software Description . . . . . . . . . . . . . . . 53
4.3 Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4 Simulation Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4.1 Experiment Procedure . . . . . . . . . . . . . . . . . . . . . . 54
4.4.2 Simulation Scenarios . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.3 Measuring Execution Time . . . . . . . . . . . . . . . . . . . 56
4.4.4 Selection Parameters . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.5 Comparison Method . . . . . . . . . . . . . . . . . . . . . . . 58
4.5 Results Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5.1 Execution Time . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.5.2 Acceptance Ratio . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.5.3 Embedding Cost . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.5.4 Ratio of Average Cost to Average Revenue . . . . . . . . . . . 69
4.5.5 Impact of Decomposition Selection Cost Parameters . . . . . 69

5 Conclusion and Future Work 72


5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

References 74

xii
Appendices 89

A Additional Results 90

xiii
Abstract

Network Function Virtualization (NFV) and Software Defined Net-


working (SDN) have attracted many Telecoms operators to deploy
them in the fifth Generation (5G) of mobile network infrastructure.
Network Function (NF) decompositions were proposed to map tradi-
tional NFs into their corresponding Virtual Network Functions (VNFs)
in order to deploy them flexibly in the NFV environment. This re-
implementation of large functions such as mobile core network func-
tion might lead to multiple paths service graph in the form of one
traditional function to many VNFs with (expected) high number of
virtual link interconnections. Therefore, it is expected that solving
NFV Resource Allocation (NFV-RA) problem for service chains that
contains multiple virtual paths will inherit the complexity of Virtual
Network Embedding (VNE) problem, which was proved to be NP-
hard. This study proposed a path mapping approach to solve the
NFV-RA problem for decomposed Network Service Chains (NSCs).
The problem was formulated as Integer Linear Programming (ILP).
Then, two schemes were suggested to solve the problem with path
mapping approach. One is an ILP-based scheme and the other is a
heuristic scheme. Both schemes were simulated with 22 experimental
scenarios. The results evaluation showed that the proposed approach
has significantly enhanced execution time and embedding cost.

xiv
Chapter 1

Introduction

This chapter is introducing the concepts of Network Function Virtualization


(NFV), Network Function (NF) decomposition, NFV Resource Allocation (NFV-
RA) problem, and the benchmark selection. Also, it considering use case and sig-
nificant of the study.

1.1 Virtualizing Telecom Network Services

Virtualization of telecom network services has attracted many of the telecom


operators and vendors [1]. Motivations of telecom industry toward virtualization of
network services are as follows: Virtualization would enable dynamic, flexible and
automatic network and service chaining configuration based on application layer
demand [2]. Utilizing Commercial-of-the-Shelf (COTS) hardware and new virtu-
alization technologies to deploy network functions for operators’ networks would
compensate the expected decline in Average Revenue Per User (ARPU) due to the
increasing demand for bandwidth and the number of connected machine-to-machine
(M2M) devices, sensors and actuators by the year 2020 [3].

Although the virtualization started with Virtual Machines technology, Software


Defined Networking paradigm has introduced many hypervisors [4]. Those hypervi-
sors aimed to abstract (virtualize) physical resources in three aspects, namely node,

1
link, and topology abstraction. Abstraction of physical node resource where the
hypervisor abstracts the physical resources of the physical node. Abstraction of
Physical Link Resources where the hypervisor abstracts the physical link resources,
such as bandwidth and attributes, such as, bit rate, delay, as well as the available
link queues and link buffers define the level of virtualization. Topology abstrac-
tion where virtual nodes and virtual links define the level of virtualization while
the hypervisor can abstract an end-to-end (E2E) network path traversing multiple
physical links as one end-to-end virtual link [4]. Whereas IT data centers and cloud
computing basically consider the abstraction of physical nodes and physical links,
Network function virtualization considers end-to-end chains of services, which are
considered in this study. In consequence, the concept of traditional Network Service
(NS) is going to be re-designed [5] in order to realize end-to-end network service
chaining.

For example, Figure (1.1) shows a distributed network function in three scenar-
ios; 4G slice, 5G slice, and 5G Internet of Things (5g-IoT) [6]. IoT is available with
4G mobile network [7] while in 5G it will have massive deployment. Virtual environ-
ment enables telecom operators to deploy totally separated network slices [8, 9] as
shown in Figure (1.1) where in 4G slice there is a direction that separated the Base
Band Unit (BBU) from the Evolved Node B (eNB). Then BBU pool implemented
on Edge cloud datacenter [10, 11].Another direction is previsioning 4G core network
functions in virtualized environment as in [12]. 5G slice is the implementation of 5G
mobile services for ordinary users is another trend of virtualizing telecom infrastruc-
ture and distribute network function to Mobile Edge Cloud [13, 14]. 5G-IoT was
proposed from service attributes point of view where the services that are sesitive
to latency proposed to be placed in MEC such as the Vehicle-to-Vehicle (V2V) or
Vehicle-to-Anything (V2X) [15]. 5G networks were studied for multi-tenants [12],
multi-domain [16], multi-services [17], and mobile services [18].

2
BSS/OSS

Core Cloud
5G Core 5G Core
4G Core
(CP) (CP)

NFV/SDN Management and Orchestration


Symbols meaning:

5G-IoT Slice
Cloud/Datacenter

5G Slice
4G Slice

NFV/SDN Orchestrator
Datacenter Networking Switch
Gateway and Routing
Access Node

Edge Cloud
App.
V2X SRV
IoT SRV
Control/Signaling DU
(BBU) 5G Core DU (IoT)
User Data (UP)
5G Core
Configuration and Monitoring (UP)

VNF

Network
Access

UE UE IOT Device

Figure 1.1: Top level design of virtualized Telecom 4G, 5G, and 5G-IoT networks

1.2 ETSI NFV Architectural Framework

Network function virtualization (NFV) and Software Defined Networking (SDN)


are proposed by academic and industry researchers to be the architecture of the next
generation (fifth generation 5G) of mobile networks[19] for several economic reasons
[20]. Of these, reducing the Capital Expense (CAPEX) through decoupling software
form hardware and using commercial of the shelf supper volume servers [21, 22]. Due
to that decoupling, the implementation of mobile network functions as a Virtualized
Network Functions (VNFs) makes it possible to flexibly deploy them in central or
distributed servers in which potentially saves operational expense [23, 24]. In addi-
tion, virtualized environment provides flexible management and agile development
of new services with faster time-to-market [22–24].

The idea of NFV is to convert network functions to a programmable software


form as a Virtual Network Functions (VNFs) or Virtual Network Function Com-
ponents (VNFCs) that work in Virtual Machine (VM) or Virtual containers on the
top of NFV Infrastructure (NFVI). VNFs can be a stand alone service or a part of
service that is connected with other VNFs or with both VNFs and Physical Net-
work Functions (PNFs) to realize a Network Service (NS). Network Service is an

3
emerging concept that refers to a chain of VNFs that are connected in specific se-
quence to provide one or more services, which is usually called Service Function
Chains (SFCs) [25]. SFC also known as Service Chain (SC) and/or Network Service
(NS) are placed and managed through Virtual Network Function (VNF) lifecycle
management by NFV Management and Orchestration (MANO) framework.

Resource management on NFV is one of the challenging problems that requires


further research before the mobile network functions can be deployed on NFV for
commercial use [24]. The European Telecommunication Standards Institute (ETSI)
has been selected to be the home of Industry Specification Group for NFV (ETSI
NFV ISG) [24, 26]. The ETSI developed a standard architectural platform for the
NFV, which is named NFV management and orchestration (NFV-MANO) [27]. It
is designed to support heterogeneous environment that runs software functions from
multi-providers on multi-vendors’ hardware infrastructure, where the management
of VNFs and the orchestration between services and physical infrastructure are
occurred via standard interfaces [28]. The ETSI NFV ISG reliability and availability
team has reported that the placement algorithms are essential part of the resiliency
[29], and reliability [30] of the VNF lifecycle operations and fault management.

The ETSI NFV-MANO framework [27], as shown in Figure (1.2) is introduced


as a Telecom-Grade reference that provides the provisioning of VNFs, and the re-
lated functions, operations and interfaces. The functional blocks of the MANO
framework can be grouped into three main entities: NFV management and orches-
tration (MANO), NFV Infrastructure (NFVI), and network management systems.
For enabling the interoperability and flexibility of deployment from multiple vendors
of hardware and multiple software providers, those functional blocks are connected
through a set of reference points [31].

NFV Management and Orchestration

4
Figure 1.2: ETSI Reference NFV Architectural Framework (depicted from [28])

1.2.1 NFV Management and Orchestration

ETSI NFV MANO consists of three main functional blocks and four data repos-
itories. The MANO blocks are: NFV Orchestrator (NFVO), VNF Manager (VNFM)
and Virtualized Infrastructure Manager (VIM) and the data repositories are: NS
Catalog, VNF Catalog, NFV Instances and NFVI Resources.

NFV Orchestrator (NFVO)

The NFVO aims to combined NFs to realize End-to-End service chains. Func-
tionally, The NFVO orchestrates resources through Resource Orchestrator (RO)
and services through Service Orchestrator (SO). Resource Orchestrator manages
the NFV Infrastructure (NFVI) resources across multiple VIMs. Service Orchestra-
tor (SO) manages the lifecycle of VNFs and guest network services. SO also provides
policy management and evaluation for the network service and VNF instances (e.g.
policies related with affinity/anti-affinity placement, scaling, fault and performance,
regulatory rules, NS topology, etc.).

5
VNF Manager (VNFM)

The VNFM manages VNF lifecycle operations,such as lifecycle management,


virtualized resource capacity management, lifecycle change notifications, and other
operations [32]. Each VNF instance is assumed to have a VNFM, which may be
assigned to manage single or multiple VNF instances from single or multiple types in
the same domain. VNFM manages Network Services (NSs) deployment templates
and VNF Packages (e.g. on-boarding new NSs and VNF Packages). During the
on-boarding of NS and VNF, a validation step is required to verify the integrity and
authenticity of the provided deployment template, and that all mandatory informa-
tion is present and consistent. Then the software images (VNF Package) that are
provided by the tenant are cataloged in one or more NFVI-PoPs using the support
of VIM and Service Orchestrator (SO) [33]. After the initiation of the NSs, the
VNFM becomes responsible for the lifecycle management operations.

Mobile operators who aim to migrate some of their services to the NFV environ-
ment, intends to gradually transit from network infrastructures based on physical
nodes to the NFV. Also, operators may need to integrate the NFV with their cur-
rent existing Operation System Support (OSS), and Business System Support (BSS).
The NFV-MANO provides reference interfaces to connect with operators OSS/BSS,
which can provide management system for both the physical NSs and virtual NSs.
The VNFM controls the VNF through Element Management System (EMS). The
EMS is responsible for FCAPS management functionality for a VNF. FCAPS is a
short name for Fault Management, Configuration Management, Accounting Man-
agement, Performance Management, and Security Management functionality for a
VNF.

Virtualized Infrastructure Manager (VIM)

The VIM manages and controls NFVI physical and virtual resources in a single
domain. An NFV architecture may contain more than one VIM, which can manage
and control NFVI from multiple vendors and multiple purposes, such as compute,
storage, compute only or storage only. The VIM orchestrates, with the RO, the allo-

6
cation, upgrade, release, reclamation of NFVI resources including the optimization
of resources usage. It manages the association of virtualized resources to the physical
compute, storage and networking resources. For resiliency purposes, VIM manages,
with support of VNFM, the virtualized resource capacity, fault management cycle,
VNF Forwarding Graph (VNFs and virtual and/or physical network links), VNF
images and performance information collection. It is important to mention that the
VIM implementation is out of scope for NFV-MANO [27]. OpenStack controller
and openVIM are examples of the VIMs that can be used in the NFV-MANO.

Data Repositories

Data repositories are shown in Figure (1.2) in the block named ”Service, VNF
and Infrastructure Description”. Data repositories are databases that keep informa-
tion about NFV-MANO catalogs, which there are four of them:

1. The NS catalog is a set of pre-defined templates, which define how services


may be created and deployed, as well as the functions needed for the service
and their connectivity.

2. The VNF catalog is a set of templates which describe the deployment and
operational characteristics of available VNFs.

3. The NFVI resources repository holds information about available/allocated


NFVI resources. This repository is the dedicated one to implement part of the
solution in this study. That part is the physical paths catalog.

4. The NFV instances repository holds information about all function and service
instances throughout their lifetime.

1.2.2 Network Function Virtualization Infrastructure (NFVI)

NFVI is a combination of hardware and software resources, which build up


a virtual environment, such as cloud or data centers. The smallest size of this

7
Figure 1.3: NFVI node components (depicted from [34])

virtualization environment is called NFVI node. NFVI node consists of the hardware
servers, the virtualized layer of compute, storage, and virtualized network resources
[34]. Each NFVI node has input gateway and output gateway. NFVI node is
illustrated in Figure (1.3).

An example of NFVI operating system is the OpenStack 1 , which is an open


source Infrastructure as a Service (IaaS) platform. OpenStack is used in Telecom
Core Network infrastructure [35]. In the context of ETSI NFV, OpenStack consists
of the VIM and NFVI blocks of the MANO framework. The controller node of
the OpenStack presents the VIM and it consists of many services that orchestrates,
control and manages the lifecycle operations of the NFVs and allocates the required
resources for its process and network connection. The NFVI can be divided in pools
(or zones) of computing nodes (nova), block storage nodes (cinder), object storage
nodes (swift) and networking control and management node (neutron).

In addition, OpenStack consists of many projects and sub-project. Those


projects are logically connected to work together through API interfaces. Open-
Stack is considered as the NFV promising infrastructure platform [36] and there are
various new projects, which have been developed to accelerate and realize the NFV
MANO, such as Tacker and Congress projects.
1
OpenStack project: https://www.openstack.org

8
1.3 Network Function Decomposition

However, the migration from traditional mobile network functions to the NFV
requires re-implementing those functions to be deployable on the NFV environment.
That re-implementation is important for the management and orchestration automa-
tion during the VNF lifecycle operations, such as instantiation, scaling, migration,
updating, recovery from failure state and termination. From the perspective of SDN
network, the network functions are re-implemented by separating the control plane
from the user plane [37]. In industry, the 3rd generation partnership project (3GPP)
has introduced the same concept of separating the control plane from user plane of
evolved packet core (EPC) functions [38]. A reference architecture for mobile core
on NFV/SDN is introduced in [17], which allocates the control plane in the central
and user plane to the edge of NFV virtual infrastructure managers.

From the academic point of view, the network function decomposition concept
is used to describe the network function re-implementation in order to deploy them
on NFV flexibly. Function decompositions is defined in [39] as an approach to sep-
arate out the tightly coupled network sub-functions within a network entity. This
definition implies that; the network decompositions can be separated in a manner
that fulfills the economic objectives. The motivation of network function decom-
position is to introduce independent scalability of NF decompositions, controlling
the traffic on the network links by placing NFs in central or in mobile edge net-
works near to the user equipment, and enhancing function separation using network
slices. Whereas, the NF decomposition is important for the VNF resilience, reliable
operation, and flexible management of NFV resources. Nevertheless, it is likely to
produce additional virtual links in the VNF forwarding graphs (VNF-FG).

Figure (1.4) shows an example of service decomposition as introduced for NFV.


One network function might re-implemented in two network functions, such as NF2,
which is re-implemented in NF4 and NF5. Another example is when a network
function can be re-implemented in more than one virtualization technique types,
such as NF2, which can be implemented in two virtualization technique types where
NF4 can be a virtual machine and NF5 can be in virtual container as in the third

9
Service Graph (SG)
in NF2 out

in NF1 out in NF3 out

NF2

in NF4 out in NF5 out

NF4 NF5

in NF6 out in NF7 out

NF4

in NF8 out in NF9 out

Figure 1.4: An example of service decomposition (depicted from [40])

line of the figure with NF6 and NF7. For diversity, a network function can be re-
implemented in N-version of virtualization types as illustrated with NF4, which can
be re-implemented in NF6, which is the first version or NF8 and NF9, which both
represent the second version.

The VNF-FG is known also as Service Function Chaining (SFC), which is the
terminology of the Internet Engineering Task Force (IETF) [41]. However, in this
study, the term Service Graph (SG) is used to refer to the service requests in which
those requests are compliant to the SFC definition and the ETSI carrier grade re-
quirements. The SG is a connected NFs in an end-to-end directed acyclic graph,
where the NFs in each path have specific order to work together to provide a service.
For mobile services, the network functions might serve millions of users and requires
large process capacity; however, the service decomposition may result in a multiple
paths of SG, which will increase the management and orchestration of the service
on NFV.

For example, Figure (1.5) shows that the network function NF0 can be decom-
posed in three forms of service graphs. Figure (1.5)-(a) shows a service graph that
starts at one sub-function and ends at other one, and all the sub-functional nodes
have one input edge and one output edge. Figure (1.5)-(b) shows a service graph

10
NF0

NF1 NF2 NF1 NF3

NF1 NF2

NF3 NF2 NF4

(a) Simple path SG (b) Forking path SG (c) Multiple paths SG

Figure 1.5: Network function decomposition might result in (a) simple path service
graph; (b) forking path service graph; (c) multiple paths service graph

that starts at one sub-functional node and ends at more than one sub-functional
nodes. That means some nodes have more than one output edges. The graph in
Figure (1.5)-(c) shows the multiple paths service graph, which starts at more than
one sub-functional nodes and ends at more than one sub-functional nodes. In multi-
ple paths SGs, nodes in the middle might have more than one input edges and more
than one output edges. This manner of connection is not violating the ordering
characteristic of the SFC, that is because the order can be linear or non-linear [41].

According to [42], the complexity of a Virtual Network Embedding (VNE)


problem is a strong NP-hard even with special cases obtained by fixing one of the
dimensions of the placement problem to one. As a result, the placement of mobile
services in the form of decomposed SGs will be strong NP-hard too, this is because
the SFC placement problem has more dimensions than the VNE, such as the ordering
and the chain form of the service graph. Furthermore, the multiple paths SGs might
be mapped with additional embedding cost because it possible that virtual links are
embedded to longer physical links. That in consequent would increase the execution
time too.

11
1.4 The Use Case of the Study

One of the use cases of service function chaining is traffic engineering which is
usually applicable on mobile core network functions [43]. In addition, the mobile core
network function is one of the use cases of the ETSI NFV architecture [44]. These
two use cases are valid use cases in current literature for academic and industry
researches.

1.5 Problem Statement

The problem of embedding multiple paths SGs has two aspects. The first aspect
is mapping the service with longer paths than required, which it was proved in [45].
The second aspect is the complexity of the placement problem, which it was proved
to be a NP-hard problem, where the execution time increases as the dimensions of
the service graph or the physical network increase. The proposed solutions in [46]
and [47] used the back-track mechanism. The back-track mechanism could find a
solution by trying all candidate nodes while it consumes much time before it gives
negative response. It is possible that the back-track mechanism finds solutions that
maps virtual links to long physical paths which increases the embedding cost and
consumes resources.

This study assumes that mapping service requests on physical network based
on the path identification of both (service and physical) would potentially enhance
the execution time and the embedding cost. whereas the current literature shows
that the increase of physical nodes results in a significant increasing in execution
time and embedding cost, this study focus on the impact of increasing physical links
for multiple paths service requests on execution time and embedding cost.

12
1.6 Research Objective

The goal of this study is to solve the NFV-RA problem with service decomposi-
tion support for simple/forking and multiple paths SGs on small and large physical
networks. In order to achieve the goal, the study introduced a path identification
method, which was used to minimize the input size to the placement algorithm to
reduce execution time and minimize the embedding cost, too.

1.7 The Significance of the Study

For Telecom operators, development of rapid and efficient placement algorithms


is essential to the accelerate NFV [48]. Whereas, the reliability of mobile core
network services requires very short time to recover the virtual services in case of
any failure [49]. Therefore, the execution time of the placement algorithm is very
important to fulfill the required reliability and availability of mobile core services
on NFV. In consequence, this study is important for accelerating the deployment of
NFV on mobile core infrastructure as planned and recommended by ETSI NFV.

1.8 Research Methodology

This study was evaluated experimentally using simulation method. Quantita-


tive data has been measured in terms of execution time, acceptance ratio of service
request, average embedding cost, and average embedding cost to average revenue of
mapped service request. The NFV-RA problem was formulated in Integer Linear
Programming (ILP) and implemented in two schemes. Both schemes were simulated
2 3
in python language using some python packages such as NetworkX to model the
network in graph and PuLP modeler to model the problem in ILP. Also, SimPy
4
package was used to originate the simulation environment. Proposed ILP-based
2
https://www.python.org/
3
https://pypi.python.org/pypi/networkx
4
https://pypi.python.org/pypi/simpy

13
5
scheme was solved in COIN-OR CBC solver.

1.9 Scope of the Study

The scope of the study is to optimize the NFV-RA problem for multiple paths
service chains, which can be result from network function decomposition of mobile
core network function. The study considered mobile (telecom) operator network
with ETSI NFV Infrastructure (NFVI) architecture.

1.10 Benchmark Selection

For the best of our knowledge, the embedding of multiple paths service graphs
with joint of path mapping is not studied in the current literature. In addition,
resiliency of virtualized network function can be enhanced by using network function
decomposition to re-implement mobile core network functions. This study aimed to
develop an efficient placement approach that can be used to map mobile core network
functions on NFVI. The NFV-RA problem was solved for mobile operator network
scenario with the following attributes:

• Multiple paths service graph,

• Supporting multiple virtualization technique types to enhance the resiliency


by reducing single point of failures,

• Supporting variety of re-implementations for mobile core services by using


several network function decompositions.

Then, the closely related work to this study was the work in [46], which solved
the NFV-RA problem with network function decomposition support. It also used
the virtualization technique types. Therefore, that work has been selected to be the
benchmark of this study.
5
https://projects.coin-or.org/Cbc.

14
1.11 Contributions

This thesis proposes the path mapping approach, which considers to map end-
to-end paths of service chains request instead of mapping node by node which pro-
posed in the literature. Physical and service chain networks are modeled with path
identifications, which used virtualization technique types to identify virtual nodes
in end-to-end paths. The main contribution is formulating NFV-RA problem with
network function decomposition support in ILP-based scheme (exact scheme). ILP
formulation identifies simple physical paths for each virtual links. In order to in-
vestigate the possibility of mapping the whole virtual path to exact match physical
path, we proposed a heuristic scheme, which is named Decomposition Path Selection
Mapping (DcPSM).

The results of the proposed approach using both the exact and the heuristic
schemes proved that the proposed path mapping approach is efficient in minimizing
execution time and embedding cost in large physical network with multiple paths
service graph.

1.12 Thesis Organization

It is important to mention that the terms ”placement”, ”mapping”, and ”em-


bedding” are used, in this study, to describe the process of finding available resources
with valid attributes in physical nodes and links and then allocate those physical
resources to virtual network services to be deployed on them. Those terminolo-
gies are used in the context of NFV resource allocation with Telecom-Grade policy
constraints.

The rest of this thesis is organized as follows. The litrature review and related
work is discussed in chapter 2. The proposed approach including path identifi-
cation, exact scheme and heuristic scheme are discribed in chapter 3. Simulation
environment, performance metrics, simulation expriments, and results discussion are
described in chapter 4. Finally, conclusion and future work are in chapter 5.

15
Chapter 2

Literature Review and Related


Work

2.1 Network Function Placement in Literature

Despite the success sounding the NFV, Mijumbi, et. al [31] reported three
aspects of NFV resource management problem including, NFV points-of-presence,
function placement, and dynamic resources management. By examining the liter-
ature, the placement problem is divided into three main problems, namely, virtual
network embedding [50–54] Virtual Network Function Placement (VNF-P) [55–58],
and Service Function Chaining Placement Problem (SFC-PP) [45, 47, 59–65].

2.1.1 Virtual Network Embedding

The VNE considers the embedding of virtual network in the physical substrate
and focuses on resource allocation for virtual nodes and virtual links [66]. Most of
the proposed approaches that attempted to improve VNE is surveyed and discussed
in [54, 67].

16
2.1.2 Virtual Network Function Placement

Moens et al. [68] decoupled the VNE problem into VNF chaining and VM
embedding problems. VM embedding considers the placement of VNFs on their
corresponding virtual machines (VMs), while the VNF chaining can be a mapping,
an assignment or scheduling of NFs in their corresponding VNFs and links that
connecting them in network substrate. The VNF chaining is known as Service
Chaining and formally as Service Function Chaining (SFC). Nonetheless, the focus
of VNF-P is to know where to deploy virtual machine placement [54, 69] and how
to schedule the required VNFs [58, 70, 71].

2.1.3 NFV Resource Allocation

In NFV, the placement was studied as NFV Resource Allocation (NFV-RA)


problem. It usually aims to embed service chains, which also including virtualized
network functions and their interconnections. NFV-RA focused on resource allo-
cation of end-to-end chains of network functions. It is worth to point out that,
NFV-RA is also known as Service Function Chaining placement problem (SFC-PP)
[72], [73]. As observed from the literature, to address the issues related to SFC-PP,
three main stages should be taking into account, namely VNFs Chain Composi-
tion (VNFs-CC) [74], VNF Forwarding Graph Embedding (VNF-FGE), and VNFs
Scheduling (VNFs-SCH) [72].

The work in [75] reviews the Service Function Chaining Resource Allocation
(SFC-RA) problem. They classified the placement work in literature into six ap-
proaches as follows:

1. Basic approach, that decomposes the placement problem into three steps,
which are placement of VNFs, assigning VNFs to service requests, and chain-
ing the VNFs;

2. Dynamic approaches, which consider how to allocate resource at run time due
to changes in service requests;

17
3. Online approaches, which is the same as dynamic approaches but utilizing
online algorithms;

4. Multiple providers approaches, which consider the placement of SFCs in mul-


tiple infrastructure providers;

5. Scheduling approaches, which schedule the traffic to pre-mapped VNFs;

6. Mobile network approaches, which consider the mobile network functions place-
ment.

The work in this study is classified under the mobile network approach with consid-
ering online and dynamic uses of the proposed solution during design.

2.1.4 VNF Placement and Routing (VNF-PR)

VNF-PR has been solved in literature with multi objective goal as in [76, 77].
Solving placement problem as VNF-PR is much similar to NFV-P but it consider
additional objectives related to service provider requirements.

In [76], a joint problem of admission control and SFC has been formulated in
Mixed Integer Linear Programming (MILP) for service provider. That formulation
encompasses splittable VNF and multipath routing scenarios. It employ relaxation,
reformulation, and successive convex approximation (SCA) methods to solve the
problem. The work in [76] considered the forking service graph with split data flow
and with routing. In [77], the VNF-PR was formulated as MILP with two objectives
the first is to minimize link utilization which is Traffic Engineering (TE) objective.
The second is minimize CPU utilization in NFVI.

2.2 Placement Scenarios

Researchers have attempted to address the placement problem by adapting


several scenarios. Some of those scenarios are namely: cloud [52, 53, 65], data

18
centers [51, 61], operator networks [45, 55–57, 71, 78], wireless network [58], service
provider networks [50, 60], and NFV network [59]. For operator networks, the service
chaining might involve legacy middle boxes functions and virtual network functions,
this scenario is known as hybrid network [62].

In NFV, the placement problem usually has further constraints. Of these con-
strains are, the policy-based constraints which are required to meet Carrier-Grade
requirements, such as affinity and anti-affinity constraints [79], migration policy [63],
network management during run time [64], [80], and other regulatory or Quality of
Service (QoS) constraints. Although, the description of the policy constraints has
been described based on VNF Forwarding Graph (VNF-FG) [27]. Another scenario
for describing the service request structure for SDN/NFV network is introduced in
[81].

2.3 Proposed Strategies to Solve the Placement


Problems

The VNF placement problem is an optimization problem, hence it has been


formulated in various ways following the required objectives of the optimization.
From NFV provider’s point of view, network services placement can be optimized
based on the required objectives, such as minimizing placement cost by avoiding
more resources than the NS’s need, and/or maximizing the provider’s revenue by
maximizing the service request acceptance rate. In the other hand, the NFV ten-
ants, who have different objectives, such as service continuity for critical services
(like voice call), or minimizing revenue lost by minimizing service outages. Accord-
ing to [82] there are four algorithm based approached for network service placement
and mapping, they are: Integer Linear Programming (ILP), Reinforcement Learn-
ing (RL), Multi-stage Network Service Embedding and VNF Scheduling over an
NFVI. Also, there are other proposed approaches in literature, such as an evolvable
approach [83] and Binary Linear Programming (BLP).

19
2.3.1 Integer Linear Programming

Integer Linear Programming (ILP) based approaches aim to optimize the map-
ping of NS to NFVI PoPs (Point-of-presence) and having as objective the mini-
mization of mapping costs and service delay in respect of infrastructure and services
constraints. ILP approach takes decisions based on the current state of the network
(as provided by the network monitoring) and on the NS requirements and specifica-
tions (as gathered from the NS catalogue in NFV repository). ILP approach related
work as in [62, 84–86].

2.3.2 Reinforcement Learning

Reinforcement Learning Based Approach is based on the reinforcement learning


theory. It aims at exploring the possibility of improving mapping decisions based on
iterative learning of the environment dynamics (VNF types, arrival and termination
rates, resources capacity, etc.). As in [87] and [82], this approach uses learning
algorithms in each substrate node and substrate link, providing self-organization
capabilities. A possible scenario can be, for example, by using multi-agent learning
algorithm which collects evaluation feedback from its agents to learn an optimal
policy that can be used to manage the resource allocation for the virtualized nodes
and connecting links.

2.3.3 Multi-Stage Network Service Embedding

Multi-stage Network Service Embedding approach has two levels of mapping.


The first is an ILP based approach, which maps the VNFs and links, and it aimed at
balancing the load across the network. The second level approach based on Mixed
Integer Programming (MIP), where the objective is to maximize the NS co-location,
while minimizing the traffic within the DC. Specific control functions are executed
during certain period of time to control the traffic flow and work together with
traffic-handling functions. The virtual path computation element and the multi-
domain virtual forwarding functions are examples of those control functions [82]. In

20
addition, game theory was used as in [88] while two stage heuristic was proposed by
[89].

The work in [88] focused on the third use case of NFV [44], which is end-to-end
services supported by network service providers which involve cross-administrative-
boundary operation, inter-working, and migration to/from physical NF implementa-
tions. They proposed an integrated design for network function instance allocation
and end-to-end demand realization sharing the same physical substrate network
and demonstrate that the corresponding network design problem is NP complete.
A Mixed Integer Programming (MIP) formulation is proposed to find its optimal
solution, followed by a two-player pure-strategy game model which captures the
competition on physical resources between network function instance allocation and
routing. Then they design an algorithm based on iterative weakly dominated elim-
ination in Game Theory. Computational results demonstrate experimentally the
value of the integrated approach and its ability to allocate network function in-
stances supporting end-to-end requests with limited physical resources in optical
networks.

2.3.4 VNF Scheduling

VNF scheduling over previously mapped VNFs on their virtual machine in


physical NFVI. In scheduling the VNF-FG is already solved and embedded on NFVI,
then workloads are scheduled to those VNF-FG. Scheduling of workloads and tasks
is used in order to minimize the total execution time of the service without degrading
the service performance and respecting all the precedences and dependencies among
the functions composing the service. Authors of [90] proposed a dynamic resource
allocation and scheduling algorithm for cloud-based virtual content delivery network
(CDN), which aim to maximize the QoS while minimize the resource allocation cost.
For NFV environment, authors of [71] formulate the online virtual function mapping
and scheduling problem and propose TABU search-based heuristic algorithm and
evaluate it by simulation and comparing its results with three greedy algorithms, in
terms of total service processing times, revenue, and cost.

21
2.3.5 Evolvable Approach

This approach aimed to reduce the cost for dynamic placement, such as re-
configurations of virtual machines (VMs) after changes of processing requests for
VNF by tenant management system. The author of [83] proposed Modularly Vary-
ing Goals (MVG), which was based on genetic algorithms (GAs) and two evolvable
VNF placement methods named Evolvable VNF Placement (EvoVNFP) and Evolv-
able VNF Placement-2 (EvoVNFP-2). Those placement algorithms used the GA to
reduce the number of reconfiguration after the changes of processing requests from
tenant while minimizing delay on traffic routing.

2.3.6 Placement on Top of Linux Containers

ETSI NFV framework suggested to implement VNFs in virtual machine (VM)


based containers because of the stable use, easy isolation, and being mature tech-
nologies. Other virtualization techniques such as Linux containers are suggested
too. Container-based placement is the placement of VNFs on top of container-
based virtualization layer. Container-based virtualization (aka; Operating System
Virtualization) is an approach to virtualization in which a lightweight virtualization
layer runs as an applications on top a shared operating system (OS) of the host. In
this approach, the operating system’s kernel runs on the hardware node with sev-
eral isolated guest applications installed on top of it or on top of its virtualization
layer, such as Docker. Guest applications are isolated using containers. The OS’s
kernel layer in container-based virtualization replaces the Hypervisor layer. Linux
Containers 1 is an operating system-level virtualization method for running multiple
isolated Linux systems (containers) on a single control host (LXC host). The guest
of LXC can be a (linux) virtual machine or an application. VM guest containers can
be deployed by LXD container system, while deploying applications in containers
2
can be done using Docker

In [91], Authors suggest a container-based deployment of OpenEPC in NFV


1
https://linuxcontainers.org/
2
For more information visit: http://www.docker.com

22
environment. They have experimentally tested their suggestion and compared the
resource consumption to the VM deployment over hypervisor. They claim that
using container-based NFs is significantly improves the performance in terms of
lower memory usage and lower computational resources overhead to improve load
balancing, redundancy and NF availability. We may consider the work in [91] as
Proof-of-Concept (PoC) put it is out of the scope of this study because the placement
and configuration have been done manually. In this study we consider placement of
a NF on container based virtualization as defined in section 3.4.

2.4 Complexity of Placement Problem

According to the work reported in [42], VNE is classified as NP-hard problem.


Similarly, VNF-P is a NP-hard problem [55] and SFC-PP is also a NP-hard problem
[72]. As a result, some mathematical methods are proposed to find the optimal
solution for VNE, VNF-P and SFC-PP. These proposed methods are under the
exact approach which are usually formulated as Linear Programming (LP). The
heuristic approach is proposed to solve the scalability problem of the ILP-based
algorithms in large physical network scenarios, where solving placement problems
in large networks consume much execution time. ILP solutions are formulated in
[46, 47, 51, 55, 56, 92] while Mixed ILP (MILP) is formulated in [52, 57, 70, 76].

Another mathematical solution is the eigendecomposition-based method that


is proposed in [65], which is a matrix based method. The exact solutions are often
proposed with heuristic ones to compare the performance of the heuristic to the
optimal. For example, authors of [55] focus on optimizing the operational cost and
resource utilization without violating service level agreements. They proposed an
ILP and a dynamic programming-based heuristic to solve the VNF orchestration
problem. The work in [55] claimed that, the cost of the heuristic solution can be
within 1.3 times the optimal one and the execution time is 65 to 3500 faster than
the optimal.

23
2.5 Placement with Service Decomposition Sup-
port

From another perspective, service decomposition is suggested to optimize mo-


bile core network functions for the next generation mobile networks that based on
NFV architecture [38], [39]. The work in [62] introduced a customizable network
function chains solution which builds up the service chain at run-time using variabil-
ity of selectable sub-function decompositions. In contrast, the placement of evolved
packet core sub-functions is used to enhance user mobility, while minimizing path
between users and their respective data anchor gateways [93].

The primary-backup pair searching algorithm is introduced in [45] with a mo-


tivation of realizing 1+1 (primary + backup) protection scheme for service chains.
It worth to mention that mapping service chains with protection scheme is resulting
on multiple paths service graph. In addition, Khan et. al [45] reported that, their
solution result on mapping longer backup path for 1+1 protection scheme. Hmaity
et. al [92] concluded that, the protection of one single node and one single link
requires 107% NFV nodes which is more than the unprotected scenario.

Service decomposition re-implements the service by mapping NFs in the service


to VNFs. Four mapping methods are introduced by [94], namely 1 : 1 mapping,
1 : N mapping, N : 1 mapping, and N : 2 mapping. We argue that decomposition
with 1 : N mapping is more likely to meet the carrier grade requirements, such as
scalability, high availability. 1 : N mapping maps a traditional mobile core network
function to N virtual nodes (VNFs).

Regardless of whether the service decomposition is separating sub-functions to


features and smaller functions or separating sub-functions to their control and user
planes, the resulting service graph would highly be a multiple paths service graph.
Figure (2.1) shows two types of decompositions; the first for NF3, which decomposed
into a pool of sub-functions. The second is for NF2, which is decomposed into
its control and user plane sub-functions. For mobile core network functions, both
decompositions are likely to happen. and it is important to study the placement

24
Service Graph (SG) of a Network Service (NS)

in NF2 out

in NF1 out in NF3 out in NF4 out

NF3 is large and can be break down to smaller functions

Decompositions of NF3

in NF6 out in NF8 out

in NF5 out

in NF7 out in NF9 out

Also, NF can be decomposed to its control plane (CP) and user plan (UP)
NF2 CP/UP Decompositions

in NF2 out
Control Plane (CP)

in User Plane (UP)

in NF2 out

Figure 2.1: Service decomposition types.

of multiple paths service graphs to develop efficient placement algorithms to map


those resulting service graphs after decomposition in objective cost and reasonable
execution time.

2.6 Efficiency Measures

The work in [61] aimed to minimize cost of solving the VNF-P on NFV. It
considered one measure of the efficiency, which is the reducing the cost by 19% of
the previous work. Reducing scheduling time span was considered as and efficiency
metric in [70] and [57]. Efficient use of resources were considered in [80]. In con-
sequence, we considered the enhancement in execution time and embedding cost
as the metric of the efficiency of this study. The acceptance ratio is going to be
a metric for the efficiency of the exact scheme, while the embedding cost trade off
with acceptance ratio in heuristic.

25
Table 2.1: Comparison of related works for VNE and VNF-P
Related Strategy Scenario Contribution
work

Virtual Network Embedding (VNE)

[52] Exact Cloud Introduced a Green Virtual Network Embed-


ding (GVNE) framework to minimize energy
consumption.
[51] Heuristic Data cen- Proposed Markov Chain-based Algorithm for
ter VNE (MCA-VNE) to minimize request rejec-
tion and maximize revenues.
[53] Heuristic Cloud Proposed SR-VNE algorithm to maximize
revenue and acceptance in long term.
[50] Heuristic Service Proposed MaVEn-M and MaVEn-S algo-
provider rithms using the multicommodity flow and
network Markov decision processes to maximize rev-
enue.
[78] heuristic Cloud proposed Adaptive-VNE algorithm to maxi-
mize revenue, acceptance, and end-user sat-
isfaction.

Virtual Network Function Placement (VNF-P)

[71] Heuristic, Operator Proposed three greedy and a tabu search-


Meta- network based algorithms for VNF embedding and
heuristic process scheduling to maximize revenue.
[57][70] Exact, Operator Formulated VNFs chaining scheduling as
Meta- network problem as a series of scheduling decisions
heuristic for services to minimize scheduling latency.
[58] Exact, Mobile Proposed a proof of concept that NFV man-
Heuristic network agement can be extended to the radio seg-
ment of mobile network.
[55] Exact, Operator Proposed an ILP formulation for VNF or-
Heuristic network chestration problem and a dynamic program-
ming heuristic to minimize the operational
cost and physical resource fragmentation.
[93] Heuristic Operator Proposed a placement algorithms with two
cloud objectives and used bargaining Nash theory
to find a fair tradeoff between them to min-
imize end-to-end path and user’s mobility.

26
Table 2.2: Comparison of NFV-RA related work
Related Strategy Scenario Contribution
work

Service Function Chaining Placement Problem (SFC-PP)

[20] Description- Telecom Proposed a descriptive data model that present con-
based operator current users of generic services on multiple layered
architecture.
[45] Heuristic Operator Proposed a primary backup redundant scheme map-
network ping to maximize the service continuity.
[46] Exact, Service Proposed NF decomposition selection based on VNF
Heuristic provider clustering using virtualization technique type to min-
network imize mapping cost.
[47] Exact, Operator Proposed a SFC placement with function scalability
Heuristic network to realize the dynamic operations on NFV.
[63] Heuristic Operator Proposed a consolidation algorithm based on migra-
network tion policy to reduce the cost of QoS degradation dur-
ing VNF migration.
[64] Heuristic NFV net- Presented an automatic policy-based approach to
work solve service chain composition on NFV ot reduce op-
erational cost.
[80] Heuristic Service Proposed SDN-based NFV orchestration to imple-
provider ment policy
[81] Heuristic Service Presented a YANG model to describe the service
provider structure and solve the first stage by selecting a Par-
ito set of possible compositions.
[86] Exact, Operator Proposed a NF Consolidation on NFV to minimize
Heuristic network resource occupation by reducing the number of VNF.
[88] Exact, Optical Proposed placement algorithm based on game theory
Heuristic network to minimize mapping cost.
[61] Heuristic Data cen- Optimized VNF placement and service chaining using
ter a Markov approximation with many-to-one matching
theory in coordinated approach to minimize the cost.
[73] Exact, NFVI Proposed a coordinated approach to jointly optimize
Heuristic NFV-RA in the three stages of the problem.
[62] Exact Hybrid Proposed a customizable SFC composition to mini-
network mize the mapping and the management cost.
[60] Exact, Service Proposed a survivability for SFC with multi-path link
Heuristic provider mapping in order to maximize survivability and min-
network imize resource redundancy
[65] Heuristic Cloud Proposed an eigendecomposition based approach to
maximize revenues.
[59] Heuristic NFV net- Proposed a coordinated placement algorithm that
work solves service chain composition and embedding with
reasonable execution time in large-scale physical net-
works.
[76] Exact, Service Considered the joint problem of admission control and
Heuristic provider SFC to enhance resource allocation.
[89] Exact, cloud dat- Considered solving the placement problem for SFC to
Heuristic acenter minimize resource allocation during VNF instantia-
tion and with time-varying workloads.
[77] Exact Service Solved the VNF-PR problem as a multiple objectives
provider then showed a trade-off between classical Traffic En-
gineering (TE) and NFVI efficiency.
[95] Heuristic Service propose a distributed search method for ordered
provider VNFs to suppress delays while considering the control
server load, with an in-network guidance technology
for query messages
[96] Heuristic Datacenter Proposed a joint problem of the VNF placement and
path selection to minimize server and link utilization.
[74] Metaheuristic Service Solved the VNF-FG composition stage to minimize
provider bandwidth demand.
[97] Heuristic Service Proposed a fix-and-optimize-based heuristic algo-
and Meta- provider rithm and Variable Neighborhood Search (VNS) to
heuristic minimize resource allocation.
[98] Exact, Service Solved VNF-PR considering to improve disaster re-
Heuristic provider covery with minimizing cost.
[99] Exact, Service Consider dynamic reconfiguration with carrier grade
Heuristic provider constraints.
[100] Exact Multiple Solved VNF-PR problem to minimize resource utiliza-
tion.

27
Chapter 3

The Proposed Approach

This chapter models the physical network and service request with path identi-
fication. Then, it formulates the problem of network service resource allocation with
support of network service decomposition. Next, the NVF-RA problem is solved us-
ing path mapping with two schemes, the exact is ILP-based scheme and the heuristic
scheme Decomposition Path Selection Mapping (DcPSM). Figure (3.1) is a simple
example of mapping virtual service requests with 4 VNFs on physical network that
consists of 7 physical nodes with different virtualization types. Next sections explain
the terminology and notations that are used to model the physical network, service
request, problem objective, problem variables, and mapping constraints.

28
Service Request (Decomposition)
NF0 NF1 NF2 NF4
in out
HW I/O VM PRC

1: HW 2: I/O 3:PRC

4:VM

5:VM 6:PRC 7:I/O

Physical Network

Figure 3.1: Simple example of a physical network and a service request. Red lines
represents NF mapping when YNfu = 1 and blue lines presents link mapping when
e
ZLijuv = 1

3.1 Network Modeling

3.1.1 Physical Network

The physical network is formulated as undirected graph denoted by G = (N, L),


where N is physical nodes set and L is physical links (edge) set. Each node is denoted
as Nu ∈ N, u ∈ [1, m] and m is number of nodes in N . Each node has a set of
resources K, such as CPU, memory and storage. Given that NFVI should contain
no single point of failure, different types of hypervisors, which provide different
types of virtualization techniques, were recommended by ETSI NFV framework
[29]. Thus, each Nu supports one virtualization technique {t ∈ T } where T is the
set of virtualization technique types (hypervisors) in NFVI. Each node Nu has a set
t,k
of resources {RN u
|t ∈ T andk ∈ K}. The embedding cost of a resource unit of type

29
Table 3.1: Physical Network Model
Notation Description
G = (N, L) physical network graph.
N set of physical nodes.
L set of physical links.
Nu physical nodes.
m number of nodes in N .
T set of virtualization technique types.
t a virtualization technique type.
t
RN u
Virtualization technique type of physical node Nu .
K set of resource types.
t,k
RN u
resource k of physical node Nu that has t virtualization type.
CNt,ku embedding cost of resource k in node Nu of type t.
Luv physical link between Nu and Nv .
BLuv bandwidth of Luv .
DLuv delay of Luv .
CLuv cost of embedding on Luv .
Puv path between Nu and Nv .
Iuv identification of the path Puv .
CP Catalogue of physical paths.

k and Nu has a virtualization type t is denoted by CNt,ku . Each physical link between
Nu and Nv is denoted by Luv ∈ L where u, v ∈ [1, m]. Luv has a bandwidth BLuv
and a propagation delay DLuv . The embedding cost of a bandwidth unit is denoted
as CLuv . A summary of notations used in modeling physical Network is shown in
Table (3.1).

3.1.2 Path Identification

Path identification has two purpose, one is to minimize the number of candidate
physical links in the input of the placement algorithm in order to enhance the
execution time. The other is to avoid mapping virtual links to long physical paths

30
in order to minimize and control the embedding cost. Therefore, path identification
is formulated as follows.

Physical edge between two adjacent nodes Nu and Nv where u, v ∈ m is denoted


by Euv . Then, a simple path between Nu and Nv is denoted by Puv . If Nv is not
adjacent to Nu , the path between them will be a sequence of edges from source to
destination as expressed in Equation (3.1).

Puv = [Eux1 , Ex1 x2 , . . . , Exn−1 xn , Exn v ] (3.1)

where u, x1 , x2 , xn−1 , xn , v ∈ m.

While the edge Euv can be expressed as a tuple of nodes at both ends of the
edges, then it can be expressed by Euv = (Nu , Nv ) and Puv as in Equation (3.2).

Puv = [Nu , Nx1 , Nx2 , . . . , Nxn−1 , Nn , Nv ] (3.2)

Whenever physical nodes have constant attributes, it is possible to identify


simple paths using those constant attribute. One of the attributes that are shared
between physical nodes and virtual nodes of service requests is the virtualization
technique type. Thus, virtualization technique type of each node in path Puv as
expressed in Equation (3.2) is used to identify that path. Simple path identification
is denoted by Iuv and expressed in Equation (3.3).

Iuv = [tu , tx1 , tx2 , . . . , txn−1 , tn , tv ] (3.3)

where tu , tx1 , tx2 , txn−1 , tn , and tv are the virtualization technique types of Nu , Nx1 ,
Nx2 , Nxn−1 , Nn , and Nv respectively.

It is important to know that path identification is a unique entry while the


content of those unique entries is not where one identification can retrieve a set of
all simple paths that have the same path length and the same ordered sequence
of virtualization technique types. For example, the identification IP ath = [t1 , t2 , t3 ]
can be an address in a data set for many simple physical paths P1 , P2 , . . . , Pn that
have the length of three nodes, which have the same sequence of virtualization types
t1 , t2 , t3 in the same order.

31
The data set of path identifications is denoted by CP . Each entry of CP contains
a data set of all paths, which have the same path identification of the entry as
expressed in Equation (3.4).

CP (Ipath ) = CP ([t1 , t2 , t3 ]) = [P1 , P2 , . . . , Pn ] (3.4)

where Ipath can be any unique sequence of available virtualization types with variable
length in the range of 2 nodes to the number of nodes in the longest simple path
in the physical network. If a is the maximum number of available unique path
identifications, the data set of CP is expressed as in Equation (3.5).

CP = (IP ath1 , IP ath2 , . . . , IP atha ) (3.5)

To realize the proposed path mapping approach on NFV, we suggest imple-


menting CP as a catalogue in the NFVI repository and we named it catalogue of
physical paths.

3.1.3 Service Requests

Given that traditional network function can be mapped to one VNF or VNFs
chain where those VNFs might be implemented with different virtualization tech-
nique types. Then it is possible to compose several combinations of the service
chains. In addition, the service request might contain further policy-based con-
straints, such as the life time of the service or affinity and anti-affinity constraints.
Therefore, the service request is denoted by S and expressed in Equation (3.6)

S = {rid , sdc , Ψ } (3.6)

where rid is the service request identification. sdc is the set of possible service
decompositions. Thus,

sdc = (dc1 , dc2 , . . . , dcx ); x ∈ N

. The variable Ψ is a set of policy constraints. In this work, we implemented one


constraints, which is the life time of the service request which denoted by τ . A
summary of notations that are used in service request is shown in Table (3.2).

32
Table 3.2: Service Request Model
Notation Description
S Service request where S = {rid , sdc , Ψ }
rid request id
sdc set of decompositions.
sdc = (dc1 , dc2 , . . . , dcx ); x ∈ N
dcx = Gs
Ψ set of constraints.
Gs = (F, E) graph of service chain.
F set of VNFs in Gs .
E set of virtual links in Gs .
f ∈F virtualized network function.
eij ∈ E virtual link between functions i and j.
Rfk the k resource of the function f .
Rft virtualization type t of function f .
Rft,k resource k for function f that has virtualization type t.
Beij required bandwidth for eij .
Deij maximum allowed delay for eij .
Pe2e set of end-to-end virtual paths in Gs .
p an end-to-end path where p ∈ Pe2e

33
However, Each service decomposition is a VNF-FG for a service chain. The
service chain is modeled as a directed graph Gs = (F, E). F is the set of virtualized
network functions and E is the set of links between them. Each network function
{f |f ∈ F } has a resource set denoted by {Rft,k |k ∈ Kandt ∈ T } where K is a
resource set and the function f is implemented by a virtualization technique type t.
Each virtual link between two functions i and j is denoted by eij ∈ E and i, j ∈ F .
The eij requires a bandwidth resource, which denoted by Beij and it has a maximum
allowed delay that denoted by Deij .

The service chain may contain one end-to-end path or more. Each end-to-end
path starts at a source function and ends at a destination one. End-to-end virtual
path is denoted by p. The set of all end-to-end paths in the service chains is denoted
by Pe2e . A network function in p is denoted by {fnp |n ∈ m} and m is the number
of network functions in p. The virtualization technique type of the fnp is denoted
by tfnp . All paths of the service is identified by an ordered set of types of functions
in paths. Path identification was denoted by Ip = (tf1p , tf2p , . . . , tfnp ). Ip is a unique
identification and it is possible to address more than one end-to-end virtual paths
that have the same length and the same order of virtualization type.

3.2 Problem Formulation

3.2.1 Problem Variables

During the embedding stage of NFV-RA problem, only one service decompo-
sition is selected to be mapped on the physical network. A binary variable Xdc is
used to indicate whether a decomposition is mapped or not. The Xdc is expressed
in Equation (3.7).

1 if dc is mapped.

Xdc = ; ∀dc ∈ sdc . (3.7)
0 otherwise.

The binary variable YNfu indicates if network function f is mapped on physical

34
node Nu . The YNfu is expressed in Equation (3.8).

1 if f is mapped on Nu .

f
YN u = ; ∀dc ∈ sdc , ∀f ∈ Gdc , ∀Nu ∈ N. (3.8)
0 otherwise.

e
The binary variable ZLijuv indicates if the virtual link eij is mapped on physical
link Luv . For the best of our knowledge, this variable was expressed in the literature
as in Equation (3.9).

1 if eij is mapped on Luv .

eij
ZLuv = ; ∀dc ∈ sdc , ∀eij ∈ E, ∀Luv ∈ L. (3.9)
0 otherwise.

In large physical networks, the Equation (3.9) would generate large number of vari-
ables, which increased the execution time in consequence. In order to minimize
the number of variables, the path identifications Ip of end-to-end paths of the ser-
e
vice request is used to retrieve possible candidate physical paths. Then the ZLijuv is
expressed again in Equation (3.10).


1 if eij is mapped on Luv .

e
ZLijuv =
0 otherwise.

; ∀dc ∈ sdc , ∀p ∈ Pe2e , ∀eij ∈ p, ∀Luv ∈ Puv , ∀Puv ∈ CP (Ip ). (3.10)

3.2.2 Objective Function

Assuming that different resource type has different embedding costs. Then, the
amount of required resource type k to embed f on Nu is denoted by Rft,k→Nu . Where
f and Nu have the same virtualization technique t.

Thus, the objective is to minimize the embedding cost is expressed in Equa-


tion (3.11), Equation (3.12), and Equation (3.13).

X X X XX
A= (CNt,ku × Rft,k→Nu × Xdc × YNfu ) (3.11)
dc∈sdc f ∈F Nu ∈N t∈T k∈K

35
e
X X X X X
B= (CLuv × Beij × Xdc × ZLijuv ) (3.12)
dc∈sdc p∈Pe2e eij ∈p Puv ∈CP (Ip ) Luv ∈Puv

Minimize A + B (3.13)

3.2.3 Constraints of the Problem

Decomposition Constraint

Only one decomposition of the service request should be embedded. This con-
straint is expressed in Equation (3.14).
X
Xdc = 1 (3.14)
dc∈sdc

Virtual Network Function Constraint

The constraint in Equation (3.15) is to prevent embedding virtual network


functions more than once. It also grantees that only the nodes from the selected
decomposition will be embedded.
X
YNfu = Xdc . (3.15)
f ∈F

Physical Node Constraint

If there are two virtualization types t, t1 ∈ T in the network, then it is not


allowed to map a virtual function f t of the type t1 on physical node Nut1 if t 6= t1.
In addition, the sum of allocated resources Rfk of the type k for all virtual functions
k
f that are mapped on Nu must be less or equal to the available resources RN u

in Nu .The constraints in Equation (3.16) and Equation (3.17) express that, it is


possible to embed any number of virtual functions f t on physical node Nut1 only if

36
Nu has enough resources and the function has the same virtualization type of the
physical node t = t1.

P ft
 t YNut1 = 0 ; t 6= t1.



f ∈F
, ∀Nut1 ∈ N, ∀dc ∈ sdc , ∀t, t1 ∈ T. (3.16)
P ft
 t YNut1 ≥ 0 ; t = t1.



f ∈F

X
Rfk × YNfu ≤ RN
k
u
; ∀Nu ∈ N, ∀dc ∈ sdc , ∀k ∈ K. (3.17)
f ∈F

Path Length Constraint

For mobile network the connections between virtual functions of the service
might traverse through transmission mediums, which might be with high cost. The
path length embedding constraint in Equation (3.18) determines if it is allowed to
embed end-to-end paths on longer than required physical paths. One of the reasons
behind high embedding cost is mapping virtual links to more than one hub physical
links, in one hand. In the other hand mapping virtual links to more than one
hub physical links might improve the acceptance ratio. This trade-off between the
embedding cost and the acceptance ratio can be controlled by the network operator
through determining the value of h|h ∈ 0, 1, 2, . . . in Equation (3.18) where h value
should equal to the maximum allowed additional hubs to the length of the virtual
path.
e
X
ZLijuv ≤ len(p) + h; ∀dc ∈ sdc , ∀p ∈ Pe2e , ∀Luv ∈ L (3.18)
eij ∈p

where len(p) is the number of virtual links in p. In case, there is a link in p where
both nodes at the two ends of that link have the same virtualization type, both
can be embedded to the same physical node. Then, the embedding will be in lower
number of physical links than len(p).

Unsplittable Path Flow Constraint

When a virtual link is mapped to more than one physical links, the traffic on
that link should not be split in more than one path. Then, if we assume that the

37
outgoing link from a node to next node has a positive sign and the incoming link
from a previous node to a node has a negative sign. Unsplittable path flow constraint
is expressed in Equation (3.19).

e e
X X
ZLijuv + −ZLijuv = YNi u − YNj u ; ∀dc ∈ sdc , ∀eij ∈ E, ∀Nu ∈ N.
Luv ∈L,Nu =src Luv ∈L,Nu =dst
(3.19)

Bandwidth Constraint

The sum of bandwidth for all virtual links that are mapped to a physical link
should not exceed the bandwidth capacity of that link and this constraint expressed
in Equation (3.20).

e
X
Beij × ZLijuv ≤ BLuv ; ∀Luv ∈ L, ∀dc ∈ sdc . (3.20)
eij ∈E

Path Delay Constraint

The end-to-end delay for all the physical links which the virtual link mapped
to, should not exceed the allowed delay for that virtual link, as in Equation (3.21).

e
X
DLuv × ZLijuv ≤ Deij ; ∀dc ∈ sdc , ∀eij ∈ E. (3.21)
Luv ∈L

3.3 Exact Scheme

Equations (3.1)-(3.21) formally formulate the problem of network service re-


source allocation with service decomposition support using path identification. These
equations are implemented in ILP-based scheme, which is our proposed exact scheme
and named ILP-P.

38
3.4 Catalogue of Physical Paths

The catalogue of physical paths (denoted by CP ) is a data set that can be


stored in the NFVI repository. It contains information about physical simple paths,
where each entry in the catalogue is addressing all paths that have the same length
and the same ordered attributes of nodes. Constant attributes of nodes are used to
identify those simple paths. Those attributes must to have a fixed value during the
embedding procedure even if the available resources of the nodes and links in the
path change. The virtualization technique types are used in this work to identify
paths for both physical paths and end-to-end paths of service requests. Those virtu-
alization technique types are: Virtual Machine (VM), Hardware Appliances (HW),
Process in a Container (PRC) and packet I/O.

Each simple path in the physical network Puv is identified using an ordered
set of virtualization technique types ( Equation (3.2)). Path identified by Iuv (
Equation (3.3)).

For all simple path in the physical network and the path starts at node u
and ends at node v, the identification Iuv for that path is composed as a tuple
of virtualization technique types for all nodes in the path with the same sequence
from u to v. All paths that have the same length (number of nodes) and same
sequence of virtualization type (same identification) are added to the same entry of
that identification in CP . In service request, paths identification of end-to-end paths
are done in the same way. The number of path identification in a service request
is equal or lesser than the number of end-to-end paths in its service graph. For
example, if a service graph of the request consists of 2 end-to-end paths, the number
of identification for that request will be 2 also unless there are two end-to-end paths
with the same sequence of virtualization types. Figure Figure (3.2) shows in (a) an
example of a service request graph and in (b) show how each path in the graph is
identified.

39
Service Request
Two paths SG:
in
NF0 NF1 NF2 NF4
out Path 1: (NF0, NF1, NF2, NF4)
HW I/O VM PRC
IP1 : (HW, I/O, VM, PRC)
Path 2: (NF0, NF3, NF4)
NF3
IP2: (HW, VM, PRC)
VM

(a) Two paths service request (after


(b) Path identification for the service
selection)
request
Physical Network

1: HW 2: I/O 3:PRC
Candidate paths:
For IP1: (HW, I/O, VM, PRC)
4:VM Candidate path 1 in Iuv1: (1, 2, 4, 6)
For IP2: (HW, VM, PRC)
Candidate path 2 in Iuv2: (1, 5, 6)

5:VM 6:PRC 7:I/O Candidate group: ( (1, 2, 4, 6), (1, 5, 6) )

(c) Physical Network (d) Candidate physical paths and


candidate group

Figure 3.2: Labeling and candidate paths grouping example; (a) example of two
paths service request, (b) path identification of the service request in a, (c) example
of a physical network, (d) candidate physical paths and candidate paths grouping.

3.5 Heuristic Scheme

This section describes the Decomposition Path Selection Mapping (DcPSM) al-
gorithms. DcPSM consists of decomposition selection, service mapping, path map-
ping, check node validation, and check links validation algorithms.

3.5.1 Decomposition Selection Algorithm

Whenever a service request S arrives, the decomposition selection algorithm


selects a decomposition from the decomposition set of services dc = GS ∈ sdc . The
benchmark [46] of this study used selection algorithm based cost function as in
Equation (3.22).
C(dc) = a · 1/Pdc + b · CF dc + g · ndc (3.22)

Where Pdc is the minimum number of candidate physical nodes which is used to
map NFs of dc, CF dc is the clustering factor, and ndc is the number of NFs in dc.

40
Figure 3.3: Clustering Factor (CF) as proposed by Sahhaf et. al. [46]

The constants a, b, g are used for weighting cost parameters. The clustering in [46]
considers that it is possible to combined any two NFs in sides of virtual edge inside
one physical node if both NFs have the same virtualization type. While a VNF
can contain more than on NF, clustering factor (CF) proposed in [46] is roughly
the number of VNFs in a dc as shown in Figure (3.3). Clustering is not effectively
reduce embedding cost in small number of NFs, as we can see in the results of this
study. Therefore, this study used different cost function as in Equation (3.23) to
determine which decomposition is going to be selected.

cost(dc) = we · ne (dc) + wp · np (dc) + wn · nf (dc) (3.23)

The cost function has three selection factors, which are number of edges ne (dc),
number of nodes nf (dc), and number of paths np (dc). Each factor has a weighting
parameter that is used to control the impact of the factor. Weighting parameters
are we , wp , and wn , which are for number of edges, paths, and nodes factors, re-
spectively. The pseudo code of the decomposition selection algorithm is illustrated
in Algorithm (1).

41
Algorithm 1: Decomposition Selection Algorithm
Data: sdc : Service request decomposition set, we : edges weighting
parameter,wp : paths weighting parameter, wn : nodes weighting
parameter
Result: Service graph of selected decomposition with minimum cost
1 begin
2 minCost ← inf inity
3 for Gs ∈ sdc do
4 cost = we ∗ ne (Gs ) + wp ∗ np (Gs ) + wn ∗ nf (Gs )
5 if minCost > cost then
6 minCost = cost
7 SelectedDc = Gs
8 end
9 end
10 Return: SelectedDc
11 end

3.5.2 Service Mapping Algorithm

Service mapping algorithm uses decomposition selection algorithm to find the


decomposition with minimum cost Gs . Then, it retrieves end-to-end simple paths of
physical network for each virtual path from the catalogue of physical paths Cp . Next,
the function pathGroupGenerator generates path group list P athGroupList.
P athGroupList is a data set that each group of physical paths in the set con-
tains one candidate path for each path in Pe2e of the selected decomposition. That
candidate group of paths is passed to the path mapping algorithm with Pe2e . If the
path mapping algorithm has success in embedding the service the service mapping
algorithm returns success state, else it continue testing next candidate path group.
For example, if the selected Gs has two paths p1 , p2 ∈ Pe2e and the identification of
them I(p1 ) and I(p2 ) and Cp (I(p1 )) = (Pab , Pcd ) and Cp (I(p2 )) = (Pef , Pgh ), then

CandidateP athsList = (Cp (I(p1 )), Cp (I(p2 )))

while
P athGroupList = ((Pab , Pef ), (Pab , Pgh ), (Pcd , Pef ), (Pcd , Pgh ))

42
Algorithm 2: Service Mapping Algorithm
Data: S: Service request contains few decompositions, G: Physical
network graph, CP : Catalogue of physical paths.
Result: service mapping success state.
1 begin
2 ReqP athsList ← φ
3 CandidateP athsList ← φ
4 Gs = DecompositionP athSelection(sdc )
5 Pe2e ← end-to-end paths of Gs
6 for path ∈ Pe2e do
7 IP ath ← V irtT ype(path) /* virtualization technique
types for nodes in path */
S
8 CandidateP athsList Cp (IP ath )
9 end
10 Generate path Group list:
P athGroupList = pathGroupGenerator(CandidateP athsList)
11 for CandidateP athsGroup ∈ P athGroupList do
12 Success = PathMapping(Pe2e , CandidateP athsGroup)
13 if Success == T rue then
14 Path mapping success
15 break
16 end
17 end
18 if Path mapping success then
19 Return: Mapping Success
20 end
21 else
22 Return: Mapping Fails
23 end
24 end

3.5.3 Path Mapping Algorithm

Path mapping algorithm tries to map Pe2e to their candidate physical path
group. Given that the end-to-end paths in Pe2e have shared virtual nodes because
the service graph Gs is connected. Thus, we used a simple method to check if
candidate paths have shared physical nodes too. That method is comparing the
number of physical nodes to the number of virtual nodes. If the physical less or
equal, then the algorithm continue. Otherwise it returns negative response. That
check method is stated in line 2 of path mapping (Algorithm (3)).

43
Algorithm 3: Path Mapping Algorithm
Data: Pe2e : a set of end-to-end paths of the service request,
CandidateP athsGroup: A list of candidate paths.
Result: T rue/F alse
1 begin
2 if The number of unique nodes in the CandidateP athsGroup more
than the number of nodes in Gs then
3 Return F alse
4 end
5 make a SavePoint /* save a copy of the physical network.
*/
6 mappedN odes = φ mappedEdges = φ
7 for Puv ∈ CandidateP athsGroup do
8 for p ∈ Pe2e do
9 for Nu ∈ Puv do
10 for f ∈ p do
11 if f ∈
/ mappedN odes then
12 checkN ode = CheckNodeValidation(f, Nu )
13 if checkN ode == F alse then
14 Role Back to SavePoint
15 Return F alse
16 end
17 checkLinks = CheckLinksValidation(f, Nu ,
mappedN odes, mappedEdges)
18 if checkLinks == F alse then
19 Role Back to SavePoint
20 Return F alse
21 end
S
22 mappedN odes (f, Nu )
23 end
24 end
25 end
26 end
27 end
28 Return T rue
29 end

The rest of pseudo code of the path mapping algorithm is described in Al-
gorithm (3) where it saves a the physical network state to a save point in or-
der to rolls back if the mapping fails. Next, it checks the virtualization tech-
nique type and available resources to map f on Nu using a validation function

44
named CheckNodeValidation. Whenever a new function is processed for map-
ping the links between the mapped nodes and that function is checked for avail-
able bandwidth and end-to-end link delay. Links validation function is named
CheckLinksValidation.

In this heuristic scheme, we tried to test if it possible to map end-to-end paths


to simple candidate paths of the same path identification. That means path length
constraints in Equation (3.18) is not take in account. In consequence, it is not
expected to get high acceptance ratio. In order to improve the acceptance ratio,
we suggest to retrieve physical paths base on path identification of virtual links
instead of end-to-end paths. We reported path mapping based on end-to-end path
identification to proof the concept of end-to-end path mapping where the results of
the experiments in this study indicate that the performance of proposed heuristic
scheme in large-scale overcomes its weakness in small-scale.

3.5.4 Check Node Validation Algorithm

Algorithm (4) shows the pseudo code of CheckNodeValidation, which checks


the virtualization type virtT ype of both the virtualized N F and the physical node
P node. Then it checks if there are enough resources for mapping the N F on P node
in terms of CPU, memory and storage. If the check returns positive response, the
virtual links between the N F in the process and all other previously mapped N F s
will be checked in terms of end-to-end delay and available bandwidth of the physical
paths between corresponding used physical nodes.

45
Algorithm 4: CheckNodeValidation Algorithm
Data: Gs : A service graph, G: Physical network, N F : Virtual node
in Gs , P node: Physical node to be checked.
Result: T rue/F alse
1 begin
2 if virtT ype(N F )! = virtT ype(P node) then
3 Return F alse
4 end
5 else if available resource of P node not enough to host N F then
6 Return F alse
7 end
8 else
9 Return T rue
10 end
11 end

3.5.5 Check Links Validation Algorithm

The CheckLinksV alidation algorithm (in Algorithm (5)) checks the end-to-
end delay for links between N F and previously mapped N F s, then it checks if
the physical edges that mapped before to the virtual links have enough bandwidth
to host them. It returns true if the check of end-to-end delay and bandwidth is
positive otherwise it returns f alse. The assignment of virtual links is done in the
CheckLinksV alidation algorithm where each physical edge used in mapping of the
virtual link vLink and it appends to its entry in the mappedEdges. Using the
mappedN odes and the mappedEdges registries enable better controlling of resources
and rolling back.

46
Algorithm 5: CheckLinksValidation Algorithm
Data: Gs : A service graph, G: Physical network, N F : Virtual node
in Gs , P node: Physical node to be checked, mappedN odes:
Mapped nodes data set.
Result: T rue/F alse
1 begin
2 for (fi , Nv ) ∈ mappedN odes do
3 if (fi , u)OR(u, f ) ∈ edgesof Gs then
4 vLink = (f, fi )OR(fi , f )
5 PhyPath = ShortestP athBetween(P node, u)
6 if DelayOf E2E(P hyP ath) > DelayOf (vLink) then
7 Return F alse
8 end
9 for edge ∈ P hyP ath do
10 if BandwidthOf (edge) < BandwidthOf (vLink) then
11 Return F alse
12 end
13 else
14 BandwidthOf (edge)− = BandwidthOf (vLink)
S
15 mappedEdges (vLink, edge)
16 end
17 end
18 end
19 end
20 Return T rue
21 end

47
Chapter 4

Experiment and Performance


Evaluation

This chapter describes the simulation environment, performance metrics and


the evaluation of results. The goal of the evaluation is to show the efficiency of the
proposed approach. Our concentration was on the efficiency and scalability of the
placement approach in order to be applicable in the mobile NFV cloud.

4.1 Experiments Design Framework

The experiment framework is designed in a modular blocks as in Figure (4.1).


The framework contains of the following blocks: Control panel controls the envi-
ronment setup, scenario timers, and algorithm selection. Physical network gen-
erates the physical network attributes, capacity of nodes, link bandwidth, and
calculate link delay. Service request generator generate service requests and
stores them according to the simulation scenario. The physical network and service
requests are modeled as a graph using the python networkx package. Algorithm
classes is the implementation classes of the simulated schemes. The simulator is
the simulation environment organizer. python simPy package is used to organized
the simulation procedures. All the generated networks and the results of the sim-

48
ulation is stored in the storage repository. Then, the results are analyzed and
draw using python matplotlib and numpy packages.

Physical Network
Generator Plot
Results
Service Request
Generator Storage
Repository

Algorithm Classes Simulator Results


Analysis

Control Panel

Figure 4.1: Experiment framework design.

4.2 Environment Setup

This study considered the similar environment setup to the works in [101] [102],
which claimed that the actual characteristics of substrate and virtual networks are
not well understood since network virtualization is still an open field. This claim
has been adopted by recent works, such as [47]. In consequence, Synthetic service
requests are used in this study following to previous works in literature while physical
networks are depicted from real network topologies. Synthetic physical networks
have been used in this study to investigate the performance of compared schemes in
various scenarios.

The conducted experiments in this thesis has two simulation run types, which
are long simulation runs and short simulation runs. The long simulation runs are
conducted for 200 time window with total 20000 time units with average 800 service
requests in each run. The short runs are executed with 2.5 time window with average
10 service requests in each run and total 250 time units. The environment setup is
described in details in the following sub-sections. Summary of simulation parameters
have listed in Table (4.1) while environment setup for service requests is shown in
Table (4.2).

49
Table 4.1: Environment Setup: Simulation Parameters
Parameter Value Unit Remarks

Length of Simulation Runs

Long simulation 20000 time units


run
Short simulation 250 time units
run

Allowed additional links in path

h 1 link

Cost function parameters

Sahhaf’s DSBM cost function weighting parameters

a 0.25
b 0.25
g 0.50

Our proposed DcPSM cost function weighting parameters

we 0.60
wp 0.30
wn 0.10

4.2.1 Generating Service Requests

The service requests are generated in Poisson process with average equals to
4 services per time window, which equals 100 time units. Each service has a few
decompositions, which are uniformly distributed between 2 to 5 decompositions in
a service. Each decomposition has 2 to 10 NFs uniformly distributed. Each NF
has CPU, memory and storage capacity, which are uniformly distributed between
1 and 20 capacity unit. Every pair of NFs in the decomposition is connected with
0.5 chance to generated the links between NFs. The bandwidth of those links is
uniformly distributed between 1 and 50 bandwidth units. The delay of virtual links

50
is assigned to 1000 time units. The life time of each service request is exponentially
distributed with average equals to 1000 time units. The generated service decom-
positions are verified to be directed acyclic graph. The service graph is verified to
be in the simple path or in the forking path SG forms for the Simple-Small and
Simple-Large scenarios; whereas it verified to be in the multiple paths SG form for
the Multiple-Small and Multiple-Large scenarios. The virtualization technique type
of nodes is random select of available virtualization technique types.

Table 4.2: Environment Setup


Item Range Unit Distribution

Arrived service re- 4 requests Poisson process with aver-


quests age 4 requests per 100 time
units.
Number of dc ∈ sdc 2-5 Decompositions uniform
Number of f ∈ dc 2 - 10 Nodes Uniform
Links between any 0.5 Chance Chance
pair of nodes
Rfk 1 - 20 Capacity Uniform
units
Rft [VM, PRC, type Chance
I/O, HW]
Beij 1 - 50 bandwidth Uniform
units
Deij 1000 time units Fixed
Service life time 1000 Time units exponential with average
1000 time units

4.2.2 NFV Physical Network Infrastructure

NFV physical network uses real topologies of two real networks, which were
obtained from Internet Topology Zoo1 and they are the BT Europe network and
1
http://www.topology-zoo.org

51
Interoute network. The BT Europe network consists of 24 nodes and 37 edges and
the Interoute network consists of 110 nodes and 148 edges. The CPU, memory and
storage of physical nodes and the edge bandwidth are uniformly distributed between
100 and 150 capacity units, while the bandwidth of edges are uniformly distributed
between 100 and 150 bandwidth units. The delay of each edge is calculated pro-
portionally to the real geographical distance between nodes is between 1 and 30
time units. The embedding cost of physical nodes and physical edges is equals to 1
cost unit. The virtualization technique type of nodes is random select of available
virtualization technique types. Summary of physical network parameters is shown
in Table (4.3).

Table 4.3: Environment Setup: Service request parameters.


Item Range Unit Distribution
k
RN u
100 - 150 Capacity unit Uniform
t
RN u
[VM, PRC, type Chance
I/O, HW]
CNt,ku 1 Cost unit Fixed
BLuv 100 - 150 Bandwidth Uniform
unit
DLuv 1 - 30 time units calculated by geographical
distances between nodes
CLuv 1 Cost unit Fixed

4.2.3 Synthetic Physical Networks

In order to evaluate the execution time, Synthetic physical networks were gen-
erated with number of nodes that ranges between 10 and 150. The physical edges
between nodes are generated randomly between any pair of nodes in chance of 0.5.
The resources of nodes, delay of edges, and bandwidth of edges are generated as
described above.

52
4.2.4 Hardware and Software Description

The simulation is developed by Python language using Python packages, such


as networkx, numpy, simpy, scipy, matlibplot, and pulp. The hardware used to run
TM
the simulation is a Lenovo ThinkPad T440p with 2.50GHz Intel Core
R i7-4710MQ
CPU and 16 MB RAM and the operating system is OpenSuSE Leap 42.2.

4.3 Performance Metrics

To evaluate the proposed approaches, a common used metrics are measured.


These metrics were used in literature to evaluate the efficiency of proposed solution,
such as the work in [46] and [47]. The measured metrics are:

1. Execution time (ET ): This metric measures the spent time by an algorithm
to find the embedding solution [46], [47]. Execution time is an important
metric to evaluate the placement algorithm where developing rapid algorithms
is important for resiliency mechanisms in NFV.

2. Acceptance ratio (AR = RA /RT ): This metric measures the accepted ser-
vice requests (RA ), which are successfully mapped, to the total number of
arrived requests (RT ) [46]. High acceptance ratio might be an indicator of
high revenues. But some mechanism, such as the back track, might consume
much resources to increase the acceptance ratio, which in consequence increase
the embedding cost too. This trade off can be determined by the NFVI oper-
ator where lower acceptance ratio with reasonable use of resources might be
satisfying.

3. Embedding cost (Cavg ): The embedding cost is the average of total used re-
sources for mapping service requests on 100 time unit[46], [47]. The embedding
cost is calculated as in the objective equations (3.11-3.13).

4. Average embedding cost/average revenue (Rc/r = Cavg /Ravg ): This is


the ratio between the average embedding cost Cavg and the average revenue

53
Ravg of a service requests in 100 time units [46]. Revenue of a service request is
calculated by multiplying total resources of virtual nodes by average physical
nodes cost then sum it with the multiplying of total bandwidth of virtual links
by average cost of physical links.

4.4 Simulation Experiments

The procedure of experimental simulation was organized according to the fol-


lowing.

4.4.1 Experiment Procedure

The experiment procedure has been conducted according to the following steps:

Step 1: Generate Service Graphs with Poisson Process. Each service has a few
decompositions and number of network functions in each decomposition which
are uniformly distributed. Capacity of resources in each network function are
uniformly distributed.

Step 2: Using a real network topologies for small and large physical networks. The
Capacity of CPU, memory and storage, and edges bandwidth is generated
in uniform distribution. Delay of each physical edge in the topology will be
distributed proportionally to the calculated distance between physical nodes
with its geographical coordinates.

Step 3: Formulate Integer Linear Programming to find the optimal solution of ser-
vice chains embedding as in [46].

Step 4: Develop the proposed decomposition path selection mapping approach and
algorithms to realize it.

Step 5: Develop simulation scenarios to show the impact of the proposed approach
in small and large physical network for simple/forking and multiple paths
service graphs.

54
Step 6: Record measurements for performance metrics.

Step 7 Analyze measurements.

Step 8: Report the results evaluation of the study.

4.4.2 Simulation Scenarios

The experiment is conducted with four scenarios, which are (1) Simple-Small,
(2) Simple-Large, (3) Multiple-Small and (4) Multiple-Large. The name of each
scenario is composed of two parts. The first part describes the form of the service
request which can be simple or multiple. The simple means that the service requests
are generated in the form of simple or forking path SGs. The multiple means the
service requests are multiple paths SGs. The second part of the scenario name
describes the size of physical network where small is a small physical network and
large is a large physical network.

The evaluation results are compared against the results of the benchmark [46].
The benchmark schemes were reimplemented from the scratch. The schemes of the
benchmark were denoted by ILP-A for the ILP-based and DSBM for the heuristic.
The suffix A of ILP-A means that all edges in the physical network have link variable
as described in [46], which is similar to binary variable ZLeijev in Equation (3.9). The
proposed schemes of our approach are denoted by ILP-P for the ILP-based and
DcPSM for the heuristic. The suffix P of ILP-P means that part of physical edges
were given variables ZLeijev as as in Equation (3.10).

Given that, ILP-A has long execution time as claimed in [46]. Then, ILP-A was
tested in short runs to compare the execution time. Whereas the acceptance ratio
of ILP-P was measured almost 100% in Simple-Small and Multiple-Small scenarios,
the results of ILP-A only reported for the execution time. Short run simulation
considered 250 time units for each simulation run.

Furthermore, ILP-P has reasonable execution time comparing to ILP-A. Thus,


experiment tested ILP-P in large scenarios too. A list of compared schemes are in

55
table Table (4.4) and a list of reported scenarios are in table Table (4.5).

Table 4.4: List of compared schemes


Notation Description
ILP-A Benchmark ILP-based scheme as in [46]
DSBM Benchmark heuristic scheme as in [46]
ILP-P Proposed ILP-based scheme
DcPSM Proposed heuristic decomposition
path selection mapping scheme.

4.4.3 Measuring Execution Time

To measure the impact of number of paths in a service graph on the execution


time; and in case of the service graph is embedded to a physical network with the
same number of nodes and higher number of edges. The experiment has tested this
case in 6 scenarios. Where the service graphs was generated with 5, 10, and 20 paths
in each service decomposition. These generated requests was embedded on physical
networks that has the same number of nodes and different number of edges. The
physical networks generated randomly with maximum number of edges equal to 3
and 4 edges at each node. These scenarios are denoted by SPE53 , SPE54 , P SPE103 , SPE104 ,
SPE203 , and SPE204 .

The SPE53 is the service graph of each service decomposition of each request has
5 paths and the synthetic physical network was generated with maximum 3 edges at
each node. SPE54 has 5 paths and physical network was genetated with maximum 4
edges at each node. In the same manner the execution time was measured for SPE103 ,
SPE104 , SPE203 , and SPE204 scenarios.

The impact of number of physical nodes is studied in higher number of nodes.


The work in [46] evaluated the execution time for physical networks that have the
number of nodes ranging between 10 and 50. In this study the physical nodes
were expanded to range between 10 and 150 nodes. Also, this study the impact
of higher number of edges where more edges were added between nodes that have

56
Table 4.5: Experiment scenarios
Run Notation Description
Long Simple-Small Simple/forking requests on small-scale topology
Long Simple-Large Simple/forking requests on large-scale topology
Long Multiple-Small Multiple paths requests and small-scale topology
Long Multiple-Large Multiple paths requests on large-scale topology
Short, Long SPE53 Requests with 5 paths and maximum 3 edges at
each physical node in physical network.
Short, Long SPE103 Requests with 10 paths and maximum 3 edges at
each physical node in physical network.
Short, Long SPE203 Requests with 20 paths and maximum 3 edges at
each physical node in physical network.
Short, Long SPE54 Requests with 5 paths and maximum 4 edges at
each physical node in physical network.
Short, Long SPE104 Requests with 10 paths and maximum 4 edges at
each physical node in physical network.
Short, Long SPE204 Requests with 20 paths and maximum 4 edges at
each physical node in physical network.

lesser number of edges than the average number of edges of the physical network.
In case of testing the impact on execution time, synthetic physical networks with
different number of edges were generated as in table Table (4.6). The fields of the
table is denoted by P hN for the number of physical nodes, P hE3 for the maximum
edges at each node equal 3, and P hE4 for maximum edges at each node equal to 4.

4.4.4 Selection Parameters

Unlike the work in [46], the ILP-based scheme in this study did not used any
selection function. The reason is to find the best solution to compare both heuristic
schemes (our heuristic and benchmark one).

As the heuristic (DSBM and DcPSM) uses weighting parameter in their decom-

57
Table 4.6: List of synthetic physical network
P hN P hE3 P hE4
10 14 21
30 50 64
60 98 133
90 156 198
120 227 265
150 265 333

position selection procedure, specifically in the cost functions, the reported results
were measured using the following weighting parameters. The cost function of the
decomposition selection of the DSBM uses the weighting parameters of selection
factors, which are a = 0.25, b = 0.25 and g = 0.50. These parameters are recom-
mended in [46]. The cost function of the path selection of DcPSM uses the weighting
parameters of selection factor, which are we = 0.60, wp = 0.30 and wn = 0.10. The
weighting parameters of the path selection of DcPSM are selected experimentally as
discussed in Section 4.5.5.

4.4.5 Comparison Method

Comparing our proposed approach with previous work involves the network
topologies, service requests, problem formulation, and evaluation method.

Physical Network Topologies

In this thesis, we used teal telecom operator network for small-scale and large-
scale (the BT-Europe and Interout networks from Internet Topology Zoo), which
were used in [46] and [47]. The synthetic topologies are used in this study with
reasonable number of attached physical links to each node. In real networks, high
volume servers usually contains small number of network adapters, which might
range from 2 adapters to few folds of 2 and usually 4 network adapters in each

58
server (node). Thus, synthetic topologies were generated with maximum number
of attached links to each node equals to 3 or 4 links. The implementation in [47]
considered 100 nodes and 570 links in the synthetic network, which we think that
such physical network would increase capital and operational cost because of the
high number of physical links. In addition, compared schemes were evaluated using
topologies with higher number of nodes up to 150 nodes (Table (4.6)) comparing to
50 nodes in [46] and 100 nodes in [47].

Service Requests

Service request is formulated with mapping constraints as expressed in Equa-


tion (3.6) where mapping algorithm can handle directory. For the best of our knowl-
edge, service request were generated in the literature as simple/forking path service
graph, such as the work in benchmark or with random connection between any pair
of virtual node with probability of (0.5) such the work in [45]. In our work, five
types of service request were studied, which are Simple, Multiple, P5 , P10 , and P20 .
All the types generated with the probability of 0.5 method, and further check was
done to ensure that the generated graph have the same type in all the decompo-
sitions of that service request type. Simple service requests usually have one start
virtualized node with simple path or forking paths. Multiple paths service requests
type were generated without any constraints of number of starting nodes or ending
nodes. service requests in P5 type were generated with any number of virtual nodes
in the range [2,10] and any number of virtual links in condition that the service
graph consists of 5 end-to-end paths. Similarly, P10 and P20 were generated with 10
and 20 virtual links respectively. Studying of the impact of multiple virtual paths
on the efficiency of mapping algorithm was not considered in the literature.

Problem Formulation

The NFV-RA problem was formulated and implemented in ILP-based scheme


(ILP-P) where this method has been used in the literature. ILP-P minimized the
number of link variable to the number of physical links that has the same path

59
identification of the virtual links (Equation (3.10)), which indicate that ILP-P is
more efficient in using space. Moreover, ILP-P scheme gibes the network operator
the ability to control the trade off between the embedding cost and the acceptance
ratio where the length constraint in Equation (3.18) ensure lower embedding cost
with lower value of h while the higher values improves the acceptance ratio by
mapping longer paths. Most of the work in literature considered the embedding
cost for measuring the efficiency of the placement algorithm. We also give the
advantage to the embedding cost over the acceptance ratio because our proposed
solution focus on mobile networks. Mapping virtual paths to shorter of equal length
of physical paths is important to enhance end-to-end latency and user quality of
experience.

Evaluation Method

In literature, previous proposed solution were evaluated with consideration of


the number of physical nodes only while in this study we evaluated the performance
of compared schemes considering more aspects, such as the impact of physical links,
the impact of virtual nodes, virtual links, and end-to-end virtual paths of the service
requests. Most of recent related works have evaluated their proposed scheme in
ether long simulation run or short simulation run whereas both were conducted. We
evaluated our proposed schemes with 16 scenarios as in Table (4.5). Performance of
compared schemes according to the attributes of service request, such as number of
virtual nodes, number of virtual links, and number of end-to-end runs were evaluated
in large simulation runs using small-scale and large-scale topologies. About 40000
service request (in average) were solved to evaluate the impact of service request
attributes on compared schemes for long run of Simple, Multiple, P5 , P10 , and P20
service types on small and large topologies.

To evaluate the execution time, we conducted 12 experiments with 3 types of


service requests (P5 , P10 , and P20 ) on 12 synthetic networks in Table (4.6). Six
synthetic networks was generated with maximum number of physical links that
attached to each node is equal to 3 (denoted by P hE3 ) and the other six was
generated with maximum 4 links (denoted by P hE4 ). Used topologies and service

60
requests in this setup consider the real network configuration and reasonable cost
of the physical topologies where much physical links in synthetic network might be
unnecessary. Distribution of service requests with specific attributes is counted and
plotted in Figure (4.2).

DcPSM DcPSM
ILP-P ILP-P
DSBM
12000 DSBM
16000
10000 14000
8000 12000
10000

Count

Count
6000 8000
4000 6000
2000 4000
2000

25 30ges 7080
20 5060f paths
2 3 4 15 f ed 0 5 10 40 o
Numb5er of6 7 8 10 er o Numbe15 2030mber
nodes 9 10 5 Numb r of ed20ges 25 30 0 10 Nu
0

(a) Counts of request (nodes, edges) (b) Counts of request (paths, nodes)

Figure 4.2: The counters for service requests with: (a) specific number of nodes and
specific number of edges; (b) specific number of virtual paths and specific number
of nodes.

4.5 Results Evaluation

General performance evaluation indicates that path mapping approach is effi-


ciently reduced average execution time and average embedding cost where average
generated number of variables in ILP-P were reduced to 40% of the number of vari-
ables in ILP-A for the small-scale and to 38% in large-scale. Reducing number
of variables in ILP formulation using path identification enhanced the efficiency of
using space and also enhanced the execution time.

4.5.1 Execution Time

Execution time measurements of compared schemes are reported in Figure (4.3),


which contains six figures for six scenarios as described in Table (4.5). The curves of
ILP-P and DcPSM show less waving comparing to ILP-A and DSBM in all scenarios,
which indicates that path mapping approach has stable incremental execution time

61
8 ILP-A 17.5 ILP-A
ILP-P ILP-P
DSBM 15.0 DSBM
Execution time (s)

Execution time (s)


6 DcPSM DcPSM
12.5
10.0
4
7.5
2 5.0
2.5
0 0.0
10 30 60 90 120 150 10 30 60 90 120 150
Number of nodes in physical network Number of nodes in physical network

(a) SPE53 (b) SPE54

40
12 ILP-A ILP-A
ILP-P 35 ILP-P
10 DSBM 30 DSBM
Execution time (s)

Execution time (s)

DcPSM DcPSM
8 25
6 20
15
4
10
2 5
0 0
10 30 60 90 120 150 10 30 60 90 120 150
Number of nodes in physical network Number of nodes in physical network

(c) SPE103 (d) SPE104

25 ILP-A 80 ILP-A
ILP-P ILP-P
DSBM DSBM
Execution time (s)

Execution time (s)

20 DcPSM 60 DcPSM
15
40
10
20
5

0 0
10 30 60 90 120 150 10 30 60 90 120 150
Number of nodes in physical network Number of nodes in physical network

(e) SPE203 (f) SPE204

Figure 4.3: Execution time of six scenarios with 3 types of service requests and 2
types of physical networks. The average of 10 simulation runs is reported.

62
with the increasing size in physical and/or virtual networks. ILP-P and DcPSM are
more efficient than the ILP-A and DSBM in the large-scale (range [120, 150] nodes
and P20 ) where the increasing of execution time with the increasing of physical nodes
or edges is less as described in Table (4.7).

By comparing the results of all schemes (algorithms), the increase of physical


edges enhanced the execution time in the range of 10 to 90 nodes for the DSBM.
The average execution time enhanced with 3% for ILP-A and 47% for DSBM in the
range of 10 to 90 physical nodes, whereas it declined by 62% for ILP-A and 217%
for DSBM in the range up to 150 nods. The increasing of number of physical edges
by average 31% of the original number of physical edges cause an increase in the
execution time with 41% for ILP-P and 39% for DcPSM. The increased percentage
in the execution time of the ILP-P and DcPSM is near and proportional to the ratio
in the large scenario, which is the case of the mobile core infrastructure.

In large scenario where physical network ranging between 120 to 150 physical
nodes and the service request have 20 paths. If the physical nodes or the physical
edges increased with 25% of the original number of nodes of edges, the physical
nodes has more impact on the the exact algorithms. The increase in physical edges
impacts the execution time of the heuristic more than the increase of physical nodes.
Percentage of the increasing ratio in execution time is shown in table Table (4.7).

Table 4.7: Comparing the increasing of execution time regarding to the increase in
physical nodes or physical edges
Algorithm Increase of 25% Increase 25%
of Nodes of edges
ILP-A 58% 48%
ILP-P 48% 46%
DSBM 206% 208%
DcPSM 62% 66%

To evaluate the impact service request attributes, the average execution time for
requests with specific number of nodes, links, and paths is reported in Figure (4.4).
For small-scale physical network average execution time of ILP-P for all service

63
request from all service types was reduced to 58% of the execution time of ILP-A and
to 57% of average execution time of DSBM in all physical network scenarios. Path
mapping approach is also efficiently reduced average execution time ratio between
heuristic and exact schemes where the ratio between average execution of DcPSM
to average execution of ILP-P was 1 to 6.2, which is much better than the ratio in
the literature.

DcPSM DcPSM
ILP-P ILP-P
DSBM DSBM
17.5
14

Execution time, s

Execution time, s
12 15.0
10 12.5
8 10.0
6 7.5
4 5.0
2 2.5
0 0.0
80
25 30ges 50 6070ths
2 3 4 15 20r of ed 0 5 10 40 of p a
Numb5er of6 7 8 10 e
5 mb Numbe15
r of ed20ges 25 30 10 2030umber
nodes 9 10 0 Nu 0 N

(a) ET by request (nodes, links) (b) ET by request (paths, links)

Figure 4.4: Average execution time for service requests with: (a) specific number of
nodes and specific number of links; (b) specific number of paths and specific number
of links.

From these results it can be conclude that the impact of increasing the number
of physical nodes or increasing the number of physical edges impacts the execution
time grater than the increase on number of nodes or edges of the service request.
Furthermore, the algorithms proposed approach (ILP-P and DcPSM) are more effi-
cient in consuming time than the benchmark algorithms (ILP-A and DSBM).

Long run for service requests with five, ten, and twenty paths have been sim-
ulated on small (BT Europe) and large (Interoute) physical networks. the results
confirms the reported results where the ILP-P and DcPSM are more efficient than
the benchmark algorithms. Therefore, minimizing the input of the placement algo-
rithm minimize the execution time and the embedding cost in long run, too. The
results of these scenarios are reported in the additional results (Appendix-A).

64
4.5.2 Acceptance Ratio

The acceptance ratio is evaluated in long simulation run for all schemes on
small-scale physical network. In the large-scale, ILP-A was not evaluated because
it requires long execution time. The results of ILP-P in Simple-Small and Multiple-
Small are better than the ILP-A. In consequence, we expect that the ILP-P will be
more efficient in Simple-Large and Multiple-Large. The acceptance ratio is reported
in Figure (4.5). The ILP-P has a little improvement in the acceptance ratio over
the ILP-A in long simulation run because ILP-P minimize the use of physical links
which enhance the acceptance in long run. Unlike the ILP-P, the DcPSM maps
long paths of service requests where the possibility that long paths with the same
path identification is low in small-scale physical network. Then, DcPSM shows
low acceptance ratio in Simple-Small and Multiple-Small while in it has higher
acceptance ratio in Simple-Large and Multiple-Large.

As expected, the number of links in the service request impacts the acceptance
ratio more than the number of nodes. Figure (4.6)-(a) shows that the low acceptance
ratio is distributed over the number of nodes (x-axis) and over number of edges
for both DSBM and DcPSM. Moreover, low acceptance ratio is concentrating for
service request with high number of edges and high number of paths as shown in
Figure (4.6)-(b). For all service request from all service request types the average
acceptance ratio of DcPSM equals to 84% of the average acceptance ratio of DSBM,
which point out that path mapping can map end-to-end paths efficiently and it
worths to improve heuristic algorithms that more efficient than the DcPSM.

4.5.3 Embedding Cost

In Simple-Small and Multiple-Small, the proposed ILP-P performs more effi-


cient than the ILP-A because ILP-A use the decomposition selection which selects
the service decomposition based on the number of nodes. The results in Figure (4.7)
and Figure (4.8) proves that selecting service decomposition according to the num-
ber of paths and the number of edges reduces the embedding cost efficiently. The

65
1.0 1.0
0.9 0.9
Acceptance ratio

Acceptance ratio
0.8 0.8
0.7 0.7
ILP-A
0.6 ILP-P 0.6 ILP-P
0.5 DSBM 0.5 DSBM
DcPSM DcPSM
0.4 0.4
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Simple-Small (b) Simple-Large


1.0 1.0
0.9 0.9
Acceptance ratio

Acceptance ratio

0.8 0.8
0.7 0.7
ILP-A
0.6 ILP-P 0.6 ILP-P
0.5 DSBM 0.5 DSBM
DcPSM DcPSM
0.4 0.4
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(c) Multiple-Small (d) Multiple-Large

Figure 4.5: Average acceptance ratio for: (a) Simple-Small, (b) Simple-Large, (c)
Multiple-Small, and (d) Multiple-Large scenarios. The shaded background behind
each curve represents the 95% confidence interval on the reported average values.

66
DcPSM DcPSM
ILP-P ILP-P
DSBM DSBM
1.0 1.0

Acceptance ratio

Acceptance ratio
0.8 0.8
0.6 0.6
0.4 0.4
0.2 0.2
0.0 0.0
80
20 25 30ges 506070ths
2 3 4 15 f ed 0 a
10 er o
5 10 3040 er of p
Numb5er of6 7 8 5 Numb Numbe15
r of ed20ges 25 30 1020 Numb
nodes 9 10 0 0

(a) AR by request (nodes, edges) (b) AR by request (paths, edges)

Figure 4.6: Average acceptance ratio for service requests with: (a) specific number
of nodes and specific number of edges; (b) specific number of paths and specific
number of edges.

average of embedding cost of ILP-P was lower than the average embedding cost
of ILP-A with 4% in small-scale while in all scenarios ILP-P cost was 29% fo the
DSBM cost. In addition, the cost of DcPSM was equal to 1.09 of the optimal cost
in ILP-P, which is more efficient than the best ratio in the literature.

The curves of average embedding cost of ILP-P and DcPSM is lower than DSBM
for all four scenarios as shown in Figure (4.7). It worth to mention that the ILP-P
behaves similar to the reported figure of the ILP algorithm in benchmark for the
Simple-Small scenario. In Simple-Large and Multiple-Large, the DcPSM algorithm
shows near to optimal average embedding cost. In Multiple-Small the heuristic
algorithms (DSBM and DcPSM) curve down with the time because these algorithms
selects small decompositions and in consequence few of them are accepted.

In addition, experiments results show that increasing number of VNFs in a


requests might not impact the execution time and embedding cost as much as the
increase of virtual links between those VNFs. Figure (4.8) shows that the average
embedding cost of DSBM increases with larger number of edges in the service re-
quest. The proposed approach has mitigated that increasing in embedding cost with
larger number of edges for both proposed schemes the ILP-P and DcPSM.

67
250 500
ILP-A ILP-P
ILP-P 400 DSBM
200 DSBM DcPSM
Avg. cost

Avg. cost
DcPSM
300
150
200
100
100
50
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Simple-Small (b) Simple-Large


500 1200
ILP-A ILP-P
400 ILP-P 1000 DSBM
DSBM DcPSM
800
Avg. cost

Avg. cost

DcPSM
300
600
200
400
100
200
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Multiple-Small (b) Multiple-Large

Figure 4.7: Average embedding cost for: (a) Simple-Small, (b) Simple-Large, (c)
Multiple-Small, and (d) Multiple-Large scenarios. The shaded background behind
each curve represents the 95% confidence interval on the reported average values.

68
DcPSM DcPSM
ILP-P ILP-P
DSBM DSBM
3500 3000

Embedding cost

Embedding cost
3000 2500
2500 2000
2000
1500 1500
1000 1000
500 500
0 0
30 50
25 s 40 s
20 e 30 of path
2 3 4 15 edg 0
Numb5er of6 7 8 10 ber of 5
Nu10 20 r
5 m mber o15
f edges20 10 Numbe
nodes 9 10 0 Nu 25 30 0

(a) Cavg by request (nodes, edges) (b) Cavg by request (paths, edges)

Figure 4.8: Average embedding cost for service requests with: (a) specific number
of nodes and specific number of edges; (b) specific number of paths and specific
number of edges.

4.5.4 Ratio of Average Cost to Average Revenue

To evaluate if the average embedding cost is proportional to the average revenue,


Figure (4.9) shows the ratio between average embedding cost and average revenue.
The lower ratio indicates that the embedding cost is profitable where the cost of
the resource needed for the service request is higher. The curve of the DcPSM has
almost similar ratio of the ILP-P in the Simple-Large and Multiple-Large scenarios.

The larger number of edges in the service request the larger it possible to cluster
nodes and to embed them in one physical node. Clustering nodes in DSBM results
in lower average embedding cost to average revenue. This behavior is shown in
Figure (4.10) where the lower number of nodes and edges in the service request
cause higher cost to revenue ratio. The proposed approach is efficient in embedding
the service request with lower cost in low and high number of nodes and edges of
the service request regardless of the possible clustering of nodes.

4.5.5 Impact of Decomposition Selection Cost Parameters

The DcPSM use a cost function to select the service decomposition with the
least number of edges, number of paths and number of nodes. These selection
parameters are weighted and experimentally studied the impact of the weighting

69
2.5
1.2
Avg. cost/avg. revenue

Avg. cost/avg. revenue


1.0 2.0
ILP-P
0.8 1.5 DSBM
ILP-A DcPSM
ILP-P 1.0
0.6 DSBM
DcPSM 0.5
0.4
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Simple-Small (b) Simple-Large


2.5
1.2 ILP-A
Avg. cost/avg. revenue

Avg. cost/avg. revenue

ILP-P 2.0
1.0 DSBM
DcPSM ILP-P
0.8 1.5 DSBM
DcPSM
0.6 1.0

0.4 0.5
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Multiple-Small (b) Multiple-Large

Figure 4.9: Average cost to average revenue for: (a) Simple-Small, (b) Simple-Large,
(c) Multiple-Small, and (d) Multiple-Large scenarios. The shaded background be-
hind each curve represents the 95% confidence interval on the reported average
values.

70
DcPSM DcPSM
ILP-P ILP-P
DSBM4.0 DSBM3.5
3.5 3.0

Cost to revenue

Cost to revenue
3.0 2.5
2.5 2.0
2.0 1.5
1.5
1.0 1.0
0.5 0.5
0.0 0.0
80
20 25 30ges 70
5060f paths
2 3 4 15 f ed 0 5 10 40
30 er o
Numb5er of6 7 8 10 er o Numbe15
nodes 9 10 0
5 Numb r of ed20ges 25 30 0 1020 Numb

(a) Rc/r by request (nodes, edges) (b) Rc/r by request (paths, edges)

Figure 4.10: Average embedding cost to average revenue for service requests with:
(a) specific number of nodes and specific number of edges; (b) specific number of
paths and specific number of edges.

parameters. It is found that the DcPSM performs well when the weights of the edges
factor and the paths factor are higher than the weight of nodes factor. The DcPSM
performs the best when the weights equal to the values we = 1.0, wp = 0.0, wn = 0.0
then it degraded a little when the weights equal to the values we = 0.0, wp =
1.0, wn = 0.0 while the DcPSM performs bad when the weights equal to the values
we = 0.0, wp = 0.0, wn = 1.0. Therefore, the selection factors are sorted by their
impact on the performance of the DcPSM from the most to the least in this order:
The number of edges, the number of paths and the number of nodes of the service
graph.

71
Chapter 5

Conclusion and Future Work

5.1 Conclusion

The work in this thesis considers the placement of service chains on NFV en-
vironment focusing on the mobile cloud scenario. We proposed path mapping ap-
proach with exact and heuristic schemes to solve the NFV-RA problem. Path map-
ping aims to optimize the NFV resource allocation execution time and embedding
cost by minimizing the input size of the placement algorithm using end-to-end path
identification of the service chains and using catalog of physical paths.

The proposed approach was simulated and the results evaluation indicates that
the proposed approach is an efficient in minimizing the execution time of the exact
scheme to 57% of the execution time of the heuristic of the benchmark while average
embedding cost of proposed exact was minimized by 4% of the embedding cost of
the exact of the benchmark. Thus, the proposed path mapping is more efficient
than the solution in previous work because it prevents embedding on long physical
paths.

72
5.2 Future Work

For future work, we are planning to study the impact of path mapping approach
on the dynamic management on NFV by implementing the approach in service
chains life-cycle management, such as scale in/out, migration. Also it is possible
to improve the acceptance of heuristic DcPSM by modifying the path mapping
algorithm to work on identifying the edges of service request instead of end-to-end
paths. This suggestion would improve the acceptance ratio of the proposed approach
in small physical network.

73
References

[1] N. O. participating in the ETSI NFV ISG, “Network Functions Virtualisation


(NFV): Network Operator Perspectives on Industry Progress, white paper,”
in SDN and OpenFlow World Congress. Dusseldorf, Germany: ETSI,
October 2014, pp. 1–20, october 14-17, 2014. [Online]. Available: https:
//portal.etsi.org/Portals/0/TBpages/NFV/Docs/NFV White Paper3.pdf

[2] Huawei Technologies Co., “White Paper - Huawei Observation to NFV,”


Huawei Technologies Co., LTD, Tech. Rep., 2014. [Online]. Available:
http://www.huawei.com/ilink/en/download/HW{ }399662

[3] H. Basilier, M. Darula, and J. Wilke, “Virtualizing network


services the telecom cloud,” Ericsson, The communications tech-
nology journal, March 28,, Tech. Rep. 3, 2014. [Online]. Available:
https://www.ericsson.com/en/publications/ericsson-technology-review/
archive/2014/virtualizing-network-services---the-telecom-cloud

[4] A. Blenk, A. Basta, M. Reisslein, and W. Kellerer, “Survey on network virtu-


alization hypervisors for software defined networking,” IEEE Communications
Surveys Tutorials, vol. 18, no. 1, pp. 655–685, Firstquarter 2016, date of Pub-
lication: 09 October 2015.

[5] K. Katsalis, N. Nikaein, E. Schiller, R. Favraud, and T. I. Braun, “5g archi-


tectural design patterns,” in 2016 IEEE International Conference on Commu-
nications Workshops (ICC), May 2016, pp. 32–37.

[6] S. Li, L. D. Xu, and S. Zhao, “5g internet of things: A survey,” Journal of
Industrial Information Integration, vol. 10, pp. 1 – 9, 2018. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S2452414X18300037

74
[7] P. Ray, “A survey on internet of things architectures,” Journal of King
Saud University - Computer and Information Sciences, vol. 30, no. 3, pp.
291 – 319, 2018. [Online]. Available: http://www.sciencedirect.com/science/
article/pii/S1319157816300799

[8] A. Nakao and P. Du, “Application and device specific slicing for mvno,” in
2014 International Science and Technology Conference (Modern Networking
Technologies) (MoNeTeC), Oct 2014, pp. 1–5, slicing Mechanism.

[9] T. Shimojo, Y. Takano, A. Khan, S. Kaptchouang, M. Tamura, and


S. Iwashina, “Future mobile core network for efficient service operation,” in
Proceedings of the 2015 1st IEEE Conference on Network Softwarization (Net-
Soft), April 2015, pp. 1–6, placement resilience technique.

[10] R. Mijumbi, J. Serrat, J. L. Gorricho, J. Rubio-Loyola, and S. Davy, “Server


placement and assignment in virtualized radio access networks,” in Network
and Service Management (CNSM), 2015 11th International Conference on,
Nov 2015, pp. 398–401.

[11] G. Lu, C. Liu, L. Li, and Q. Yuan, “A dynamic allocation algorithm for phys-
ical carrier resource in bbu pool of virtualized wireless network,” in Cyber-
Enabled Distributed Computing and Knowledge Discovery (CyberC), 2015 In-
ternational Conference on, Xi’an, China, Sept. 17-19, 2015, Sept 2015, pp.
434–441.

[12] R. Vilalta, A. Mayoral, R. Casellas, R. Martnez, and R. Muoz, “Experimen-


tal demonstration of distributed multi-tenant cloud/fog and heterogeneous
sdn/nfv orchestration for 5g services,” in 2016 European Conference on Net-
works and Communications (EuCNC), Athens, Greece, June 27-30, 2016, June
2016, pp. 52–56.

[13] T. Taleb, A. Ksentini, and B. Sericola, “On service resilience in cloud-native 5g


mobile systems,” IEEE Journal on Selected Areas in Communications, vol. 34,
no. 3, pp. 483–496, March 2016.

[14] J. P. Santos, R. Alheiro, L. Andrade, . L. Valdivieso Caraguay, L. I.


Barona Lpez, M. A. Sotelo Monge, L. J. Garcia Villalba, W. Jiang,

75
H. Schotten, J. M. Alcaraz-Calero, Q. Wang, and M. J. Barros, “SELFNET
Framework self-healing capabilities for 5G mobile networks,” Transactions on
Emerging Telecommunications Technologies, vol. 27, no. 9, pp. 1225–1232,
2016, ett.3049. [Online]. Available: http://dx.doi.org/10.1002/ett.3049

[15] Y. C. Hu, M. Patel, D. Sabella, N. Sprecher, and V. Young, “Etsi white paper
no. 11, mobile edge computinga key technology towards 5g,” ETSI, Sophia
Antipolis CEDEX, France, Tech. Rep. 11, 2015.

[16] R. Vilalta, A. Mayoral, R. Casellas, R. Martı́nez, and R. Muñoz, “Sdn/nfv


orchestration of multi-technology and multi-domain networks in cloud/fog
architectures for 5g services,” in 21st Optoelectronics and Communications
Conference / International Conference on Photonics in Switching 2016,
Niigata, Japan, July 3-7, 2016, 2016. [Online]. Available: http://5g-crosshaul.
eu/wp-content/uploads/2015/05/OECC PS 2016 invited vilalta.pdf

[17] H. Droste, P. Rost, M. Doll, I. Berberana, C. Mannweiler, M. Breitbach,


A. Banchs, and M. A. Puente, “An adaptive 5g multiservice and
multitenant radio access network architecture,” Transactions on Emerging
Telecommunications Technologies, vol. 27, no. 9, pp. 1262–1270, 2016,
ett.3087 placement resilience technique. [Online]. Available: http://dx.doi.
org/10.1002/ett.3087

[18] S. Abdelwahab, B. Hamdaoui, M. Guizani, and T. Znati, “Network function


virtualization in 5g,” IEEE Communications Magazine, vol. 54, no. 4, pp.
84–91, April 2016.

[19] IMT Vision Framework and overall objectives of the future development of
IMT for 2020 and beyond, RECOMMENDATION ITU-R M.2083-0 Std., Sep.
2015.

[20] I. Cerrato, A. Palesandro, F. Risso, M. Su, V. Vercellone, and


H. Woesner, “Toward dynamic virtualized network services in telecom
operator networks,” Computer Networks, vol. 92, pp. 380 – 395,
2015, software Defined Networks and Virtualization. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S1389128615003485

76
[21] J. Costa-Requena, J. L. Santos, V. F. Guasch, K. Ahokas, G. Premsankar,
S. Luukkainen, O. L. Prez, M. U. Itzazelaia, I. Ahmad, M. Liyanage, M. Yliant-
tila, and E. M. de Oca, “Sdn and nfv integration in generalized mobile network
architecture,” in Networks and Communications (EuCNC), 2015 European
Conference on, Paris, France, June 29- July 2, 2015, June 2015, pp. 154–158.

[22] I. F. Akyildiz, S. Nie, S.-C. Lin, and M. Chandrasekaran, “5g


roadmap: 10 key enabling technologies,” Computer Networks, vol. 106,
no. Supplement C, pp. 17 – 48, September 2016. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S1389128616301918

[23] V. G. Nguyen, A. Brunstrom, K. J. Grinnemo, and J. Taheri, “Sdn/nfv-based


mobile packet core network architectures: A survey,” IEEE Communications
Surveys Tutorials, vol. 19, no. 3, pp. 1567–1602, thirdquarter 2017.

[24] R. Mijumbi, J. Serrat, J. L. Gorricho, N. Bouten, F. D. Turck, and


R. Boutaba, “Network function virtualization: State-of-the-art and research
challenges,” IEEE Communications Surveys Tutorials, vol. 18, no. 1, pp. 236–
262, Firstquarter 2016.

[25] S. Boucadair, D. Lopez, I. Telefonica, D. Guichard, and C. Pignataro,


“Service function chaining: Framework & architecture draft-boucadair-
sfc-framework-00,” IETF, Tech. Rep., 2014. [Online]. Available: https:
//tools.ietf.org/html/draft-merged-sfc-architecture-00

[26] B. Yi, X. Wang, K. Li, S. k. Das, and M. Huang, “A comprehensive survey of


network function virtualization,” Computer Networks, vol. 133, pp. 212 – 262,
2018. [Online]. Available: http://www.sciencedirect.com/science/article/pii/
S1389128618300306

[27] ETSI NFV ISG, “GS NFV-MAN 001 V1.1.1 Network Functions Virtualisation
(NFV); Management and Orchestration,” European Telecommunications
Standards Institute, Cedex - FRANCE, Tech. Rep., 2014. [Online].
Available: http://www.etsi.org/deliver/etsi gs/NFV-MAN/001 099/001/01.
01.01 60/gs NFV-MAN001v010101p.pdf

77
[28] ETSI NFV ISG, “GS NFV 002 V1.1.1 Network Functions Virtuali-
sation (NFV); Architectural Framework,” European Telecommunications
Standards Institute, Cedex - FRANCE, Tech. Rep., oct 2013. [On-
line]. Available: http://www.etsi.org/deliver/etsi gs/nfv/001 099/002/01.01.
01 60/gs nfv002v010101p.pdf

[29] ETSI NFV ISG, “GS NFV-REL 001 V1.1.1 Network Functions Virtu-
alisation (NFV); Resiliency Requirements,” European Telecommunication
Standards Institute, Cedex - FRANCE, Tech. Rep., 2015. [Online].
Available: http://www.etsi.org/deliver/etsi gs/NFV-REL/001 099/001/01.
01.01 60/gs NFV-REL001v010101p.pdf

[30] ETSI NFV ISG, “GS NFV-REL 003 V1.1.2 Network Functions Vir-
tualisation (NFV); Reliability; Report on Models and Features for
End-to-End Reliability Disclaimer,” European Telecommunication Stan-
dards Institute, Cedex - FRANCE, Tech. Rep., jul 2016. [Online].
Available: http://www.etsi.org/deliver/etsi gs/NFV-REL/001 099/003/01.
01.02 60/gs nfv-rel003v010102p.pdf

[31] R. Mijumbi, J. Serrat, J. l. Gorricho, S. Latre, M. Charalambides, and


D. Lopez, “Management and orchestration challenges in network functions
virtualization,” IEEE Communications Magazine, vol. 54, no. 1, pp. 98–105,
January 2016.

[32] ETSI NFV ISG, “ETSI GS NFV-IFA 009 V1.1.1 Network Functions
Virtualisation (NFV); Management and Orchestration; Report on Archi-
tectural Options,” European Telecommunication Standards Institute, Cedex
- FRANCE, Tech. Rep. DGS/NFV-IFA009, jul 2016. [Online]. Avail-
able: https://www.etsi.org/deliver/etsi gs/nfv-ifa/001 099/009/01.01.01 60/
gs nfv-ifa009v010101p.pdf

[33] M. Abu-Lebdeh, S. Yangui, D. Naboulsi, R. H. Glitho, and C. W. Tchouati,


“A virtual network paas for 3gpp 4g and beyond core network services,”
in Cloud Networking (IEEE CloudNet 2016), 2016 5th IEEE International

78
Conference on, Pisa, Italy, Oct. 3-5, 2016, 2016, check this later. it was
preprint. [Online]. Available: https://arxiv.org/pdf/1608.05869v2.pdf

[34] ETSI NFV ISG, “ETSI GS NFV-EVE 003 V1.1.1 Network Functions Virtu-
alisation (NFV); Ecosystem; Report on NFVI Node Physical Architecture
Guidelines for Multi-Vendor Environment,” European Telecommunication
Standards Institute, Cedex - FRANCE, Tech. Rep. DGS/NFV-EVE003, jan
2016, nFVI specifications. [Online]. Available: https://www.etsi.org/deliver/
etsi gs/NFV-EVE/001 099/003/01.01.01 60/gs nfv-eve003v010101p.pdf

[35] G. Parulkar, “CORD: Central Office Re-architected as a Datacenter,” in 2nd


IEEE Conference on Network Softwarization (NetSoft 2016), vol. 29, Seoul,
Korea, June 6-10, 2016.

[36] M. Yoshida, W. Shen, T. Kawabata, K. Minato, and W. Imajuku, “Morsa: A


multi-objective resource scheduling algorithm for nfv infrastructure,” in Net-
work Operations and Management Symposium (APNOMS), 2014 16th Asia-
Pacific, Sept 2014, pp. 1–6.

[37] D. Kreutz, F. M. V. Ramos, P. E. Verssimo, C. E. Rothenberg, S. Azodol-


molky, and S. Uhlig, “Software-defined networking: A comprehensive survey,”
Proceedings of the IEEE, vol. 103, no. 1, pp. 14–76, Jan 2015.

[38] P. Schmitt, B. Landais, and F. Y. Yang, “Control and user plane separation
of epc nodes (cups), july 03,” 3rd Generation Partnership Project (3GPP),
Tech. Rep., 2017. [Online]. Available: http://www.3gpp.org/news-events/
3gpp-news/1882-cups

[39] M. R. Sama, X. An, Q. Wei, and S. Beker, “Reshaping the Mobile core net-
work via function decomposition and network slicing for the 5G era,” in 2016
IEEE Wireless Communications and Networking Conference Workshops (WC-
NCW), Doha, Qatar, April 3-4, 2016, April 2016, pp. 90–96.

[40] S. Sahhaf, W. Tavernier, D. Colle, and M. Pickavet, “Network service chaining


with efficient network function mapping based on service decompositions,”
in Proceedings of the 2015 1st IEEE Conference on Network Softwarization
(NetSoft), April 2015, pp. 1–5.

79
[41] J. Halpern and C. Pignataro, “Service function chaining (sfc) architecture;
draft-merged-sfc-architecture-00,” Internet Engineering Task Force (IETF),
Internet-Draft, July 3, 2014, 2014, july 3, 2014. [Online]. Available:
https://tools.ietf.org/html/draft-merged-sfc-architecture-00

[42] E. Amaldi, S. Coniglio, A. M. Koster, and M. Tieves, “On The Computational


Complexity of The Virtual Network Embedding Problem,” Electronic Notes
in Discrete Mathematics, vol. 52, pp. 213 – 220, 2016, {INOC} 2015
7th International Network Optimization Conference. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S1571065316300336

[43] W. Liu, H. Li, O. Huang, M. Boucadir, N. Leymann, Q. Fu, Q. Sun, C. Pham,


C. Huang, J. Zhu, and P. He, “Service Function Chaining (SFC) General Use
Cases,” Internet-Draft draft-liu-sfc-use-cases-08, Tech. Rep., 2014. [Online].
Available: https://tools.ietf.org/html/draft-liu-sfc-use-cases-08

[44] ETSI NFV ISG, “GS NFV 001 V1.1.1 Network Functions Virtualisation
(NFV); Use Cases,,” European Telecommunication Standards Institute, Cedex
- FRANCE, Tech. Rep., oct 2013. [Online]. Available: http://www.etsi.org/
deliver/etsi gs/nfv/001 099/001/01.01.01 60\/gs nfv001v010101p.pdf

[45] A. Khan, X. An, and S. Iwashina, “Virtual Network Embedding for


Telco-Grade Network Protection and Service Availability,” Computer Com-
munications, vol. 84, no. 15 June 2016, pp. 25 – 38, 2016. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S0140366416300858

[46] S. Sahhaf, W. Tavernier, M. Rost, S. Schmid, D. Colle, M. Pickavet,


and P. Demeester, “Network Service Chaining with Optimized Network
Function Embedding Supporting Service Decompositions,” Computer
Networks, vol. 93, Part 3, pp. 492 – 505, 2015, cloud Networking and
Communications {II} vnf-cc, vnfs-cc, decomposition. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S138912861500359X

[47] B. Yi, X. Wang, and M. Huang, “Design and evaluation of schemes


for provisioning service function chain with function scalability,” Journal
of Network and Computer Applications, vol. 93, pp. 197 – 214,

80
2017. [Online]. Available: http://www.sciencedirect.com/science/article/pii/
S1084804517302102

[48] C. Ghribi, M. Mechtri, O. Soualah, and D. Zeghlache, “Sfc provisioning over


nfv enabled clouds,” in 2017 IEEE 10th International Conference on Cloud
Computing (CLOUD), June 2017, pp. 423–430.

[49] OPNFV, “OPNFV high availability (HA) requirement,” OPNFV, 2015.


[Online]. Available: https://privatewiki.opnfv.org/ media/ha requirement.
pdf

[50] S. Haeri and L. Trajkovi, “Virtual network embedding via monte carlo tree
search,” IEEE Transactions on Cybernetics, vol. PP, no. 99, pp. 1–12, Febru-
ary 2017.

[51] T. Truong-Huu and M. Gurusamy, “Markov chain based algorithm for virtual
network embedding in optical data centers,” in 2016 IEEE 18th International
Conference on High Performance Computing and Communications; IEEE 14th
International Conference on Smart City; IEEE 2nd International Conference
on Data Science and Systems (HPCC/SmartCity/DSS), Sydney, Australia,
Dec 2016, pp. 899–906, 12-14 December.

[52] L. Nonde, T. E. H. Elgorashi, and J. M. H. Elmirgahni, “Virtual network


embedding employing renewable energy sources,” in 2016 IEEE Global Com-
munications Conference (GLOBECOM), Washington, DC USA, Dec 2016, pp.
1–6, 4 8 December 2016.

[53] Y. Li, Y. Li, M. Shu, J. Tang, and Y. Peng, “An efficient vne algorithm via
preferentially mapping important nodes,” in 2016 IEEE 41st Conference on
Local Computer Networks Workshops (LCN Workshops), Dubai, United Arab
Emirates, Nov 2016, pp. 34–41, 7-10 November 2016.

[54] A. Fischer, J. F. Botero, M. T. Beck, H. de Meer, and X. Hesselbach, “Virtual


network embedding: A survey,” IEEE Communications Surveys Tutorials,
vol. 15, no. 4, pp. 1888–1906, Fourth 2013.

81
[55] F. Bari, S. R. Chowdhury, R. Ahmed, R. Boutaba, and O. C. M. B. Duarte,
“Orchestrating virtualized network functions,” IEEE Transactions on Network
and Service Management, vol. 13, no. 4, pp. 725–739, Dec 2016.

[56] M. C. Luizelli, L. R. Bays, L. S. Buriol, M. P. Barcellos, and L. P. Gaspary,


“Piecing together the nfv provisioning puzzle: Efficient placement and chain-
ing of virtual network functions,” in 2015 IFIP/IEEE International Sympo-
sium on Integrated Network Management (IM), Ottawa, Canada, May 2015,
pp. 98–106, may 11-15, 2015.

[57] L. Qu, C. Assi, and K. Shaban, “Network function virtualization scheduling


with transmission delay optimization,” in NOMS 2016 - 2016 IEEE/IFIP
Network Operations and Management Symposium, Istanbul, Turkey, Apr. 25-
29, 2016, April 2016, pp. 638–644.

[58] R. Riggio, A. Bradai, D. Harutyunyan, T. Rasheed, and T. Ahmed, “Schedul-


ing wireless virtual networks functions,” IEEE Transactions on Network and
Service Management, vol. 13, no. 2, pp. 240–252, June 2016.

[59] M. T. Beck and J. F. Botero, “Scalable and coordinated allocation of service


function chains,” Computer Communications, vol. 102, no. Supplement C, pp.
78 – 88, 2017. [Online]. Available: http://www.sciencedirect.com/science/
article/pii/S0140366416303577

[60] M. M. A. Khan, N. Shahriar, R. Ahmed, and R. Boutaba, “Multi-path link


embedding for survivability in virtual networks,” IEEE Transactions on Net-
work and Service Management, vol. 13, no. 2, pp. 253–266, June 2016.

[61] C. Pham, N. H. Tran, S. Ren, W. Saad, and C. S. Hong, “Traffic-aware and


energy-efficient vnf placement for service chaining: Joint sampling and match-
ing approach,” IEEE Transactions on Services Computing, vol. PP, no. 99, pp.
1–1, 2017.

[62] H. Moens and F. D. Turck, “Customizable Function Chains: Managing Service


Chain Variability in Hybrid NFV Networks,” IEEE Transactions on Network
and Service Management, vol. 13, no. 4, pp. 711–724, Dec 2016, date of Pub-
lication: 14 June 2016.

82
[63] V. Eramo, E. Miucci, M. Ammar, and F. G. Lavacca, “An approach for ser-
vice function chain routing and virtual function network instance migration in
network function virtualization architectures,” IEEE/ACM Transactions on
Networking, vol. 25, no. 4, pp. 2008–2025, Aug 2017.

[64] E. J. Scheid, C. C. Machado, R. L. dos Santos, A. E. Schaeffer-Filho, and


L. Z. Granville, “Policy-based dynamic service chaining in network functions
virtualization,” in 2016 IEEE Symposium on Computers and Communication
(ISCC). Messina, Italy, June 27-30, 2016: IEEE, June 2016, pp. 340–345.

[65] M. Mechtri, C. Ghribi, and D. Zeghlache, “A scalable algorithm for the place-
ment of service function chains,” IEEE Transactions on Network and Service
Management, vol. PP, no. 99, pp. 1–1, 2016, 03 August 2016.

[66] A. Khan, X. An, D. Perez-Caparros, and W. Kiess, “Virtual network embed-


ding algorithm for one-to-one site protection,” in 2013 IEEE Global Commu-
nications Conference (GLOBECOM), Dec 2013, pp. 1278–1284.

[67] F. L. Pires and B. Barn, “A virtual machine placement taxonomy,” in Cluster,


Cloud and Grid Computing (CCGrid), 2015 15th IEEE/ACM International
Symposium on. Shenzhen, China, May 4-7, 2015: IEEE, May 2015, pp.
159–168, date Added to IEEE Xplore: 09 July 2015.

[68] H. Moens and F. D. Turck, “Vnf-p: A model for efficient placement of virtu-
alized network functions,” in 10th International Conference on Network and
Service Management (CNSM) and Workshop, Nov 2014, pp. 418–423.

[69] X. Li and C. Qian, “A survey of network function placement,” in 2016 13th


IEEE Annual Consumer Communications Networking Conference (CCNC),
Jan 2016, pp. 948–953.

[70] L. Qu, C. Assi, and K. Shaban, “Delay-aware scheduling and resource opti-
mization with network function virtualization,” IEEE Transactions on Com-
munications, vol. PP, no. 99, pp. 1–1, 2016.

[71] R. Mijumbi, J. Serrat, J. L. Gorricho, N. Bouten, F. D. Turck, and S. Davy,


“Design and evaluation of algorithms for mapping and scheduling of virtual

83
network functions,” in Network Softwarization (NetSoft), 2015 1st IEEE Con-
ference on, London, UK, April 2015, pp. 1–9, 13-17 April 2015.

[72] J. G. Herrera and J. F. Botero, “Resource Allocation in NFV: A Compre-


hensive Survey,” IEEE Transactions on Network and Service Management,
vol. PP, no. 99, pp. 518 – 532, 2016, 05 August 2016.

[73] L. Wang, Z. Lu, X. Wen, R. Knopp, and R. Gupta, “Joint optimization of


service function chaining and resource allocation in network function virtual-
ization,” IEEE Access, vol. 4, pp. 8084–8094, 2016, 17 November 2016.

[74] J. Gil-Herrera and J. F. Botero, “A scalable metaheuristic for service func-


tion chain composition,” in 2017 IEEE 9th Latin-American Conference on
Communications (LATINCOM), Nov 2017, pp. 1–6.

[75] Y. Xie, Z. Liu, S. Wang, and Y. Wang, “Service function chaining resource
allocation: A survey,” eprint arXiv:1608.00095, jul 2016. [Online]. Available:
http://arxiv.org/pdf/1608.00095v1

[76] M. A. T. Nejad, S. Parsaeefard, M. A. Maddah-Ali, T. Mahmoodi, and B. H.


Khalaj, “vspace: Vnf simultaneous placement, admission control and embed-
ding,” IEEE Journal on Selected Areas in Communications, vol. 36, no. 3, pp.
542–557, March 2018.

[77] M. Gao, B. Addis, M. Bouet, and S. Secci, “Optimal orchestration of


virtual network functions,” Computer Networks, vol. 142, pp. 108 – 127,
2018. [Online]. Available: http://www.sciencedirect.com/science/article/pii/
S1389128618303578

[78] I. Fajjari, N. Aitsaadi, B. Dab, and G. Pujolle, “Novel adaptive virtual


network embedding algorithm for clouds private backbone network,”
Computer Communications, vol. 84, pp. 12 – 24, 2016. [Online]. Available:
http://www.sciencedirect.com/science/article/pii/S0140366416300871

[79] N. Bouten, M. Claeys, R. Mijumbi, J. Famaey, S. Latr, and J. Serrat, “Se-


mantic validation of affinity constrained service function chain requests,” in

84
2016 IEEE NetSoft Conference and Workshops (NetSoft). Seoul, Korea, June
6-10, 2016: IEEE, June 2016, pp. 202–210.

[80] X. Li and C. Qian, “An nfv orchestration framework for interference-free pol-
icy enforcement,” in 2016 IEEE 36th International Conference on Distributed
Computing Systems (ICDCS). Nara, Japan, June 27-30, 2016: IEEE, June
2016, pp. 649–658.

[81] S. Mehraghdam and H. Karl, “Placement of services with flexible structures


specified by a YANG data model,” in 2016 IEEE NetSoft Conference and
Workshops (NetSoft), Seoul, Korea, June 6-10, 2016, June 2016, pp. 184–192.

[82] T-NOVA Project, “Network Functions as-a-Service over Virtualised In-


frastructures; Service Mapping,” T-NOVA project, Community Re-
search and Development Information Services, European Commission,
Coordinated in Greece, Tech. Rep. Deliverable D3.3, Jan. 2016.
[Online]. Available: http://www.t-nova.eu/wp-content/uploads/2016/02/
Deliverable 3.3 Service Mapping v1.0.pdf

[83] M. Otokura, “An evolvable approach for the virtual network function place-
ment problem in varying environments,” Master’s thesis, Information Science
and Technology, Osaka University, feb 2016.

[84] M. F. Bari, S. R. Chowdhury, R. Ahmed, and R. Boutaba, “On orchestrating


virtual network functions,” in Network and Service Management (CNSM),
2015 11th International Conference on, Nov 2015, pp. 50–56.

[85] M. Bouet, J. Leguay, T. Combe, and V. Conan, “Cost-based placement


of vdpi functions in nfv infrastructures,” International Journal of Network
Management, vol. 25, no. 6, pp. 490–506, 2015. [Online]. Available:
http://dx.doi.org/10.1002/nem.1920

[86] T. Wen, H. Yu, G. Sun, and L. Liu, “Network function consolidation in service
function chaining orchestration,” in 2016 IEEE International Conference on
Communications (ICC), May 2016, pp. 1–6.

85
[87] R. Mijumbi, J. L. Gorricho, J. Serrat, M. Claeys, F. D. Turck, and S. Latr,
“Design and evaluation of learning algorithms for dynamic resource manage-
ment in virtual networks,” in 2014 IEEE Network Operations and Management
Symposium (NOMS), May 2014, pp. 1–9.

[88] T. Lin, Z. Zhou, M. Tornatore, and B. Mukherjee, “Demand-aware network


function placement,” J. Lightwave Technol., vol. 34, no. 11, pp. 2590–2600, Jun
2016. [Online]. Available: http://jlt.osa.org/abstract.cfm?URI=jlt-34-11-2590

[89] D. Li, P. Hong, K. Xue, and j. Pei, “Virtual network function placement
considering resource optimization and sfc requests in cloud datacenter,” IEEE
Transactions on Parallel and Distributed Systems, vol. 29, no. 7, pp. 1664–
1677, July 2018.

[90] T.-W. Um, H. Lee, W. Ryu, and J. K. Choi, “Dynamic resource allocation and
scheduling for cloud-based virtual content delivery networks,” ETRI Journal,
vol. 36, no. 2, Apr. 2014.

[91] J. Fontenla-Gonzlez, C. Prez-Garrido, F. Gil-Castieira, F. J. Gonzlez-Castao,


and C. Giraldo-Rodriguez, “Lightweight container-based openepc deployment
and its evaluation,” in 2016 IEEE NetSoft Conference and Workshops (Net-
Soft). Seoul, Korea, June 6-10, 2016: IEEE, June 2016, pp. 435–440.

[92] A. Hmaity, M. Savi, F. Musumeci, M. Tornatore, and A. Pattavina, “Vir-


tual Network Function Placement for Resilient Service Chain provisioning,”
in 2016 8th International Workshop on Resilient Networks Design and Mod-
eling (RNDM), Halmstad, Sweden, Sept 2016, pp. 245–252, 13-15 Sept. 2016.

[93] T. Taleb, M. Bagaa, and A. Ksentini, “User Mobility-Aware Virtual Network


Function placement for Virtual 5G Network Infrastructure,” in 2015 IEEE
International Conference on Communications (ICC), June 2015, pp. 3879–
3884.

[94] T. Taleb, M. Corici, C. Parada, A. Jamakovic, S. Ruffino, G. Karagiannis, and


T. Magedanz, “Ease: Epc as a service to ease mobile core network deployment
over cloud,” IEEE Network, vol. 29, no. 2, pp. 78–88, March 2015.

86
[95] Y. Oda, Y. Tanigawa, and H. Tode, “Distributed search for ordered vnfs config-
uring service chaining based on in-network guidance,” in 2018 15th IEEE An-
nual Consumer Communications Networking Conference (CCNC), Jan 2018,
pp. 1–4.

[96] T.-W. Kuo, B.-H. Liou, K. C.-J. Lin, and M.-J. Tsai, “Deploying chains of
virtual network functions: On the relation between link and server usage,”
IEEE/ACM Trans. Netw., vol. 26, no. 4, pp. 1562–1576, Aug. 2018. [Online].
Available: https://doi.org/10.1109/TNET.2018.2842798

[97] M. C. Luizelli, W. L. da Costa Cordeiro, L. S. Buriol, and L. P. Gaspary,


“A fix-and-optimize approach for efficient and large scale virtual network
function placement and chaining,” Computer Communications, vol. 102, pp.
67 – 77, 2017. [Online]. Available: http://www.sciencedirect.com/science/
article/pii/S0140366416305485

[98] D. Oliveira, J. Crichigno, N. Siasi, E. Bou-Harb, and N. Ghani, “Joint map-


ping and routing of virtual network functions for improved disaster recovery
support,” in SoutheastCon 2018, April 2018, pp. 1–8.

[99] Z. Allybokus, N. Perrot, J. Leguay, L. Maggi, and E. Gourdin, “Virtual


function placement for service chaining with partial orders and anti-affinity
rules,” Networks, vol. 71, no. 2, pp. 97–106, 2018. [Online]. Available:
https://onlinelibrary.wiley.com/doi/abs/10.1002/net.21768

[100] A. Gupta, M. F. Habib, U. Mandal, P. Chowdhury, M. Tornatore,


and B. Mukherjee, “On service-chaining strategies using virtual network
functions in operator networks,” Computer Networks, vol. 133, pp. 1 – 16,
2018. [Online]. Available: http://www.sciencedirect.com/science/article/pii/
S1389128618300379

[101] M. Yu, Y. Yi, J. Rexford, and M. Chiang, “Rethinking virtual network


embedding: Substrate support for path splitting and migration,” SIGCOMM
Comput. Commun. Rev., vol. 38, no. 2, pp. 17–29, Mar. 2008. [Online].
Available: http://doi.acm.org/10.1145/1355734.1355737

87
[102] M. Chowdhury, M. R. Rahman, and R. Boutaba, “Vineyard: Virtual
network embedding algorithms with coordinated node and link mapping,”
IEEE/ACM Trans. Netw., vol. 20, no. 1, pp. 206–219, Feb. 2012. [Online].
Available: http://dx.doi.org/10.1109/TNET.2011.2159308

88
Appendices

89
Appendix A

Additional Results

This appendix shows the results of long run of the following scenarios.

• Figure (A.1) shows the results of measured metrics on small physical network
(BT Europe) for all requests with five paths.

• Figure (A.2) shows the results of measured metrics on large physical network
(Interoute) for all requests with five paths.

• Figure (A.3) shows the results of measured metrics on small physical network
(BT Europe) for all requests with ten paths.

• Figure (A.4) shows the results of measured metrics on large physical network
(Interoute) for all requests with ten paths.

• Figure (A.5) shows the results of measured metrics on small physical network
(BT Europe) for all requests with twenty paths.

• Figure (A.6) shows the results of measured metrics on large physical network
(Interoute) for all requests with twenty paths.

90
Execution Time
5 2.5
ILP-A ILP-P
Execution Time, s
4 ILP-P 2.0 DSBM

Execution Time, s
DSBM DcPSM
3 DcPSM 1.5
2 1.0
1 0.5
0 0.0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Small physical network (b) Small with 25% additional edges
Acceptance ratio
1.0 1.0
0.8 0.8
Acceptance ratio

Acceptance ratio
0.6 0.6
0.4 ILP-A 0.4
ILP-P ILP-P
0.2 DSBM 0.2 DSBM
DcPSM DcPSM
0.0 0.0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Small physical network (b) Small with 25% additional edges
Embedding cost
1200 1200 ILP-P
1000 1000 DSBM
ILP-A DcPSM
800 800
Avg. cost

Avg. cost

ILP-P
600 DSBM 600
DcPSM
400 400
200 200
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Small physical network (b) Small with 25% additional edges
Embedding cost to revenue
2.5 2.5
ILP-P
Avg. cost/avg. revenue
Avg. cost/avg. revenue

2.0 2.0 DSBM


ILP-A DcPSM
1.5 ILP-P 1.5
DSBM
1.0 DcPSM 1.0
0.5 0.5
0.0 0.0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Small physical network (b) Small with 25% additional edges

Figure A.1: Long run results for requests with 5 paths on (a) Small physical network
and (b) Small physical network with 25% additional edges. The shaded background
behind each curve represents the 95% confidence interval on the reported average
91
values.
Execution Time
4 4
ILP-P ILP-P
Execution Time, s
DSBM DSBM

Execution Time, s
3 DcPSM 3 DcPSM
2 2

1 1

0 0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Large physical network (b) Large with 25% additional edges
Acceptance ratio
1.0 1.0
0.8 0.8
Acceptance ratio

Acceptance ratio
0.6 0.6
0.4 0.4
ILP-P ILP-P
0.2 DSBM 0.2 DSBM
DcPSM DcPSM
0.0 0.0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Large physical network (b) Large with 25% additional edges
Embedding cost
1500 1500
ILP-P ILP-P
1250 DSBM 1250 DSBM
DcPSM DcPSM
1000 1000
Avg. cost

Avg. cost

750 750
500 500
250 250
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Large physical network (b) Large with 25% additional edges
Embedding cost to revenue
2.5 2.5
ILP-P
Avg. cost/avg. revenue
Avg. cost/avg. revenue

2.0 2.0 DSBM


DcPSM
1.5 ILP-P 1.5
DSBM
1.0 DcPSM 1.0
0.5 0.5
0.0 0.0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Large physical network (b) Large with 25% additional edges

Figure A.2: Long run results for requests with 5 paths on (a) Large physical network
and (b) Large physical network with 25% additional edges. The shaded background
behind each curve represents the 95% confidence interval on the reported average
92
values.
Execution Time
10 5
ILP-A ILP-P
8 ILP-P 4 DSBM
Execution Time, s

Execution Time, s
DSBM DcPSM
6 DcPSM 3
4 2
2 1
0 0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Small physical network (b) Small with 25% additional edges
Acceptance ratio
1.0 1.0
ILP-P
0.8 0.8 DSBM
Acceptance ratio

Acceptance ratio
DcPSM
0.6 0.6
0.4 ILP-A 0.4
ILP-P
0.2 DSBM 0.2
DcPSM
0.0 0.0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Small physical network (b) Small with 25% additional edges
Embedding cost
2000 2000
ILP-A ILP-P
ILP-P DSBM
1500 DSBM 1500 DcPSM
Avg. cost

Avg. cost

DcPSM
1000 1000

500 500

0 5000 10000 15000 20000 0 5000 10000 15000 20000


Time, (time units) Time, (time units)

(a) Small physical network (b) Small with 25% additional edges
Embedding cost to revenue
1.50 2.0
ILP-A ILP-P
Avg. cost/avg. revenue
Avg. cost/avg. revenue

1.25 ILP-P DSBM


DSBM 1.5 DcPSM
1.00 DcPSM
0.75 1.0
0.50
0.5
0.25
0.00 0.0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Small physical network (b) Small with 25% additional edges

Figure A.3: Long run results for requests with 10 paths on (a) Small physical network
and (b) Small physical network with 25% additional edges. The shaded background
behind each curve represents the 95% confidence interval on the reported average
93
values.
Execution Time
10 5
ILP-P
8 DSBM 4
Execution Time, s

Execution Time, s
DcPSM
6 3 ILP-P
DSBM
4 2 DcPSM
2 1
0 0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Large physical network (b) Large with 25% additional edges
Acceptance ratio
1.0 1.0
ILP-P
0.8 0.8 DSBM
Acceptance ratio

Acceptance ratio
DcPSM
0.6 0.6
0.4 0.4
ILP-P
0.2 DSBM 0.2
DcPSM
0.0 0.0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Large physical network (b) Large with 25% additional edges
Embedding cost
2000 2000
ILP-P ILP-P
DSBM DSBM
1500 DcPSM 1500 DcPSM
Avg. cost

Avg. cost

1000 1000

500 500

0 5000 10000 15000 20000 0 5000 10000 15000 20000


Time, (time units) Time, (time units)

(a) Large physical network (b) Large with 25% additional edges
Embedding cost to revenue
1.50 2.0
ILP-P ILP-P
Avg. cost/avg. revenue
Avg. cost/avg. revenue

1.25 DSBM DSBM


DcPSM 1.5 DcPSM
1.00
0.75 1.0
0.50
0.5
0.25
0.00 0.0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Large physical network (b) Large with 25% additional edges

Figure A.4: Long run results for requests with 10 paths on (a) Large physical network
and (b) Large physical network with 25% additional edges. The shaded background
behind each curve represents the 95% confidence interval on the reported average
94
values.
Execution Time
15.0
10
12.5

Execution Time, s
Execution Time, s
8
10.0 ILP-A
ILP-P ILP-P
7.5 6 DSBM
DSBM DcPSM
5.0 DcPSM 4
2.5 2
0.0 0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Small physical network (b) Small with 25% additional edges
Acceptance ratio
1.0 1.0
ILP-P
0.8 0.8 DSBM
Acceptance ratio

Acceptance ratio
DcPSM
0.6 0.6
0.4 ILP-A 0.4
ILP-P
0.2 DSBM 0.2
DcPSM
0.0 0.0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Small physical network (b) Small with 25% additional edges
Embedding cost

2500 ILP-A 2500 ILP-P


ILP-P DSBM
2000 DSBM 2000 DcPSM
Avg. cost

Avg. cost

DcPSM
1500 1500
1000 1000
500 500

0 5000 10000 15000 20000 0 5000 10000 15000 20000


Time, (time units) Time, (time units)

(a) Small physical network (b) Small with 25% additional edges
Embedding cost to revenue
1.0 1.0
ILP-A ILP-P
Avg. cost/avg. revenue
Avg. cost/avg. revenue

0.8 ILP-P 0.8 DSBM


DSBM DcPSM
0.6 DcPSM 0.6
0.4 0.4
0.2 0.2
0.0 0.0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Small physical network (b) Small with 25% additional edges

Figure A.5: Long run results for requests with 20 paths on (a) Small physical network
and (b) Small physical network with 25% additional edges. The shaded background
behind each curve represents the 95% confidence interval on the reported average
95
values.
Execution Time
15.0 15.0
ILP-P
Execution Time, s 12.5 12.5 DSBM

Execution Time, s
10.0 10.0 DcPSM
ILP-P
7.5 DSBM 7.5
DcPSM
5.0 5.0
2.5 2.5
0.0 0.0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Large physical network (b) Large with 25% additional edges
Acceptance ratio
1.0 1.0
0.8 0.8
Acceptance ratio

Acceptance ratio
0.6 0.6
0.4 0.4
ILP-P ILP-P
0.2 DSBM 0.2 DSBM
DcPSM DcPSM
0.0 0.0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Large physical network (b) Large with 25% additional edges
Embedding cost

2500 ILP-P 2500 ILP-P


DSBM DSBM
2000 DcPSM 2000 DcPSM
Avg. cost

Avg. cost

1500 1500
1000 1000
500 500

0 5000 10000 15000 20000 0 5000 10000 15000 20000


Time, (time units) Time, (time units)

(a) Large physical network (b) Large with 25% additional edges
Embedding cost to revenue
1.0 1.0
ILP-P ILP-P
Avg. cost/avg. revenue
Avg. cost/avg. revenue

0.8 DSBM 0.8 DSBM


DcPSM DcPSM
0.6 0.6
0.4 0.4
0.2 0.2
0.0 0.0
0 5000 10000 15000 20000 0 5000 10000 15000 20000
Time, (time units) Time, (time units)

(a) Large physical network (b) Large with 25% additional edges

Figure A.6: Long run results for requests with 20 paths on (a) Large physical network
and (b) Large physical network with 25% additional edges. The shaded background
behind each curve represents the 95% confidence interval on the reported average
96
values.
‫الـمـلـخــص‬

‫اجتضضذبت وظيفضضة الشضضبكة ‬


‫االفرتاضضضية (‪ )NFV‬والشضضبكة املعرفضضة اب لرت جميضضات (‪ )SDN‬العديضضد من‬
‫واخليضضل ‪4‬‬ ‫مشغيل االتصاالت ‪4 7‬‬
‫اخلامس (‪.)5GG‬‬ ‫املوابيضضل للجيضضل الرابضضع (‪ )4GG‬‬
‫لنرشها ‪3‬يف البنية التحتية لشضضباكت ‬ ‫‪3‬‬
‫‪K‬‬ ‫‪K‬‬ ‫ً‬
‫كبرتة فضضإن اال حباث السضضابقة اوصضضت بتحليلهضضا إىل‬
‫لملوابيل ‪3‬‬
‫ونظرا إىل أن خدمات الشبكة التقليدية االساسية ‬
‫االفرتاضضضية (‪ )VNF‬لتهسيل ‪7‬نرشها مبرونضضة عيل‬ ‫صغرتة ليمت حبويلهضضا إىل سالسضضل من وظضضائف الشضضبكة ‬
‫وظائف ‪3‬‬
‫بيهنا عيل شضضلك ‪4‬جمطضضط‬ ‫كبرت من الوصضضالت الرابطضضة ‪4‬‬ ‫‪ .NFV‬وقد يؤدي هذا التحويل إىل عدد من ‪ VNF‬وعدد ‪3‬‬
‫االفرتاضضضية عيل ‪ NFV‬من املسضضائل‬ ‫وتعترت معلية توضيع الوظائف ‬ ‫شبكة متعددة الوصالت متعددة املسارات‪ .‬‬
‫ً‬ ‫‪K‬‬
‫اليت ثبت اب ‪4‬هنا من مسائل ‪ .NP-hard‬امك تعتض ضرت معليضضة توضضضيع سالسضضل الوظضضائف أكض ‪7‬ضرت تعقيضضدا وتعضضرف‬
‫‬
‫املعقدة ‪3‬‬
‫االفرتاضضضضضية (‪ .)NFV-RA problem‬هضضذه الدراسضضة تقضضدم ‪4‬هنج‬ ‫ضلكة  ‪4‬حبصضضيص املوارد عيل شضضبكة الوظيفضضة ‬
‫مبشض ‬

‫اخلدمات (‪ )NSC‬عيل بيئضضة‬ ‫ضلكة وضضضع سالسضضل شضضباكت ‪4‬‬ ‫جديد يسىم رمس املسار(‪ )Path Mapping‬خلل مشض ‬
‫اخلطيضضة (‪ )ILP‬ومت حلهضضا بطر يقض ‪4 3‬‬
‫ضتني‪:‬‬ ‫االفرتاضضضية‪ .‬وقضضد صضيغت املشض ‬
‫ضلكة ابسضضتخدمام الرت جمة العدديضضة ‪4‬‬ ‫‪ NFV‬‬
‫ِ‬
‫يض الضضضدقيق (‪ )Exact Scheme‬وطريقضضضة الرت ‪4‬اب ›جم ‪¢‬االرشضضضادي اب ‪4‬خلوارزميضضضة (‪Heuristic‬‬ ‫طريقضضضة الرت ‪4‬اب ›جم ‪4 3‬‬
‫الراب ‪3‬‬
‫‪ .)Scheme‬ومت إثبضضات حصة وكفضضاءة ‪4‬الهنج املقضضدم ‪3 4‬يف هضضذه الدراسضضة ابسضضتخدام احملا اكة لعضضدد ( ‪ )22‬سضضيناريو‪.‬‬
‫املعاخلة وتاكليف توضيع ‪4‬‬ ‫‪K‬‬ ‫‪K‬‬ ‫‪4‬‬
‫اخلدمات‪.‬‬ ‫‬ ‫نتاجئ احملا اكة ابن ‪4‬الهنج املقدم خفض بشلك كفؤ زمن‬
‫وأهظرت ›‬
‫الجمهورية اليمنية‬
‫وزارة التعليم العالي والبحث العلمي‬
‫جامعة العلوم الحديثة‬
‫عمادة الدراسات العليا‬
‫برنامج تقنية معلومات‬

‫نهج كفؤ لتموضع خدمات المحمول‬


‫األساسية على وظيفة الشبكة االفتراضية‬
‫رسالة مقدمة إلى جامعة العلوم الحديثة – عمادة الدراسات العليا كمتطلب جزئي لنيل‬
‫درجة الماجستير تخصص تقنية معلومات‬

‫من الطالب‬
‫بشير أمين رضوان‬

‫المشرف‬
‫أستاذ دكتور خليل سعيد الوجيه‬

‫جمادى أول ‪ 1440‬ه – يناير ‪ 2019‬م‬

You might also like